Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

Background scan search time?

Rank

Total Posts: 3

Joined 2014-01-24

PM

Hello,

I currently have 2 nodes that I am locating via rssi. When I don't have the ExtendedAssignment set, the speed of getting packets is CHANNEL_PROOF_PERIOD/32768.

When I set it into background scan (extendedAssign.enableBackgroundScanning();) mode this frequency of packets drops significantly.

Is there a way to speed this up.

Project: One slave, everything else masters. Could be zero to any number of masters.

Patrick      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Hi,

Background scanning is not intended for strong packet reception. The best way to guarantee high reception of packets on an Android device is to open multiple channels at the channel period you expect to receive them at.

Please refer to the ANT Channel Search and Background Scanning Channel application note for more information.

If you require full reception of all master channel packets (more than 8) to a single slave, you will require Continuous Scanning Mode which is not generally supported on Android devices.

If you need to communicate with many devices via a single channel, you may also reverse your topology, and use 1 master channel to query many slaves using shared channels, which are also described in the ANT Message Protocol and Usage document.      
Rank

Total Posts: 3

Joined 2014-01-24

PM

Shared Channels?

Do you know how fast the handshaking is? Continuous scanning was my first intention. While implementing, I missed the one sentence that tells me it is not meant for Android because it locks all channels.

I have a possibility of having lots of nodes, but all will not be available at the same time. They will be spread out over a space. Initially for simplicity I was going to have no communication with the slave to master, only the masters giving me information and the slave dealing with what it gets. The information needs to come faster than 1 packet every second or two. Continuous scanning would be perfect.

Shared Channels? I will be connecting and disconnecting with nodes at a high rate. I will not have a high number of nodes at a single time. Can shared channels handle the connecting and disconnecting issue?

Thanks
Patrick      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Hi Patrick,

Is this application for use on Android devices in general or a single purpose device running Android?

Any acquisition time for any particular ANT slave will be dependent on the master channel period and the slave search waveform. Generally Android devices by default run a faster waveform (they typically have much larger batteries). Using the faster waveform you should see an average acquisition time of ~1 second and a max of ~2 seconds for 4 Hz devices in an ideal environment. Higher channel periods will reduce your acquisition times.

It does not initially sound like shared channels would be a solution for your use case as your devices are quickly moving in/out of range of your central Android device. Shared channels require a few messages to pass the device's shared channel ID to the master for registration.

Assuming you need to receive consecutive messages using any Android device supporting ANT (or USB Host).
1) Open multiple channels at a high channel period.
In this topology you maintain master devices, but you open up multiple slave channels as wildcards. At say 16 Hz your worst case acquisition time should approximately be ~0.4 seconds. As you find channels, you quickly listen for the duration you need, close the channel, re-wildcard it (perhaps also blacklisting the devices you just listened to for a period), and re-opening to search again. In this case you'll need to balance acquisition time with master power consumption.

2) Plug a USB-m ANT stick in using the USB Host Service.
USB-m sticks use "high duty search", which is a type of search which turns the radio on nearly 100% of the time. Running a background scanning channel on a USB-m from Android will closely resemble the packet reception you see running continuous scanning mode.

If the issue is that you require ~1 packet of data at approximately 1 Hz, then background scanning should be sufficient if your devices are broadcasting at 4-16 Hz.