Date   

Re: APRS-IS RESOLVE/APRS-IS DELAY

Steve N3FWE
 


Did this problem every get resolved?    It seems I may be having a similar problem.   I got a new computer with Windows 10.  I installed the software and copied over the configuration from my old computer.   After running the software I noticed I wasn't getting any stations from the internet except my Davis Weather Station.   I checked my old XP computer and it was doing the same thing.    I been running the software for a while and never had any issues like this before.   I connect to rotate.aprs.net on 14580.  I tried firenet and same issue.   I tried port 10152 to see if what would happen and I started receiving everything like I should.       My filters look ok.  

I tried APRSdroid on my phone which connects to rotate.aprs.net  and that works fine.   Also my stand alone Davis Weather Station sends data to rotate.aprs.net and that is working.     Am I missing something or make a change I may of missed?

I

Steve, N3FWE


Re: Internet only stations

Jean-Pierre Desilets
 

Hi  group  , aprs.fi ios  application for  i-phone  report  the position  direct to  aprs.fi server  without  passing  though the aprs-is network  tier2 .
you can see  ve2se-i  ( my iphone) on  aprs.fi  but  not  on  findu.com for example

Jean-Pierre  ve2se


Re: Internet only stations

Lynn Deffenbaugh
 

My son-in-law has the aprs.fi app on his cellphone.  It delivers packets to the APRS-IS, but only if you have the subscription upgrade.  At least, I THINK it does.  I didn't actually verify this when we were together last week.  Maybe sometime over Christmas I'll have another chance.

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


On 12/5/2020 10:17 AM, Fred Hillhouse wrote:

I am not sure that iPhones running the APRS.FI application will be available on APRS-IS which is where the filters work.

You will need to verify before depending on it.

 

You might be able to check this by changing your call sign to one from an iPhone.

http://www.findu.com/cgi-bin/find.cgi?call=N2KGC-3

 

Don’t check with APRS.FI. I believe it may give you a false positive.

 

When you find out, please post the results.

 

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Brian Webster via groups.io
Sent: Monday, November 23, 2020 11:47 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

Thanks guys. That’s the answer we needed.

 

Brian N2KGC

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Monday, November 23, 2020 10:47 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

Oh, and to filter for only APRS-IS direct packets, add a +d/TCPIP which restricts the matching packets to only those with TCPIP in their "digipeater" path.

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

On 11/23/2020 10:44 AM, Lynn Deffenbaugh wrote:

And if you want to only include position packets (likely), add a "+t/p" to the buddy filter, separated by a space.  Otherwise you'll end up gating ALL packets from the buddy stations which is probably more than you're interested in if those stations happen to generate telemetry or inject objects to the APRS-IS.

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

On 11/23/2020 10:25 AM, Rob Giuliano via groups.io wrote:

That question was answered as part of the thread (slightly edited):

 

On Sunday, November 22, 2020, 4:07:25 PM EST, Lynn Deffenbaugh <kj4erj@...> wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like " b/call1-SS/call2-SS/call3-SS +t/p +d/TCPIP
    Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the
    default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt (Implement) the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.

b/call1-SS/call2-SS/call3-SS +t/p +d/TCPIP

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

 

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

 

I do not recall the maximum number of callsigns you can put into the buddy filter, but you should be able to look that up

 or just find see if you hit a limit.

 

Robert Giuliano
KB8RCO

 

 

On Monday, November 23, 2020, 12:21:56 AM EST, Brian Webster via groups.io <radiowebst@...> wrote:

 

 

The original poster would be happy with just using the buddy filter option. This particular evolution he only wanted to send particular stations traffic back over RF. So learning how to do the buddy filter back out over RF would be the solution he would like to use. I am not 100% sure how to do it in APRSISCE myself. I was the one who actually wanted to see the phones that were connected only to the IS. I like to run my station on RF only and was not seeing the IS only users using a phone app.

 

What would be the proper procedure in the software to gate only specific station out over RF?

 

Brian N2KGC

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Sunday, November 22, 2020 5:06 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

I'm now up to:

+t/p m/50 +d/TCPIP -t/oiw -u/APDG*/APOSW/APJI*

which eliminates weather and another source of DStar gateways.  But I still get a lot of fixed stations with this filter.

