Date   

APRS positions not uploading to APRS.FI

macclad44@...
 

Hi, although  my raw packets are being reported by APRS.FI, and that I'm active, positions and stations that have clearly been decoded on my RF port are suddenly not being shown under "Stations heard by N7TTQ-9" nor "Stations which heard N7TTQ-9".  Identical stations heard identically up to the 29th were fine, then nothing.  I must have hit a button somewhere.  Mind you prop has not been good in the last few days but for example VA6ATA-1 I clearly have heard and have even messaged but doesn't show up as being heard by me nor vice versa.  

Does anybody have any ideas?

Thanks.
Jeff


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

macclad44@...
 

My bad that I didn't post it here.  It's all on me, sorry man!  It was more or less not entering KISS mode correctly 'cause you have to cycle power on the SCS tracker after exiting the program in order that the KISS on command works after you RE-start the program. It's even listed as a known bug over on robust-packet.net's manual.. and I even read it, and dutifully ignored and forgot it.  Lynn sleuthed it fairly quickly but just looking at my RF port's log and seeing it was no bueno.
I may not have figured that out for a thousand years tho.  That's why it's good to have the author on this group. Wonderful in fact.


Re: Heard List on APRSIS32?

Rob Giuliano
 

So it would only work on RF received packets going to APRSIS32 from an 'AGW device' like AGWpe, Direwolf, etc.
I have only used it with Direwolf  and only on very limited occasions.  It did provide an RF mHeard list.

I believe another option would be if Direwolf is running on a Raspberry Pi and AX.25 is enabled (-p option I think).  I am pretty sure the AX.25 tools package has an mHeard tool.  I've never tried that one.

Robert Giuliano
KB8RCO



On Saturday, January 23, 2021, 5:40:31 PM EST, Lynn Deffenbaugh <kj4erj@...> wrote:


The AGW port on APRSIS32 is the wrong direction. It receives from RF and only transmits what it wants to go back out over RF.  I suspect AGWmonitor only works when connected to an AGW-providing program which APRSIS32 is not.  APRSIS32 is an AGW-consuming program.

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


On 1/23/2021 3:23 PM, Rob Giuliano via groups.io wrote:
I often use Direwolf with APRSIS32 (typically with KISS over TCP/IP).  
When I feel I need it, I use AGWmonitor to connect to the AGW port of Direwolf and it provides an mheard list. 

This method will work with any AGW interface, so I assume you could open an AGW RF port on APRSIS32 and connect that to AGWmonitor, then send the data you want to monitor in a list to that port.

Just a thought.



On Sat, Jan 23, 2021 at 14:34, Lynn Deffenbaugh
View / None followed by View / RF / All.

Or what I use on my IGate is Configure / Scroller / Show IGate/Digi
along with No Internals and RF Only.  That way the packet scroller on
the left side shows only RF-received packets and whether they were
direct or via a digipeater.

Oh, and if you're running the View / RF / All you can toggle View / All
on and off to see the "rest" of the stations that must have been heard
via the APRS-IS.  There is not really any such thing as "heard via an
IGate", except maybe the View / Transport / RF Only which will show
those stations that appeared to be RF, and not talking directly to the
APRS-IS.

But the APRSISCE/32 author doesn't believe in lists...

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


On 1/23/2021 10:05 AM, Demetre - M0SUY/SV1UY wrote:
> Hi Lynn and all,
>
> Is there a Heard List in APRSIS32 so that if we select it we can see which callsigns were heard on RF directly or via a DIGIpeater or via an IGATE?
>






Re: Heard List on APRSIS32?

Demetre - M0SUY/SV1UY
 

Hi Rob and thanks for reply,

Yes I also use AGW PE on HF for ROBUST PACKET and UZ7HO Soundmodem for AX25 PACKET so at least I can see the heardlist this way.
On VHF though I use an APRS Voyager VHF radio with an embedded TNC and BT which connects to APRSIS32 using a SimplyKISS port via bluetooth port since the Radio's Bluetooth TNC does not appear as a COMport on the PC, I cannot connect it to AGW Packet Engine, that is why I was wondering if there was a way to have a Heard List on APRSIS32. Never mind!

