Re: APRSIS settings for ISS


Gervais Fillion <ve2ckn2@...>
 

hello
i would like to see your filter guys,
how do you write the line,is it possible?


i would compare with mine here if i am ok,

thanks
gervais ve2ckn



De : APRSISCE@groups.io <APRSISCE@groups.io> de la part de Lynn Deffenbaugh <kj4erj@...>
Envoyé : 15 juillet 2020 17:39
À : APRSISCE@groups.io <APRSISCE@groups.io>
Objet : Re: [APRSISCE] APRSIS settings for ISS
 

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:

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