Maybe if you could have all APRS-IS stations use a specific symbol that is not commonly used, you could use an s/ filter in place of the m/50.   That'd be closer to selecting the desired stations instead of trying to weed out all the undesired stations.

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

On 11/22/2020 4:32 PM, Lynn Deffenbaugh wrote:

Just played with the proposed filter for a bit and have now extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i

This will exclude objects and items like DStar objects and hot-spots...

And while writing this up, I've further extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i -u/APDG*/APOS

which removes DStarGateway and OpenSpot generated packets via their unproto (ToCall) values.  But even that's not really good enough...  It's FAR better to just select the callsign-SSIDs you're interested in with buddy filters!

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

 

PS.  Here's some of the packets you would probably NOT want to gate to RF:

 

WinMain:2020-11-22T21:24:34.692 IS[APRS-IS](Hit(m/15.5mi)) [1]K1JOG-B>APDG02,TCPIP*,qAC,K1JOG-BS:!2810.61ND08128.68W&RNG0001 440 Voice 446.61250MHz +0.0000MHz
WinMain:2020-11-22T21:24:52.539 IS[APRS-IS](Hit(m/15.5mi)) [0]WD4WDW-B>APJI40,TCPIP*,qAC,WD4WDW-GS:!2823.72ND08131.87W&RNG0030 440 Voice 442.000
WinMain:2020-11-22T21:26:18.639 IS[APRS-IS](Hit(m/15.5mi)) [0]NO4MM-B>APDG02,TCPIP*,qAC,NO4MM-BS:!2817.95ND08128.50W&RNG0001 440 Voice 439.81750MHz +0.0000MHz
WinMain:2020-11-22T21:27:21.966 IS[APRS-IS](Hit(m/15.5mi)) [0]NS1X-N>APDG03,TCPIP*,qAC,T2CAEAST:!2827.00ND08136.60W&/A=000000440 MMDVM Voice 438.80000MHz +0.0000MHz, NS1X_Pi-Star
WinMain:2020-11-22T21:27:31.982 IS[APRS-IS](Hit(m/15.5mi)) [0]WP4JMV>APOSW,TCPIP*,qAC,T2HAKATA:@222127z2818.75N\08122.50W-/A=000000SharkRF openSPOT2
WinMain:2020-11-22T21:28:33.102 IS[APRS-IS](Hit(m/15.5mi)) [1]NO3E-B>APDG02,TCPIP*,qAC,NO3E-BS:!2815.27ND08117.64W&RNG0001 440 Voice 446.71250MHz +0.0000MHz

 

And during that short time span, this is the only one that MAYBE you'd want to pass along...

 

WinMain:2020-11-22T21:26:50.858 IS[APRS-IS](Hit(m/15.5mi)) [0]KG7PVM>APRS,TCPIP*,qAC,T2NALA:@222126z2813.82N/08130.00W_109/002g002t077r000p000P000h77b10170L046AmbientCWOP.com

 

On 11/22/2020 4:07 PM, Lynn Deffenbaugh wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

 

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:

I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

 

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.

  <Ctrl>G   and set a filter to limited what goes from IS to RF

This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

 

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO

 

 

On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:

 

 

On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?




Avast logo

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



Re: Internet only stations

Fred Hillhouse
 

I am not sure that iPhones running the APRS.FI application will be available on APRS-IS which is where the filters work.

You will need to verify before depending on it.

 

You might be able to check this by changing your call sign to one from an iPhone.

http://www.findu.com/cgi-bin/find.cgi?call=N2KGC-3

 

Don’t check with APRS.FI. I believe it may give you a false positive.

 

When you find out, please post the results.

 

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Brian Webster via groups.io
Sent: Monday, November 23, 2020 11:47 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

Thanks guys. That’s the answer we needed.

 

Brian N2KGC

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Monday, November 23, 2020 10:47 AM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

Oh, and to filter for only APRS-IS direct packets, add a +d/TCPIP which restricts the matching packets to only those with TCPIP in their "digipeater" path.

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

On 11/23/2020 10:44 AM, Lynn Deffenbaugh wrote:

And if you want to only include position packets (likely), add a "+t/p" to the buddy filter, separated by a space.  Otherwise you'll end up gating ALL packets from the buddy stations which is probably more than you're interested in if those stations happen to generate telemetry or inject objects to the APRS-IS.

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

