Skip to content
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

parse() cannot handle special characters in message ID #53

Open
stroobandt opened this issue Oct 5, 2019 · 2 comments
Open

parse() cannot handle special characters in message ID #53

stroobandt opened this issue Oct 5, 2019 · 2 comments

Comments

@stroobandt
Copy link

stroobandt commented Oct 5, 2019

Even though the APRS specification states message IDs ought to be alphanumerical, in practice one now routinely sees any group of five printable ASCII characters as a message ID behind the {.

Could you please fix this and make it available on PyPI? I am trying to develop an application using your library for the upcoming scouts JOTA event, but unfortunately, I need to jump through hoops to circumvent these special message IDs. Thanks & 73 de ON4AA

@stroobandt stroobandt changed the title parse() cannot handle special characters in message ID parse() cannot handle special characters in message ID Oct 5, 2019
@rossengeorgiev
Copy link
Owner

Could you provide examples of such messages?

Just because someone is not following that spec, doesn't mean we have to change the library to accommodate their misuse. Exception being if the practice gets widely adopted.

@stroobandt
Copy link
Author

stroobandt commented Mar 21, 2022

Here is already one official protocol reason why special characters should be allowed:
http://www.aprs.org/aprs11/replyacks.txt

Apart from that, I occasionally have seen the piggy bagging of data instead of line numbers. Lookout for these on raw aprs.fi, after logging in: https://aprs.fi/?c=raw&call=&limit=1000&view=normal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants