Continuous scanning mode collisions

Username		Password		Remember Me?	forgot password?

20 December 2012 10:36 PM

cchockidg Newbie

Total Posts: 22

Joined 0

Hello

I'm making a prototype for using ANT to see how many different masters I can see with a USB stick operating in continuous scanning mode so I wrote a little C# program to display all of the unique devices I see. I'm using a handful of Garmin Chirps as the dumb master device and I'm only reading their beacon page (page 0).

For the most part, this approach is working fine, and each chirp is showing up individually and I see all of them within a few seconds of starting the application, but this afternoon I ran into a very weird problem. I have 13 chirps total, each with their own nickname and 2 of them werent behaving properly.

The two chirps are "HARVEY" and ":-O" and when the program started, each showed up without a problem, but after a few seconds, :-O wasn't heard from again. HARVEY was not showing up at the .5 Hz as he should have, with a discernible beacon but instead showing up maybe 2/3 of the time that he should have been. Every now and then, I'd have a new member show up in the group that had a name that was a weird concoction of the two names. It collided 3 times, the resultant names being ":-O EY", ":!RVEY" and ":-NVEY". I started taking the battery out of the other 11 chirps one by one and some of the "hybrid" names showed up again though only twice and under different nicknames. Once I took HARVEY's battery out, :-O's beacon went strong and steady without missing a beat.

From my understanding, the masters check their channels before they transmit and try to avoid each other, is this correct? I'm assuming this works fine when there are only a couple of masters in the environment, but I have 13 masters total and plan to add many many more. Is there something that I can do to avoid this in the future? Since I want to run this in continuous scanning mode, I'm under the impression that I can't incorporate frequency agility into the slave receiver. Has anyone else seen this before with a multiple master situation?

I'm going to try an experiment where I turn them all on at once and see what happens tomorrow, see if that turns up anything interesting.

21 December 2012 10:05 AM #1

alejandra Moderator

Total Posts: 662

Joined 2012-10-09

PM

You are correct in that ANT masters manage coexistence in the time domain; 13 nodes @ 0.5 Hz should not be a problem.

What is a little unusual in your description is the following note:

Every now and then, I'd have a new member show up in the group that had a name that was a weird concoction of the two names. It collided 3 times, the resultant names being ":-O EY", ":!RVEY" and ":-NVEY

That sounds more like an issue at the application level in your scanning mode application, in decoding the names and mixing the values from different transmissions.
If you created the application using the ANT C# library, you can enable debug logging and that generates a DeviceXX.txt file with all the serial communication between the ANT USB stick and the PC application. This log will let you see the raw messages and identify whether there is an error at the application level. Since your scanning application likely uses extended messages to distinguish between messages received from different nodes, you would also be able to confirm from the logs (which are timestamped) how often do you see each of the transmitters.

What kind of USB stick are you using?

21 December 2012 02:52 PM #2

cchockidg Newbie

Total Posts: 22

Joined 0

PM

I'm using the USB ANT2 stick (I believe) - the marking on the back is "USB2 Wireless USB Stick"

21 December 2012 07:40 PM #3

cchockidg Newbie

Total Posts: 22

Joined 0

PM

So after some experimenting, today, here are my conclusions:

I wired up all of the chirps so that they're on a shared power supply and thus start and stop at the same time as each other.

On the shared power supply (CR123 battery), when I started up the chirps at the same time, they began negotiating their channels and there were a few of what I'll call "collisions" that only occurred once in the very beginning of this. These aberrations weren't seen again and the expected results showed up at the proper period once all the devices had negotiated their respective slots.

I've attached a plot that I made of the time domain behavior as well as each respective beacon's occurance on that time scale as reported in the logs by the USB stick.

Is this a known issue with this kind of collisions between the masters as far as the slave interprets the results? I've also attached the log from the application that I used to create this plot. When creating the graph, I only filtered through the received logs in the same way that my application would. My application works off of the dChannelResponseHandler event.

One thing to note is that I have this data only from when the channels are being established initially, though I have not gotten data from when the devices have been running for a while and start drifting into each other which is what I suspect is what happened in my original post. I'll run these over the weekend and check on Monday to see if any collisions have occurred and if they have, I'll post the log results.

File Attachments

Oddity_1.txt (File Size: 266KB - Downloads: 551)

21 December 2012 07:41 PM #4

cchockidg Newbie

Total Posts: 22

Joined 0

PM

This is the graph (apparently the original graph was too large)

Image Attachments

Click thumbnail to see full-size image

27 December 2012 02:30 PM #5

Kat Kent Sr. Member

Total Posts: 235

Joined 2012-08-31

PM

Hi cchockidg,

Thanks for sharing this. ANTUSB2 should be good in this situation. Can I ask for some clarification of the graph that you have posted. I understand that the y-axis is showing each chirp, and the x-axis is time, but what are the events that you have plotted? Also, I assume that power up was at ~68 seconds?

