Re: APRSIS settings for ISS


Lynn Deffenbaugh
 

The key assumption in the Reply-Acks spec is the first line of the Summary:

Original APRS ACK:  {#####  <== There were no restrictions on #####

And in the original spec, why qualify "5 alphanumeric characters" with "no spaces" when a space isn't alpha-numeric anyway?

The simple fix is to use up to all 5 characters after the { regardless of what they are as that is the assumption in Reply-Ack.

I was always bothered by the fact that it is a "message number" that isn't numeric!

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 7/15/2020 6:13 PM, Heikki Hannikainen wrote:

Hi,

My app currently does not implement the replyacks protocol (other than ignoring it). I couldn't quite parse out the document on how it should actually work and didn't have time to reverse engineer it yet.

As per APRS101.PDF "The message identifier consists of the character { followed by a message number (up to 5 alphanumeric characters, no spaces) to identify the message." and so the app currently only returns the message ID (alphanumeric!) in the ack, and not the trailing } sent by SatSrv.

And yep, orphan or duplicate/delayed acks may well happen at times.


On Wed, 15 Jul 2020, Lynn W Deffenbaugh (Mr) wrote:

Hessu - You may want to read this and also http://www.aprs.org/aprs11/replyacks.txt

4) When you receive a message line XXX.., send the normal existing
    "ackXXX..". This algoirithm is unchanged.  Even if XXX.. is MM}AA
    then the ack is just the exact copy as before "ackMM}AA"

It appears that your app is not properly acknowledging the responses from the SatSrv.  It uses "Reply-Ack" formatting, but your application is stripping off the final character of the ack string.  Consider the following raw packets captured from aprs.fi.

2020-07-15 08:39:28 CDT: WM6H-4>APFII0,qAC,APRSFI::ISS      :ISS{B3421
2020-07-15 08:39:29 CDT: ISS>APWW10,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :ackB3421
2020-07-15 08:39:29 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h32m (16 0111z) SE^6{NK}
2020-07-15 08:39:38 CDT: WM6H-4>APFII0,qAC,APRSFI::ISS :ackNK
2020-07-15 08:39:40 CDT: WM6H-4>APFII0,W0GQ-1,WIDE1*,WIDE2-1,qAR,KW0O-12:@133938h4201.25N/09141.36W-195/000APRS message enabled!w+R!
2020-07-15 08:40:03 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h32m (16 0111z) SE^6{NK}
2020-07-15 08:40:36 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h32m (16 0111z) SE^6{NK}
2020-07-15 08:41:39 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h32m (16 0111z) SE^6{NK}
2020-07-15 08:42:52 CDT: WM6H-4>APFII0,W0GQ-1,WIDE1*,WIDE2-1,qAR,KW0O-12:@134248h4201.25N/09141.37W-298/000APRS message enabled!w21!
2020-07-15 08:43:16 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h32m (16 0111z) SE^6{NK}

2020-07-15 08:43:16 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h31m (16 0111z) SE^6{NL}
2020-07-15 08:43:25 CDT: WM6H-4>APFII0,qAC,APRSFI::ISS :ackNL
2020-07-15 08:43:48 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h31m (16 0111z) SE^6{NL}
2020-07-15 08:44:21 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h31m (16 0111z) SE^6{NL}
2020-07-15 08:45:25 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h31m (16 0111z) SE^6{NL}
2020-07-15 08:47:01 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h31m (16 0111z) SE^6{NL}

2020-07-15 08:47:01 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h28m (16 0111z) SE^6{NM}
2020-07-15 08:47:33 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h28m (16 0111z) SE^6{NM}
2020-07-15 08:48:06 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h28m (16 0111z) SE^6{NM}
2020-07-15 08:49:10 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h28m (16 0111z) SE^6{NM}
2020-07-15 08:50:46 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h28m (16 0111z) SE^6{NM}
2020-07-15 08:52:20 CDT: WM6H-4>APFII0,qAC,APRSFI::ISS :ackNM

2020-07-15 08:52:21 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h19m (16 0111z) SE^6{NN}
2020-07-15 08:52:25 CDT: WM6H-4>APFII0,qAC,APRSFI::ISS :ackNN
2020-07-15 08:52:54 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h19m (16 0111z) SE^6{NN}
2020-07-15 08:53:18 CDT: WM6H-4>APFII0,qAC,APRSFI::ISS :ackNN
2020-07-15 08:53:26 CDT: ISS>APWW10,KJ4ERJ-15*,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 11h19m (16 0111z) SE^6{NN}

The ack string from your app should have been "ackNK}", but it only sent "ackNK".  Since this wasn't the expected ack, SatSrv continued retrying the message, but your app only seems to have acked it once, or the APRS-IS dupe-suppressed the others.  But then it gets interesting...

Apparently, since the ackNK didn't match any outstanding messages, APRSIS32 (the host for SatSrv) passed it on to SatSrv. Since SatSrv doesn't care what the body of the message is (except for known stations, see below), it thought the mis-matched ack was a new request, so it queued up another response to be sent when the retries from the first one were exhausted.  When that was sent with {NM}, your app ack'd with ackNM which also didn't match so it queued up another response.  And so the cycle continued.

Please do be cautious of what the message content is that you send to SatSrv.  If the message body is a known APRS station ID, you will get the next pass prediction for the last known location of THAT station and not your own.  So sending "ISS" as the body of the request is not only redundant, but could have looked at the last location of the ISS object and given a pass prediction from there.  It turns out it didn't do that, or the information would have been in the body of the response like (note the @ KQ1L-4):

AOS 2h03m (2339z) SE^4 @ KQ1L-4 (*2-17:36:00)

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  I think I'll make SatSrv ignore any orphan ack's rather than treating them as a new request and document the fact that the message body should not start with "ack" or you will not get a response.

On 7/15/2020 3:55 PM, bobolink wrote:

    Send an APRS message by any method (Internet is probably best) to
    the satellite name, and you'll get a reply message with
    information showing the next pass.  So, just send a message to
    "ISS".  The message text can be anything (it's not used).  Be sure
    to beacon where you are first.

That worked but is there a way to stop the messages? This may be a problem in the iOS message app I’m using:



  - Hessu



Join APRSISCE@groups.io to automatically receive all group messages.