I usually implement a 2-BYTE SYNC header in my data packet that never changes.... i.e $FF and $AD .... The receiver looks for $FF and doesn't process any other bytes until $FF is received.
I was thinking of reserving two bits from the addresses (since I'll be using less than 64) as the sync bytes, but I suppose two full bytes are more robust? Ok. I'll now say my first 2 bytes are FF and AD then. I might decide later to do AA and 55 since that means alternating 1's and 0's in binary.
I also implement a SEED that can be random but a simple incremental rollover byte is sufficient.
Hmm... I thought it'd be more economical to store such seed in all devices in the same network rather than transmitting it. With the fletcher checksum I used before, I could start the number with any common seed (typically 0). If it is more economical transmitting the seed every time, I'm curious to know why.
So my packet may look something like this ...
Simple 6-BYTE data packet...
$FF : $AD : SEED : ADDRESS : DATA : CRC
Well Ideally I'd like 3 bytes for raw data and 1 for command because I could be passing a number that's in the million range, and that would require 24 bits.
So If I use 1 byte CRC then I'm thinking:
FFh ADh Address Address/Command Data Data Data CRC
where the 4th byte is split between address and command. Then in total I'd have 6 bits for sender, 6 bits for receiver, and 4 bits for command. Could I still get decent data integrity if I used only halves of the first two bytes for syncing and the remaining halves for command so format will be:
Byte 1:
Bits 1-4: sync nibble 1
Bits 5-8: command nibble 1
Bits 9-12: sync nibble 2
Bits 13-16: command nibble 2
Byte 2: Sender
Byte 3: Receiver
Bytes 4 to 7: Data
Byte 8: CRC
CRC(calculated) = $FF ^ $AD ^ SEED ^ ADDRESS ^ DATA + CRC (received)
For this math, you xor'ed every byte but the CRC byte and then you added the CRC byte again to get the CRC to transmit?
If you have bidirectional capabilities, then proper handshaking would send a re-transmit request if the received CRC did not match the calculated CRC value. Otherwise you just have to send the data multiple times hoping that the receiver got the data intact.
I do but I don't have full-duplex capabilities.
If the CRC matches, then and only then the DATA is written to the ADDRESS
Ok, this part I got figured out. Its just the rest of it as explained above I need more elaboration on because I want to be able to send at least 3 bytes of raw parametric data and 1 byte of command to any address (from 0 to 63).