APRS Messaging: Ack/Nak Process and (potentially) speed of sending data to APRS-IS

Issue #82 resolved
Joerg Schultze-Lutter created an issue

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:

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)

  1. Joerg Schultze-Lutter reporter

    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.

  2. Log in to comment