Date   

Re: qty or freq tune.

Brad Ko6kL
 

I would love to see a youtube video of this repeater object showing up on the Kenwood710 and what buttons to press go get a QSY.
I think the new big display yeasu duel bander will do this as well...
again I would like to see some software that receives this repeater object from aprs and uses the CAT to tune my Kenwood 2000 like that....
it would seem you could scan the logging files for the object and output that to the radios cat input.
or maybe someday have it all running on some guys web-sdr for remote users poking about.
It would be nice to know if I'm getting the object syntax right with out having to buy a kenwood710







Re: APRSIS settings for ISS

bobolink
 

I guess you should close out the session.
On the Mac ctrl+] 
ctrl+z to exit Telnet 


Re: APRSIS settings for ISS

bobolink
 

This is kind of interesting. While Hessu is fixing the iOS app, I thought I’d try it myself on the Mac so I looked all this up on the internet. You need to get a APRS-IS password nnnn
||||||||||||||||||||||||||||||||||||||||||||||||

telnet -c noam.aprs2.net 14580

user wm6h-4 pass nnnn

|||||||||||||||||||||||||||||||||||||||||||||||||
1>Beacon your position. Change the position from my house to yours. A little man symbol shows up at your house on aprs.fi 

WM6H-4>APFII0,WIDE1-1,WIDE2-1:!4201.25N/09141.37W[/Test Message1
2>The actual request. You might have to wait a few minutes for the beacon to be registered. You will get the “Please Beacon Your Position” message in the mean time. Just make up a sequence number

WM6H-4>APRS::ISS      :{0005

2A>The request acknowledgment 

ISS>APWW11,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :ack0005

 

3>The ISS pass

ISS>APWW11,KJ4ERJ-15,TCPIP*,qAS,KJ4ERJ-15::WM6H-4   :AOS 6h31m (2335z) SE^20{RQ}

4>The pass acknowledgement

WM6H-4>APRS::ISS      :ackRQ}

 

I don’t know what this is:

KJ4ERJ-15>APZTLE,TCPIP*,qAC,SEVENTH:;ISS      *163224h0607.91S\17432.71ESMsg4Pass }k1jzNqg\wBx+i"N+3B$\%q5zN{!wf+!

I’ll be listening!


Bob
wm6h


Re: qty or freq tune.

Rob Giuliano
 

There is a perspective that needs to be taken into account.
It is possible for the D710 to receive a packet with QSY information and tune to the provided frequency with the proper tone, etc. on its display that you can select and the radio will change frequency. This is handled by the radio itself.

APRSIS (assumed to mean APRSIS32 and not the internet backbone) cannot tell an attached D710 to change frequency and tone (CAT functions for a computer to make the radio act) so that the user can make a voice contact. 

APRSIS32 "CAN" send the properly formated object to tell someone that is driving by (or in any way) using a QSY enabled device (like the D710 radio) that "you" are listening and available on a voice frequency.  This is why it is listed in the Configure Object section of the WIKI.  It does not change the radio attached to the computer running APRSIS32, but requests someone else's radio to change frequency to what you sent and you are listening for voice communication.

So if you wanted to take advantage, you probably need another radio, or at least a radio capable of running packet on one side and voice on the other at the same time.  Then create an object that has the frequency and tone information of the radio you are listening to, send the object periodically while you are listening to that voice frequency listed, and wait for someone to "click" your object.

I hope this helps explain it. 

Robert Giuliano
KB8RCO



On Monday, July 20, 2020, 6:04:49 PM EDT, T W via groups.io <kf6kyd@...> wrote:


In the past I have asked if its possible to tune a D710 to the frequency listed in the frequency monitor. I was told it is a cat function which is something APRSIS does not do. In reading the Wiki it looks like it does work that way. The function in called QSY, and its description is discussed on the configure objects page. Would it be possible to get some clarification on this?

Cheers
kf6kyd


qty or freq tune.

T W
 

In the past I have asked if its possible to tune a D710 to the frequency listed in the frequency monitor. I was told it is a cat function which is something APRSIS does not do. In reading the Wiki it looks like it does work that way. The function in called QSY, and its description is discussed on the configure objects page. Would it be possible to get some clarification on this?

Cheers
kf6kyd


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:


Re: APRSIS settings for ISS

Lynn Deffenbaugh
 

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:


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




Re: APRSIS settings for ISS

bobolink
 

On Wed, Jul 15, 2020 at 05:13 PM, Heikki Hannikainen wrote:
  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.
Noted.
Thanks guys.

Bob
wm6h


Re: APRSIS settings for ISS

Heikki Hannikainen
 

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


Re: APRSIS settings for ISS

Lynn Deffenbaugh
 

What is the callsign-SSID of that instance and what iOS app are you using?  Did you look at your raw packets?

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

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:


