Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

Data loss for a long time when channel_search_timeout occur

RankRankRankRank

Total Posts: 523

Joined 2012-11-15

PM

Hi friend,

I meet some problem on my RF product. We are building a outdoor device that using 24AP1 RF chip to display HRM & Combo sensor (speed & cadence).The problem is When combo sensor is link and I purposely power off HRM then data will long time loss around 1 min . I guess this issue is occur when any channel search timeout then the other channel will not receive any data. Long time data loss will not occur when only 1 channel create.These test case is done by shielding room and easy to reproduce.
BTW: How to disable search timeout.      
Avatar
RankRankRankRank

Total Posts: 662

Joined 2012-10-09

PM

In the AP1, when a channel is searching, the search operation will preempt other active channels, resulting in the data loss you are seeing, until the search times out. You can set the timeout to 0 for the search to immediately timeout, however, this would keep you from finding the HRM again when it is back.

The AP2 has the Low Priority Search feature, that would let you continue searching for the HRM, without interrupting your other channels. You can find more details on this on the "AN11 ANT Channel Search and Background Scanning Channel" application note here
http://www.thisisant.com/pages/support/developer-zone

The AP2 also supports infinite search timeout (i.e., search never times out)      
RankRankRankRank

Total Posts: 523

Joined 2012-11-15

PM

Hi friend,

Thanks for your info.

What is your suggestion that fix data loss issue? As I know Edge705 have no long time data loss but frequency data loss around 2 sec.

I try to tracker current to know link,search and search timeout status and I found data loss 4 sec will resulting AP1 to transfer to search.
Is the 4 sec adjustable or it is depend on ChannelPeriod.      
Avatar
RankRankRankRank

Total Posts: 662

Joined 2012-10-09

PM

The time for dropping back to search after missing consecutive transmissions is not adjustable. If the message rate is slower than 2 Hz, the slave will go to search mode after four missed
messages; for message rates faster than 2Hz, the
slave will drop back into search after two seconds worth of missed messages. If your device is expected to be searching for the HRM for an extended period of time, the AP2 is really the best option. Otherwise, you might want to reduce the timeout to limit the data loss to a shorter time.      
RankRankRankRank

Total Posts: 523

Joined 2012-11-15

PM

Hi friend,

Thanks your info. but I seems can not fix my issue. I have three more question below, please help me to solved it.
1. Device can not link any sensor when both channel at search status after 3mins then turn sensor on(search timeout=0).
2. Why Device will receive six package at 1 sec as below data log
(message rate=1Hz)?

Rcv:>(17:13:48)[a4][9][4e][0][7e][e6][2a][19][3f][4][cb][32][8a]
(17:13:48) Speed = 188
(17:13:48) Cadence = 0
Rcv:>(17:13:48)[a4][9][4e][0][7e][e6][2a][19][6c][7][cd][32][dc]
(17:13:48) Speed = 182
(17:13:48) Cadence = 0
Rcv:>(17:13:48)[a4][9][4e][0][b4][a][2b][19][32][c][d0][32][b3]
(17:13:48) Speed = 181
(17:13:48) Cadence = 6
Rcv:>(17:13:48)[a4][9][4e][0][b4][a][2b][19][26][f][d2][32][a6]
(17:13:48) Speed = 196
(17:13:48) Cadence = 6
Rcv:>(17:13:48)[a4][9][4e][0][e1][12][2c][19][88][13][d5][32][59]
(17:13:48) Speed = 198
(17:13:48) Cadence = 29
Rcv:>(17:13:48)[a4][9][4e][0][e1][12][2c][19][da][17][d8][32][2]
(17:13:48) Speed = 200
(17:13:48) Cadence = 29

3. Only one channel active and no others but still have data loss
8 secs

Rcv:>(17:13:38)[a4][9][4e][0][7e][e6][2a][19][36][f0][bd][32][1]
(17:13:38) Speed = 224
(17:13:38) Cadence = 40
Rcv:>(17:13:39)[a4][9][4e][0][7e][e6][2a][19][38][f4][c0][32][76]
(17:13:39) Speed = 216
(17:13:39) Cadence = 0
Rcv:>(17:13:47)[a4][9][4e][0][7e][e6][2a][19][5f][f8][c3][32][1e]
(17:13:47) Speed = 209
(17:13:47) Cadence = 0
Rcv:>(17:13:47)[a4][9][4e][0][7e][e6][2a][19][3a][fb][c5][32][7e]
(17:13:47) Speed = 202
(17:13:47) Cadence = 0
Rcv:>(17:13:47)[a4][9][4e][0][7e][e6][2a][19][a5][ff][c8][32][e8]
(17:13:47) Speed = 196
(17:13:47) Cadence = 0      
Avatar
RankRankRankRank

Total Posts: 662

Joined 2012-10-09

PM

A few thoughts on this issue

1) Search timeout

The search timeout specifies how long a slave device will look for the transmission of a master.
If you set the timeout to 0, on the AP1, this means your timeout is the lowest possible value - 2.5s. With such a short time, it is unlikely that your device will be able to acquire any of the sensors. The longest timeout you can achieve on the AP1 is ~ 10 minutes.

How often does your use case require to search?

2) Data loss during search

Searching will interfere with other active channels.
I notice that you are receiving at 1Hz, which means that missing a single packet might have a bigger effect on your application than receiving at a higher rate. Do you see any improvement receiving at a higher rate (2HZ or 4Hz?)

3) Message timing

>> Why Device will receive six package at 1 sec as below data log (message rate=1Hz)?
Where does that time stamp get generated?
While ANT will receive one message per second, the time at which these messages are processed by your application depends on your specific threading. From the log, it seems that messages queued up while your application was busy doing something else, and then got processed all at once. The event time and event count do change in these packets, so they clearly are different messages, generated at different times.

4) Data loss with single sensor.

Looking at your log, it looks that you have a gap between the second and fourth messages, and then you get a set of messages with the same timestamp. This could very well be related to (3), so you might not be missing any messages, and it just happens that they get processed at the same time. It is possible then that this issue is related to synchronization in your application.

Do you get any EVENT_RX_FAIL messages during the data loss periods? Any messages indicating you are dropping back to search or search timeout? If you do see very poor RF performance, further testing would need to be done. Nordic Semiconductor can provide further pointers on troubleshooting the RF for your device (and sensors, if custom design), with the casing and placement required for your use case.