Date   

PinPoint APRS support?

Lynn Deffenbaugh
 

Does anyone know where the PinPoint APRS author can be reached?  I suspect that package doesn't properly support Reply-Acks in APRS messages.

http://www.aprs.org/aprs11/replyacks.txt

Consider the following message interchange that I just had between APRSIS32 and PinPoint APRS via RobustPacket on 30m:

2021-01-20 16:22:38 EST: WB8SKP-13>APIN20,WIDE1-1,qAR,VE4KLM::KJ4ERJ   :Hello test.{1
2021-01-20 16:22:38 EST: KJ4ERJ>APWW11,TCPIP*,qAC,NINTH::WB8SKP-13:ack1

2021-01-20 16:23:08 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Greetings{HR}
2021-01-20 16:23:08 EST: WB8SKP-13>APIN20,TCPIP*,qAC,T2CAWEST::KJ4ERJ   :ack
2021-01-20 16:23:40 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Greetings{HR}
2021-01-20 16:24:13 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Greetings{HR}
2021-01-20 16:25:17 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Greetings{HR}

2021-01-20 16:25:59 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Pinpoint acks are broken{HS}
2021-01-20 16:25:59 EST: WB8SKP-13>APIN20,TCPIP*,qAC,T2CAWEST::KJ4ERJ   :ack [Duplicate message content]
2021-01-20 16:26:31 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Pinpoint acks are broken{HS}
2021-01-20 16:27:03 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Pinpoint acks are broken{HS}


2021-01-20 16:27:07 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:They don't support Reply-Acks{HT}
2021-01-20 16:27:07 EST: WB8SKP-13>APIN20,TCPIP*,qAC,T2CAWEST::KJ4ERJ   :ack [Duplicate message content]
2021-01-20 16:27:40 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:They don't support Reply-Acks{HT}
2021-01-20 16:28:12 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:They don't support Reply-Acks{HT}

2021-01-20 16:28:40 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:which are non-numeric{HU}
2021-01-20 16:29:14 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:which are non-numeric{HU}
2021-01-20 16:29:47 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:which are non-numeric{HU}
2021-01-20 16:30:52 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:which are non-numeric{HU}

PinPoint is apparently only acking the first reception of a message where the base APRS spec says that ALL receptions should be ack'd.  The reason for this is, even though the destination received the message and issued the ack, the ack may not get back to the source which will then retry the original message resulting in a duplicate message at the destination.  This duplicate MUST be acked in the hopes that eventually the ack gets through to the source which will then quit retrying the message.  In my case, I manually aborted the retries on each message once I was certain it was received on the destination.

Also, notice that PinPoint's acks are missing the sequence "number".  Well, it was called a "number" in the original spec, but was not constrained to be "numeric".  The subsequent Reply-Ack extension took advantage of that by using alpha-numeric and } in the (up to) 5 characters of the ack "sequence".  Because the ack wasn't complete, my station continued to retry the message which, as mentioned above SHOULD have triggered additional acks, even though they would have been incorrect.

WB8SKP-13 then switched to YAAC which gave the following, correct, trace.

2021-01-20 16:32:29 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:which are non-numeric{HU}
2021-01-20 16:32:37 EST: WB8SKP-13>APJYC1,qAR,KB1EJH::KJ4ERJ   :ackHU}

2021-01-20 16:34:21 EST: WB8SKP-13>APJYC1,TEMP1-1,qAR,WA7GMX-1::KJ4ERJ   :OK. Now using YAAC.{M0001
2021-01-20 16:34:21 EST: KJ4ERJ>APWW11,TCPIP*,qAC,NINTH::WB8SKP-13:ackM0001

2021-01-20 16:35:00 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:This should work better.{HV}
2021-01-20 16:35:08 EST: WB8SKP-13>APJYC1,qAR,KB1EJH::KJ4ERJ   :ackHV}

2021-01-20 16:35:17 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Yep, I got a valid ack for that one!{HW}

