Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

Message delay after power up

Rank

Total Posts: 4

Joined 2010-10-19

PM

Hello ANTs,

I recently started working with the dev kit and a USB2 stick. It was no problem to configure a channel with one transmitter and one receiver. The transmitter consists of the ANT11TS33M5IB module and the battery board. It uses SensRcore to work as a freqeuncy counter with a single channel. The receiver is the USB2 stick, information is shown with ANTware II. The message rate is 32 Hz. Works.

Now I want to replace the battery with a harvester. The application needs information as soon as possible when the system is powered up, but the process is interrupted regularily. When I take the battery out of the battery board, reinsert it, and observe the result in ANTware II, I see delays of about 0.5s to 1.5s for the first message to arrive after power up. I would be happy with 0.2s. Here are my questions:

1. What is the reason for the variation in the delay? What can be done to have the smallest observed delay always?

2. What is the best configuration for this application? I am overwhelmed by the possibilities and since it is currently difficult for me to measure the delay precisely, I need information on a configuration that minimizes the delay.

3. Is the delay perhaps associated with the module rather than the chipset, such that a custom (or customized) module would solve the problem? Can I change the module to get closer to my design target?

Thank you.

Regards,

Heinrich      
RankRank

Total Posts: 47

Joined 2010-07-08

PM

Hello Heinrich,

1) There are two reasons for the delay on power up. One is that the AT3 module itself has to initialize and begin transmitting (this takes from 200 to 500ms). Then on the receiver side (the USB stick), the module has to find the transmitting signal via search mode. Search mode can vary in how fast it will find the signal.

There is not much you can do about the AT3 initialization. Because the AT3 has two chips, it does take a bit longer to initialize than the AP1 or AP2, but of course you cannot run sensRcore on those other chips.

On the receiver side, make sure you disable low priority search (under advanced, set the timeout to 0). You can easily test how long it takes to acquire a 32 Hz signal by setting up two devices in antware and counting how many messages it takes before the receiver finds the signal. I did a few runs of this and it appears to take as long 500ms.

So with your setup you are looking at about 1 second total time to find your signal, which is about what you are seeing. The only way to reduce the search time would be to increase the channel period from 32 Hz (the higher this number, the faster the search time). Of course power usage goes up as you increase the channel period, but this might not be a problem for you.


2) I can't say exactly what you should do, but I think you are on the right track. To reduce search times you need to have a very high channel period. There is no way around this. I think you can measure delay more precisely by counting messages. Being able to monitor both sides is key, and I would suggest doing some simulations with antware or even simple custom programs first.


3) If you made a custom module using AP2, you might be able to reduce the delay a bit since AP2 is faster to initialize. The AT3 module is not optimized for speed, so if you did your own design you might be able to make the initialization faster. You do need to understand a target of 0.2s end to end is definitely pushing the limits of what ANT is capable of.      
RankRank

Total Posts: 47

Joined 2010-07-08

PM

One other thing I just realized is that if you will be always be using a PC as the receiver in your final product, you can enable Rx scanning mode which is a search that is on 100% of the time and will always find the first message. This mode is not valid for coin cell operation because it would rapidly drain the battery.

In antware, this option is under "advanced -> open in scan mode."      
Rank

Total Posts: 4

Joined 2010-10-19

PM

Dear Jefferson,

"open in scan mode" makes quite a difference. It reduces the delay to an amount that really requires precise measurement for further investigation. It is a good solution for me right now. While the PC is not the receiver for the final application, there will always a plenty of power available on the receivers side.

Thank you.

Regards,

Heinrich