On 11/23/2020 10:25 AM, Rob Giuliano via groups.io wrote:

That question was answered as part of the thread (slightly edited):

 

On Sunday, November 22, 2020, 4:07:25 PM EST, Lynn Deffenbaugh <kj4erj@...> wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like " b/call1-SS/call2-SS/call3-SS +t/p +d/TCPIP
    Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the
    default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt (Implement) the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.

b/call1-SS/call2-SS/call3-SS +t/p +d/TCPIP

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

 

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

 

I do not recall the maximum number of callsigns you can put into the buddy filter, but you should be able to look that up

 or just find see if you hit a limit.

 

Robert Giuliano
KB8RCO

 

 

On Monday, November 23, 2020, 12:21:56 AM EST, Brian Webster via groups.io <radiowebst@...> wrote:

 

 

The original poster would be happy with just using the buddy filter option. This particular evolution he only wanted to send particular stations traffic back over RF. So learning how to do the buddy filter back out over RF would be the solution he would like to use. I am not 100% sure how to do it in APRSISCE myself. I was the one who actually wanted to see the phones that were connected only to the IS. I like to run my station on RF only and was not seeing the IS only users using a phone app.

 

What would be the proper procedure in the software to gate only specific station out over RF?

 

Brian N2KGC

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Sunday, November 22, 2020 5:06 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Internet only stations

 

I'm now up to:

+t/p m/50 +d/TCPIP -t/oiw -u/APDG*/APOSW/APJI*

which eliminates weather and another source of DStar gateways.  But I still get a lot of fixed stations with this filter.

Maybe if you could have all APRS-IS stations use a specific symbol that is not commonly used, you could use an s/ filter in place of the m/50.   That'd be closer to selecting the desired stations instead of trying to weed out all the undesired stations.

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

On 11/22/2020 4:32 PM, Lynn Deffenbaugh wrote:

Just played with the proposed filter for a bit and have now extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i

This will exclude objects and items like DStar objects and hot-spots...

And while writing this up, I've further extended it to:

+t/p m/25 +d/TCPIP -t/o -t/i -u/APDG*/APOS

which removes DStarGateway and OpenSpot generated packets via their unproto (ToCall) values.  But even that's not really good enough...  It's FAR better to just select the callsign-SSIDs you're interested in with buddy filters!

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

 

PS.  Here's some of the packets you would probably NOT want to gate to RF:

 

WinMain:2020-11-22T21:24:34.692 IS[APRS-IS](Hit(m/15.5mi)) [1]K1JOG-B>APDG02,TCPIP*,qAC,K1JOG-BS:!2810.61ND08128.68W&RNG0001 440 Voice 446.61250MHz +0.0000MHz
WinMain:2020-11-22T21:24:52.539 IS[APRS-IS](Hit(m/15.5mi)) [0]WD4WDW-B>APJI40,TCPIP*,qAC,WD4WDW-GS:!2823.72ND08131.87W&RNG0030 440 Voice 442.000
WinMain:2020-11-22T21:26:18.639 IS[APRS-IS](Hit(m/15.5mi)) [0]NO4MM-B>APDG02,TCPIP*,qAC,NO4MM-BS:!2817.95ND08128.50W&RNG0001 440 Voice 439.81750MHz +0.0000MHz
WinMain:2020-11-22T21:27:21.966 IS[APRS-IS](Hit(m/15.5mi)) [0]NS1X-N>APDG03,TCPIP*,qAC,T2CAEAST:!2827.00ND08136.60W&/A=000000440 MMDVM Voice 438.80000MHz +0.0000MHz, NS1X_Pi-Star
WinMain:2020-11-22T21:27:31.982 IS[APRS-IS](Hit(m/15.5mi)) [0]WP4JMV>APOSW,TCPIP*,qAC,T2HAKATA:@222127z2818.75N\08122.50W-/A=000000SharkRF openSPOT2
WinMain:2020-11-22T21:28:33.102 IS[APRS-IS](Hit(m/15.5mi)) [1]NO3E-B>APDG02,TCPIP*,qAC,NO3E-BS:!2815.27ND08117.64W&RNG0001 440 Voice 446.71250MHz +0.0000MHz

 

And during that short time span, this is the only one that MAYBE you'd want to pass along...

 