Re: APRSIS settings for ISS

bobolink
 

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:


Re: Google Maps to GPX

Min
 

Thanks Fred…

 

Min G0JMS

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Fred Hillhouse
Sent: 14 July 2020 20:31
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Google Maps to GPX

 

A long time ago I purchased ExpertGPS for some other stuff I was doing. I never really liked Basecamp (BC). The free map options was not pretty enough.

 

I too have found paths that did not work. One that sticks in my mind was a relatively local bridge that was out of service. I could not figure out why Google would not route over it until I did my trip. At the time there was no indication the bridge was out of service.

 

I used Google My Maps as well. It will export to an KML which I had to convert to GPX.

 

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Min via groups.io
Sent: Tuesday, July 14, 2020 3:13 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Google Maps to GPX

 

Hi Fred

 

Thanks for the link and will try it but I normally use Basecamp for any mapping and routes, motor biking(motorcycling) or car.

With the controls that BC has a true time for the setup but doesn’t have the road closure at that time….

I’ll try anything once J….

 

I’m an active user of Google and used to use MyRoute APP when it Tyre to Travel and wondered why a route would not work (The road through the Alps was closed due to rock fall) making it a 120 km reroute !!! Google intelligence at the time but since they started charging up to the minute planning has gone from some routing websites.

 

So plan it on BC and then check on Google for road works and closure nearer the time.

 

My routes taken are then put into BC and it’s worrying the information available to you and others!!!!!!

 

Min G0JMS

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Fred Hillhouse
Sent: 13 July 2020 23:17
To: APRSISCE@groups.io
Subject: [APRSISCE] Google Maps to GPX

 

Greetings,

 

It has been a while since I tried converting a Google Maps travel solution to GPX. I just tried it and had success. It has never been simpler!

 

https://mapstogpx.com/

 

Give it a shot!

 

Best regards,

Fred N7FMH

 


Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com

 


Re: Google Maps to GPX

Fred Hillhouse
 

A long time ago I purchased ExpertGPS for some other stuff I was doing. I never really liked Basecamp (BC). The free map options was not pretty enough.

 

I too have found paths that did not work. One that sticks in my mind was a relatively local bridge that was out of service. I could not figure out why Google would not route over it until I did my trip. At the time there was no indication the bridge was out of service.

 

I used Google My Maps as well. It will export to an KML which I had to convert to GPX.

 

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Min via groups.io
Sent: Tuesday, July 14, 2020 3:13 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Google Maps to GPX

 

Hi Fred

 

Thanks for the link and will try it but I normally use Basecamp for any mapping and routes, motor biking(motorcycling) or car.

With the controls that BC has a true time for the setup but doesn’t have the road closure at that time….

I’ll try anything once J….

 

I’m an active user of Google and used to use MyRoute APP when it Tyre to Travel and wondered why a route would not work (The road through the Alps was closed due to rock fall) making it a 120 km reroute !!! Google intelligence at the time but since they started charging up to the minute planning has gone from some routing websites.

 

So plan it on BC and then check on Google for road works and closure nearer the time.

 

My routes taken are then put into BC and it’s worrying the information available to you and others!!!!!!

 

Min G0JMS

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Fred Hillhouse
Sent: 13 July 2020 23:17
To: APRSISCE@groups.io
Subject: [APRSISCE] Google Maps to GPX

 

Greetings,

 

It has been a while since I tried converting a Google Maps travel solution to GPX. I just tried it and had success. It has never been simpler!

 

https://mapstogpx.com/

 

Give it a shot!

 

Best regards,

Fred N7FMH

 


Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com

 


Re: Google Maps to GPX

Fred Hillhouse
 

For a while mapstogpx did not work. It was after one of the big Google map changes. I am glad it is working again. I have tried other methods and some were better than others. I quickly made a collection of tracks that covered a few was to a destination.

 

Fred N7FMH

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Stan Leeds
Sent: Monday, July 13, 2020 9:17 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Google Maps to GPX

 

I've used it a lot.� Did some mapping for Amtrak routes that my wife and I will do with APRSIS32 once this virus thing gets more under control.� Its good when you only need routes as defined by Google Maps.

Another one I have used was www.mapmyride.com.� I paid for the low range offering to support, but it's pluses were when you need to change from roads or documented pathways to say through a fence gate or using a foot path, you are able to change the tool that documents that and then you can output as a GPX with no hand editing the file.� Used for a number of bike and marathons here and again with APRSIS32. (No affiliation just the one I came across that worked for what I needed)

Cheers and 73,
Stan, KC7EHJ

 

On 7/13/2020 6:17 PM, Fred Hillhouse wrote:

Greetings,

�

It has been a while since I tried converting a Google Maps travel solution to GPX. I just tried it and had success. It has never been simpler!