--
73 de Demetre M0SUY/SV1UY
APRS: 1st & best Social Network


Re: Heard List on APRSIS32?

Lynn Deffenbaugh
 

The AGW port on APRSIS32 is the wrong direction. It receives from RF and only transmits what it wants to go back out over RF.  I suspect AGWmonitor only works when connected to an AGW-providing program which APRSIS32 is not.  APRSIS32 is an AGW-consuming program.

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


On 1/23/2021 3:23 PM, Rob Giuliano via groups.io wrote:
I often use Direwolf with APRSIS32 (typically with KISS over TCP/IP).  
When I feel I need it, I use AGWmonitor to connect to the AGW port of Direwolf and it provides an mheard list. 

This method will work with any AGW interface, so I assume you could open an AGW RF port on APRSIS32 and connect that to AGWmonitor, then send the data you want to monitor in a list to that port.

Just a thought.



On Sat, Jan 23, 2021 at 14:34, Lynn Deffenbaugh
View / None followed by View / RF / All.

Or what I use on my IGate is Configure / Scroller / Show IGate/Digi
along with No Internals and RF Only.  That way the packet scroller on
the left side shows only RF-received packets and whether they were
direct or via a digipeater.

Oh, and if you're running the View / RF / All you can toggle View / All
on and off to see the "rest" of the stations that must have been heard
via the APRS-IS.  There is not really any such thing as "heard via an
IGate", except maybe the View / Transport / RF Only which will show
those stations that appeared to be RF, and not talking directly to the
APRS-IS.

But the APRSISCE/32 author doesn't believe in lists...

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


On 1/23/2021 10:05 AM, Demetre - M0SUY/SV1UY wrote:
> Hi Lynn and all,
>
> Is there a Heard List in APRSIS32 so that if we select it we can see which callsigns were heard on RF directly or via a DIGIpeater or via an IGATE?
>






Re: Heard List on APRSIS32?

Rob Giuliano
 

I often use Direwolf with APRSIS32 (typically with KISS over TCP/IP).  
When I feel I need it, I use AGWmonitor to connect to the AGW port of Direwolf and it provides an mheard list. 

This method will work with any AGW interface, so I assume you could open an AGW RF port on APRSIS32 and connect that to AGWmonitor, then send the data you want to monitor in a list to that port.

Just a thought.



On Sat, Jan 23, 2021 at 14:34, Lynn Deffenbaugh
<kj4erj@...> wrote:
View / None followed by View / RF / All.

Or what I use on my IGate is Configure / Scroller / Show IGate/Digi
along with No Internals and RF Only.  That way the packet scroller on
the left side shows only RF-received packets and whether they were
direct or via a digipeater.

Oh, and if you're running the View / RF / All you can toggle View / All
on and off to see the "rest" of the stations that must have been heard
via the APRS-IS.  There is not really any such thing as "heard via an
IGate", except maybe the View / Transport / RF Only which will show
those stations that appeared to be RF, and not talking directly to the
APRS-IS.

But the APRSISCE/32 author doesn't believe in lists...

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


On 1/23/2021 10:05 AM, Demetre - M0SUY/SV1UY wrote:
> Hi Lynn and all,
>
> Is there a Heard List in APRSIS32 so that if we select it we can see which callsigns were heard on RF directly or via a DIGIpeater or via an IGATE?
>






Re: Heard List on APRSIS32?

Lynn Deffenbaugh
 

View / None followed by View / RF / All.

Or what I use on my IGate is Configure / Scroller / Show IGate/Digi along with No Internals and RF Only.  That way the packet scroller on the left side shows only RF-received packets and whether they were direct or via a digipeater.

Oh, and if you're running the View / RF / All you can toggle View / All on and off to see the "rest" of the stations that must have been heard via the APRS-IS.  There is not really any such thing as "heard via an IGate", except maybe the View / Transport / RF Only which will show those stations that appeared to be RF, and not talking directly to the APRS-IS.

But the APRSISCE/32 author doesn't believe in lists...

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

On 1/23/2021 10:05 AM, Demetre - M0SUY/SV1UY wrote:
Hi Lynn and all,

