APRS Messaging: Ack/Nak Process and (potentially) speed of sending data to APRS-IS
There seems to be an issue with the ack/nak handling of APRS messages when you send a message to a user. Do the following:
Send a message to e.x. WXBOT such as “tomorrow”. You will receive this end user result (your output will look different as WXBOT does only work for U.S. addresses - I am located in Germany).
When looking at the traffic, you can see that QTH did not only send one request - but three of them. Additionally, the message status is still set to ‘failed’. Maybe this is a timing issue as I also only see two ACK messages.
I believe that the FIRST message (line 2) below must NOT be send with the trailing message part (MQ) - see links below.
1) Send all MSG numbers in the new {MM}AA format. AA is null if none.
But AA is only appended at the INSTANT of transmission. For the
same MM message, the AA must always represent the "latest" outstanding
ACK for that station. It may change at future retries...
2021-03-15 12:42:07,255 - aprs_listen -INFO - Starting callback consumer
2021-03-15 12:42:36,340 - aprs_listen -INFO - {'raw': 'DF1JSL-10>APQTH1,TCPIP*,qAC,T2SP::WXBOT :tomorrow{01}MQ', 'from': 'DF1JSL-10', 'to': 'APQTH1', 'path': ['TCPIP*', 'qAC', 'T2SP'], 'via': 'T2SP', 'addresse': 'WXBOT', 'format': 'message', 'message_text': 'tomorrow{01}MQ'}
2021-03-15 12:42:39,404 - aprs_listen -INFO - {'raw': 'WXBOT>APRS,qAS,KI6WJP::DF1JSL-10:Sorry, unable to get a forecast for location 51.83883/8.32683{MR}01', 'from': 'WXBOT', 'to': 'APRS', 'path': ['qAS', 'KI6WJP'], 'via': 'KI6WJP', 'addresse': 'DF1JSL-10', 'format': 'message', 'message_text': 'Sorry, unable to get a forecast for location 51.83883/8.32683{MR}01'}
2021-03-15 12:42:39,719 - aprs_listen -INFO - {'raw': 'DF1JSL-10>APQTH1,TCPIP*,qAC,T2SP::WXBOT :tomorrow{01}MR', 'from': 'DF1JSL-10', 'to': 'APQTH1', 'path': ['TCPIP*', 'qAC', 'T2SP'], 'via': 'T2SP', 'addresse': 'WXBOT', 'format': 'message', 'message_text': 'tomorrow{01}MR'}
2021-03-15 12:42:47,059 - aprs_listen -INFO - {'raw': 'WXBOT>APRS,qAS,KI6WJP::DF1JSL-10:Sorry, unable to get a forecast for location 51.83883/8.32683{MS}01', 'from': 'WXBOT', 'to': 'APRS', 'path': ['qAS', 'KI6WJP'], 'via': 'KI6WJP', 'addresse': 'DF1JSL-10', 'format': 'message', 'message_text': 'Sorry, unable to get a forecast for location 51.83883/8.32683{MS}01'}
2021-03-15 12:42:47,455 - aprs_listen -INFO - {'raw': 'DF1JSL-10>APQTH1,TCPIP*,qAC,T2SP::WXBOT :tomorrow{01}MS', 'from': 'DF1JSL-10', 'to': 'APQTH1', 'path': ['TCPIP*', 'qAC', 'T2SP'], 'via': 'T2SP', 'addresse': 'WXBOT', 'format': 'message', 'message_text': 'tomorrow{01}MS'}
2021-03-15 12:42:47,569 - aprs_listen -INFO - {'raw': 'DF1JSL-10>APQTH1,TCPIP*,qAC,T2SP::WXBOT :ackMS}01', 'from': 'DF1JSL-10', 'to': 'APQTH1', 'path': ['TCPIP*', 'qAC', 'T2SP'], 'via': 'T2SP', 'addresse': 'WXBOT', 'format': 'message', 'message_text': 'ackMS}01'}
2021-03-15 12:42:55,547 - aprs_listen -INFO - {'raw': 'WXBOT>APRS,qAS,KI6WJP::DF1JSL-10:Sorry, unable to get a forecast for location 51.83883/8.32683{MT}01', 'from': 'WXBOT', 'to': 'APRS', 'path': ['qAS', 'KI6WJP'], 'via': 'KI6WJP', 'addresse': 'DF1JSL-10', 'format': 'message', 'message_text': 'Sorry, unable to get a forecast for location 51.83883/8.32683{MT}01'}
2021-03-15 12:42:55,841 - aprs_listen -INFO - {'raw': 'DF1JSL-10>APQTH1,TCPIP*,qAC,T2SP::WXBOT :ackMT}01', 'from': 'DF1JSL-10', 'to': 'APQTH1', 'path': ['TCPIP*', 'qAC', 'T2SP'], 'via': 'T2SP', 'addresse': 'WXBOT', 'format': 'message', 'message_text': 'ackMT}01'}
In case you want to verify this:
- Install Python on your machine and use e.g. https://github.com/joergschultzelutter/aprstest/blob/master/aprs_listen.py - this is a read-only code snippet from my githib repo. Change the APRS filter. You need to install aprslib via pip - apart from that, there should be no other dependencies.
Process description: http://www.aprs.org/aprs11/replyacks.txt and http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/2011-November/037717.html. For my own APRS bot which will issue no retries, I will also need to understand how this thing works. If you happen to have a good document with some real-life examples on how this bloody thing works, feel free to add those to the ticket.
As a PROPER understanding of how this thing works has been lingering on for a while, I am somewhat tempted to ask for better examples via the TAPR mailing list. My bot supports the “old” ack/rej format as described in aprs101.pdf - but I need to enable the new one as well.
Comments (4)
-
reporter -
repo owner I think this was fixed in 0.1.7. I found a couple problems with ack handling.
-
reporter Confirmedl fixed with 0.1.7
-
reporter - changed status to resolved
Fixed with 0.1.7
- Log in to comment
As a brief update - I have implemented the ‘new’ ack/rej handling in my bot and it seems to be working just fine. If you have any issues with your implementation, I might be able to help.