ANT Forum

Hello,

I am starting with AT3 module. I am using async mode. I am driving SLEEP = 0, SUSPEND = 1, RESET = 1, BR1-BR3 selected baudrate matches with my settings, RTS is sent to host (although it seems like RTS is very high impedance signal), PORTSEL = 0.
After sending a sequence (0x57 0x00 0x01 0x00), I get no answer from module (VCC = 3.3V). Why?      

Are you using a pull-up resistor for RTS as shown in the reference design in the datasheet for the AT3 module?
RTS will rise for ~50us after each correctly formatted message has been received. Do you see this happen?
Could you post the full message you are sending to ANT, including the sync byte and the checksum?
Are you planning on using the AT3 with SensRcore?      

The issue was in the sync byte, which I got from synchronous transfer and there it is different.
Now, I have other issue. When reading the contents from AT3 (in the command structures), I get following command:
[57][02][00][00] - I cannot see such command in the AT3 documentation, I suppose it is "set default sector 0" command, which I sent there while programming, but the byte order does not follow the documentation.
Similarily, I have:
[57][03][BD][00] - which is probably supposed to be "End of sector" (byte order also does not follow documentation), but I dont understand what does 0xBD stands for.      

The documentation for these commands is in the "SensRcore Messaging and Usage" document, available on the Downloads area of the website.

How are you reading the "command structures"? Are you requesting an NVM_Dump() to see the contents of the NVM?      

Yes, I am using NVM_Dump(). And as I said, in the documentation "SensRcore Messaging and Usage", there is written, that Set Default Sector 0 should be:
[57][00][02][00]
unlike:
[57][02][00][00]
that is sent back. So, the question is once again. Is that a bug? If not, what does [57][02][00][00] message stands for? This command is not described in "SensRcore Messaging and Usage".      

An NVM dump provides access to the contents of the NVM, which is not in exactly the same format as the commands that have been sent in.
For example, the Set Default Sector command
[57][00][02][00]
contains a filler byte which is not stored when saving to NVM.      

Well, I consider this reply as "it's not a bug, it's a feature", because I can argue with what it written in the documentation:
"It causes the part to send NVM_Write commands to the Host with the data commands that have been sent in, unless the NVM has
been locked from reading (3.1.6 below). It also will send out NVM_EndSector commands to denote the end of a sector and an NVM_DefaultSector command with the stored default sector." - so explicitly there is written "NVM_EndSector" and "NVM_DefaultSector" commands to be sent, which were not (as those commands are described in the documentation and dont match anything like [0x57][0x02][0x00][0x00].
It's better to update documentation to clarify it and not to confuser users.