Could you post a zoomed in version of an early section - say between 80 - 85 seconds, and of say 115 - 120 seconds? I'm wondering if being able to see what's happening at a similar time-resolution to the channel period would help.

Do you know what was happening with the three chirps that don't show up? Do you know of anything that changes at ~89 seconds? Also, did you find anything at the application level that could have merged the two chirps names (Harvey & :-O)?

27 December 2012 02:51 PM #6

cchockidg Newbie

Total Posts: 22

Joined 0

PM

Hi

The x and y values are what you thought; each data point is when the USB stick saw the beacon from the chirp.

As far as power up is concerned, that is correct.

In the application level, I didn't find anything on my end - I can try to go into the ANT dll but from the trace I saw, it looks like the receiver chip itself is believing that those are the messages it's receiving. The debug output was used to generate these graphs.

27 December 2012 02:52 PM #7

cchockidg Newbie

Total Posts: 22

Joined 0

PM

80-85 seconds

Image Attachments

Click thumbnail to see full-size image

27 December 2012 02:52 PM #8

cchockidg Newbie

Total Posts: 22

Joined 0

PM

115-120 seconds

Image Attachments

Click thumbnail to see full-size image

27 December 2012 03:23 PM #9

Kat Kent Sr. Member

Total Posts: 235

Joined 2012-08-31

PM

Hi!

So it looks like you changed the channel period from 4Hz to 0.5Hz at ~99s?

I don't really see anything strange here. It is normal for there to be an occasional dropped message.

Did you see any garbled names in this experiment, and if so do you know which timestamps in your log these would match up to?

Sounds like the weekend test with logs could be useful. If you can avoid running any other programs on your test computer during that time, that would remove a possible source of error of course.

27 December 2012 04:13 PM #10

cchockidg Newbie

Total Posts: 22

Joined 0

PM

Thanks - I've found a much better example of the collisions I'm talking about. I've attached a picture with what was received by the ANT device. This is a much better example - it's almost like the two chirps collide then the receiver can't discern one from the other.

Image Attachments

Click thumbnail to see full-size image

27 December 2012 05:25 PM #11

Kat Kent Sr. Member

Total Posts: 235

Joined 2012-08-31

PM

Can you describe what you did in this experiment? Were all the chirps supposed to be transmitting all the time? Have you looked for any other sources of interference, or tried conducting this experiment in a shielded environment?

5 min dropouts definitely don't look normal for this many ANT devices.

I would be tempted to try the same set-up but with two computers set up to listen to the chirps at the same time. If you see the same pattern in the results from both computers then it would point towards collisions / interference. If the results are different then it points towards something in the software or USB stick. Could help narrow down the search...

27 December 2012 05:42 PM #12

cchockidg Newbie

Total Posts: 22

Joined 0

PM

For this experiment, I started my application which basically is a UI built around the ANT library with the USB stick set to receive in continuous scanning mode. The software has the debug log and that is what I use to generate the above plots.

Each chirp was turned on one at a time and I just left them there and ran this for several hours.

I'm not sure how to check for interference and since I'm using the chirps, I can't just reprogram them.

My test environment is our office; a shared building with WiFi and bluetooth and who knows what else. I don't think I have access to a quieter environment though I do have several USB sticks and I'm seeing the same behavior on all of them.

31 December 2012 11:56 AM #13

alejandra Moderator

Total Posts: 662

Joined 2012-10-09

PM

Please note that it is not possible for ANT to create the "mangled" names. If collisions did take place over the air, your receiver would see the node with the strongest signal or none, as there is additional mechanisms built into the ANT protocol to prevent corrupted data. While occasional collisions are to be expected in group environments, this should not cause mangled data like you are seeing. I would still strongly suggest looking at the application level code (i.e. is new data being written to the buffer where you are storing the received data while you are decoding it?).

Could you please post the device log of the last experiment, where you saw the mangled data? If you can also point at the timestamps where your application saw the mangled names, that would be helpful as well.

03 January 2013 09:27 PM #14

cchockidg Newbie

Total Posts: 22

Joined 0

PM

Happy new year, everyone. Sorry about the delay in posting this. The most interesting parts of this log are in the first 20 minutes or so, which is what I've attached (the total log is 32MB)

The time stamps of the oddity events are as follows:
40.560
83.741
385.744
387.709
389.737
393.731
395.743
391.734
399.737
401.734
1029.731
1031.744
1033.741
1035.737
1039.731
1041.743
1043.740
1045.737
1047.734

File Attachments

Staggared_start_crop.txt (File Size: 829KB - Downloads: 509)

04 January 2013 09:00 AM #15

old_man_biking Sr. Member

Total Posts: 296

Joined 0

PM

The mangled names in your first post most probably come from unhandled concurrency in your application.
Not that the ANT libraries create additional threads, so that you have to handle concurrency issues.
Ensure to use proper synchronization (e.g. "lock" in C#) to ensure that ONE message is written COMPLETELY before another thread get's the chance to interrupt and intersperse its output into the first message.

Cheers,
OMB

ANT Forum