XOR in C (PICC-18)

[NJ Roadmap]

Just checking this:

If I've got two chars char1 (0b00001111) and char2 (0b11111111), when I set another char char3 = char1^char2, the value of char3 will be 0b11110000?

I'm not at home where I can check this on a compiler but I just had a thought for an error-checking code for RF comms..i.e. send one byte followed by its inverted value. This would allow errors to be checked as well as detected.

 

[3v0]

...but I just had a thought for an error-checking code for RF

comms ..i.e. send one byte followed by its inverted value. This would allow errors to be checked as well as detected.​

​

That would work but since you do not know which byte is wrong, it is only good for error detection. A lot has been written about error detection and correction.

Without any idea of what you are attempting to do I will stop here.

 

[Papabravo]

Just checking this:

If I've got two chars char1 (0b00001111) and char2 (0b11111111), when I set another char char3 = char1^char2, the value of char3 will be 0b11110000?

I'm not at home where I can check this on a compiler but I just had a thought for an error-checking code for RF comms..i.e. send one byte followed by its inverted value. This would allow errors to be checked as well as detected.

Well you must have bandwidth to burn if you are willing to cut your throughput in half for very little gain. There are many better schemes that you can use to detect and correct errors. Google for Cyclic Redundancy Codes(CRC) for example. In many contexts it is cheaper to retransmit a block or a packet than it is to run an error correction algorithm. It's strictly a cost benefit analysis.

 

[Sceadwian]

XOR'd data is redundant, but it's less redundant than sending the entire packet a second time completly. A good middle ground if the communication is only one way, or you're trying to minimize bandwidth during errors. With XOR'd data you actually have a chance to recover the packet without asking for a retransmit, which adds latency to data reception.

 

[3v0]

XOR'd data is redundant, but it's less redundant than sending the entire packet a second time completly. A good middle ground if the communication is only one way, or you're trying to minimize bandwidth during errors. With XOR'd data you actually have a chance to recover the packet without asking for a retransmit, which adds latency to data reception.

Unless you have a way bad channel XOR'ed data is way more redundant then resending bad packets. Esp with radio where error tend to happen in groups. Packet Radio should ring a bell.

You can not recover the data with XOR. IE:

Assume you send 1111 1111 followed by 0000 0000.
At the other end you read 1111 1111 followed by 0000 0001.
You have a 1 bit error.
What that bit should be?

NJ Roadmap did not provide enough info to determine what sort of error checking/correction would be best for his app. He is a regular visitor here. How about letting him provide a few more details instead of guessing.

 

[Papabravo]

XOR'd data is redundant, but it's less redundant than sending the entire packet a second time completly. A good middle ground if the communication is only one way, or you're trying to minimize bandwidth during errors. With XOR'd data you actually have a chance to recover the packet without asking for a retransmit, which adds latency to data reception.

My point was that if it takes more time to run the error correction algoritm than it does to retransmit a bad packet then you are better off using error detection and retransmission. It's not a matter of redundancy, but of the total time it takes to get a set of messages over a channel given an assumption about bit and frame error rates.

This is especially true for disk drives where the time frame for error correction is the rotation time of the platter. If a sector has an error then you can either correct the error or read the sector again when it comes around.

 

[NJ Roadmap]

Thanks for the comments so far. I'm not too bothered about error correction as its a simple poll-receive system with a repeat period of 5 seconds. The good thing is that the sensor's data being transmitted doesn't change within the repeat period of 5 seconds, so it's ok if error-correction can't be done since a correct packet can be received 5 seconds later.

Currently I'm detecting errors in the packet (same size on every transmit) by having some static bytes in the packet. If the byte at a certain location in the packet isn't equal to say an ASCII 'x', then the packet is discarded. I have 4 sensors and i've encapsulated the sensor data in static bytes, for example 'p1008p' where 1008 is the data a 'p' and 'p' are the static bytes. But any errors within the actual sensor data cannot actually be detected. Hence the reason for using XOR. The other option is obviously CRC, but I am yet to investigate how I would code it. I plan to do that tomorrow.

 

[3v0]

...The other option is obviously CRC, but I am yet to investigate how I would code it. I plan to do that tomorrow.

You do not need anything so fancy as a CRC for the data you described. I would use a simple check sum. When sending add all the bytes of a packet together and use that sum as the last byte. As the packet comes in sum all but the last byte, if the sum is not equal to the last byte reject the packet.

 

[Nigel Goodwin]

You do not need anything so fancy as a CRC for the data you described. I would use a simple check sum. When sending add all the bytes of a packet together and use that sum as the last byte. As the packet comes in sum all but the last byte, if the sum is not equal to the last byte reject the packet.

A CRC is a LOT more effective than a simple checksum though, and is simple to implement - as there are plenty of examples you can download.

 

[3v0]

A CRC is a LOT more effective than a simple checksum though, and is simple to implement - as there are plenty of examples you can download.

NIgel,

In general RF is a different beast then working over a wire. With a wire, bit errors are more or less randomly spaced. With RF, errors tend to come in clumps. Large chunks of packets are lost. These errors can not be recovered by a CRC because too much data is missing.

The checksum is much easier to debug. I only have hints regarding NJ Roadmap's experience level but I am guessing in this case KISS would be a good thing.

To some degree this is a shades of grey problem. But given the above I think the checksum is a better choice.

 

[Nigel Goodwin]

In general RF is a different beast then working over a wire. With a wire, bit errors are more or less randomly spaced. With RF, errors tend to come in clumps. Large chunks of packets are lost. These errors can not be recovered by a CRC because too much data is missing.

The checksum is much easier to debug. I only have hints regarding NJ Roadmap's experience level but I am guessing in this case KISS would be a good thing.

To some degree this is a shades of grey problem. But given the above I think the checksum is a better choice.

I wasn't referring to error correction, but to error DETECTION - a CRC is a good reliable method, a checksum is a really poor, unreliable method.

Years back I wrote my own packet radio software (using Turbo Pascal for DOS), if I recall correctly it used CRC - simple checksums had been abandoned many years before as useless for the purpose.

 

[3v0]

I have a weather station that also controls the heating and cooling in my greenhouse. It polls once a minute. It uses no error detection at the message level. The PC app linked to the controller/station rejects values that are out of range or too much changed from the last value (good thing to do even with error detection/correction). It is ugly, crude, and I am not proud of it, but it does the job.

Given where the OP was at with XOR and "fixed bytes", checksums would be a major improvement. In the odd event that an error got by the checksum it would only be active for 5 seconds. This is sensor data not packet radio.

But, NJ Roadmap may want to look for the CRC8 code used by Dallas 1 wire networks. A number of people have coded this up for the PIC.

 

[Nigel Goodwin]

But, NJ Roadmap may want to look for the CRC8 code used by Dallas 1 wire networks. A number of people have coded this up for the PIC.

There are LOT'S of CRC code for PIC's you can download, so it makes it pretty easy to use.