Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

About Zero PAD byte

Rank

Total Posts: 5

Joined 0

PM

Hi,
Who can give me more information about the Zero PAD byte (if any).
p.s. I have read "Interfacing with The ANT of Gen ... "Doc.      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Hi,

The zero pad bytes are simply optional bytes which ANT ignores which can be added to the end of messages which go from the Host -> ANT Radio, which help to give ANT time to finish processing the last message sent to it by providing some space between messages to ANT. ANT indicates it is busy processing and cannot receive a new message at that moment by asserting the RTS line.

You can avoid using zero pad bytes by instead ensuring the RTS line is no longer being asserted before sending a new message to ANT.

Cheers      
Rank

Total Posts: 7

Joined 0

PM

Hello,

Could you indicate me some information about the device for a simple application :
(i'm working with a MCU and a uart communication)
suspend GND ? Vcc ?
sleep GND ? Vcc ?
reset GND ? Vcc ?

i don't connect rst because i'm waiting a while after the message structure (sync - ML - ID - data... CS).
Moreover, when i test my application (MCU with AP2(master+ broadcast) to USB stick with ANTwareII(slave)), there isn't any change in rts ... But i don't undestand why. Could i have some suggestion or idea ?

Thanks,      
Rank

Total Posts: 7

Joined 0

PM

Hello,

Could we don't use rts if we let some time after the structure message ?
Could you give me few advice on the branch connection of AP2 (for a simple application (mcu with uart)):
reset : GND ? VCC?
sleep : GND ? VCC?
suspend :GND ? VCC?
Moreover, is it possible to communicate between a computer (with a usb stick and ANTwareII) and a MCU with a AP2 ?

Thanks for your help.      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Hi,

It is strongly recommended to implement the flow control (RTS) line.

While simply waiting between sending messages should work for a simple single channel broadcast case, you will still occassionally have lost messages. The amount of time ANT requires between messages will vary depending on how busy the radio is, so the length of time RTS is asserted can vary over a wide range.
For more complex use cases such as bursting or utilizing multiple channels, implementing the RTS is virtually a must do because of the highly varied and tight timing of the messages in these cases. If you do plan to continue not using the RTS line, I would recommend leaving it unconnected to not put any additional load on the chip as it is an output line.

It is also strongly recommended to implement the reset line.

While Asynchronous mode does offer just sending the ANT_ResetSystem command, it is more reliable to reset by passing in and out of the suspend state, and it's most reliable to reset by asserting the reset pin or power cycling the chip. Being able to reset reliably to a known starting state can greatly assist your development. If you plan on not implementing the reset line, Nordic recommends leaving it unconnected for the AP2.

It is recommended to at least implement the SLEEP line to take advantage of ANT's low power states.

Only if your application is unconcerned about power consumption would I not utilize the SLEEP line, as it allows ANT to enter it's ultra low power state modes. If you plan on not utilizing this feature then I would leave the SLEEP line tied off to ground. Suspend should be tied off to VCC if it is not in use as well.

It is absolutely possible to establish a channel between a computer using a USB stick/ANTware II and an MCU controlling an AP2 module. I would recommend reading two of the stickied threads in this forum, the "Getting Started with Development of ANT+ Enabled Applications" thread found here, and "Getting Started with ANT Development in Embedded Systems" found here.
For more information on ANT's ultra low power states I would read the AN13 Power States app note found here.
The ANT AP2 Tranceiver Module Datasheet would also be a useful read, and it can be found here.

Cheers      
Rank

Total Posts: 7

Joined 0

PM

Hello,

I have again few problem to communicate with the AP2.

My first question is: there is two bytes for device number in set channel ID (0x51) (data2 and data3) and i would like to know where i must put the LSB and MSB.
In theory, with uart and AP2 we have to send LSB first so in my opinion data2 = LSB and data = MSB is it correct ?

Then here is my configuration of AP2:
init:
0x42 => length : 3 data : 1, 0x10, 0
0x51 => length : 5 data : 1, 33 , 1 , 1
0x45 => length : 2 data : 1, 66
0x43 => length : 3 data : 1, 8192
0x60 => length : 2 data : 1, 3
0x4B => length : 1 data : 1

while(1):
0x4E => length : 9 data : 1,0,0,0,0,0,0,0,0,0
wait();

with this setting, i have a problem with rts because there is one more peak at the beginning of my message (between syn/leng/id and datas) (screen of oscilloscope in attachment)

Thanks for your help. [img size=512]http://www.thisisant.com/images/fbfiles/images/oscillo.jpg[/img]      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Hi,

The device number is two bytes arranged in little endian as described in the ANT Message Protocol and Usage document meaning the LSB comes first and the MSB comes last. So yes, the LSB is sent before the MSB.

A view from a logic analyzer rather than an oscilliscope would be more helpful.
What I can discern from your photo is that you were sending the sync/length/id while RTS was high for a moment, meaning ANT would have lost those bytes. The RTS raised itself likely in response to receiving a broken message, and then again having received another broken message.

Are you receiving the messages from ANT? ANT will be periodically sending response messages after each action it takes.
While you can choose to not receive the RX messages or ignore the status of the RTS line, I will not be able to provide any support for that level of implementation.

Cheers      
Rank

Total Posts: 7

Joined 0

PM

Hello,

First of all thanks for your advice and your help.

Now i send only one configuration in order to check if ap2 accept it.
So i test the assign channel that's why i send with my mcu the following message:
0xA4--0x03--0x42--0x01--0x10--0x00--0xF4
according to theory, i should watch on TX an event message which should probably be :
0xA4--0x03--0x40--0x01--0x42-0x00 if the configuration was a success. is it correct ?

After a few test, i have the following answer : 0xA4-0x01-0x00-0xA4-0x01-0xF6...
i don't undestand why i receive this wrong data...

In fact, i respect the uart : 1 bit start/ 8 bits datas/ 1 bit stop/ no parity/ lsb are send first/ same baud rate on mcu and ap2
So if you could give me again few advice to solve this problem.

Thanks.
Best regards      
Avatar
RankRankRankRank

Total Posts: 745

Joined 2012-09-14

PM

Hi,

That would be a correct status message if that command was a success, and yes the UART operates on fairly standard parameters (8bits/transfer, 1 stop bit, no parity bit, lsb sent first, non inverted).

Are you immediately resetting AP2 at startup and then seeing the startup message (6F) before you send any additional messages?

I've attached an example on channel 0 from a USB logic analyzer of what you should see after sending a 0x42 command. While RTS is relatively short in this example it's duration can still vary.

I would also try to do your triggering on H>L transitions as well.

Cheers [img size=850]http://www.thisisant.com/images/fbfiles/images/Example.jpg[/img]