WinMain:2020-11-22T21:26:50.858 IS[APRS-IS](Hit(m/15.5mi)) [0]KG7PVM>APRS,TCPIP*,qAC,T2NALA:@222126z2813.82N/08130.00W_109/002g002t077r000p000P000h77b10170L046AmbientCWOP.com

 

On 11/22/2020 4:07 PM, Lynn Deffenbaugh wrote:

Yes, the checkboxes govern "normal" IGate functionality.  To gate arbitrary packets from the APRS-IS to RF, follow the steps below:

1) Hit Control-G to enter a test filter.   Something like "m/10 +t/p +d/TCPIP" would get you stations within 10 km of your current location, must be posit packets and have TCPIP in their "digipeater" path.  Note the "+" qualifier is APRSIS32-specific and joins that filter term with an AND instead of the default OR for filter terms.

2) After monitoring the test filter trace log for a while to ensure that you're not getting TOO many packets...

3) Hit Control-I to adopt the filter and gate those packets to your RF port(s) as 3rd party packets.

Note that there is nothing in the filter spec to prevent gating filter-selected packets to RF for stations that were seen on RF.  So if you have any RF stations beaconing to the APRS-IS directly, you'll end up 3rd party gating their APRS-IS packets back to RF.

Filtered gating from the APRS-IS to RF is not something to be taken lightly.  It is fraught with peril and quite likely to flood the local RF channel, particularly if an unexpected, mis-behaving APRS-IS station starts matching your filter.

I really recommend individual station filtering through the buddy (b/) filter rather than any range-based filter.  That way you are individually selecting the stations that you will be using.  Something like the following in place of the m/10 shown above.

b/call1-SS/call2-SS/call3

And play with the filters (without the Control-I) for days, weeks, or even months before the event so that you get an idea of just what packets are being select.  And even then, when the actual event starts and additional stations come out of the woodwork, you have to keep an eye on things so they don't run amok.

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

 

PS.  The Control-G/Control-I is purposely not persistent and must be re-configured after every APRSIS32 restart.  It is designed for targetted use and not routine, ongoing, (and likely) unmonitored gating of APRS-IS packets to the local RF environment.

On 11/22/2020 12:35 PM, Rob Giuliano via groups.io wrote:

I am pretty sure the check boxes are for 2-way traffic messaging.  So a message that starts on RF and goes through IS can be replied to - provided it didn't get into the system from a listen only IGATE.

 

One way traffic (like position reports) can get tricky because you can easily overwhelm the RF system with the volume of traffic from the internet.  This can be done with the development version of APRSIS32 through a special filter after testing.

  <Ctrl>G   and set a filter to limited what goes from IS to RF

This should be specific enough to ensure that only the information for your event is gated to RF from your igate.  This might be rather difficult.

 

I don't remember the next <Ctrl> key to have APRSIS32 use the test filter and start the process.  You will have to check the WIKI or maybe someone else.

Robert Giuliano
KB8RCO

 

 

On Sunday, November 22, 2020, 11:52:07 AM EST, John Rudolph <john@...> wrote:

 

 

On Halloween we ran an ARES event, Pumpkin Patrol, and had many of our posts run various cellphone APRS apps since few have RF rigs. I was using APRSIS via agwpe to igate the traffic to the RF only stations but the cellphone only stations while showing on aprs.fi were never igated. In settings I had everything selected to igate but it still didnt work. Any suggestions on why that may be and how do I make it work for future events?




Avast logo

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



Re: Telemetry support packets

Fred Hillhouse
 

I heard about the findu option today. I have already sent the support packets over RF but was curious. I was sending them at the ‘excessive’ rate of every two hours. ;)
I backed them off to every six hours a little bit ago just because I can.
J

 

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Tuesday, December 01, 2020 6:33 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Telemetry support packets

 

I use one of the APRS messaging web interfaces (search for it at findu) to send the telemetry definition messages from myself to myself as the callsign-SSID that will be doing the telemetry.  That way aprs.fi and the rest of the active APRS-IS gets it as well as my APRSIS32 instance(s).

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

On 12/1/2020 5:55 PM, Fred Hillhouse wrote:

I was thinking that might be the case. I did notice that I could edit the XML (APRSIS32 not running) to manually add the support packets. It wouldn’t take much effort.

 

Thank you!

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Tuesday, December 01, 2020 5:03 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Telemetry support packets

 

