Request From Developer for ANT Protocol

OK, we’ve worked through the ANT payload question and have the following comments:

1.       We’ve used the following assumptions:

a.       ANT mode – We assume we can move from command and response mode to sensor mode and vice-versa at will.  We would use command and response mode before and after the rowing, and sensor mode during the rowing.  This would enable us to synchronize clocks with the PM, which would mean we would not need time included in the packets in sensor mode.

b.      Split retrieval – We assume after the piece is completed we can retrieve up to 30 splits from the PM memory using command and response mode.  This would enable us to defer collection of splits until after the piece instead of catering for their collection while in sensor mode.

c.       Heartbeat period retrieval – We assume we can retrieve heartbeat period information as part of the sensor mode protocol, and that the PM firmware will be able to send each new heartbeat period data in the next packet.

d.      Packet size – We assume all 8 bytes are available as payload.  The protocol we’ve devised would result in some unused bytes in some packets.  OTU whether to suppress unused bytes or send all 8 bytes regardless.

e.      Packet types – We assume we can use some payload bits to signal packet types, and we also assume the PM firmware will handle a selection of different packet types.  The protocol we’ve devised uses different packet types at different points in the conversation.

f.        Number crunching – We assume the PM firmware will handle number manipulation into the required number of bits, for example taking Current Distance to a set number of decimal places and converting this into a set number of bits.  If we instead need to use standard number-processing algorithms the PM already has, for example floating point, then we will need to expand our bit usage estimates accordingly.

g.       Number of PMs – We assume the dongle will be capable of conducting interleaved conversations with multiple ergs.  Our goal is to communicate with up to 16 ergs at 100ms intervals, even if this initially requires a number of ANT dongles side by side.

h.      PM ID – We assume the underlying transport protocol has some way to identify to us which PM sent each packet.  If not, we’d need to assign some payload to transporting the PM ID.

i.         Packet integrity – We assume the underlying transport protocol has some form of packet integrity check.  If not, we’d need to assign some payload to at least a rudimentary integrity check.

j.        Distance – We assume the distance from dongle to PM can be up to ~40ft for a line of 8 ergs.  Note: If it would be possible to reach up to ~70ft that would enable a line of 16 ergs.

k.       Distance recycling – We assume the distance will not be recycled to 0 after x meters.  We believe we can live within the 8-byte packet without needing to recycle distance, and we’d prefer not to recycle distance if this is avoidable.

l.         Communication performance – We assume if we want to monitor and log or report on jitter, packet loss and packet corruption, we will need to do that at the application layer.  This means the transport layer would need to a) timestamp arriving packets and report the timestamps to the application, and b) pass bad packets to the application the app can monitor packet corruption.

3.       Based on the above assumptions, we’ve devised the following draft protocol that would cover what the application needs:

a.       A packet up to 64 bits long would be sent on a 100 msec tick from each PM to an ANT dongle, and this would be passed on to application on arrival or on a 100msec tick.

b.      Every packet would include:

                                                               i.      The packet type ~ 3 bits.

                                                             ii.      Rowing status ~ 3 bits

                                                            iii.      The current Distance to at least 2 and preferably 3-4 decimal places ~ 24 bits.

                                                           iv.      Additional payload that would depend on the packet type 0 – 34 bits as below.

c.       There would be 3 different packet types (potentially more could be added later to expand the protocol), which would include the following additional payload:

                                                               i.      Distance Packet – Packet Type / Rowing Status / Current Distance.

                                                             ii.      Heartbeat Packet – Packet Type / Rowing Status / Current Distance / Heartbeat Period ~ 11 bits.

                                                            iii.      Stroke Packet – Packet Type / Rowing Status / Current Distance / Stroke Rate ~ 8 bits / Pace ~ 8 bits.

d.      There would be a simple priority order for sending the packets:

                                                               i.      Priority 1:  Stroke packets ~ every 400-4000 msec.

                                                             ii.      Priority 2:  Heartbeat packets ~ every 250-1700 msec.

                                                            iii.      Priority 3:  Distance packets ~ every 100 msec, i.e. whenever one of the other packet types is not available.

e.      Every packet would be accompanied by the following information from the transport layer:

                                                               i.      Received time stamp and/or packet sequence number.

                                                             ii.      Packet integrity check pass/fail (i.e. bad packets would not be dropped by the transport layer, rather they would be reported as bad to the application).

                                                            iii.      PM ID of the sending PM, or in the case of outgoing packets the destination PM.