bitwise operations on concatenated ints

Hi,
I’m trying to implement an efficient RF data transfer protocol, but I’m a bit at a loss and would appreciate some help:

I want to transfer a number of ints, so a single package would look like that:

the first two bytes contain FF (all bits on) to signal a message start
the 3rd byte is a corrector (which will be explained later)
the 4th byte contains the number of integers in the message (N)
bytes 5 through N+4 contain the actual data (concatenated ints)
and the last two bytes contain FE (all bits on exept for the last) to signal a message end.
after creating the message, I check to see if its body (bytes 4 through N+4) contains FF or FE.
that would, obviously, be a problem, as it will confuse the receiver.
If it does contain FF or FE, I want to add 1 to each byte of the message’s body, and then add 1 to the corrector. I check again for FF/FE and repeat until the body does not contain either.
I will now send the message, and the receiver would do the following:
- stay idle until FF is received
- start recording until FE is received
- substract the number in the second byte (the corrector) from each byte of the message
- check if the message is as long as it should be (number of bytes equals the number in the first byte of the body*sizeof(int) + 2)
- split the data to itegers.

I’m having a really hard time understanding how I should implement the message creation:
I guess the easiest way would be to create an array of bytes and populate it with the message, then send it cell-by-cell. But then I’m not sure how to check if the concatenation of two bytes create an FF (e.g. if I send the integers 31, 224, I’m actually sending 0001111111100000, which contains FF)

Any ideas?
Thanks a lot!

Your protocol strikes me as unnecessarily complicated and deficient.

When designing an on-wire format there are some enduring questions...

• What problem does this piece of the protocol solve? For example, if your frame includes the length, what problem is solved by including a frame terminator or the "corrector"?

• How are transmission errors detected? The reliable method is to include a CRC. In your case, you can't detect an error.

• What is the recovery path when an error is detected?

• Can the protocol be expanded? Does it need to be? For example, at some point will you need a destination address? Is there a way to add it later?

For point-to-point communications I nearly always resort to something strongly resembling the Optomux protocol. The Modbus RTU protocol is also a good choice. I suggest you steal from something that has been proven to work well.

For "efficient data transfer" there are two good strategies...

• Off-the-shelf compression (e.g. gzip)

• Huffman encoding (great choice if the payload predominantly includes a subset of all possible values)

It serves as a kind of error detection mechanism - if a frame was received which is exactly the length it should be, I assume that the frame is not corrupted. I know it is not neccessarily so, but it is good enough for me.

I ignore the message. It's really fine with my application.

Doesn't need to be. :slight_smile:

I only care about two things with this protocol:
a. I need it to have as low a fram/data ratio as possible
b. I need to have a decent chance to know if a frame is corrupted

I'd be happy to try any other protocol which is as efficient or better, but I'd really love an answer to the original question, as it drives me crazy that I can't figure out how to implement it :slight_smile:

You could use the encoding style MQTT uses for integers

mqtt.png
(from: http://indigoo.com/petersblog)

encoded this way all bytes have the MSB off,
making it easy to use a single 0x80 as start and 0x81 as end delimiter.

You could easily add a checksum encoded in the same way.

Why don't you calculate and send a checksum of the data package?