�

https://mapstogpx.com/

�

Give it a shot!

�

Best regards,

Fred N7FMH

 


Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com




Re: Google Maps to GPX

Min
 

Hi Fred

 

Thanks for the link and will try it but I normally use Basecamp for any mapping and routes, motor biking(motorcycling) or car.

With the controls that BC has a true time for the setup but doesn’t have the road closure at that time….

I’ll try anything once J….

 

I’m an active user of Google and used to use MyRoute APP when it Tyre to Travel and wondered why a route would not work (The road through the Alps was closed due to rock fall) making it a 120 km reroute !!! Google intelligence at the time but since they started charging up to the minute planning has gone from some routing websites.

 

So plan it on BC and then check on Google for road works and closure nearer the time.

 

My routes taken are then put into BC and it’s worrying the information available to you and others!!!!!!

 

Min G0JMS

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Fred Hillhouse
Sent: 13 July 2020 23:17
To: APRSISCE@groups.io
Subject: [APRSISCE] Google Maps to GPX

 

Greetings,

 

It has been a while since I tried converting a Google Maps travel solution to GPX. I just tried it and had success. It has never been simpler!

 

https://mapstogpx.com/

 

Give it a shot!

 

Best regards,

Fred N7FMH

 


Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com




Re: Google Maps to GPX

Stan Leeds <srkleeds@...>
 

I've used it a lot.� Did some mapping for Amtrak routes that my wife and I will do with APRSIS32 once this virus thing gets more under control.� Its good when you only need routes as defined by Google Maps.

Another one I have used was www.mapmyride.com.� I paid for the low range offering to support, but it's pluses were when you need to change from roads or documented pathways to say through a fence gate or using a foot path, you are able to change the tool that documents that and then you can output as a GPX with no hand editing the file.� Used for a number of bike and marathons here and again with APRSIS32. (No affiliation just the one I came across that worked for what I needed)

Cheers and 73,
Stan, KC7EHJ

On 7/13/2020 6:17 PM, Fred Hillhouse wrote:

Greetings,

�

It has been a while since I tried converting a Google Maps travel solution to GPX. I just tried it and had success. It has never been simpler!

�

https://mapstogpx.com/

�

Give it a shot!

�

Best regards,

Fred N7FMH




Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



Google Maps to GPX

Fred Hillhouse
 

Greetings,

 

It has been a while since I tried converting a Google Maps travel solution to GPX. I just tried it and had success. It has never been simpler!

 

https://mapstogpx.com/

 

Give it a shot!

 

Best regards,

Fred N7FMH




Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



Re: Passcode request (posted to main group)

Rob Giuliano
 

He has been sending emails direct to me and I have tried to cross post, but his replies always come back to me alone.
It appears he has moved on to a different client.  He didn't say which.

I did ask him to check the folder that he ran APRSIS32.exe from, to see if there is an APRSIS32.xml file in it.
I am pretty sure I tried this from work (with restricted internet access allowing no maps), it created the xml, but left the screen blank (no map).

If there was na XML but no OSMTiles folder, I would guess #1.
No XML, and it was definitely run from within the zip.

I just don't know if he will take the time to look.

Robert Giuliano
KB8RCO



On Sunday, July 5, 2020, 8:33:25 PM EDT, Lynn Deffenbaugh <kj4erj@...> wrote:


You can download the .ZIP file to anywhere.  It is critically important, however, that you UNZIP the contents into a newly-created, empty, and not protected (like not under Program Files) directory.  Then make sure you execute APRSIS32.EXE from within that newly created directory.

By placing the .ZIP into the directory where you unzipped it, it is still possible that you double-clicked a folder view of the .ZIP and not the unzipped .EXE file.

The behavior you are describing may be Rob's first issue, but it certainly describes what you see when you double-click a .ZIP view.

Try going to the following URL and see if you get a map tile.


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

On 7/5/2020 6:43 PM, Rob Giuliano via groups.io wrote:
Cross posting to the APRSIS32 group.

That sounds like 2 possibilities:
1. having an issue connectin to the internet (port blockled) and you can't download maps
    I know I can't download maps when I am at work - it is blocked.
2. the folder access for either the APRSIS32.xml or maps

Is there an APRSIS32.XML file in the folder you tried installing it into?
You can attach that and maybe there will be a clue.

Robert Giuliano
KB8RCO

PS: Please reply to all to post to the APRSIS32 groips.io board.


On Sunday, July 5, 2020, 5:28:45 PM EDT, David George <va3dpg@...> wrote:


Robert, thank you for emailing me back.

After downloading the zip file to the C drive into its own folder,(not under programs) I unzipped the file. It required me to insert my call sign and the pass code you gave me.

After entering this I was expecting the map to show up for me to enter my location, as shown by the video? All that would show up was a white box across my screen a half inch wide 6 inchess long with a small blue square flashing on and off.

