ANT-PC Interface

Goals:

• Provide an alternative to USB to connect the PC or other mobile device to the PM4 monitor
• Provide communication from one PC to many PM4's within the limits of ANT.
• Continue to use CSAFE protocol for most communications
• Addition of ANT's native "Sensor Mode" to allow PC's and other devices to receive telemetry data from a users rowing session.

One of the software vendor's request is located here.

Discussion of use of standard ANT+ profiles located ANT Plus Profile Notes and Specifications

The following information is DEPRECIATED and no longer in use.  Plese ignore all notes below this sentence...

Here is a straw man to take a whack at - important points to look at are the transmitter overlap table and the interleaving packet table. 

RowPro Requirements

DLL Interface

ANT Overview

ANT is a 2.4GHz bidirectional wireless Personal Area Network (PAN) communications technology optimized for transferring low data-rate, low latency data between multiple ANT-enabled devices. The ultra-low power consumption of ANT guarantees an extended battery life even from low capacity supplies such as a coin cell battery, such as are required for heart rate monitors, bicycle computers, and wrist watches. 

ANT CSAFE Command and Response Channel

There is currently an ANT channel set up on the Concept 2 PM4 that accepts CSAFE commands and generates CSAFE responses.  This channel will be opened in certain screens on the PM4.  To ensure that the power consumption is a small as possible the channel will only remain open for a small period of time.  The duty cycle will be determined by the desired discovery time.   Once a connection has been established the channel will remain open until explicitly closed or an activity timeout.

More information on the CSAFE interface can be obtained from http://bugz.c2vt.com/default.asp?W12 or Concept2's "Software Development Kit" published on Concept2's web site under Service, Software, SDK.

ANT CSAFE Channel Specifications (temporary until assigned by Concept2/Dynastream)

ANT CSAFE Channel Operation

The ANT CSAFE Channel will be opened every 5 seconds on the main screen (other screens to follow).  The channel will timeout after 250ms if no messages are received.  Once an initial message is received the channel will timeout after 1 second.  When the CSAFE channel times out both the CSAFE channel and the Sensor channel are closed.  In order to keep the CSAFE and Sensor channels open, a CSAFE command must be sent to the PM4 once a second. 

Note:  If the PM4 is configured to run with a wireless HeartRate belt (Suunto, Garmin) than intermittent loss of data can occur on both the CSAFE and Sensor channels.  In particular, if the PM4 looses communication with the HeartRate belt then all communication with the CSAFE and Sensor channels halts while the ANT chip searches for the HeartRate belt.

ANT Sensor Mode Channel

The ANT Sensor Mode Channel will be opened via a CSAFE command and is intended to broadcast sensor data on a periodic basis.  Currently there are 4 different packet types (DynaStream refers to these as data pages) defined.  These are intended to report discovery data, distance and time data, heart beat data, and stroke data. 

ANT Sensor Mode Channel Specifications

ANT Sensor Mode Channel Operation

The ANT Sensor Mode Channel is configured using the Sensor Mode Configuration CSAFE Command described below.  The command configures the channel to send differents packets at various rates.  The are several peculiarities about both the ANT protocol and the PM4 firmware to take into account when choosing the period of transmission and the rate of various packets.  The Channel Period determines how often the ANT protocol will send a message - if no new message has been sent to the ANT chip by the firmware, the previous message will be retransmitted.  This can help create message redundancy but choosing an excessive Channel Period will cause interference with other PM4 devices sharing the channel.  Also the software on the PC side will need to detect/handle duplicate messages.  The PM4 firmware only polls the ANT chip approximately every 20ms and therefore will only change data being sent every 20ms.  For any given polling cycle of the ANT chip the firmware will update the ANT chip with the highest priority packet which is pending or with the default packet (lowest priority packet) if there are no packets pending. 

Note:  If the PM4 is configured to run with a wireless HeartRate belt (Suunto, Garmin) than intermittent loss of data can occur on both the CSAFE and Sensor channels.  In particular, if the PM4 looses communication with the HeartRate belt then all communication with the CSAFE and Sensor channels halts while the ANT chip searches for the HeartRate belt.

Transmitter Overlap

Because all the PMs will be transmitting asynchronously, there will be transmitter overlap.  When two transmitters overlap, the data from both of the transmitters is lost.  Based on an 8 byte payload the following table illustrates some of the restrictions.  If we allow upto 4 frequencies for sensor data transmission we can have less PM overlap.

