- THIS IS ANT

Username		Password		Remember Me?	forgot password?

27 June 2013 02:20 PM

markrages Jr. Member

Total Posts: 40

Joined 2009-03-20

Application Note AN11 describes background scanning channel in section 8. I am attempting to implement it and am running into some infelicities. Consider this sequence of events:

1. A slave opens a background scanning channel with timeout=255 (search forever).

2. The background scanning channel finds a master. The slave sees this and opens a second channel to track the master.

3. The master goes away.

How can I have the second channel time out and close itself? Because there is already a search running on the "background" channel the slave drops into search but never actually begins the search because the background channel is blocking it from searching. Therefore the second slave channel never completes searching and never closes itself.

I have thought of two possible solutions to the problem.

One possible solution is to pause the background scanning channel on receipt of EVENT_RX_FAIL_GO_TO_SEARCH on the second channel and resume it on EVENT_CHANNEL_CLOSED. But this would require additional application logic so as not to lose the scanning channel if the search is successful. (the master returns after a brief dropout, perhaps.)

Another possible solution is to close the channel as soon as EVENT_RX_FAIL_GO_TO_SEARCH is received. But then additional application logic is required to implement the "real" timeout, so that brief dropouts are tolerated.

How can I have the second channel time out and close itself?

27 June 2013 03:35 PM #1

alejandra Moderator

Total Posts: 662

Joined 2012-10-09

PM

Hi Mark,

Could you provide more details on your setup?

What kind of hardware is used in the slave (AP2/USB2/USBm/etc..)?
Is the background scanning channel operating on the same frequency/network as the synchronized slave channel?

27 June 2013 03:53 PM #2

markrages Jr. Member

Total Posts: 40

Joined 2009-03-20

PM

I have tried with USB2, C7 and nRF51422 Ant devices.

Background channel is same parameters, except:
device_id=0,
extended assign=1, and
channel_type=0x40

Frequency and network are the same.

I'll try to put together an AutoANT script for this.

27 June 2013 04:37 PM #3

markrages Jr. Member

Total Posts: 40

Joined 2009-03-20

PM

Here is an AutoANT script demonstrating this. I hope.

It opens two channels. First, channel #0 is opened as the background scanning channel, with wildcard IDs but the most selective proximity setting, and infinite low priority search timeout. Then, channel #1 is opened as a normal slave channel with device_id=12345 and a short timeout.

Neither channel sees any incoming messages, but channel #1 never times out. (channel #0 never times out either, but that is expected.)

If you set channel #0's search timeout to a small value, then you will see channel #0 time out, and only after that channel #1 begins its search time, eventually timing out too. But with channel #0 timeout=255, channel #1 will never close itself.

----

Ah, I see attachments do not work on the forum, so I'll paste the script here:

###ANT_SCRIPT_VERSION: 0.01
w [4A][00] # >>> 'reset_system'

w [42][00][40][00][01] # >>> 'assign_channel_extended':
#                         |>  { 'channel': 0
#                         |>    'channel_type': 64
#                         |>    'network_number': 0
#                         |>    'extended': 1 }

r102 [40][00][42][00] # <<< 'response_no_error':
#                        |<  { 'channel': 0
#                        |<    'message_id': 66 }

w [51][00][00][00][00][00] # >>> 'channel_id':
#                             |>  { 'channel': 0
#                             |>    'device_number': 0
#                             |>    'device_type_id': 0
#                             |>    'transmission_type': 0 }

r102 [40][00][51][00] # <<< 'response_no_error':
#                        |<  { 'channel': 0
#                        |<    'message_id': 81 }

w [45][00][39] # >>> 'channel_frequency':
#                 |>  { 'channel': 0
#                 |>    'rf_frequency': 57 }

r102 [40][00][45][00] # <<< 'response_no_error':
#                        |<  { 'channel': 0
#                        |<    'message_id': 69 }

w [43][00][F6][1F] # >>> 'channel_period':
#                     |>  { 'channel': 0
#                     |>    'period': 8182 }

r103 [40][00][43][00] # <<< 'response_no_error':
#                        |<  { 'channel': 0
#                        |<    'message_id': 67 }

w [44][00][00] # >>> 'search_timeout':
#                 |>  { 'channel': 0
#                 |>    'search_timeout': 0 }

r102 [40][00][44][00] # <<< 'response_no_error':
#                        |<  { 'channel': 0
#                        |<    'message_id': 68 }

w [63][00][FF] # >>> 'low_priority_search_timeout':
#                 |>  { 'channel': 0
#                 |>    'search_timeout': 255 }