2021-01-20 16:35:19 EST: WB8SKP-13>APJYC1,TEMP1-1,qAR,WA7GMX-1::KJ4ERJ   :OK. Now using YAAC.{M0001
2021-01-20 16:35:19 EST: KJ4ERJ>APWW11,TCPIP*,qAC,NINTH::WB8SKP-13:ackM0001

2021-01-20 16:35:52 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:Yep, I got a valid ack for that one!{HW}
2021-01-20 16:36:00 EST: WB8SKP-13>APJYC1,qAR,WA7GMX-1::KJ4ERJ   :ackHW}

2021-01-20 16:37:13 EST: WB8SKP-13>APJYC1,TEMP1-1,qAR,KJ4ERJ::KJ4ERJ   :TNX for the help.{M0002
2021-01-20 16:37:13 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:ackM0002

2021-01-20 16:37:17 EST: WB8SKP-13>APJYC1,TEMP1-1,qAR,KB1EJH::KJ4ERJ   :OK. Now using YAAC.{M0001
2021-01-20 16:37:17 EST: KJ4ERJ>APWW11,TCPIP*,qAC,NINTH::WB8SKP-13:ackM0001

2021-01-20 16:37:28 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:I'm writing up the PinPoint issue for aprssig{HX}
2021-01-20 16:38:03 EST: KJ4ERJ>APWW11,TCPIP*,qAC,T2NANJING::WB8SKP-13:I'm writing up the PinPoint issue for aprssig{HX}
2021-01-20 16:38:12 EST: WB8SKP-13>APJYC1,qAR,VE4KLM::KJ4ERJ   :ackHX}

You'll notice that the acks from YAAC correctly include the alphanumeric and } sequence from the message resulting in a much faster exchange without retries.   And YAAC's traditional, although also alphanumeric, sequences (like M0001 and M0002) were properly issued in the return acks.  And even though some messages were duplicated in a retry, acks were correctly issued for the duplicate receptions.

So, if the PinPoint author is not on any of the three addressed groups, please pass this message along to their support channel so that hopefully it's messaging can be fixed.  Reply-Acks don't need to be fully implemented, but whatever "sequence" follows the { in an incoming message, should be copied into the subsequent ack... without modification and such acks should be issued for ALL message receptions, not just the first copy.

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



Re: Important Info regarding the SCS tracker I learned from Lynn!

macclad44@...
 

Todd sorry a bout that excessive verbiage on my part.  Mea culpa.  It will settle down now as it's fixed. I worked on it for well over a man-week with no progress so I was frustrated.


Re: Important Info regarding the SCS tracker I learned from Lynn!

macclad44@...
 

Oh I've copied packets now... hah hah! All good Lynn!


Re: Important Info regarding the SCS tracker I learned from Lynn!

macclad44@...
 

Well it DID say you SHOULD power off and power back on the SCS tracker. I read it, and disregarded it  And I didn't know WHAT a back packet looked like in the logging file .  Lynn honed in on it immediately.
His software is GOOD!  It did all it should. Even with Lynn not being familiar with the SCS tracker he  had the good sense to go BACK to that manual in robust-packet.net and FIND that info.  Info I had ALREADY read.  But it DOES say the 
issue is under investigation so I just blew it off.
All credit goes to Lynn. Also the far right LED should be lit when in Kiss mode. Shhhhoooot I didn't know that!


Re: Iiiiit's woooorrrrking! hah hah! Victory! I now have N7TTQ-9 up and running as a Robust Packet Gateway.

Steve
 

Sorry, I missed that....probably because busy processing the rash of passcode requests we have had lately!

73
Steve,  KF6WAX

On Tue, Jan 19, 2021 at 5:58 PM Lynn Deffenbaugh <kj4erj@...> wrote:

The answer was already posted.  His RF port trace log was saying "Missing C0" indicating that the TNC was not in KISS mode.  Also, the Transmit menu option wasn't keying up the radio, further indicating a problem possibly between APRSIS32 and the TNC.

Then we noticed the following one-liner in https://robust-packet.net/Robust-Packet-Network-Manual.pdf

Anyhow, when restarting APRSIS32 it is vital to switch the tracker powerless for a second (under investigation).

Once the SCS Tracker was powered down with APRSIS32 not running, everything started working fine.

So the final thing is that if you're using an SCS Tracker, you must cycle power before allowing APRSIS32 to talk to it.  This means before starting APRSIS32 and also before Enabling the RF port in a running instance if you disable the port for some reason.

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


On 1/19/2021 12:48 PM, Steve wrote:
So after all that what do we have to do to wring the answer out of you???

73
Steve,  KF6WAX

On Tue, Jan 19, 2021 at 5:01 PM <macclad44@...> wrote:

I gotta give the author, Lynn, K4ERJ all the credit.  The solution ended up simple but without his help, nuh uh.
I just sent a beacon and N0KQX-3 heard me.  Bonus!  And I can hear a bunch of stations.

All good!
Thanks again Lynn!

Jeff


Re: Iiiiit's woooorrrrking! hah hah! Victory! I now have N7TTQ-9 up and running as a Robust Packet Gateway.

Lynn Deffenbaugh
 

The answer was already posted.  His RF port trace log was saying "Missing C0" indicating that the TNC was not in KISS mode.  Also, the Transmit menu option wasn't keying up the radio, further indicating a problem possibly between APRSIS32 and the TNC.

Then we noticed the following one-liner in https://robust-packet.net/Robust-Packet-Network-Manual.pdf

Anyhow, when restarting APRSIS32 it is vital to switch the tracker powerless for a second (under investigation).

Once the SCS Tracker was powered down with APRSIS32 not running, everything started working fine.

So the final thing is that if you're using an SCS Tracker, you must cycle power before allowing APRSIS32 to talk to it.  This means before starting APRSIS32 and also before Enabling the RF port in a running instance if you disable the port for some reason.

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


On 1/19/2021 12:48 PM, Steve wrote:
So after all that what do we have to do to wring the answer out of you???

73
Steve,  KF6WAX

On Tue, Jan 19, 2021 at 5:01 PM <macclad44@...> wrote:

I gotta give the author, Lynn, K4ERJ all the credit.  The solution ended up simple but without his help, nuh uh.
I just sent a beacon and N0KQX-3 heard me.  Bonus!  And I can hear a bunch of stations.

All good!
Thanks again Lynn!

Jeff


Re: Iiiiit's woooorrrrking! hah hah! Victory! I now have N7TTQ-9 up and running as a Robust Packet Gateway.

Steve
 

So after all that what do we have to do to wring the answer out of you???

73
Steve,  KF6WAX

On Tue, Jan 19, 2021 at 5:01 PM <macclad44@...> wrote:

I gotta give the author, Lynn, K4ERJ all the credit.  The solution ended up simple but without his help, nuh uh.
I just sent a beacon and N0KQX-3 heard me.  Bonus!  And I can hear a bunch of stations.

All good!
Thanks again Lynn!

Jeff


Iiiiit's woooorrrrking! hah hah! Victory! I now have N7TTQ-9 up and running as a Robust Packet Gateway.

macclad44@...
 

I gotta give the author, Lynn, K4ERJ all the credit.  The solution ended up simple but without his help, nuh uh.
I just sent a beacon and N0KQX-3 heard me.  Bonus!  And I can hear a bunch of stations.

All good!
Thanks again Lynn!

Jeff


Re: Important Info regarding the SCS tracker I learned from Lynn!

todd.dugdale@...
 

I guess I was hoping that one of the lessons to be learned is "Don't open multiple new topics for the same issue".  Or at least, "Don't open a new topic daily for the same issue". 
Or possibly we could learn that doing this defeats the purpose of the mute function. 
 
I'd have liked that lesson to be absorbed, because it would allow people who aren't interested in the configuration of a TNC they will never own to avoid getting multiple daily emails with the latest thrilling chapter of that struggle. There's little point in muting each thrilling chapter of the struggle, because a new topic will be opened the next day.
 


Re: Important Info regarding the SCS tracker I learned from Lynn!

Lynn Deffenbaugh
 

The biggest lesson to be learned by all is if you see any messages in a KISS-type port trace log that mentions "Missing C0", that means that the TNC said something to APRSIS32 that was not wrapped in a proper KISS packet, likely meaning the TNC is NOT in KISS mode no matter whose instructions were followed to supposedly put it there.

And the Transmit menu option wasn't triggering an actual PTT from the TNC, reinforcing the fact that APRSIS32 and the TNC were likely not communicating properly.

The actual one-liner from the SCS Tracker / APRSIS32 configuration guide at https://robust-packet.net/Robust-Packet-Network-Manual.pdf is:

Anyhow, when restarting APRSIS32 it is vital to switch the tracker powerless for a second (under investigation).

It's only that line coupled with the knowledge of what "Missing C0" means to APRSIS32 that allowed us to get his installation this far.  Presumably it's working but his APRSIS32 instance still hasn't actually copied a packet from the SCS Tracker.  And my own RPR work is not using any SCS hardware, but the new WinRPR sound-card TNC implementation.

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


On 1/19/2021 6:45 AM, todd.dugdale@... wrote:
So this entire epic saga had nothing to do with APRSIS32, or even with APRS at all? It was just technical support for a poorly-documented piece of hardware. 
As someone who muted the original tedious and endless discussion, I especially appreciate how it was turned into a new topic so that everyone who tuned out of the 'thrilling' daily drama got to hear the eye-rolling conclusion.


30m RPR Stations copied

Lynn Deffenbaugh
 

Here's my Heard List from WinRPR having run on 30m overnight, after a few restarts as I worked out the configuration:

WinRPR decodes both AX.25 FSK 300, 1200, and 9600 as well as RPR 300 and 600.  I know at least FSK300 and R300/R600 are concurrently decoded from a single audio source.  The "Mod" column above indicates A and R to differentiate, and I know they match where I see the signal in the water fall.

My "RPR Monitor" APRSIS32 instance now has an additional filter of (those being all of the "R" modulation decodes I've had both before and during the overnight run):

e/DK2EZ-10/EI5HBB-10/HB9ZF-10/IR2UFV-5/K4KPN-10/KO0OOO-6/N2PYI-3/N7TTQ-9/VA3PPI-4/VE2GQF-2 b/DK2EZ-10/EI5HBB-10/HB9ZF-10/IR2UFV-5/K4KPN-10/KO0OOO-6/N2PYI-3/N7TTQ-9/VA3PPI-4/VE2GQF-2

I don't know that all of those stations are IGates, so the e/ on them may be ineffectual, but I know they transmitted an RPR signal at least once.  I've ignored the "A" modulation stations for this test.

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

PS.  Here's a tightly scrunched map of the stations in the monitoring instance in the past 2 hours using the filter above in conjuntion with WinRPR.  The packet scroller is only showing the RF-received packets and I find the lower-case stations rather interesting, but I haven't looked into them in detail yet.



Re: Important Info regarding the SCS tracker I learned from Lynn!

todd.dugdale@...
 

So this entire epic saga had nothing to do with APRSIS32, or even with APRS at all? It was just technical support for a poorly-documented piece of hardware. 
As someone who muted the original tedious and endless discussion, I especially appreciate how it was turned into a new topic so that everyone who tuned out of the 'thrilling' daily drama got to hear the eye-rolling conclusion.


For Lynn: Some RP Igates.. I haven't heard them, I only started from K4KPN and checked all the links to stations which heard this and their links and so on..

macclad44@...
 


Important Info regarding the SCS tracker I learned from Lynn!

macclad44@...
 

Well we'll see when the propagation improves tomorrow but I think we have this solved.
(Mostly me being sillly but Lynn was able to sleuth).
In the config description in Robust-packet.net, it says that you should power down the SCS tracker when getting out of KISS mode or it won't re-enter KISS mode properly.."This is being investigated" it says.. I REMEMBER reading that and ignoring it!  I did so at my own peril.  Then when I captured the logging info Lynn noticed that it was complaining that I wasn't in KISS mode.  And, I NEVER noticed that there's an LED that SHOULD light up when you're in KISS mode. I HAVE NEVER HAD THAT LIGHT ON BEFORE! 

So I exited APRSISCE, unpowered the SCS tracker, powered it back up, then re-started APRSISCE (and we fixed some other stuff) and POOF!  There's an LED that I had never seen before!  On the bottom of the LED it says, "KISS mode" OOOOOOOOHHHH! THAT's why I've heard stations, I've had the decode light go on, and I've transmitted, but since I wasn't in KISS mode (because of the power-on issue mentioned in the Robust-packet.net "manual", and I transmitted, but it transmitted some kinda gibberish, so nobody could see me, then when I received stuff (and the SCS tracker COULD internally decode that, the data was not sent out the USB port correctly) I didn't see anything. 

My bets are on this will be fine. I'm in receive mode only right now and will see if anything is being received by morning or at least by noon.
Then I'll take it off of receive only and send out a beacon or four, and see if they're heard by anybody.

Thanks again Lynn!  Film at eleven.


Re: I need help .. with SCS tracker and gateway. Can someone talk to me? I can probalby fix this in seconds if I knew what I was doing wrong.

Patrick Connor
 

I do not have a Robust Packet modem. My only other suggestion is to try another APRS client or a terminal program like LX Term or QT Term, or whatever you have on your Raspberry Pi. Maybe looking at the raw data will tell you something.

Patrick (N3TSZ)


On Sunday, January 17, 2021, 07:57:11 PM EST, <macclad44@...> wrote:


I've been thru that a zillion times. I've got some other problems.  I need to talk to someone.  Patrick, do you have an RP gateway working right now?


Re: I need help .. with SCS tracker and gateway. Can someone talk to me? I can probalby fix this in seconds if I knew what I was doing wrong.

macclad44@...
 

I've been thru that a zillion times. I've got some other problems.  I need to talk to someone.  Patrick, do you have an RP gateway working right now?


Re: I need help .. with SCS tracker and gateway. Can someone talk to me? I can probalby fix this in seconds if I knew what I was doing wrong.

Patrick Connor
 

I found this manual for the SCS tracker. It contains a page with instructions to set up APRSIS32 to work with the SCS tracker. I hope this helps.

Patrick (N3TSZ)


On Sunday, January 17, 2021, 06:37:35 PM EST, macclad44@... <macclad44@...> wrote:


Ugh. I've spent 40 hours and no headway.  I seem to hear others, they seem to hear me  because there's transmissions back and forth, but I see NO dialogue in the logger for that port.  Yet it must be working bi-direcitonally or it wouldn't respond back to whatever is calling me.
Can someone please respond and possiibly set up a very quick phone call?  The more familiar with the program you are, the quicker I can get this done an get off of everyone's backs.

I really appreciate the help.
Jeff
N7TTQ


I need help .. with SCS tracker and gateway. Can someone talk to me? I can probalby fix this in seconds if I knew what I was doing wrong.

macclad44@...
 

Ugh. I've spent 40 hours and no headway.  I seem to hear others, they seem to hear me  because there's transmissions back and forth, but I see NO dialogue in the logger for that port.  Yet it must be working bi-direcitonally or it wouldn't respond back to whatever is calling me.
Can someone please respond and possiibly set up a very quick phone call?  The more familiar with the program you are, the quicker I can get this done an get off of everyone's backs.

I really appreciate the help.
Jeff
N7TTQ


APRSISCE and TinyTrak4 with Bluetooth module.

cavuobservatory
 

Hello all,

I'd like to be able to have APRSISCE connect to my TinyTrak4 Bluetooth module and have access to both the TinyTrak4 data and GPS data.
I can get APRSISCE connect to either device but not both at the same time. The Byonics Bluetooth module provides two Comm ports when
my computer is connected to the BT module and I've tried numerous settings for both devices with no luck.

Has anyone been able to get this to work?  

Thanks,

Larry W0SX


Re: I hear an APRS station SCREAMING in, the red light shows decoded packets, but I see NOTHING in my log to indicatie it.

macclad44@...
 

My station and the unknown station did some back and forth but again nothing to see.

1 - 20 of 35174