ANT Forum

Moishe,

The Rx-only option only has an effect in the AP2; the AT3 does not have this feature.

If you are only receiving the first two packets of the burst, this would indicate a problem with your flow control on the device sending the burst. More details on this here:
http://www.thisisant.com/component/option,com_fireboard/Itemid,146/func,view/id,139/catid,25/#139      

My code won't send anything to the ANT if the RTS signal is high. Is there anything else I need to consider for proper flow control? Thanks.      

Then it could be the case that you are sending your messages too slow. ANT will buffer two message packets before the message period (these are the two messages you actually receive). The burst will start on the message period, after which you have to send the packets as soon as RTS allows you to. If your processor does not send the subsequent messages fast enough it will fail.

Sebastian      

My MSP430 USART is configured for 19.2kHz. It would be easy for me to change this to a faster speed but unfortunately the Nordic chip is hardwired for 19.2kHz in such a way that I can't change it. Is 19.2kHz not fast enough in asynchronous mode?

The MSP430 is running at 1Mhz and the burst transmission is done in a while loop that does nothing other than loading values from flash and transmitting as fast as possible.

Thanks!      

19.2kHz is fast enough to support a burst transmission.
There could be other aspects in your drivers implementation that could be causing the burst to be sent not fast enough (e.g. interrupt latency, other system latency...). Looking at the serial lines in a scope when the problem happens could provide a clue on where the problem is.      

Ok, I finally had a chance to do some more debugging. I first used an o-scope to to read the serial line between the MSP430 and the ANT and saw that when burst data is sent two packets are first sent and then there is a long delay before additional packets are sent. I also checked the codes coming back from the ANT and I'm only getting TRANSFER_SEQUENCE_NUMBER_ERROR even though I've verified the sequence and it's correct. So I'm guessing there's a timeout in that long delay and it's treating the two sets of packets as two different burst transmissions.

I'm trying to track down the source of the long delay and I've run out of ideas. I have a single while loop in main() that send out the burst packets. There shouldn't be anything interrupting it - i don't have that many interrupts and the ones I have are pretty short. Also I don't think an interrupt is causing the issue because the long delay is always in the same spot - after the first two packets.

I've also disabled power management and I think the only thing that could possibly cause a delay at this point is waiting for the ANT RTS line. I'm using asynch serial and every time I send a byte I wait for the RTS line to signal that the ANT chip is ready for more data.

Any ideas? The sequence numbers that i'm using in the test code are 0x00, 0x20, 0x40, 0xE0.      

The delay you are seeing after sending the first two packets is normal, as ANT will buffer two message packets before the message period, and then start the burst transmission:
http://www.thisisant.com/component/option,com_fireboard/Itemid,146/func,view/id,139/catid,25/#139

Please look at RTS, along with your serial Tx line. Have you verified the baud rate is indeed 19200 bauds per second? You should see the first two packets, and then RTS going high until the message period, and then toggling in between packets afterwards. Is this what you see?      

I've attached some pictures from some recent testing with the o-scope.

TTI - This shows the overall signals that I'm getting from the tx and RTS lines. First two packets are sent, then it attempts to send a few more but fails with a TRANSFER_SEQUENCE_NUMBER_ERROR as I mentioned previously.

TTI2 - This is a closer view of the second set of packets.
TTI3 - This is a closer view of the first set of packets.
TTI4 - This is a view of the first packet in the second set.

I then verified the baud rate and I'm getting 18.9 kbaud. I tweaked the settings in the MSP430 to increase the baud rate to 19.6 kbaud (I couldn't get any closer to 19.2) but the same behavior was observed.

TTI5 - First set of packets with the faster baud rate.
TTI6 - Close up view of the RTS line toggling.
TTI7 - Another close up of the RTS toggling, this time from the second set of packets.

Please let me know if there's anything else I can try. Have you actually used burst transmissions at 19.2 kHz in asynchronous mode? I noticed that most of your code is in synchronous mode and I'm wondering if we should switch to synchronous mode for the next board revision.

Thanks!      

I got an error saying the attachment was too large.. [file name=2010_03_09_TTI.zip size=484222]http://www.thisisant.com/images/fbfiles/files/2010_03_09_TTI.zip[/file]      

Bursting has been tested with UART (min baud rate 19.2kbps), bit and byte synchronous communication.

What you see with the first two packets is normal - the first two packets are received by ANT, and then RTS goes high until the next message period, when the first packet gets transmitted.

The difference in baud rates is a concern, as the baud rate has to match the 19.2kbps configured on the ANT module. If the baud rates do not match, serial communication will not be reliable and the burst will fail. Did you consider the start and stop bits when measuring the baud rate?

Specially in the second set of captures (tti7), it looks like you are transmitting while RTS is high. How are you checking for RTS? Are you using a hardware UART? You must ensure that changes in RTS are always detected and avoid attempting to transmit a packet when it is high, as the ANT engine will ignore it. The next packet will not be the one expected, and ANT will give you the TRANSFER_SEQUENCE_NUMBER_ERROR.      

This is the code I'm using to send a byte to the ANT.

while (!(IFG1 & UTXIFG0)); //wait for tx buffer to empty
while (P1IN & 0x10) { //do nothing while RTS signal (1.4) is high.
}
TXBUF0 = ucByte; //send the byte

Maybe the problem is that I'm sending a byte at a time to the MSP buffer and if RTS goes high in the middle of a byte I'll miss it. Would you recommend using an interrupt instead? If so, could you send me some example code?

Thanks!      

I used to do something similar - check RTS for every byte sent. As a result I find my transmission got slow down. Now I changed it to check RTS once for every packet sent. Maybe you can test out with this.      

I'll try that.. but it seems like I need to be checking RTS more often, not less since I'm still sending a few bits after the RTS line goes high. Should I use a hardware interrupt instead?

Moishe      

Whether an interrupt is suitable for your design depends on your specific system characteristics. It might help to ensure you do not miss changes in RTS, but you also need to be careful in your implementation to ensure it plays nice with other parts of your system. We do not have available sample code for this.      

Hello,

I am new to this forum.
I have a question regarding the minimum baud rate required to set up the ANT burst mode.
Is 19200 the minimum required baud rate for burst transfer or can i realize it with 9600 also?

Thanks in advance.