Is there a Heard List in APRSIS32 so that if we select it we can see which callsigns were heard on RF directly or via a DIGIpeater or via an IGATE?


Heard List on APRSIS32?

Demetre - M0SUY/SV1UY
 

Hi Lynn and all,

Is there a Heard List in APRSIS32 so that if we select it we can see which callsigns were heard on RF directly or via a DIGIpeater or via an IGATE?

--
73 de Demetre M0SUY/SV1UY
APRS: 1st & best Social Network


Re: Diging Internet to RF

Lynn Deffenbaugh
 

First, digipeating is RF to RF and based on the path.  IGating has to do with IS and RF.

APRSIS32, in development mode only, supports filtered gating of packets from the APRS-IS to RF as provided by the following:

http://www.aprs-is.net/IGateDetails.aspx

Gate all packets to RF based on criteria set by the sysop (such as callsign, object name, etc.).

To do this, use the following procedure (all with focus on the main window of the IGate instance):

1)  Hit Control-G to enter a test filter

2)  Enter your desired filter using standard APRS-IS server filter terms, like b/K7MT-63.  APRSIS32 also supports a + filter term modifier that enforces an AND condition on that term.  For instance, "b/K7MT-63 +t/p" will match ONLY position packets from K7MT-63.

3)  Monitor the TestFilter window for a few hours or days to ensure that the filter is ONLY picking up the packets you want to transmit via RF.

4) With the filter still in place, hit Control-I (for IGate) and confirm your intention to gate the matching packets to RF.

This is NOT persistent, but is designed for intermittent use by IGate operators.  Maybe one day it will be persisted, but not at this time.  Use of the filtered gate option doesn't affect the required message gating for the IGate, to wit:

Gate message packets and associated posits to RF if all of the following are true:

  1. the receiving station has been heard within range within a predefined time period (range defined as digi hops, distance, or both).
  2. the sending station has not been heard via RF within a predefined time period (packets gated from the Internet by other stations are excluded from this test).
  3. the sending station does not have TCPXX, NOGATE, or RFONLY in the header.
  4. the receiving station has not been heard via the Internet within a predefined time period.
    A station is said to be heard via the Internet if packets from the station contain TCPIP* or TCPXX* in the header or if gated (3rd-party) packets are seen on RF gated by the station and containing TCPIP or TCPXX in the 3rd-party header (in other words, the station is seen on RF as being an IGate).
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32



On 1/22/2021 1:03 PM, Bill Erhardt wrote:
Howdy gang,

In APRSIS32 is there a way to select a callsing with suffix (K7MT-63 for example) from internet to my VHF Igate K7MT ???  I have K7MT-8, K7MT-63, and K7MT-11 HF on 10 meters and would like to send those out on my VHF Igate so others know there are HF Igates in Helena, Mt.  I read over the entire instructions and could not find anything that would allow me to select a call from Internet to RF..

Bill K7MT Helena, Mt.


Diging Internet to RF

Bill Erhardt
 

Howdy gang,

In APRSIS32 is there a way to select a callsing with suffix (K7MT-63 for example) from internet to my VHF Igate K7MT ???  I have K7MT-8, K7MT-63, and K7MT-11 HF on 10 meters and would like to send those out on my VHF Igate so others know there are HF Igates in Helena, Mt.  I read over the entire instructions and could not find anything that would allow me to select a call from Internet to RF..

Bill K7MT Helena, Mt.


Re: PinPoint APRS support?

Glenn O'Connor
 

Examine this download page for PP and note the dates for bug fixes, last one done this past December.

https://pinpointaprs.com/download.html

73,
Glenn-KF0ED


Re: PinPoint APRS support?

Doug Ferrell
 

Never heard of that client before…

 

…DOUG

KD4MOJ

 


Re: PinPoint APRS support?

Rob Giuliano
 

I remember seeing a post somewhere on PinPoint APRS and it said
PinPoint is a labor of love by Frank Watervoort AB0WV. Feel free to send email to ab0wv@....

Did you try that email?

Robert Giuliano
KB8RCO



On Wednesday, January 20, 2021, 4:54:07 PM EST, Lynn Deffenbaugh <kj4erj@...> wrote:


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



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

321 - 340 of 35507