ANT Forum

There is no ANT-FS API for Android currently. If you wanted to write an ANT-FS manager I would start with the ant-fs-specification      

Yes, thank you.

But the Android APIs only allow me to send already defined commands. If the APIs would allow me to send byte level commands, then that would be much better. Right now, the way APIs are defined, there is basically not room for user extensions. Or there is?      

public void ANTTxMessage(byte[] message) throws AntInterfaceException

from ANTLib should do what you need. Pass it a byte array with no sync byte or checksum, just len, id, data. e.g. for a reset: [01][4A][00]      

I'm trying to develop an Android-based ANT-FS application and am running into some difficulty sending acknowledged messages from the host to the client to step through the connection states.

While it is highly likely there is something else I'm not setting up properly I would like to see if someone can verify that I'm implementing the ANTSendAcknowledgedData function in the AntInterface class properly. Or point out what I'm doing wrong if not. I'm getting the sense that I'm not sending any data from the host to the client.

I'm confident that I have the channel set up properly since I can search and see the client beacon messages. The host channel parameters are:
- Channel type = AntDefine.PARAMETER_RX_NOT_TX
- Network number = 2 (ANT-FS)
- Device number = 0
- Device type = 1
- Period = 4096 (Used for ANT-FS)
- Frequency = 57
- Transmission type = 5
- Channel number = 3

The client parameters are:
- Device number = 0
- Device type = 22
- Authentication = passkey
- Manufacturing ID = 2

The host searches the channel and sees the client beacon come in as:
[09][4E][03][43][2C][00][03][16][00][02][00]
which is correct based on the client settings

