Discussions with Ross.

I’ve reserved Manufacturer ID 40 (0x0028) for Concept2.  This ID would be used anytime Concept2 is broadcasting on the ANT+ Network.

Hi Scott,

Just a quick follow up to the call to confirm that we are willing to support Concept2 to develop Fitness Device Profile support without using FIT1e.  We have not initiated any work on this yet, but are willing to provide reference code and possibly a demonstration if you express interest.

 

Regarding "what can we start on now" :

Mark could start work on the outbound messaging – FE_TX channel. 

Then the ANT-FS is just used for pairing and turning FE_TX off and on.

 

---

Note below are responses to questions, typically the questions are below the responses, though some responses are interleaved...

 

Watches – no extra comments.

 

Personal Display -

 

For things like force curves – anything that involves burst – you’ll be way further ahead doing this as a file transfer with FS than with burst.  FS uses burst but has built in retries, CRC’s etc.  The file can be any file you want, it doesn’t not strictly need to be in FIT format.  FIT is only recommended for interoperability cases.  Special applications like configuration can be handled any way that you like

 

Row Pro:

Sorry, I understand the force curve thing better.   A burst might be okay here.

Page 70 can be used to request a “high speed mode” if you need the more data faster.

 

Coach Display:

The transmitters are identified by their device number which is part of each data packet already, you don’t need to add further identification.  For applications up to 8 rowers, the USB stick can handle them on separate channels.  The coach application would probably use a scanning channel (available on USB2 sticks) if you needed more than 8, but you would not be able to back channel messages from the display to the rower quite as easily.

 

That’s all I’ve got for now.

 

Cheers,

 

Ross

 

From:Scott Hamilton [mailto:scotth@concept2.com]
Sent: October 29, 2010 10:48 AM
To: Stirling, Ross
Subject: How to mix ANT-FE profile with other use cases

 

Ross:

 

I am struggling with how to meld the needs to implement the benefits of the ANT-FE profile alongside the additional requirements of other use cases.  These use cases include demands such as “more data faster”, additional statistics not present, bursts of data (force curves), and command/control.

 

Attached are some use cases… probably not complete, but there it is…

(use case PowerPoint not included here)

 

I propose the following:

1) Have Mark start now to implement the standard FE pages we discussed; use a ‘hack’ to turn it on for R&D use now and for CES.

2) When exemplary code is available for FS (as we’ve discussed) then implement that for pairing, management, etc.

3) Utilize page 70 requesting page F0 to enable additional statistics with more specific request being placed in byte 3 at a rate of byte 4.  Examples below.  This leaves Page 70 still open to requesting standard ANT+ based pages.

 

Page F0 – REQUEST additional PERIODIC transmissions interleaved with existing FE data.

70 page request

FF reserved by ANT+

FF reserved by ANT+

01 Request additional data page 01

14 request 20 times/second (preempted by normal FE sequences)

80 Transmit until ack’d.

F0 Request additional page specified by byte 3

01 Request data page (or consider 03 = asking for repeated additional pages)

 

Byte 3 might contain things like:

01 = At a rate specified by Byte 4, send similar data to FE Page 16, but byte 7 contains stroke-state  (this is a RowPro use case; a Enum list of states such as “drive” “recovery” “waiting for acceleration” etc.)

02 = When available, setup burst data transmission of detailed force-curve data

03 = Send beat-to-beat heart rate data at a rate specified by byte 4

04 = Send drive distance, drive time, recovery time at a rate specified by Byte 4

NB  these data pages might get sent BACK to the receiving device on pages F0-FF to avoid conflicts with other pages, but the request list might be longer than 16 pages so I’ve enumerated them starting with 01

NB: These page requests could be ‘stacked’ to add additional statistics to the mix, use similar methodology to http://bugz.c2vt.com/default.asp?W15

 

Or byte 3 might contain other sorts of things like:

80 = Request to reset monitor

81 = Request to set up a workout

82 = Request to initiate an additional channel to support CSAFE command/response (or maybe better to send ANT-FS files back and forth to do this function??)

Etc…

 

 

 

---

 

Ross says...

I like this set up.  You would want to test the latency in moving between broadcast and FS mode, but it would definitely provide you with the best data integrity.

 

From:Scott Hamilton [mailto:scotth@concept2.com]
Sent: October 29, 2010 12:40 PM
To: Scott Hamilton; Stirling, Ross
Subject: RE: How to mix ANT-FE profile with other use cases

 

Ok, giving it more thought...

Maybe for CSAFE command/control items we do a Page 70, command 01 request ANT-FS session.  During the session we send a small file which contains the CSAFE request.  To get the response, we do another Page 70 command 01 to request antoher ANTFS session to retrieve the resultant CSAFE data..

I think same mechanism can be used for force curve data: request a Page 70, Command 01 request ANT-FS session.  Request a particualr file which contains the force-curve data and if available it retrieves it with ANT-FS.

that seems to make sense...

It's starting to come together... if I have not made some big blunder.

This is all assuming that we trust all the ANT FS stuff...

I still like the idea of using Page 70 request, Command 00, Page F0, with a variety of parameters stuffed into byte 3/4 to request upgrade to 8 or 16hz and interleave in additional data...  The watches will never do this but our product can and still be compliant with the FE profile.