Actually, I think they are currently forever unless manually deleted.  This is by design as some telemetry stations only issue the definitions once manually by the operator.

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


On 12/1/2020 4:48 PM, Fred Hillhouse wrote:

Hi Lynn,

 

How long do the support packets (EQNS, PARM, UNIT) for telemetry stay in the XML?

I assume they ‘age out’ at some point.

 

Thank you!

 

Fred N7FMH

 


Avast logo

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





Re: Telemetry support packets

Lynn Deffenbaugh
 

I use one of the APRS messaging web interfaces (search for it at findu) to send the telemetry definition messages from myself to myself as the callsign-SSID that will be doing the telemetry.  That way aprs.fi and the rest of the active APRS-IS gets it as well as my APRSIS32 instance(s).

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


On 12/1/2020 5:55 PM, Fred Hillhouse wrote:

I was thinking that might be the case. I did notice that I could edit the XML (APRSIS32 not running) to manually add the support packets. It wouldn’t take much effort.

 

Thank you!

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Tuesday, December 01, 2020 5:03 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Telemetry support packets

 

Actually, I think they are currently forever unless manually deleted.  This is by design as some telemetry stations only issue the definitions once manually by the operator.

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

On 12/1/2020 4:48 PM, Fred Hillhouse wrote:

Hi Lynn,

 

How long do the support packets (EQNS, PARM, UNIT) for telemetry stay in the XML?

I assume they ‘age out’ at some point.

 

Thank you!

 

Fred N7FMH

 


Avast logo

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




Re: Telemetry support packets

Lynn Deffenbaugh
 

Yes, without definitions, particularly EQNS, the raw data is displayed.

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


On 12/1/2020 6:22 PM, Rob Giuliano via groups.io wrote:
But assumed updated any time "new information" is received.

Is APRSIS32 the defaults EQNS for each channel of 0,1,0?
  Or are there some "assumed defaults" for certain devices?

I would assume the default to be 0,1,0 until scaling data is provided, but I have seen data on aprs.fi that is scaled to some assumed signal - especially for the Byonics TT4.

Robert Giuliano
KB8RCO



On Tuesday, December 1, 2020, 5:03:22 PM EST, Lynn Deffenbaugh <kj4erj@...> wrote:


Actually, I think they are currently forever unless manually deleted.  This is by design as some telemetry stations only issue the definitions once manually by the operator.

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


On 12/1/2020 4:48 PM, Fred Hillhouse wrote:

Hi Lynn,

 

How long do the support packets (EQNS, PARM, UNIT) for telemetry stay in the XML?

I assume they ‘age out’ at some point.

 

Thank you!

 

Fred N7FMH




Avast logo

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



Re: Telemetry support packets

Rob Giuliano
 

But assumed updated any time "new information" is received.

Is APRSIS32 the defaults EQNS for each channel of 0,1,0?
  Or are there some "assumed defaults" for certain devices?

I would assume the default to be 0,1,0 until scaling data is provided, but I have seen data on aprs.fi that is scaled to some assumed signal - especially for the Byonics TT4.

Robert Giuliano
KB8RCO



On Tuesday, December 1, 2020, 5:03:22 PM EST, Lynn Deffenbaugh <kj4erj@...> wrote:


Actually, I think they are currently forever unless manually deleted.  This is by design as some telemetry stations only issue the definitions once manually by the operator.

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


On 12/1/2020 4:48 PM, Fred Hillhouse wrote:

Hi Lynn,

 

How long do the support packets (EQNS, PARM, UNIT) for telemetry stay in the XML?

I assume they ‘age out’ at some point.

 

Thank you!

 

Fred N7FMH




Avast logo

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



Re: Telemetry support packets

Fred Hillhouse
 

I was thinking that might be the case. I did notice that I could edit the XML (APRSIS32 not running) to manually add the support packets. It wouldn’t take much effort.

 

Thank you!

Fred N7FMH

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Lynn Deffenbaugh
Sent: Tuesday, December 01, 2020 5:03 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] Telemetry support packets

 

Actually, I think they are currently forever unless manually deleted.  This is by design as some telemetry stations only issue the definitions once manually by the operator.

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

On 12/1/2020 4:48 PM, Fred Hillhouse wrote:

Hi Lynn,

 