ANT transmitters are intentionally desynchronized so transmitters which are overlapping will not remain overlapped.  However, sufficient redundancy must be included in the data stream to allow for dropped packets.

Discovery Packet

The discovery packet format will be used to aid in discovering and enumerating all of the PMs in the environment.    

Distance Packet

The distance packet posts the current distance, time and stroke status.   

Heart Beat Packet

The heart beat packet posts the heart beat data.   Note the change toggle is added for compatibility with DynaStream standards.

Stroke Packet

The stoke packet posts the end of stroke data.   Note the change toggle is added for compatibility with DynaStream standards.

Interleaving of Packets

Dropping of packets, due either to noise or overlap, precludes any scheme where a specific packet is sent in response to a specific event.  For instance, if a heart beat packet was only sent at the end of a heart beat and that packet was missed then no new heart beat data would be available for at least one heart beat and possibly longer.  A different solution is to interleave packets at a fixed frequency.   In order transmit all of the data requested by RowPro the following interleaving of packets is suggested – based on a 20 Hz transmit rate

Sensor Mode Configuration CSAFE Command

In order to allow for the most flexibility in operation of the Consept2 Sensor Mode the following CSAFE command has been developed.  Basically an new CSAFE command will be implemented that allows for setting up the Sensor Mode,  configuration options will include the ANT channel (ie. frequency), the number of Tx cycles per second and a packet list.  The packet list will be used to specify what kind of packets the Sensor Mode will transmit and what the interleaving will be.  Each element in the packet list will specify the timing of a given type of packet. The packet list is prioritized so if more than one packet is pending the first packet is sent first.  The last entry in the packet list will be assumed to be the default packet and will be used whenever no other packet is pending.   For instance assume that we would like to have Distance packets reported every 50ms, Heartrate data reported every 200ms, and Stroke data reported every 300ms.  We would generate a packet list with HeartRate packets every 200ms, Stroke packets every 300ms and Data packets as default packets.  The new CSAFE command is a Custom Long Push command and thus must be wrapped with a Custom Long Push header (0x76).

Sensor Message Byte Order Definition

// Sensor message structure
typedef struct {
    UINT8_T id;
    UINT8_T addr;
    union
    {
        struct {
            UINT8_T hwid0;
            UINT8_T hwid1;
            UINT8_T hwid2;
            UINT8_T hwid3;
            UINT8_T unused0;
            UINT8_T unused1;
            } discovery;
        struct {
            UINT8_T state;
            UINT8_T dist0;
            UINT8_T dist1;
            UINT8_T dist2;
            UINT8_T time0;
            UINT8_T time1;
            } distance;
        struct {
            UINT8_T count;
            UINT8_T beat_lo;
            UINT8_T beat_hi;
            UINT8_T previous_beat_lo;
            UINT8_T previous_beat_hi;
            UINT8_T hr;
            } heartbeat;
        struct {
            UINT8_T rate;
            UINT8_T pace_lo;
            UINT8_T pace_hi;
            UINT8_T unused0;
            UINT8_T unused1;
            UINT8_T unused2;
            } stroke;
    };
} SENSOR_MSG_T;
 

 COMMENTS - NOT YET acted upon:

1.       Per Anne at Dynastream: strike the bit thing “Transmitter must toggle this bit every 4 messages. Receiver may not interpret bytes 0-3 until it has seen this bit set to both a 0 and a 1.” And “Note the change toggle is added for compatibility with DynaStream standards.” – this was specifically to deal with the fact that the ANT+SPORT HR profile did not accommodate a “Code Page” and it’s being shoe-horned in.  For any new protocols that we define, this does not need to be done, however using code pages (byte 0 tells us what data is contained herein) is recommended. Which is what we have done.

 (see redlines above)

3.     Per Scott at C2: The proposal from DigitalRowing requests distance data on every packet; does it make sense to consider this? Heartbeat packet does not contain enough room.

COMMENTS - Acted on (discarded or integrated into the document):

2.      Per Scott at C2:       It would seem that you have an error… in type 0=discovery, that’s fine but later all the other packet types are Heart Beat = 1; Distance = 1 ; etc…  I assume these should be sequentially numbered. Absolutely - done