Title Index
Recently Changed
Page Hierarchy
Incomplete
Tags
Concept2 PM4 Implementation of ANT+
Document for Discussion. Reference also case 1871
This document contains notes related to various options for implementation of ANT+ standard for the PM4 monitor. For more information on ANT+, refer to documents on www.thisisant.com which may require becoming a member.
Discussion notes related to profiles other than ANT-FE...
ANT-FE profile. Refer to Fitness Provile V 3.0 from Dynastream. Document D00001251. Fitness Equimpent Profile..
While is is apparent that Dynastream does not want Fitness Equipment vendors to use anything but the FIT1e module, there are many reasons why Concept2 does not wish to use it, such as Cost; Complete package redesign; and lack of available user-channels. More details by Contacting Scotth(at) concept2.com
Concept2 requests use of Ant FE profile that mirrors the required and optional pages listed on the ANT+ Fitness equipment Device profile with some extensions.
Alternatively, providing a way to 'build own' equivelent of FIT1e using AP2 or TI chip and source code ready to compile is an option to consider, however I do not have any indication from Dynastream that this will be made available.
That said....
Concept2 Device profile for Sensor Only mode...
Proposal:
- Start with Document D00001251.
- Subtract all references to FIT files and their transfer
- Delete all references to FIT1e requirements; implement with AP1, AP2, or other.
- Delete all references requiring proximity pairing
- Use methods of pairing and general operational modes that are similar to other Sensors.
- As this is no longer FIT compatible, not able to use the LINK HERE logo
- Argue that it is compatible with the FIT (Treadmill) logo, or alternately make another Icon for use with ROWER and SKI ERG.
(if used TI C7 module might get better proximity)
I suppose, if this is going to take along time or is unacceptable, that Concept2 has other options such as going on the Public or C2Private key and implement as we see fit, use the “ANT” logo (but not ANT+) and just work with the software vendors to implement something. As this is targeted mainly for mobile devices instead of embedded devices, making a change at a later date is not that big a deal... everyone needs to get an update and that's that. This would be along the lines of what is described in http://bugz.c2vt.com/default.asp?W15
An implementation of ANT+FE profile on the Rower/Ski Erg would want to consist of several portions:
1) Common data pages (80, 81, 82) - sent occasionally with equipment information.
2) ANT-FE required pages (16, 17) and the Rower page 22 sent at ~ 4hz in a specific pattern.
3) Ability to deal with watches, to a limited extend for link and real time data. This requires ANT-FS implementaion for at minimum link layer
4) Ability to deal with watches to a 'full' implementation; this requires ANT-FS transport layer and FIT file interpertiaon.
5) Ability to deal with advanced use cases utilizing ANT-FS
6) Ability to deal with advanced use cases utilizing custom pages
Summary of pages to be implemented.
Pages to implement fully (except maybe METS) are listed below. GREEN highlite indicates it has been implemented.
16 - General FE Data (Time, Distance, Speed/Pace, Heartrate, Fitness Equip State) - sent 2x every second.
17 - General Settings Page (stroke length, drag factor, Fitnes Equipment State) - sent 1x every second
18 - Metabolic Data (METS, Calories) - OPTIONAL; if used sent at rate of 0.2hz. - Suggest C2 Ignore for now.
22 - Rower Specific Data - (Stroke Count, cadence, Instant Power) sent 1x / second
?? - Ski Erg Specific Data (same as page 22 but for Ski Erg)
80 - Equipment Type - Sent twice in succession every other block of 64 pages
81 - Equipment Data - Sent twice in succession every other block of 64 pages
82 - Battery Data - OPTIONAL: Scott suggests sent only occasionally instead of 80 or 81, maybe every 1min?
70 - Page requests. See section on Page 70 below.
Common data pages (Document: ANT_ managed network – common data pages)
Page 80 - Manufacturer and product Information –
Byte 0: 0x50
Byte 1: ff
Byte 2: ff
Byte 3: Hardware version (we have overlapping hardware versions – what to do?)
Byte 4: mfg id lsb
Byte 5: mfg id msb (Concept2's Mfg ID is 40 or 0x0028)
Byte 6, 7: model number. - See table under Page 81.
Page 81 – Product Information and Serial #
byte 0: 0x51
Byte 1: ff
Byte 2: ff
Byte 3: SW Revision ( how to deal with the version #? just use major version #? Maybe Byte-stuff it? or we will have to make a translation table enumeration!)
| Product |
Model # |
SW Revision |
Version Transmitted |
|---|---|---|---|
| Dragonball PM3 | 1 | NA | |
| Dragonball PM4 | 2 | 27-?? | actual value (so 27..??) |
| PM3A - Rower | 3 | NA | |
| PM4A - Rower | 4 | 313 |
SW Version minus 300 |
| PM3A - SKI | 5 | NA | |
| PM4A - SKI | 6 |
SW Version minus 700 |
|
| PM5 - Future | 7 | Actual Value |
NB: Some of the values above are not valid, but for consistency we will define them all...
Byte 4-7: 4 bytes = Serial #
Page 82 - Battery Status
Byte 0: 0x52
Byte 1: ff - reserved
Byte 2: ff - reserved
Bytes 3-5: (follow the table...as best can, make best judgement how to implement)
Byte 6: Fractional Battery Voltage - implement as described
Byte 7: Descriptive bit field - implement as best can given Dynastream's sped.
Page 83: - Time And Date -- Scott does not think we need to implement this.
Page 84: --Subfield Data --- Do not implement.
Details - Page 16 (from page 21 of ANT-FE profile document)
Byte 0: 0x10 (page 16)
Byte 1: 22 - Equipment Type is Rower
Byte 2: Elapsed time; .25 second increments rollover in 64 seconds.
Byte 3: Distance Traveled; in meters; rolls over in 256 meters; should be perfectly matched with the time in Byte 2.
Byte 4, 5: Speed in units of 0.001 m/s
Byte 6: Displayable Heart Rate; FF=Invalid
Byte 7: Upper 4 bits: FE State: see table 7-5
Bit 3 lap toggle bit (CAN WE USE THIS TO INDICATE SPLIT DATA?!?)
Bit 0-2 FE State (0=reserved; 1=Asleep(off); 2=Ready; 3=in use; 4=Finished)
NOTE: Think that at each split we could consider send off the SPLIT statistics a few extra times with this data packet to ensure reception, then continue on with the normal pattern.
NOTE: Think at the end (state = 4 finished) we should continue to send finished data for a period of time, or told to shutup.
(Notes from discussion with Ross, etc.)
Set state bits; when PM4 is on and radio active; have not yet begun a session; to set it to "ready"; content speed = 0, etc. are all 0
first stroke = 3 in use. For all the data pages.
Pause (sweatshirt mode); go to paused (if rowing = 0); back to inuse if rowing starts coming back.
if cross split; raise LAP Toggle; (should we repeat the SPLIT data a few times?)
end of wokrout OR menu-back button causes state = 4 and then UNPAIR/Disconnect
every time move from ready to inuse it will create a new piece.
when user indicates on pm session is done, user presses button to disconnect, disconnect, the watch will start searching again; if does not detect broadcast back to link state. On garmin watches all data is saved.
in event that someone wants to do a 2nd piece; in use to ready; wants to do just row. What is the quickest way to get watch ready to get data again. PM4 broadcast FINISHED/PAUSED; go to READY; don't disconnect; watch will wait in READY, the display
ant-fs channel until stops; 4 minutes (?); user gets up and leaves, watch will stay beaconing in link mode for 5 min; 30 seconds timeout when FE data dissapears.
Seems like the following operational requirements would want to take place; update as needed...
| Transition or Event | Watch |
Non-Watch (Tablet, etc.) |
|
| On menu, start rowing (ie Just Row) | Ready->InUse immediately | ||
|
On menu, press Just Row |
Stay in Ready; start sending 0's; |
Same | |
| Just Row split boundaries | Toggle Lap bit every 5 min. |
Same Allow for Page 70 request to get accurate split information |
|
|
Just Row - Pause (Sweatshirt mode) |
-> Paused; -> InUse |
||
| Just Row - Menu-Back pressed to exit | -> Finished; then -> Ready | ||
| Just Row - Walk away terminated | -> Finished; then terminate link before powering down | ||
| Pre-Defined Distance Workout |
-> Ready when workout set up; sending 0's -> In Use on First Stroke Time and Distance Count Up |
Same; Time counts up; Distance counts DOWN to match PM | |
| Pre-Defined Time Workout |
-> Ready when workout set up; sending 0's -> In Use on First Stroke Time and Distance Count Up |
Same; but Time counts DOWN; distance counts up to match PM | |
| Time Intervals without Rest | |||
| Time Intervals With Rest | |||
| Time Intervals with undefined rest | |||
| Distance Intervals without rest | |||
| Distance Intervals with rest | |||
| Distance Intervals with undefined rest | |||
| Variable Intervals | (same as above behaviors, except...) | ||
| Unit powers down from Main Menu (4x MENU or timeout) | Disconnect and loose all record of last connection | Disconnect and loose all record of last connection |
Byte 7: Lower 4 bits: Capabilities: See table 7-6;
Bit 3 = 0
bit 2 = 1 (FE will transmit distance in Byte 3)
bit 0-1 = HR Data Source: Use 2 for Polar; use 1 for ANT+(Garmin); use 0 = unknown if Suunto.
Details - Page 17 (from page 24 of ANT-FE profile document)
Byte 0: 17 or 0x11
Byte 1: 0xFF reserverd
Byte 2: 0xFF reserved
Byte 3: Cycle length -> Stroke length (0.01 meter units; FF=Invalid or not available)
Byte 4, 5: Incline - 0x7FFF is invalid (no use!)
Byte 6: Resistance Level: Use Drag Factor value; 0xFF = Invalid
Byte 7: upper 4 bits: FE State (same as on page 16)
Byte 7: Lower 4 bits: Capabilities: - Reserved forr future use by Dynastream. Set to 0x0.
Details -- Page 22 -- Rower Specific Data
Byte 0 - 0x16 Page 22 data page #
Byte 1 - 0xFF Reserved
Byte 2 - 0xFF Reserved
Byte 3 - Stroke Count - incrementing stroke count from beginning of workout; rollover at 256
Byte 4 - Cadence - Instantaneious STROKES/MINUTE; 0xFF if invalid.
Byte 5 - 6: Instant Power - in WATTS. (0xFFFF = Invalid)
Byte 7
upper 4 bits: FE State (same as page 16; refer to 7.3.6)
Lower 4 bits: Capabilities Field (refer to 7.6.4.4)
Details -- Page 240 -- C2 Specific: Stroke Data
Byte 0 - 0xF0 Page 240 data page #
Byte 1 - Stroke Length - 0.01m LSB
Byte 2 - Stroke Drive Time - 0.01sec LSB
Byte 3 & 4 - Stroke Recover Time - 0.01sec LSB
Byte 5 & 6 - Stroke Distance - 0.01m LSB
Byte 7
upper 4 bits: FE State (same as page 16; refer to 7.3.6)
Lower 4 bits: Capabilities Field (refer to 7.6.4.4)
Details -- Page 241 -- C2 Specific: Absolute Distance
Byte 0 - 0xF1 Page 241 data page #
Byte 1, 2, 3 & 4 - Absolute Distance - 1m LSB
Byte 5 - Reserved
Byte 6 - Reserved
Byte 7
upper 4 bits: FE State (same as page 16; refer to 7.3.6)
Lower 4 bits: Capabilities Field (refer to 7.6.4.4)
Details -- Page 242 -- C2 Specific: Absolute Time
Byte 0 - 0xF2 Page 242 data page #
Byte 1, 2, 3 & 4 - Absolute Time - 0.25sec LSB
Byte 5 - Reserved
Byte 6 - Reserved
Byte 7
upper 4 bits: FE State (same as page 16; refer to 7.3.6)
Lower 4 bits: Capabilities Field (refer to 7.6.4.4)
Details -- Page 243 -- C2 Specific: Miscellaneous Data
Byte 0 - 0xF3 Page 243 data page #
Byte 1 & 2 - Stroke Count - 1stroke LSB
Byte 3 - Reserved
Byte 4 - Reserved
Byte 5 - Reserved
Byte 6 - Reserved
Byte 7
upper 4 bits: FE State (same as page 16; refer to 7.3.6)
Lower 4 bits: Capabilities Field (refer to 7.6.4.4)
Supported and desired ANT-FE Devices to connect to...
Standard ANT-FE profile to attempt to support the following devices:
| Device | ID Information | Status |
|
THISISANT FE Profile |
Do not have tests yet; Cannot start on this. | |
| Garmin FR60 | Product ID 988 | Target platform for Nov 2010; appears as of 11/30 it is just starting to work. Anomolies are seen in start-time; repairing; and other areas. |
| Garmin 210 | Product ID ___ | Not tested but should work when FR60 does; planned initial testing 12/2 with Judy. |
| Garmin 310 | Product ID ___ | Not tested but should work when FR60 does |
| Sony/Erricson Android |
Mfg ID 15(dynastream) |
Dynastream working on demo. Send firmware to Dynastream to test. |
| Augen WiLink6Tablet | Desired; no information or work started. | |
| iOS/Wahoo ANT-FE Profile | Waiting for profile implementation in API; next adapt Andrew's app to use; then consider coaching app. | |
| Timex w/ FE support | Unknown if ANT-FE is supported on any Timex watches | |
| PC running ANT-FE Profile Reception | Not started. |
Page 70 Extension Proposal.
Reference ANT+ managed Network Document, "Common Data Pages" (section 6.2, Page 70)
Page 70, Command 02: Request ANT-FS session; file payload contains a CSAFE command
70, Command 02: Request ANT-FS session; file request for the CSAFE response
70, Command 02: Request ANT-FS session; try to pull a file that will always contain the last known force curve data. Use case: Coaching tool - in a round-robin fashion, reqeust the ForceCurve data from a particular unit.
70, Command 01: Request an additional page (such as 18 Mets; 82 battery; or any other that is needed... ) This would be per how ANT+ specs for Page 70 (see common pages document) intended.
70, Command 01: Request Page F0 w/ additional data: Request start transmission of upgrade from 4hz to 8hz or 16hz with additional statistics interleaved.
- Provide indication if transmission should be change to 8 or 16hz (or more?)
- Indicate what extra page of data is requested
- Indicate what page it shold be returned as
- Indicate how often this data should be sent (or priority level)
Use case: RowPro would likely like to know when a new stroke is available. So define a new page that includes time/meters, but also includes strokestate. For example, page 16 but with some byte reallocated to include strokestate. In same request, ask for transmission to be upgraded to 16 hz.
Use case: Coaching tool (reference http://bugz.c2vt.com/default.asp?W123) or individual app would like to know drive/recovery ratio; so define a new page that includes drive time and recovery time (sum should equal strokerate). Request this get transmitted upon availability on each stroke, and optionally ask for upgrade to 8hz.
Use case: Coaching tool (reference http://bugz.c2vt.com/default.asp?W123) or individual app would like to get force curve data transmitted at the end of each stroke. Request burst of force curve data ever N strokes (typically 1); upon availability of the data (at the end of the stroke). Request could ask for this to be on same channel or on a new channel.
Use case: Heartrate analisys functions typically wish to know the beat-to-beat times for every heartbeat. This demands not just current 'smoothed' heartrate values (as is given in page 16), but at a minimum the 'beat-to-beat' time for the last beat, if not for the last several (reference Suunto protocol). One method is to have the receiving device (iOS, computer, etc.) receive this data directly. This may be the best solution. However a new page could be determined to re-transmit the beat-to-beat times from a HR belt reception from the Fitness equipment (rower/ski erg) in a new page.
Proposed method: Issue Page 70, Command 01.
Proposed additional pages for POLLING using page 70, or for INTERLEAVING with FE data:
Absolute Data: Sends distance (whole meters) and time (to 1/?? second resolution) without any rollover: This is the complete time without any rollover. This allows for dealing with paring in the middle of a workout, or after a long disconnection/reconnection. This page should be allowed to be "requested" on a one-time basis using Page 70, or turned on to be interleaved every N messages (or similar fashion). If more than 8 bytes are needed, then make into 2 pages.
HeartRate Beat-To-Beat Time. Used for FirstBeat type analisys. Since it is critical for every heartbeat to be accounted for, ensure that some redundancy is available, such as providing previous HR data. (Before implementing, review other dynamic pages and the HR Profile pages to ensure we are not reinventing anything here!). Contains the beat count and an accurate time stamp between this beat and the previous one (or more) heartbeats. Use Suunto as a possible example.
Last stroke drive start timestamp. This shall include in the payload an accurate ( what accuracy ??) absolte (??) timestamp of when last drive started along with meters of when this occured). If possible, also include distance (meters) for last complete stroke. Used for RowPro. This should be available as an interleaved page (NB from scott: I am not sure this needs to be an available page-request 70, but ok if it is) (NB: Can this data be added to the below drive/recovery times?)
Drive and Recovery times. For last stroke, provide the amount of time spent in drive and amount of time spent in recovery. The sum of these two should be the equivelent to the inverse of the strokes/minute. Fill in any additional information available in remaining bytes. These values can be used for A) calulation of current SPM to the fractional amount (instead of integer); B) displaying drive time; C) calculation of drive/recovery ratio. This should be able to be "polled" using Page 70, or turned on for interleaving. (discussion about 1/100 increments to 2.5 seconds using bytes; or 1/50 to get up to 5 seconds, or go to 2 bytes and use mS).
Split Information. Provide information on the summary results for the last split. This should include: Which split # this is; Avg Stroke Rate; Average HeartRate; Ending Heartrate; Duration in time for the split; Distance for the split. AKA all the data we would record to a logcard. This could be turned on to automatically be inserted several times just after a split boundry (to ensure it gets through) or could be requested via a normal Page 70. We could consider adding to the request for split inforation to indicate which split we are interested in receiving. Due to the amount of data, the response might have to be a burst, or may have to be relegated to a ANT-FS CSAFE request or something similar??
-- (unformed thoughts below)
Workout Summary Information: Provide same as split data but for the entire workout. Could be a special case of the above (ie split # FF or something like that)
Request current workout structure inforimation: Return the current workout structure (maybe this is better CSAFE through ANT-FS)
Question:
Refresh my memory – in multiple erg environments, how to tell one machine from another?? This may be implicit with the pairing process or channel selection process, have to dig into this one...
Side comments:
- page 82 has no way to tell device it is operating on either A) generated power (solar, flywheel generated, etc.) or B) Line Power. Should/Could this be added?
- If there is a way to GET time/date, shouldn't there be a way to PUT time and date?
- Section 7.3.7 Capabilities Bit Field describes source of HR data. How shouuld SUUNTO HR data be classified? “Other/Invalid”? “ANT”? It is clear it should not be POLAR or HAND GRIP.
- Confirm that it's OK to transmit additional information on pages F0-FF
FR60 Testing Notes:
1. FR60 will "timeout" if no rowing data received (ie null data received) after 5 minutes.
2. FR60 seems to "lag" behind PM4 elapsed time in 1 trial of Just Row using beta 001 firmware.
3. Just row splits were properly recognised by the watch with a BEEP.
4. Garmin Connect... (untested)
5. Unrealistic loss of tach (simulator) results in PM stopping time, but watch continues.
6. Ending just row (menu-back) properly indicates STOPPED.
FR 60 User Instructions:
- Ensure your PM4 has the latest firmware.
- On the WATCH Press the MODE button to go into TRAINING mode. This should start a little antenna icon blinking.
- On the PM4, select More Options, Connect HR
- Select the "Garmin FR", wait, and confirm.
- On the back of the PM4, the LED should be rapidly blinking to indicate communications.
Garmin 210 User Instrucitons:
- Ensure your PM4 has the latest firmware.
- ??? ---> On the WATCH Press the MODE button to go into TRAINING mode. This should start a little antenna icon blinking.
- On the PM4, select More Options, Connect HR
- Select the "Garmin FR", wait, and confirm.
Garmin 310XT User Instructions:
- Ensure your PM4 has the latest firmware.
- ??? ---> On the WATCH Press the MODE button to go into TRAINING mode. This should start a little antenna icon blinking.
- On the PM4, select More Options, Connect HR
- Select the "Garmin FR", wait, and confirm.