How long do the support packets (EQNS, PARM, UNIT) for telemetry stay in the XML?

I assume they ‘age out’ at some point.

 

Thank you!

 

Fred N7FMH

 


Avast logo

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




Re: Telemetry support packets

Lynn Deffenbaugh
 

Actually, I think they are currently forever unless manually deleted.  This is by design as some telemetry stations only issue the definitions once manually by the operator.

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


On 12/1/2020 4:48 PM, Fred Hillhouse wrote:

Hi Lynn,

 

How long do the support packets (EQNS, PARM, UNIT) for telemetry stay in the XML?

I assume they ‘age out’ at some point.

 

Thank you!

 

Fred N7FMH




Avast logo

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



Telemetry support packets

Fred Hillhouse
 

Hi Lynn,

 

How long do the support packets (EQNS, PARM, UNIT) for telemetry stay in the XML?

I assume they ‘age out’ at some point.

 

Thank you!

 

Fred N7FMH




Avast logo

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



Re: can anyone help here

Fred Hillhouse
 

 

Don

N1EDF  no one eats dead fish.  

 

Nice one!

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Rob Giuliano via groups.io
Sent: Saturday, November 28, 2020 4:24 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

Check you time code.  Your time is >235950 so that could be the issue.  

 

What is putting these packets together?

 

Do you have some kind of script that puts the packet together in Direwolf or some other computer application?  

 

On Sat, Nov 28, 2020 at 2:16 PM, Don Eklund

<n1edf@...> wrote:

It is for my weather station.    

 

I converted it to a raspberry PI from a old windows machine.   

 

I have the cord the same   

 

 




Avast logo

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



Re: can anyone help here

Don Eklund
 

Guys,

 

I got it working.     I had to put in N and W into the coordinates in the software and now is all good. 

 

Thanks again guys,

 

Don

N1EDF  no one eats dead fish.  

 

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Rob Giuliano via groups.io
Sent: Saturday, November 28, 2020 9:09 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

As someone else said.  The direction is not included in the lat and long information as well.

This is not an issue with APRSIS32, but with the application pputting the infomration together.

 

Your program is not formatting the packet properly. 

My best guess is that it reads some information from a configuration file and adds the weather information from the Davis station (maybe from a weather.txt file).  If so, it is in the configuration infomration that the issues are coming from.

 

If you name the application being used on tyhe Pi, maybe we can help with the configuration.

HOWEVER, you should probably ask it the forum for that application.

 

Robert Giuliano
KB8RCO

 

 

On Saturday, November 28, 2020, 4:26:41 PM EST, Don Eklund <n1edf@...> wrote:

 

 

It is a program capturing my weather date from my Davis and sending it to CWOP/APRS.  

 

It was working on my window machine but not my new PI  .  

 

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Rob Giuliano via groups.io
Sent: Saturday, November 28, 2020 4:24 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

Check you time code.  Your time is >235950 so that could be the issue.  

 

What is putting these packets together?

 

Do you have some kind of script that puts the packet together in Direwolf or some other computer application?  

 

On Sat, Nov 28, 2020 at 2:16 PM, Don Eklund

<n1edf@...> wrote:

It is for my weather station.    

 

I converted it to a raspberry PI from a old windows machine.   

 

I have the cord the same   

 

 


Re: can anyone help here

Rob Giuliano
 

As someone else said.  The direction is not included in the lat and long information as well.
This is not an issue with APRSIS32, but with the application pputting the infomration together.

Your program is not formatting the packet properly. 
My best guess is that it reads some information from a configuration file and adds the weather information from the Davis station (maybe from a weather.txt file).  If so, it is in the configuration infomration that the issues are coming from.

If you name the application being used on tyhe Pi, maybe we can help with the configuration.
HOWEVER, you should probably ask it the forum for that application.

Robert Giuliano
KB8RCO



On Saturday, November 28, 2020, 4:26:41 PM EST, Don Eklund <n1edf@...> wrote:


It is a program capturing my weather date from my Davis and sending it to CWOP/APRS.  

 

It was working on my window machine but not my new PI  .  

 

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Rob Giuliano via groups.io
Sent: Saturday, November 28, 2020 4:24 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

Check you time code.  Your time is >235950 so that could be the issue.  

 

What is putting these packets together?

 