Thoughts?

 

---

Related to 'who is host vs client' in ANT-FS

So I have this right...

PM4 implements FS "Host".(Ross:  Yes.  Watch is a client)

 

Watches implement a "Client"(Ross: Yes, I should read ahead more)

PC's / Android / Phones would also implement a "Client"(In this case yes.  I suspect that they ultimately will do both and be whatever they need to be.)

 

In this world, is it the "Host" or "Client" who initiates a FS session? I thougth reading the docs that the Client (watch or pc) requests this session?

 

Client is the “master” of the channel in that it transmits a beacon.  The client is intended to be lower power than the host, which must use searching to find the client.  The Host is actually the one in charge though.  It initiates the exchange by requesting a link, requesting authentication, requesting file for download and requests to upload files.   The client never initiates any of the actions.

 

Looks to me like you understand this all correctly.

 

-----

Then I got this....

 

Clarification:

The device that is broadcasting is always the client.

The phone/iPad/watch is the client in the case of the Fitness Equipment device profile, where the watch beacons and the FE searches for it and hosts downloading the files off the watch.  This leaves watches with only the client implementation required.

Likely you would not implement the FE profile in the many to PC implementation.  In that you would have the PC receiving (slave) the PM5 data stream (master).  The PC would be the host and back channel requests to .

So I guess in that implementation, your PM5 would have to be a client also.  Embedded client is about 6k worth of code in one of our apps.  Not sure what the host size is – more, but not an order of magnitude.

Ross

 

From:Scott Hamilton [mailto:scotth@concept2.com]
Sent: October 29, 2010 5:44 PM
To: Stirling, Ross
Subject: RE: question about the FS code being developed

 

Though, then, this is contrary to the use cases that I am looking at where the client (pc, iPad, etc.) asks (page 70 command 1) to initiate a FS session?

 

With an iPad or PC instead of a watch, it almost seems as if the roles want to reverse?  The higher power and richer user interface is on the iPad or PC...

 

Maybe this means that we need to add both host and client into the Pm4, and figure out how to make it behave properly when in presense of the Watch, and also properly in presense of a PC/iPad.

 

 

Related to co-existance in a crowded enviornment...

Yes, AP1 has co-existence features.

The only things that are not included in that are our oldest TX only products like the HRM1 strap.  These products would have coexistence issues when you reach about 25 units in an area.  We have been shipping the HRM1B with coexistence for a few years now.

 

For the picture shown:

 

Heads:  FIT1e, Rx of HRM, SPD, PWR, Tx of FE when watch present

Power Sensor: AT3 module, Rx of SPD, Tx of PWR

In the HRM and SPD Sensor there is a Dynastream chipset we provide to high volume OEM’s.  Tx of HRM or SPD.

 

RF interference when it occurs will cause lost messages, 2 second of lost messages will cause a drop to search.

A drop to search is not a failure.  A seach time out – not recovering from search – is a failure.

 

There is no way to know if they were searching, however they were not experiencing user-perceptible loss of data.

 

Ross

 

From:Scott Hamilton [mailto:scotth@concept2.com]
Sent: October 28, 2010 11:21 AM
To: Stirling, Ross
Subject: RE: Reference Please

 

When you say “All ANT+ devices”… does this include the AP1 ?    Which chips were in use for each of the sensors and heads? Are we assuming that none of these were dropping down to Search mode ?

 

Scott Hamilton  -   Electronic Product Engineer  -  Concept2 Inc.

105 Industrial Park Drive  Morrisville, VT 05661

Office phone: 802-888-5226 x 3062 or 800-245-5676

Fax: 802-888-6337     Cell: 802-279-6753     Urgent after hours: 802-851-5919

MSN Instant Messenger and email: scotth @ concept2.com ; Skype: C2Scott

 

From:Stirling, Ross [mailto:Ross.Stirling@thisisant.com]
Sent: Thursday, October 28, 2010 12:46 PM
To: Scott Hamilton
Cc: Heck, Teri; Aylesworth, Catherine; Doney, Dallin; Paradis, Mike
Subject: RE: Reference Please

 

Hi Scott:

 

1)      A slightly technical answer:

a.       All ANT+ devices listen briefly as part of each transmission and can adjust the time of the next transmission slightly to spaced away from other devices in the room.  The radio is on for such a tiny amount of the total message period that the transmitters can co-exist.  The typically specification statement is that you can have 80 nodes transmitting in a 10m radius on the same network and frequency.

 

b.      We test high density coexistence as part of every code release on ANT hardware.  We don’t have this reduced to an easy publicly consumable spec sheet, but it has come up that this would be a nice thing to have.  We have in the past successfully tested with 50 units at 4 Hz TX inside a 1m radius.

 

2)      A picture that speaks for itself:

a.       This worked.

b.      There are 80 bicycles in this room, each with 2 transmitters (SPD, PWR).  Participants are wearing HR straps.

c.       Each bike computer forms its own network with a spd sensor and power sensor and the user’s HRM

d.      There are at least 160 ANT+ sensors on the bikes in the room, plus the heart rate straps which is up to another 80.  Obviously the room is bigger than 10m radius, but we think this makes a good practical example.