When I receive the beacon, I call the ANTSendAcknowledgedData(chn#, txBuffer[]) function via the AntInterface class with the following byte array (in this order as well):
- byte _fsCmnd = (byte)0x43; (I've also tried 0x44 here)
- byte _link = (byte)0x02;
- byte _chFreq = (byte)0x32;
- byte _chPeriod = (byte)0x04;
- byte _snByte0 = (byte)0x01;
- byte _snByte1 = (byte)0x00;
- byte _snByte2 = (byte)0x00;
- byte _snByte3 = (byte)0x00;

I then change the host frequency to 0x32 (50 decimal) and wait for the client to beacon there with its status bit indicating that it's in the authentication state. I never see it get there. In fact, if I don't change the host frequency, I continue to see the client beacon on the previous frequency with no changes to its bytes.

Questions:
- Does the ANTSendAcknowledgedData function handle the acknowledgment in the background and throw an exception if it doesn't receive it? Thus, do I simply have to call it and not wait for a receive event?

- Is there some positive indicator that I can see (wait for) at the ANTPlusManager or higher level to confirm that the message was received or not? Do I need to wait for a period of time watching for an exception using its timed out absence as a negative indicator that the message was acknowledged?

- In case the message was sporatically missed by the client, I've tried looping with a pause to send the acknowledged message several times. Still no success.

- Do I need to add the length, channel numner, sync byte, or checksum byte in the byte array. I tried adding the length and channel number bytes to the front of it with no difference. What does a proper txBuffer[] look like?

- I also noticed that the Windows ANT-FS application sends 0x44 for the _sfCmd byte. I tried that as well but with no success.

- Maybe I'm not actually moving to the new channel frequency. I change it on the fly. Do I need to close the channel and then reopen it with the new frequency? However, as noted above, when I don't issue the new frequency command, I continue to see the client beacon; whereas, when I issue it, I don't see the beacon anymore. That pretty much tells me that I'm changing frequency properly.

- My understanding is that the client's beacon after it receives the link command is identical to that before the command except that the authenticate state is set. Does it come in to the broadcast receiver with a different message value that I'm not trapping or does it continue to come in with a 0x4E message ID?

Any advice anyone can provide with this or other settings I need to put in place to get this to work is greatly appreciated.

Thanks!      

Hello,

There a few things that I have noticed in what you have said:

1. In your channel parameters, you have specified that your host channel is set up to find device type 1, which I assume is your ANT device type. You have then specified that your client device is device type 22, which I assume is your beacon device type. I just wanted to confirm that my assumptions were actually correct, and that you aren't meant to be searching for ANT device type 22 or some other similar scenario.

2. Your command ID should be 0x44, not 0x43.

3. The txBuffer[] parameter is just the 8 byte data payload without the checksum, sync byte, channel number, length etc, so in your case if you're trying to send the link command it should be {0x44, 0x02, 0x32, 0x04, 0x01, 0x00, 0x00, 0x00} (assuming your host's serial number is 0x00000001).

4. When you send an Acknowledged message, you should receive either the EVENT_TRANSFER_TX_COMPLETE or EVENT_TRANSFER_TX_FAILED events to indicate whether or not your client device sent an acknowledgement to your message. More information on these events can be found in ANT Message Protocol and Usage. It is good practice to retry the Ack message on the EVENT_TRANSFER_TX_FAILED event rather than just after a pause as you are doing now.

5. Your frequency can be changed on the fly, there are no issues there.

6. You are correct, the beacon will come in to the broadcast receiver with the same 0x4E ID.

7. One thing I strongly recommend is developing using the PC tools rather than an established product. You can use the PC client to simulate your client device, but you also get the added benefit of having ANT logs, which can be very beneficial for debugging purposes. Those logs can indicate if your client device is actually receiving the Ack message, etc. The PC tools are located here. One thing to keep in mind is that the PC Tools have been designed to be extremely robust, so they implement rather aggressive retry mechanisms.

I hope that this helped you. If you continue to have issues, please let me know, I will do what I can to assist you.

Kassandra      

Thank you for your prompt and thorough reply to my questions. I really appreciate it.

I apologize for not responding sooner but based on your information, I needed to put more infrastructure into my code to properly test the acknowledged message functionality. I wanted to do that before responding in case I had other questions.

Since I already have a PC implementation of this applicaiton, I was confident that the channel parameters were set up properly and they agreed with the ANT-FS Technical Specification.

My problem was that I was trying to do a quick-and-dirty test of the command and therefore wasn't properly waiting for the response and most certainly wasn't reissuing it properly based on an EVENT_TRANSFER_TX_FAILED reply. That's why I never saw evidence of the message being received in any of the PC app logs. I wasn't sure if the command was implemented differently in the Android OS than in Windows. As you effectively pointed out in your message, it is not.

I've since coded things properly by issueing the command and creating a response handler based on the two events (duh...) and things are working like a charm. Not surprisingly, the code structure now looks a lot like the Windows-based code structure (...again duh). I'm now sitting in the authenticate state ready to pair.

One thing I found and would like to offer to others reading this is that things are much more robust when changing frequency to go back to the search frequency, reissue the link command, and move back to the authenticate/transport frequency if the app actually waits for the RESPONSE_NO_ERROR reply to the frequency changes as per section 9.5.2 in the ANT Message Protocol and Usage document (or minimally allows a settling time after issuing them).

Thanks again for your help!


Tom      

Hi,
I'm developing ANTFS Host for Android,too.
And now,I attached source code here.
This software' architecture and usage is the almost same as ANTFS-PC HOST(Win).
Off course ,this needs ANT Radio Service & ANT_LIB(Android API).

I tested just on Xperia arc & ANT-FS PC Client(Win).
Maybe some bugs remain in it ,but I hope it will be useful for ANTFS developers. [file name=AntfsTest.zip size=120189]http://www.thisisant.com/images/fbfiles/files/AntfsTest.zip[/file]      

Looks like above link doesn't work, perhaps the code is not available??      

Can anyone tell us if this code is available, please?      

Link should be fixed now.      

Hello,
can someone fix the downloadlink for the code from ohyamat?
I am also very interested in developing an android app to connect a ant+ device via the device-type ant-fs.

Thank you.