I connected iPod with Arduino using serial (UART) connection. Arduino sends 0-1023 number (so it’s two bytes) as it’s samples light sensor value.
I’m asking about advice about simple and reliable communication protocol.
- Do I need magic constants to start/stop communication.
- Maybe I need sent data of small chunks.
Now I have:
while (1)
{
data = getData() ;
// two bytes of 0-1024
Serial.write((data) & 0xFF)) ;
Serial.write((data) & 0x300)) ;
}
Any suggestion how to implement simple and reliable protocol ?
Image of my device: http://cl.ly/image/051f370v3e0g
Thanks
3
There are several reasons to have a protocol, even a very simple one.
- Reduce risk of errors, perhaps when the device is connected, started, stopped
- Allow for future expansion: perhaps the device sends two kinds of data in the future
- Make sure you’re reading from the right device and not something different.
- Helps debugging if you can see a stream you can recognise.
There are some advantages in using ASCII chars, if you want to debug. I’ll do it in binary, and include a length byte.
I would suggest a simple protocol of 6 bytes. Say:
Serial.write(0xc5); // start
Serial.write(0x06); // total length of packet
Serial.write(0x01); // 1=temperature data
Serial.write(data & 0xff); // low byte of data
Serial.write((data >> 8) & 0xff)); // high byte of data
Serial.write(0x5c); // end
Simple, easy to code, expandable. That would be my recommendation.
Here are some notes on my choices for these items.
- The start byte (0xc5) is a distinctive bit pattern, relatively unlikely to occur by chance, in which half the bits are off and half on. That makes it relatively easy to find with debugging tools including an oscilloscope.
- The end byte is the same reversed, for similar reasons.
- Including the length is the simplest kind of check for framing errors or dropped bytes. If the start byte, end byte and length match the packet is probably valid.
- The command byte of 0x01 allows room for expansion with future packet types. All packets should take the form
c5,length,cmd,data...,5c. - The data is sent in little-endian format, which may be easier for some servers to read. Please note the correct use of shift-mask.
As suggested in a comment, the additional of a simple checksum would improve the likelihood of detecting errors over a noisy line. A simple rotating XOR should be sufficient, and easy to code.
2
Without doing research on the topic, I would suggest the following. So, can you rapidly send the the two bytes? If so, I would break down your code into base 512 from binary, and use the following numbers for special commands. Such as…
514 = New Data Stream
DATA CHUNK
DATA CHUNK
DATA CHUNK
DATA CHUNK
…
513 = Stop Data Stream
Then convert back to binary and deserialize into a memory stream or something. This would leave you with a vast amount of basic commands to communicate with such as
EVENT#1 – 600
EVENT_PARAMSTART = 550
Param Chunk #1
Param Chunk #2
EVENT PARAMSTOP = 551
EVENTEND = 599
Does that help or am I totally off base? XD
2