I tried many times and gave up.

David va3dpg

On Sun, Jul 5, 2020 at 4:44 PM Rob Giuliano <kb8rco@...> wrote:
I don't remember seeing another post, or I deleted the update and not the original.
Did you ever get this working?

Robert Giuliano
KB8RCO



On Thursday, July 2, 2020, 9:14:12 PM EDT, David George <va3dpg@...> wrote:


When starting the exe file you are required to enter call sign and ssid, and enter. That’s is as far as I can get


On Jul 2, 2020, at 9:09 PM, Rob Giuliano <kb8rco@...> wrote:

I am not sure what you are referring to with"Filled the required fields on start up.  Aprsis32 no responding message?"
What are you expecting?

Are you getting stations in the scroll bar (left side) that are coming in from APRS-IS?

You can check your status by enabling logging
  >Menu >Enables >logging >Port(APRSIS)
This will allow you to see the interaction with the APRS-IS server.

If you disable APRS-IS and re-enable the port with logging, you can see if there are any errors

Robert Giuliano
KB8RCO



On Thursday, July 2, 2020, 6:35:27 PM EDT, David George <va3dpg@...> wrote:


Thanks for the code. Filled the required fields on start up. Aprsis32 no responding message?


On Jul 2, 2020, at 5:40 PM, Rob Giuliano <kb8rco@...> wrote:

<passcode info removed>


On Thursday, July 2, 2020, 5:14:43 PM EDT, David George <va3dpg@...> wrote:


Please provide a passcode for David George call sign VA3DPG.

Thank you.


Re: Passcode request (posted to main group)

Lynn Deffenbaugh
 

You can download the .ZIP file to anywhere.  It is critically important, however, that you UNZIP the contents into a newly-created, empty, and not protected (like not under Program Files) directory.  Then make sure you execute APRSIS32.EXE from within that newly created directory.

By placing the .ZIP into the directory where you unzipped it, it is still possible that you double-clicked a folder view of the .ZIP and not the unzipped .EXE file.

The behavior you are describing may be Rob's first issue, but it certainly describes what you see when you double-click a .ZIP view.

Try going to the following URL and see if you get a map tile.


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

On 7/5/2020 6:43 PM, Rob Giuliano via groups.io wrote:
Cross posting to the APRSIS32 group.

That sounds like 2 possibilities:
1. having an issue connectin to the internet (port blockled) and you can't download maps
    I know I can't download maps when I am at work - it is blocked.
2. the folder access for either the APRSIS32.xml or maps

Is there an APRSIS32.XML file in the folder you tried installing it into?
You can attach that and maybe there will be a clue.

Robert Giuliano
KB8RCO

PS: Please reply to all to post to the APRSIS32 groips.io board.


On Sunday, July 5, 2020, 5:28:45 PM EDT, David George <va3dpg@...> wrote:


Robert, thank you for emailing me back.

After downloading the zip file to the C drive into its own folder,(not under programs) I unzipped the file. It required me to insert my call sign and the pass code you gave me.

After entering this I was expecting the map to show up for me to enter my location, as shown by the video? All that would show up was a white box across my screen a half inch wide 6 inchess long with a small blue square flashing on and off.

I tried many times and gave up.

David va3dpg

On Sun, Jul 5, 2020 at 4:44 PM Rob Giuliano <kb8rco@...> wrote:
I don't remember seeing another post, or I deleted the update and not the original.
Did you ever get this working?

Robert Giuliano
KB8RCO



On Thursday, July 2, 2020, 9:14:12 PM EDT, David George <va3dpg@...> wrote:


When starting the exe file you are required to enter call sign and ssid, and enter. That’s is as far as I can get


On Jul 2, 2020, at 9:09 PM, Rob Giuliano <kb8rco@...> wrote:

I am not sure what you are referring to with"Filled the required fields on start up.  Aprsis32 no responding message?"
What are you expecting?

Are you getting stations in the scroll bar (left side) that are coming in from APRS-IS?

You can check your status by enabling logging
  >Menu >Enables >logging >Port(APRSIS)
This will allow you to see the interaction with the APRS-IS server.

If you disable APRS-IS and re-enable the port with logging, you can see if there are any errors

Robert Giuliano
KB8RCO



On Thursday, July 2, 2020, 6:35:27 PM EDT, David George <va3dpg@...> wrote:


Thanks for the code. Filled the required fields on start up. Aprsis32 no responding message?


On Jul 2, 2020, at 5:40 PM, Rob Giuliano <kb8rco@...> wrote:

<passcode info removed>


On Thursday, July 2, 2020, 5:14:43 PM EDT, David George <va3dpg@...> wrote:


Please provide a passcode for David George call sign VA3DPG.

Thank you.