-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timeout issues and filter module #6
Comments
Yeah, this is one of the worst problems with openant. It should be possible to recover from most problems, even if it means you have to go to search and restart communication. There is some error recovery in openant but obviously it is not enough. More explicit error messages, i.e. more types of different exceptions is probably a good start. Not sure where the added |
Currently, i didn't analyze enough to find out exactly where the I'll try to make more tests and build a PR to enhance this part of openant in the next few days. Do you have access to any documentations about those events ? Best source i've found is here : https://devzone.nordicsemi.com/answers/18680/revisions/ but maybe you have something more precise ? |
You want the official documentation on http://www.thisisant.com/developer/resources/downloads/#documents_tab. A lot of the documentation is freely available. The ANT Message Protocol and Usage is documenting the ANT protocol, probably want to start there. The channel events are in section 9.5.6. This document have been updated since I last looked at it so the feature gap from |
The documentation that are not available freely is mostly related to ANT-FS, ANT+ and FIT -- those unfortunately requires you to agree to the ANT Adopters agreement or the FIT license to read, just so you are aware of that, which adds some restrictions on you. But for the |
I often have to start
antfs-cli
again 1 or 2 times to get the files downloading without those timeout issues.I think there's a small design issue in
ant.easy.filter
module that prevents protocol error message to be displayed properly to the user, and that could be used to retry the request properly.wait_for_message function works nicely when all is working like expected. But the output is cryptic when the device sends an error message.
There are some hardcoded events (EVENT_TRANSFER_TX_FAILED & EVENT_RX_FAIL_GO_TO_SEARCH) that raise a more readable error, but i think an explicit error message should be displayed for every possible error message. Also, the retry on error should be more explicit.
Maybe the signature of
wait_for_message(match, process, queue, condition)
could be changed to something likewait_for_message(match, error_match, process, queue, condition)
whereerror_match
is a function that returns an Exception if an error message has been received ?The text was updated successfully, but these errors were encountered: