Date   

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


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.

521 - 540 of 35700