Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

You are here: Forum Home → ANT+ Forums → ANT+ Fitness Equipment → Thread

   

Channel Period and pairing protocol confusion

Rank

Total Posts: 4

Joined 2017-09-13

PM

Hello ANT community !

Quite new to ANT and ANT+ and I feel really confused about some terms and basic pairing protocol.

My project is to be able to pair a stationary bike (Elite Drivo) with a VR simulation (using Unity and C# scripting).
I've got some sample code from another dev in my company and currently trying to improve it as there's lots of latency which unfortunately cause motion sickness when running in VR...

First, when one start pedaling, it takes ~2-3 seconds before the bike start sending speed values interpreted by the VR simulation.
Then, when accelerating or stop pedaling, speed increase/decrease take another 2-3 seconds before being seen within the application. When displaying speed values within the game UI, one could see some big steps which make the experience really uncomfortable. :( (NB: VR experiences must run at 90hz to be ok).

I've played a bit with setChannelPeriod() function to see if it could alleviate this latency but no success so far... But I could see in the log file that some data are sent by the device at a higher rate than default 4Hz values.

However I have no clue what's really displayed in the log file.
- Rx: does it means "received data" i.e. data sent by the bike ?
- Tx: does it means "transmitted data" i.e. data sent by the application to the bike ?
- Is it the opposite ?

Documentation states that broadcast data (like bike speed and cadence) are sent at 4Hz. Does this frequency is hardware encoded or could this be controlled with the setChannelPeriod() function ?

I'm trying to determine here if I could somehow speed up bike data readings. I've started writing a simple C++ (console) application which try to connect to bike device and display a message when it receives speed data but so far I'm really confused about pairing protocol... I've looked at examples but couldn't get it worked.

Could someone confirm me the correct steps ?
- create ANT_Device
- get channel
- assignChannel() (I'm still not sure if it should be a master or slave as I don't really know what those two modes imply)
- set all channel parameters (setChannelPeriod)
- openChannel()

I then have a function pointer to receive message from the channel but never receive any broadcast message... Also device pairing led is still blinking...

So if anyone could give me clues about broadcast message data and pairing protocol for this project it would be really appreciated.
Thanks !
--Olivier      
Rank

Total Posts: 4

Joined 2017-09-13

PM

Forgot to tell I've managed to connect device to SimulANT+ simulator and get speed and cadence values.
However, as period is hardcoded as 4Hz, I observe same latency issues as described above...

I'll try to get into source code for inspiration and maybe tweaking it.      
Rank

Total Posts: 4

Joined 2017-09-13

PM

Me again...
So what I understand from my last tests (using SimulAnt+ and lookint/tweaking the source code) is that setChannelPeriod() function will control the rate at which the application is looking for new messages from the device. But device is broadcasting at 4Hz so if I set channel period at 8Hz, I'll get one message out of 2 to be RX_FAILURE.

Could someone confirm this behaviour ?
     
RankRankRankRank

Total Posts: 120

Joined 2013-05-07

PM

Hi Oliver,

The ANT+ FE-C device profile requires device to transmit at exactly 8192/65535 counts (or exactly 4 Hz). While this may not make a lot of sense for the VR use-case, it strikes the right balance between latency and battery consumption for the average FE-C sensor and display use-case.

The channel period value is hard coded on the sensor side, so even if you choose to receive at a higher rate, say 8 Hz, every other Rx will be a failed Rx because the sensor is not actually transmitting in that channel period, and currently there is no way to change that.

4 Hz mode should only delay you in the normal case a quarter of a second. If you are seeing a 2-3 second delay in starting, it is probably because of (1) delays in the sensor's detection code, (2) your slave search configurations. If the sensor does not start the ANT channel until after pedaling starts, and your device is using a default search, a 2-3 second delay is expected for the slave to acquire the channel. I would recommend using high duty search or a fast channel acquisition search waveform to reduce the latency of channel acquisition. Using high duty search can drop your search acquisition time to a theoretical maximum of a quarter second.

For details on the message broadcasting, please read the ANT+ Device Profile - Fitness Equipment.

Rx means received from your device (in this case the slave). Tx means transmitted from device.      
Rank

Total Posts: 4

Joined 2017-09-13

PM

Thanks for all these clarifications !