ANT Forum

Hi,

We ported the ANTFS_EMBEDDED_CLIENT on a microprocessor and have it communicating with your ANT-FS PC Host software. Everything on the demo works fine, except when we attempt to download our own file from the client to the PC Host. In order to send our own file, we need to read from a flash device; 64 bytes at a time.

I noticed in the ANTFS_EMBEDDED_CLIENT code, specifically the ANTFS_DownloadInputData() function, that the entire burst does not end until all bytes in the entire file are sent out. The problem is that we are reading 64 bytes at a time from flash and the burst is timing out(EVENT_TRANSFER_TX_FAILED) before we start to send the next 64 bytes of data due to delays from each flash read.

Am I understanding the ANTFS_EMBEDDED_CLIENT code correctly? If we delay too long between each 64 byte burst, do we need to rewrite a bulk of the ANTFS_EMBEDDED_CLIENT code in order to end each burst after 64 bytes or is there something simpler, such as a timeout that we can adjust?

Greatly appreciate your help.

Thanks,
Harvey      

Your understanding is correct. Bursting is a very time sensitive operation, and pausing to retrieve data from flash can cause the burst to fail. The ANT-FS embedded client reference code will attempt to burst the entire file in a single block.

When reading data from flash, you could try to buffer more data in advance, when you get the download request. If you are unable to do this, you could use the block size (total remaining data length) parameter in the download request response to intentionally transfer the file in multiple blocks. Refer to Section 12.7.2 of the ANT-FS Technology Specification for more details on this parameter.      

Hi,

Just a clarification, is this how we would use the Total Remaining Data Length field?

1) The PC Host sends a download request to a client.
2) The client sends back a download request response with the file size as 3k bytes, and Total Remaining Data Length as 64 bytes(for example).
3) The client bursts 64 bytes worth of data with a CRC footer packet.
4) The client repeats step 3 until all 3k bytes have been sent.


Thanks,
Harvey      

1-3 is correct.

The client then would have to wait for the host to request the next block, so steps 1-3 repeat until the file is complete.      

Hi Alejandra,

We implemented your suggestion and we now have ANTFS transferring a large file to the host PC (300k) with 3k burst blocks. However, it does not always complete successfully. About half the time we are experiencing one of two problems.

1) The download progress would restart to 0% randomly and the entire transfer is restarted. We looked at the log files and found that it is due to the CRC not matching up when it requests the next burst block. It also appears that we get the CRC error right after the PC host receives a EVENT_RX_FAIL. So it appears that the CRC does not get updated correctly when an EVENT_RX_FAIL occurs. Is there a way to reduce the amount of EVENT_RX_FAILs or should attempt to modify the client code so that the CRC is fault tolerant?

2) We would periodically get a "Error: Download Rejected" message during a download on the Host PC. This mainly occurs when we interrupt the communication channel. For example, sometimes just moving the ANT dongle around would cause it to occur. Is this error due to failing the 5 retries? If so, is it possible to increase the amount of retries to make the system more tolerable in a less than perfect environment?

Thanks for all the help,
Harvey      

1) EVENT_RX_FAIL is related to RF performance. If you are seeing a significant number of RX fails, you might need to review the RF design of the embedded device.

The ANT-FS client embedded reference design is a bit limited, as it does not have real a file system, and generates data for download on the fly. For this reason, it is unable to calculate the CRC for an arbitrary offset - it generates one block of data (64 bytes) at a time, and saves the CRC at that point. If the host requests an offset before the last save point, the reference design is unable to calculate the CRC, and will reject the request with a CRC error. In a custom implementation, with real files, you should be able to properly calculate the CRC in that case so that you don't need to resume the file from the beginning. Placing a breakpoint in the client code where CRC verification is done might help you check what value is sent by the host, and what is being expected at the client.

2) The debug logs on the host tool would show the reason for the error. The download function on the PC host does more than 5 retries when handling a download; the AttemptDownload() function on antfs_host.cpp handles this. You could modify this function to make it "try harder", but there may be another reason for this problem. Could you post the logs?      

Hi Alejandra,

I am seeing the CRC limitation that you are referring to. I think our two issues we have are related to this problem.

As I view the logs and breakpoints, I am seeing that the saved CRC offset on the client is 3456, while the CRC offset sent by the host is 3400 when a CRC error occurs. (one example)
So this is telling me that the host is calculating the CRC for every 8 bytes received, while the client is calculating the CRC after every 64 bytes. This also shows that the host is requesting an offset that is before the last save point.

If this is correct, it means that the current implementation is easily prone to complete failures if given the following likely scenario:

1) The client starts a burst to send 300kB of data
2) The client reads 64 bytes of data from flash (assume negligible delay)
3) The client bursts 64 bytes of data to the host
4) The client updates its own CRC for the 64 bytes
5) The client repeats steps 2 to 4 for the first 3392 bytes

6) The client reads the next 64 bytes of data from flash
7) The client bursts the 64 bytes of data to the host
8) The client updates its own CRC for the 64 bytes, ending with a 3456 CRC offset
9) The host only successfully receives 8 out 64 bytes of data and causes a EVENT_TRANSFER_TX_FAILED to appear on the client
10) The host attempts to resume by sending a download request with CRC offset, 3400
11) The client attempts to resume, but its CRC is 3456 and greater than the client's 3400, thus causing an error

Does this confirm everything you were mentioning? If so, would this be how we could fix the problem?
- If the host's CRC offset is less than the client's CRC offset, assume the host is correct and set the client's CRC offset to 3400 and continue by using the host's CRC seed?

Thanks for all the support,

Harvey      

Yes, you are correct. That is a limitation on the client reference design. However, since you are able to read 300K of data from flash at a time, if the offset requested by the host is less than the last save point at the client, you could recalculate the CRC from the beginning of the 300K block up to the requested offset and then compare.