Do you have some kind of script that puts the packet together in Direwolf or some other computer application?  

 

On Sat, Nov 28, 2020 at 2:16 PM, Don Eklund

<n1edf@...> wrote:

It is for my weather station.    

 

I converted it to a raspberry PI from a old windows machine.   

 

I have the cord the same   

 



Re: can anyone help here

Patrick Connor
 

I do not see North or West in the position information.

Patrick (N3TSZ)


On Saturday, November 28, 2020, 04:26:30 PM EST, Don Eklund <n1edf@...> wrote:


It is a program capturing my weather date from my Davis and sending it to CWOP/APRS.  

 

It was working on my window machine but not my new PI  .  

 

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Rob Giuliano via groups.io
Sent: Saturday, November 28, 2020 4:24 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

Check you time code.  Your time is >235950 so that could be the issue.  

 

What is putting these packets together?

 

Do you have some kind of script that puts the packet together in Direwolf or some other computer application?  

 

On Sat, Nov 28, 2020 at 2:16 PM, Don Eklund

<n1edf@...> wrote:

It is for my weather station.    

 

I converted it to a raspberry PI from a old windows machine.   

 

I have the cord the same   

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Min via groups.io
Sent: Friday, November 27, 2020 12:13 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

Don

 

What did you change ?

 

It looks like GPS data, incorrect data being received and then put to iGate.. suggest reboot or correct the change that was made.

 

Min G0JMS.

 

 

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Don Eklund
Sent: 27 November 2020 16:57
To: APRSISCE@groups.io
Subject: [APRSISCE] can anyone help here

 

 

Does anyone know why I am getting this on APRS.FI  say Invalid Uncompressed location. 

 

2020-11-27 11:50:04 EST: N1EDF>APRS,TCPXX*,qAX,CWOP-4:@271652z42.00.00/71.00.00_312/000g001t050r000p000P000b10168h94.WD 31 [Invalid uncompressed location]


Re: can anyone help here

Don Eklund
 

It is a program capturing my weather date from my Davis and sending it to CWOP/APRS.  

 

It was working on my window machine but not my new PI  .  

 

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Rob Giuliano via groups.io
Sent: Saturday, November 28, 2020 4:24 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

Check you time code.  Your time is >235950 so that could be the issue.  

 

What is putting these packets together?

 

Do you have some kind of script that puts the packet together in Direwolf or some other computer application?  

 

On Sat, Nov 28, 2020 at 2:16 PM, Don Eklund

<n1edf@...> wrote:

It is for my weather station.    

 

I converted it to a raspberry PI from a old windows machine.   

 

I have the cord the same   

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Min via groups.io
Sent: Friday, November 27, 2020 12:13 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

Don

 

What did you change ?

 

It looks like GPS data, incorrect data being received and then put to iGate.. suggest reboot or correct the change that was made.

 

Min G0JMS.

 

 

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Don Eklund
Sent: 27 November 2020 16:57
To: APRSISCE@groups.io
Subject: [APRSISCE] can anyone help here

 

 

Does anyone know why I am getting this on APRS.FI  say Invalid Uncompressed location. 

 

2020-11-27 11:50:04 EST: N1EDF>APRS,TCPXX*,qAX,CWOP-4:@271652z42.00.00/71.00.00_312/000g001t050r000p000P000b10168h94.WD 31 [Invalid uncompressed location]


Re: can anyone help here

Rob Giuliano
 

Check you time code.  Your time is >235950 so that could be the issue.  

What is putting these packets together?

Do you have some kind of script that puts the packet together in Direwolf or some other computer application?  


On Sat, Nov 28, 2020 at 2:16 PM, Don Eklund
<n1edf@...> wrote:

It is for my weather station.    

 

I converted it to a raspberry PI from a old windows machine.   

 

I have the cord the same   

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Min via groups.io
Sent: Friday, November 27, 2020 12:13 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

Don

 

What did you change ?

 

It looks like GPS data, incorrect data being received and then put to iGate.. suggest reboot or correct the change that was made.

 

Min G0JMS.

 

 

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Don Eklund
Sent: 27 November 2020 16:57
To: APRSISCE@groups.io
Subject: [APRSISCE] can anyone help here

 

 

Does anyone know why I am getting this on APRS.FI  say Invalid Uncompressed location. 

 

