Communications Protocol

Discussion in 'Mac Programming' started by jciapara, Nov 23, 2009.

  1. jciapara macrumors regular

    Joined:
    Jan 25, 2008
    #1
    Hi All,

    I am programming a RF communications protocol to download firmware updates to devices without having them to connect to the USB. The protocol needs to be reliable (as most protocols), handle retransmission, error detection, pairing, discovery, etc. I don't need to worry about error detection, since this is done already by hardware using CRC, what I do need to worry about is retransmission of packets in case of an error.

    What I am asking, is if you have any tips or suggestions as to what characteristics the protocol should/must have, it needs to be very light weight, since End Devices don't have a lot of flash space. What is the best way to handle discovery and pairing?, the part attached to the computer can be on throughout the whole process, but the End Devices need to save as much energy as possible.

    Is it better to handle the transmission/retransmission packet by packet with acks? or use a window of packets?.

    I know there are already a lot of protocols already out there which could meet my criteria, but the application is very specific to my hardware and the protocol needs to be tailored made for this application.

    Anyway any tip, suggestion, or examples I can refer to, would be greatly appreciated. BTW. I am programming it in C, in case anyone wants to know.

    Thanks,

    Julio
     
  2. jciapara thread starter macrumors regular

    Joined:
    Jan 25, 2008
    #2
    No one?

    Hey, I just wanted to see what you guys think a good but simple protocol must have, I mean basic characteristics, I already somewhat have my protocol specified, but I would like to see what others think about must have features, different ways you think discovery of devices could work. I'm sure even if you haven't code a protocol, you might've used one.

    Anyway if you want to share your opinion that would be great, personally I think is a great subject and one that can always be improved.

    Few ideas I have integrated in the design of the protocol are:

    -Communication with up to 8 different end devices at the "same time" using sort of frequency channels.

    - Will work on 2 frequencies, 915Mhz and 868Mhz (Basically European and US)

    - Packet retransmission will be handled packet by packet (Here I don't know if it's worth the extra effort or coding to implement a window of packets)

    - For the discovery phase I have in mind, having the AP broadcast a burst of 10 packets each with a sequence number, after which the AP will turn into RX mode, to listen if any device wants to join. The end devices will start on RX mode, when a package is received as broadcast it will check the sequence number and wait for the 10th packet, after which it will put itself into TX mode and transmit the Join command and its own address, the AP will save that address and transmit a Join/Ack to the ED only. (The AP doesn't have a battery constraint, whereas the ED does).

    - Once they are joined, the transfer of the new firmware will be done on variable lenght packets (actually most packets will be fixed lenght and other variable), after each packet received, checked and written into memory, the ED will send a ACK asking for the next packet. If a timeout on either end is detected packet retransmission will be done up to 5 times, after which the process will terminate, and the user will need to start it again.

    - Security is not a big issue here, the only security I need is that the Flash is write/read protected by a password but this has nothing to do with the protocol, except that at the first packet the password must be sent. The password is just a vendor specific one and is configurable.


    Anyway, I'm still on the early stages of the design, these are just the first ideas that come to my mind for the simple protocol. Any feedback, tips, improvements which you might think are needed, would be greatly appreciated.

    Sorry for the long post again.
     

Share This Page