r102 [40][00][63][00] # <<< 'response_no_error':
#                        |<  { 'channel': 0
#                        |<    'message_id': 99 }

w [66][00][01] # >>> 'enable_extended':
#                 |>  { 'enable': 1
#                 |>    'dt': 0.246526002884
#                 |>    't': 1372371198.92 }

r102 [40][00][66][00] # <<< 'response_no_error':
#                        |<  { 'channel': 0
#                        |<    'message_id': 102 }

w [71][00][01] # >>> 'set_proximity':
#                 |>  { 'channel': 0
#                 |>    'level': 1 }

r102 [40][00][71][00] # <<< 'response_no_error':
#                        |<  { 'channel': 0
#                        |<    'message_id': 113 }

w [4B][00] # >>> 'open_channel':
#             |>  { 'channel': 0 }

r102 [40][00][4B][00] # <<< 'response_no_error':
#                        |<  { 'channel': 0
#                        |<    'message_id': 75 }

p103
w [42][01][00][00] # >>> 'assign_channel':
#                     |>  { 'channel': 1
#                     |>    'channel_type': 0
#                     |>    'network_number': 0 }

r102 [40][01][42][00] # <<< 'response_no_error':
#                        |<  { 'channel': 1
#                        |<    'message_id': 66 }

w [51][01][39][30][0B][00] # >>> 'channel_id':
#                             |>  { 'channel': 1
#                             |>    'device_number': 12345
#                             |>    'device_type_id': 11
#                             |>    'transmission_type': 0 }

r103 [40][01][51][00] # <<< 'response_no_error':
#                        |<  { 'channel': 1
#                        |<    'message_id': 81 }

w [45][01][39] # >>> 'channel_frequency':
#                 |>  { 'channel': 1
#                 |>    'rf_frequency': 57 }

r102 [40][01][45][00] # <<< 'response_no_error':
#                        |<  { 'channel': 1
#                        |<    'message_id': 69 }

w [44][01][04] # >>> 'search_timeout':
#                 |>  { 'channel': 1
#                 |>    'search_timeout': 4 }

r102 [40][01][44][00] # <<< 'response_no_error':
#                        |<  { 'channel': 1
#                        |<    'message_id': 68 }

w [44][01][00] # >>> 'search_timeout':
#                 |>  { 'channel': 1
#                 |>    'search_timeout': 0 }

r102 [40][01][44][00] # <<< 'response_no_error':
#                        |<  { 'channel': 1
#                        |<    'message_id': 68 }

w [63][01][01] # >>> 'low_priority_search_timeout':
#                 |>  { 'channel': 1
#                 |>    'search_timeout': 1 }

r102 [40][01][63][00] # <<< 'response_no_error':
#                        |<  { 'channel': 1
#                        |<    'message_id': 99 }

w [4B][01] # >>> 'open_channel':
#             |>  { 'channel': 1 }

r104 [40][01][4B][00] # <<< 'response_no_error':
#                        |<  { 'channel': 1
#                        |<    'message_id': 75 } 

28 June 2013 11:31 AM #4

alejandra Moderator

Total Posts: 662

Joined 2012-10-09

PM

One thing you can try is to close the background scanning channel after you receive the EVENT_RX_FAIL_GO_TO_SEARCH, and immediately reopen it. This will effectively result in the dedicated channel becoming the active search, allowing it to timeout. You will have a small delay from the action of closing/opening the channel, which may be acceptable for your application.

28 June 2013 11:55 AM #5

markrages Jr. Member

Total Posts: 40

Joined 2009-03-20

PM

That solution occurred to me in the shower this morning, and it appears to work as far as it goes.

But it is insufficient if there are other channels tracking/searching. The race unfolds:

1. channel 0 is opened as bg, no timeout

2. channel 1 is opened and tracking

3. channel 1 times out and goes to search. channel 0 is closed and reopened in response

4. channel 2 is opened and ready to search, but blocked by the ongoing search on #1 and #0.

5. channel 1 times out and closes

6. channel 2 is perpetually waiting to search.

So I think the BG channel needs to be closed and reopened on any possible change in search status... this would include channels opening, closing, and EVENT_RX_FAIL_GO_TO_SEARCH on any of the other channels.

I think that's the list... what other events might herald a change in channel status?

02 July 2013 10:12 AM #6

alejandra Moderator

Total Posts: 662

Joined 2012-10-09

PM

That basically covers it. Dropping to search or opening a channel would change the search status.

ANT Forum

Priority inversion with background scanning channel