2020-11-27 11:50:04 EST: N1EDF>APRS,TCPXX*,qAX,CWOP-4:@271652z42.00.00/71.00.00_312/000g001t050r000p000P000b10168h94.WD 31 [Invalid uncompressed location]


Re: can anyone help here

Don Eklund
 

It is for my weather station.    

 

I converted it to a raspberry PI from a old windows machine.   

 

I have the cord the same   

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Min via groups.io
Sent: Friday, November 27, 2020 12:13 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

Don

 

What did you change ?

 

It looks like GPS data, incorrect data being received and then put to iGate.. suggest reboot or correct the change that was made.

 

Min G0JMS.

 

 

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Don Eklund
Sent: 27 November 2020 16:57
To: APRSISCE@groups.io
Subject: [APRSISCE] can anyone help here

 

 

Does anyone know why I am getting this on APRS.FI  say Invalid Uncompressed location. 

 

2020-11-27 11:50:04 EST: N1EDF>APRS,TCPXX*,qAX,CWOP-4:@271652z42.00.00/71.00.00_312/000g001t050r000p000P000b10168h94.WD 31 [Invalid uncompressed location]


Re: can anyone help here

Don Eklund
 

I am still getting that error even with the changes.   See below. 

 

2020-11-28 14:10:06 EST: N1EDF>APRS,TCPXX*,qAX,CWOP-3:@281907z4218.42/07119.42_357/000g002t036r000p000P000b02026h13.WD 31 [Invalid uncompressed location]

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Robert Bruninga
Sent: Friday, November 27, 2020 1:43 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

>You don't say what is generating these position packets, 

>but they are not formatted properly.  That is why you are getting the errors.

   Lat format    DDmm.dd

   Lon format DDDmm.dd

>You must fill each character location with a number or trailing space.  

 

Leading zeros yes, trailing zeros means something different.  If the last digit is a 0 then it is a precise position.  If the trailing zero is replaced with a space, then it is a degree of position ambiguity.

 

> In other words, the leading zero (071) on the longitude must be there.  

> For ambiguity, removing trailing zeros and use spaces. 

> I believe you can only do that after the decimal, but I could be wrong.   

   @271652z4200.  /07100.  _ 

 

Yes, I see now that you said that.  Thanks

bob

Robert Giuliano

KB8RCO

On Fri, Nov 27, 2020 at 11:56, Don Eklund

<n1edf@...> wrote:

 

Does anyone know why I am getting this on APRS.FI  say Invalid Uncompressed location. 

 

2020-11-27 11:50:04 EST: N1EDF>APRS,TCPXX*,qAX,CWOP-4:@271652z42.00.00/71.00.00_312/000g001t050r000p000P000b10168h94.WD 31 [Invalid uncompressed location]


Re: can anyone help here

Don Eklund
 

Bob,

 

Sorry,

 

It is Weather display.  

 

Don

 

 

From: APRSISCE@groups.io <APRSISCE@groups.io> On Behalf Of Robert Bruninga
Sent: Friday, November 27, 2020 1:43 PM
To: APRSISCE@groups.io
Subject: Re: [APRSISCE] can anyone help here

 

>You don't say what is generating these position packets, 

>but they are not formatted properly.  That is why you are getting the errors.

   Lat format    DDmm.dd

   Lon format DDDmm.dd

>You must fill each character location with a number or trailing space.  

 

Leading zeros yes, trailing zeros means something different.  If the last digit is a 0 then it is a precise position.  If the trailing zero is replaced with a space, then it is a degree of position ambiguity.

 

> In other words, the leading zero (071) on the longitude must be there.  

> For ambiguity, removing trailing zeros and use spaces. 

> I believe you can only do that after the decimal, but I could be wrong.   

   @271652z4200.  /07100.  _ 

 

Yes, I see now that you said that.  Thanks

bob

Robert Giuliano

KB8RCO

On Fri, Nov 27, 2020 at 11:56, Don Eklund

<n1edf@...> wrote:

 

Does anyone know why I am getting this on APRS.FI  say Invalid Uncompressed location. 

 

2020-11-27 11:50:04 EST: N1EDF>APRS,TCPXX*,qAX,CWOP-4:@271652z42.00.00/71.00.00_312/000g001t050r000p000P000b10168h94.WD 31 [Invalid uncompressed location]

861 - 880 of 35886