Date   

Fix JS8Call Parsing (Dev Release 2020/10/05 11:46)

Lynn Deffenbaugh
 

There's a new development release that I should have pushed out several weeks ago.  Primarily it updates the JS8Call ALL.TXT parsing due to changes in JS8Call's latest version.  This is what happens when you scrape changeable log files!

Here's the summary release notes:

Don't look for !shriek!s in >APECAN proprietary packets.

Support Clear / MicE Messages to quickly clear those pesky special and priority stations

QRZ/ANSRVR/SATSRV servers now ignore orphan acks, don't treat them like new requests

JS8Call objects include HB or CQ as -SSID on created objects

JS8Call objects support the latest log format from ALL.TXT (extra comma and @HB)

Correct SATSRV APRS-IS injection timing when ISS/PSAT were coming in range of Me

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


Re: Mapping JS8Call stations to local APRSis32 map?

Lynn Deffenbaugh
 

You should have a JS8Call trace log under Enables / View Logs.  Bring that up and enable it and see what it says the next time you receive a CQ or HB containing a grid-square.  You may be the first person besides me using this feature, so please bear with me while we get it working.

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

On 10/5/2020 11:21 AM, KP3FT via groups.io wrote:
Hi Lynn,

Thanks for the info.  I'm running the latest development version of APRSis32.  I must have something set wrong.  I tried what you said, but still didn't get anything on my map after running JS8Call on 40m for many hours (quite a lot of stations received).  I have the Object (KP3FT-J8) pointing to the correct JS8Call folder and ALL.TXT file.  Here's my Object settings; I just used the default that came up.  The stations in my screenshot are local from 2-meters.




Re: Mapping JS8Call stations to local APRSis32 map?

KP3FT
 

Hi Lynn,

Thanks for the info.  I'm running the latest development version of APRSis32.  I must have something set wrong.  I tried what you said, but still didn't get anything on my map after running JS8Call on 40m for many hours (quite a lot of stations received).  I have the Object (KP3FT-J8) pointing to the correct JS8Call folder and ALL.TXT file.  Here's my Object settings; I just used the default that came up.  The stations in my screenshot are local from 2-meters.




Re: Mapping JS8Call stations to local APRSis32 map?

Lynn Deffenbaugh
 

If you have the latest development version, you should be able to configure a "JS8Call" Object in Configure / Objects / New JS8Call.  I call mine KJ4ERJ-J8.  When you create the object, APRSIS32 should prompt you to tell it where the ALL.TXT file is in your JS8Call Log directory (Log / Open Log Directory menu option in JS8call).  Once you enable the object (Interval and RF Path don't matter), APRSIS32 will scrape the JS8Call's LOG.TXT file for any reception reports that appear to be an amateur radio callsign and grid square.  New objects will be created on your map with either -HB or -CQ depending on what JS8 packet was discovered.

My current map (monitoring 40m JS8Call all day today) is:

The stations without a suffix are those that come from JS8's APRS Internet gateway.  You can include those with an Additional Filter of u/APJ8*.

I run a dedicated instance for this mapping with a Range of 0 (zero) and a passcode of -1.

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

On 10/4/2020 6:44 PM, KP3FT via groups.io wrote:
Hi all,

Is it possible to map JS8Call stations to a local APRSis32 instance, on a computer with no internet access?  I've tried setting a port up in APRSis32 as "TXT" type and pointed it to 127.0.0.1 on port 2442, but not sure what I'm doing.  I can get stations to send back their grid square in JS8Call when I request one, but it doesn't show on the APRSis32 map.


Mapping JS8Call stations to local APRSis32 map?

KP3FT
 

Hi all,

Is it possible to map JS8Call stations to a local APRSis32 instance, on a computer with no internet access?  I've tried setting a port up in APRSis32 as "TXT" type and pointed it to 127.0.0.1 on port 2442, but not sure what I'm doing.  I can get stations to send back their grid square in JS8Call when I request one, but it doesn't show on the APRSis32 map.


Re: Reject SSID DIGI List

Justin Cherington
 

Lynn - is this on the list of potential developments? We’ve got some pilots here that flood the area anytime they are above 300 feet. 


Re: Reject SSID DIGI List

Lynn Deffenbaugh
 

Sorry, but APRSIS32 does not support black-listing, nor filtered digipeating at this time.  The digipeater logic is solely governed by the first unused component in the received packets.

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

On 10/4/2020 12:08 AM, ve2pcq@... wrote:
Is there a way to reject some SSID to be Digipeted from my APRSISCE that is running in I-Gate an DIGI.
I have a hude coverage and would like to filter and not Digipeted some station that are sending to many packets.


Reject SSID DIGI List

ve2pcq@...
 

Is there a way to reject some SSID to be Digipeted from my APRSISCE that is running in I-Gate an DIGI.
I have a hude coverage and would like to filter and not Digipeted some station that are sending to many packets.


Re: Connect with Kenwood D700A

Lynn Deffenbaugh
 

APRSIS32 only supports the D710 in APRS mode, not the D700.

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

On 9/29/2020 9:31 AM, ve6tdx wrote:
Try setting it to aprs12

On Tue., Sep. 29, 2020, 07:20 Joseph LaFerla, <joe@...> wrote:
I am trying to connect my Kenwood D700A with aprsisce and can successfully receive packets from aprs.  However I cannot transmit.  At least nothing happens when I hit the transmit button on the toolbar.  I have set up the port correctly and transmit is enabled in the settings.  The port is a simply kiss port.  I used to use aprsisce with my other radio (non kenwood) before and it worked fine so I suspect some setting in the kenwood.  The D700a is set to tnc pkt but I tried it with tnc aprs and it still did not work.

Any thoughts would be welcome.  Thanks.

Joe VA3JLF


Re: Connect with Kenwood D700A

Lynn Deffenbaugh
 

Simply(KISS) type is only for TNCs that can be locked into KISS mode.  The Kenwood APRS radios (outside of the D74) cannot be locked into KISS.

For the D700, use a KISS type port (not Simply) and make sure the radio is in Pkt mode when you start APRSIS32 or enable the port.  APRSIS32's KISS type port will switch Kenwood APRS radios into KISS from Packet mode automatically.

Be aware, though, that if you power-cycle the radio, it will drop out of KISS mode and APRSIS32 will no longer receive packets.  Disabling and enabling the port in APRSIS32 (or stopping and restarting the client) will put the radio's TNC back into KISS mode, provided it was in Pakcet mode to start.  A non-zero Quiet Time setting can automate this reset.

http://aprsisce.wikidot.com/tnc-d700

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

On 9/29/2020 9:19 AM, Joseph LaFerla wrote:
I am trying to connect my Kenwood D700A with aprsisce and can successfully receive packets from aprs.  However I cannot transmit.  At least nothing happens when I hit the transmit button on the toolbar.  I have set up the port correctly and transmit is enabled in the settings.  The port is a simply kiss port.  I used to use aprsisce with my other radio (non kenwood) before and it worked fine so I suspect some setting in the kenwood.  The D700a is set to tnc pkt but I tried it with tnc aprs and it still did not work.

Any thoughts would be welcome.  Thanks.

Joe VA3JLF


Re: Connect with Kenwood D700A

ve6tdx
 

Try setting it to aprs12


On Tue., Sep. 29, 2020, 07:20 Joseph LaFerla, <joe@...> wrote:
I am trying to connect my Kenwood D700A with aprsisce and can successfully receive packets from aprs.  However I cannot transmit.  At least nothing happens when I hit the transmit button on the toolbar.  I have set up the port correctly and transmit is enabled in the settings.  The port is a simply kiss port.  I used to use aprsisce with my other radio (non kenwood) before and it worked fine so I suspect some setting in the kenwood.  The D700a is set to tnc pkt but I tried it with tnc aprs and it still did not work.

Any thoughts would be welcome.  Thanks.

Joe VA3JLF


Re: Connect with Kenwood D700A

Min
 

Hi Joe

 

I have the same setup and the interface can be a pain.

 

Make sure you have the correct driver if your using a USB to 9 pin D connector (some use a Prolific Chip and you may need to find a driver from 2007)

Try here  https://www.miklor.com/COM/UV_Drivers.php

 

You may have to unplug the USB and re plug it to get the Kenwood to suddenly fire up… plug USB port in wait a few seconds and see if the CON sign comes on the radio, then you can try the TX.

 

This has to be done each time PC is shut down or USB unplugged.

 

Radio has to be in TNC Pack mode.

 

Good luck

 

Min G0JMS

 

 

From: APRSISCE@groups.io [mailto:APRSISCE@groups.io] On Behalf Of Joseph LaFerla
Sent: 29 September 2020 14:20
To: APRSISCE@groups.io
Subject: [APRSISCE] Connect with Kenwood D700A

 

I am trying to connect my Kenwood D700A with aprsisce and can successfully receive packets from aprs.  However I cannot transmit.  At least nothing happens when I hit the transmit button on the toolbar.  I have set up the port correctly and transmit is enabled in the settings.  The port is a simply kiss port.  I used to use aprsisce with my other radio (non kenwood) before and it worked fine so I suspect some setting in the kenwood.  The D700a is set to tnc pkt but I tried it with tnc aprs and it still did not work.

Any thoughts would be welcome.  Thanks.

Joe VA3JLF


Connect with Kenwood D700A

Joseph LaFerla
 

I am trying to connect my Kenwood D700A with aprsisce and can successfully receive packets from aprs.  However I cannot transmit.  At least nothing happens when I hit the transmit button on the toolbar.  I have set up the port correctly and transmit is enabled in the settings.  The port is a simply kiss port.  I used to use aprsisce with my other radio (non kenwood) before and it worked fine so I suspect some setting in the kenwood.  The D700a is set to tnc pkt but I tried it with tnc aprs and it still did not work.

Any thoughts would be welcome.  Thanks.

Joe VA3JLF


Re: Cross band digi

Patrick Connor
 

If you are using hardware TNCs, try Aprx Digipeater

Patrick (N3TSZ)


On Sunday, September 27, 2020, 09:22:13 AM EDT, Bradley Haney via groups.io <k9bdh@...> wrote:





Begin forwarded message:

From: Brad Haney <bhaney@...>
Date: September 27, 2020 at 7:13:28 AM CDT
To: "APRSISCE@groups.io" <APRSISCE@groups.io>
Subject: Cross band digi

Looking for a way to cross band  my 9600 baud digi i have hooked up to my 1200 baud digi     Is there a way to do that in the xml?

I found a sepertate program but i font want to run  a sound card modem

Brad  
K9bdh


Cross band digi

Bradley Haney
 




Begin forwarded message:

From: Brad Haney <bhaney@...>
Date: September 27, 2020 at 7:13:28 AM CDT
To: "APRSISCE@groups.io" <APRSISCE@groups.io>
Subject: Cross band digi

Looking for a way to cross band  my 9600 baud digi i have hooked up to my 1200 baud digi     Is there a way to do that in the xml?

I found a sepertate program but i font want to run  a sound card modem

Brad  
K9bdh


Re: APRSIS32 multiple instances on Win10

Demetre - M0SUY/SV1UY
 

Thanks for reply Lyn,

Actually I've discovered that the COM port was to blame because it had been changed. Once the COM port was correct, APRSIS32 started OK, although I was asked once where are the OSM files are going to be and I directed them in the correct subdirectory.

So really it might have not been the wrong COMport either and it was that the new installation could not find the OSM files.

In any case, thanks for the quick response which made me to check my installation more carefully!

Well we have the same brain, winter and summer, so it does malfunction at times! Pity it is not renewable! Hi hi hi!!

Thanks again and take care!

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


Re: APRSIS32 multiple instances on Win10

Lynn Deffenbaugh
 

Create a new directory, copy the .EXE into that directory or create a shortcut that specifies that directory as the "Start in" directory, double-click the .EXE in that directory or the shortcut that specifies that directory.

I do it all the time under Windows 10 and have probably 10-15 different instance locations for different purposes.

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

On 9/27/2020 7:07 AM, Demetre - M0SUY/SV1UY wrote:
Hi all,

Can anyone work 2 or more instances of APRSIS32 in Windows 10? I would love to
know how you do it!

I can work more than one instance of APRS32 in Windows 8.1 without any problems
either by using the same APRSIS32.EXE and put the XML of each instance in it's
own directory or by moving APRSIS32.EXE along with the XML file in another directory!

This is not possible in my Windows 10 PC though. Whenever I try to start a 2nd APRSIS32
session the way I described above, the 2nd session does not start, instead I am directed
to the 1st session and the 2nd session never runs, no matter what I do!

Any ideas would be much appreciated!


APRSIS32 multiple instances on Win10

Demetre - M0SUY/SV1UY
 

Hi all,

Can anyone work 2 or more instances of APRSIS32 in Windows 10? I would love to
know how you do it!

I can work more than one instance of APRS32 in Windows 8.1 without any problems
either by using the same APRSIS32.EXE and put the XML of each instance in it's
own directory or by moving APRSIS32.EXE along with the XML file in another directory!

This is not possible in my Windows 10 PC though. Whenever I try to start a 2nd APRSIS32
session the way I described above, the 2nd session does not start, instead I am directed
to the 1st session and the 2nd session never runs, no matter what I do!

Any ideas would be much appreciated!

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


Re: Central Florida, Identifying a station in the packet string

Lynn Deffenbaugh
 

Good point!

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

On 9/23/2020 5:23 AM, John KC4LZN wrote:
Lynn,

Hmm...

While it would explain it on the output, still doesn't explain why I'm receiving it on the input frequency .

73
John

On Tue, Sep 22, 2020, 19:26 Lynn Deffenbaugh <kj4erj@...> wrote:

If the voice repeater is colocated with the N4FLA-3 digipeater, that may be the source of it.  I'm guessing the digipeater probably runs at 50 watts, at least that's what the PHG says.  I wonder if the voice repeater input may be getting cross-talk from the digipeater?  I could see this happening when a properly-toned signal opens the repeater and a digipeat happens during the repeater tail.

But then again, if that were the case, I would expect the captured packets to have an N4FLA-3 in the used path somewhere, assuming the digipeater does callsign insertion.

What would be really sweet would be to splice into the repeater input audio and run it into a soundcard TNC on something like a PI or phone which could then relay all captured packets somewhere for near realtime visibility.  Do you know if that would be possible and/or if the site has Internet access?  Although for this use and the proper software, a cellphone with a reasonable data plan would probably work fine.

As a final thought, and this is really a stretch, is it possible that the audio from the digipeater radio is somehow being coupled into the repeater input audio?  That sort of thing could explain the packets without the N4FLA-3 in the path because it would be what the digipeater received, not what it transmitted.

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

On 9/22/2020 5:59 PM, John KC4LZN wrote:
Lynn,

I figured you could hear WC4PEM every once and a while and yes, I agree, they have been doing that for quite some time now and I don't suspect them as being the culprit. 

As for only two packets, that is all I got in a 24 hour period. With that, it tells me that I am on the fringe of the signal putting out that packet and explains why I'm only getting a few packets. Good propagation probably gave me those because after three days, those are the only two packets I could capture. While you mentioned utilizing other hams in the area, yes, it will probably take a team of listeners to resolve this. The timestamp on the string I provided was from yesterday and it being at 211337 means that it was received at 0937 local time yesterday morning if that timestamp is UTC or it was at 01:37 p.m. yesterday afternoon. 

The N4FLA voice repeater and N4FLA-3 are the same location. I believe it has a height of around 200 feet and would have a better reception than what I do at 12 feet. 

As for the station and ensuring no other data is being received, I have a TT4 hooked to my 2m rig with the squelch open on the input frequency of 147.855  with Tera Term running with an open log to capture whatever it can, whenever it can. I do not have the microphone cable connected so as not to transmit myself if a packet were to be received. 

I appreciate all the input and apologize for my mis-interpretation because after doing APRS since 1997, a lot has changed. After the New paradigm change and the introduction of many, many different devices, I stopped trying to keep up with all of the different codes and I applaud you Lynn for still trying to keep and make some sense of it because it is a chore with all of the changes. 

I will try to reach out to some other hams in the south part of Lake County and see if they can set up some monitoring stations so we can try to provide some better data. As Patrick and Randy mentioned before, I too, believe it is either a dual port or dual purpose device that is programmed where it is transmitting onto the input of the repeater. Not so much maliciously but by accident. Trust me, I've made my mistakes along the way setting stuff up and not having this or that set properly, only to apologize later.

If my setup hears anything else, I'll add as it comes. Thanks again for all the input.

73
John 

On Tue, Sep 22, 2020 at 5:01 PM Lynn Deffenbaugh <kj4erj@...> wrote:

Oh yeah, and a good timestamp on all received packets so we can go back through the various logs and know what we're looking at.

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

On 9/22/2020 4:43 PM, Lynn Deffenbaugh wrote:

And I think it would be best to have a bigger data set than 2 packets from a single station within 24 hours before we leap to conclusions as to what the source of the packets might be.

I know the D700 in my car "hears" my 144.390 transmissions when I'm monitoring the 146.610 voice repeater, but not when I'm monitoring 146.850.  I blame it on overdriving the receiver with nearby transmissions which is why I'm interested in the actual location of the N4FLA 147.255 voice repeater.

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

On 9/22/2020 4:32 PM, Randy Love wrote:
A 'friend' here locally had an issue with his APRS sending thru a local repeater.
He was using an IC-2820 with a TNC into the back data port, running APRSIS32, and had the packet band set to MAIN instead of the LEFT side of his radio.
Once he set it to left, the mystery packets disappeared.. 

You're probably gonna have to DF that signal... It does seem like it's porting to RF without the proper 3rd party headers.

Randy
WF5X


On Tue, Sep 22, 2020 at 4:19 PM Lynn Deffenbaugh <kj4erj@...> wrote:

when I shift over to the input of our repeater I have only captured two bursts of packets in a 24-hour period.

DFing or Fox Hunting something of that low a frequency will be nearly impossible, IMHO.

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

On 9/22/2020 2:57 PM, Patrick Connor via groups.io wrote:
Here's my interpretation:
WC4PEM-9 and WC4PEM-14 are the last Digis in each packet and neither of them remove the WIDE2-0 counter which is why you get WIDE2* at the end of each packet. (That also makes it appear as if there were 3 hops, and not 2). Of greater concern is the fact that these packets are getting into a repeater with tone squelch. The transmitter sending these packets must also be encoding a sub-audible tone. It could be an accident, or someone is experimenting and not realizing the consequences of their actions. But, it might also be malicious. So it sounds as if DFing and a Fox Hunt are required to resolve the situation. 

Patrick (N3TSZ)


On Tuesday, September 22, 2020, 02:34:05 PM EDT, John KC4LZN <kc4lzn@...> wrote:


The other thing too Rob, is, those repeaters are on very high towers. I can tune to $144.39 and hear them continuously over and over. when I shift over to the input of our repeater I have only captured two bursts of packets in a 24-hour period. That's why I don't think it is the broad-wide coverage digipeder for WC4PEM.

73 John

On Tue, Sep 22, 2020, 14:24 John KC4LZN via groups.io <kc4lzn=gmail.com@groups.io> wrote:
Rob,

Because the -9 and the -14 was heard on two individual packets, having come from two different locations is my reasoning thinking that it is not the WC4PEM repeaters.

I will confirm with the Polk County Emergency Management team that owns those repeaters and find out and make sure. 

Yes, understand that the WIDE2 is not a call sign but the injection of the last hop where it is in place in lieu of the call to end the digipeat, or at least that is what I remember so that is why I'm thinking this is going to be tough to trace out but we'll see.

73
John

On Tue, Sep 22, 2020, 14:05 Rob Giuliano via groups.io <kb8rco=yahoo.com@groups.io> wrote:
The WIDE2* is the path component of WIDE2-2 with all hops used.
The full trace would look something like this:
   WA4ISB-1>APMI06,WIDE2-2:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
   WA4ISB-1>APMI06,NI4CE-11,WIDE2-1:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
   WA4ISB-1>APMI06,NI4CE-11,WC4PEM-14,WIDE2*:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
So WIDE2* is not a callsign at all. 

How confident are you in the WC4PEM callsign not being the issue?
Since the DIGI's are all used up in what was recorded from the repeatrer, it is unlikely someone else would DIGI the packet again (shouldn't), so either it is the last callsign-ssid or it is more likley someone is injecting the packet from IS to RF which is not identified.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 1:50:47 PM EDT, John KC4LZN <kc4lzn@...> wrote:


Rob,

Agreed, the replication you made would be what I would believe to be true but because both -9 and -14 are repeating the signal, I don't think they are transmitting on the input of our local repeater. Both of those digipeaters have been in service for a very long time. I will reach out to the Polk County Emergency Management team and ask if they've made any changes but would think that to be unlikely but there is always that 1% probability.

I'm thinking the digipeating station's call sign is the inserted WIDE2 and it's going to be a tough one to track down, next to some type of triangulation along with a number of other hams participating in trying to isolate the source. A fox hound hunt would be a bit difficult too because there is no rhyme or reason to the transmissions.

Thanks for the reply and I'll keep working on it in hopes I can get a source.

73
John

On Tue, Sep 22, 2020 at 11:51 AM Rob Giuliano via groups.io <kb8rco=yahoo.com@groups.io> wrote:
Looking at the TX station on aprs.fi it appears he is sending with a path of only WIDE2.
I am not sure which day you copied the messages, so it is tough match timestamps.

For your data below, from a DIGI standpoint it was handled by NI4CE-11 and WC4PEM-14 (or WC4PEM-9 for second packet) which used up the 2 hops.
  So, it is most likley one of those 2 callsigns.

I am trying to remember the order of insertion, but I think it is left to right, so it would have followed this:
WA4ISB-1>APMI06,WIDE2-2:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather 
WA4ISB-1>APMI06,NI4CE-11,WIDE2-1:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
WA4ISB-1>APMI06,NI4CE-11,WC4PEM-14,WIDE2*:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather 

From that it appears WC4PEM was the last callsign (with SSID of 14) to handle the packet.
Of course it still could be someone gating from IS to RF incorrectly.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 8:30:41 AM EDT, John KC4LZN <kc4lzn@...> wrote:


First, this is one of only a few, active APRS channels that I have been a member of for some time and need some help with my memory in deciphering the packet string on an APRS system.

I live in Central Florida and in the past few months, I have been hearing the proverbial burst of packet on our local repeater. The repeater is N4FLA 147.255.

I set up my TT4 and tuned to the repeater output and captured nothing but garbage, thinking it was only capturing a portion of the string and it wasn't able to decipher it, missing the first part of the burst. 

Next test was to listen to the input at 147.855, squelch open, hoping that the station was close enough for me to hear so I could capture the full string. Well? Success, sort of.

One, I was able to capture a string and did a screen capture of the data but failed to save the file in its entirety but think I have enough to go on. But, because this identifying station was on the end of the string, I'm not sure I'm going to be able to ID just who it is that is digi'ing this signal. 

I have two  received packets and here is the initial part of the string.

WA4ISB-1>APMI06,NI4CE-11,WC4PEM-14,WIDE2*:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather 
 
WA4ISB-1>APMI06,NI4CE-11,WC4PEM-9,WIDE2*:@0211337z2720.62N/0823048W_358/ t077r000p000P000h76b10149WA4IS B weather

It is a digi of a WX packet. Most of it was trunked because I didn't have the window open enough to capture all of it. If memory serves me correct, the WIDE2* was the digi'ing station. The two strings are from what appears from two different digipeaters but I doubt both of them are trying to transmit on our input. My thought is, the WIDE2* is the digi'ing station without the identifier of who they actually are and that isn't unusual, if the protocol serves me correct.

DB0ANF used to be a database website, accessible to identify who was a digipeater but that site has since gone silent and I don't know of any other site that was doing things quite like he was. Is there another site like that one that collects data to possibly see data like that?

Can someone, one, refresh my memory on the protocol and two, possibly try and monitor the input of our local frequency to see if they can capture any more than I am in hopes to identify this station so we can correct their transmit digi?

73
John
KC4LZN
EL98ds


Re: Central Florida, Identifying a station in the packet string

John KC4LZN
 

Lynn,

Hmm...

While it would explain it on the output, still doesn't explain why I'm receiving it on the input frequency .

73
John

On Tue, Sep 22, 2020, 19:26 Lynn Deffenbaugh <kj4erj@...> wrote:

If the voice repeater is colocated with the N4FLA-3 digipeater, that may be the source of it.  I'm guessing the digipeater probably runs at 50 watts, at least that's what the PHG says.  I wonder if the voice repeater input may be getting cross-talk from the digipeater?  I could see this happening when a properly-toned signal opens the repeater and a digipeat happens during the repeater tail.

But then again, if that were the case, I would expect the captured packets to have an N4FLA-3 in the used path somewhere, assuming the digipeater does callsign insertion.

What would be really sweet would be to splice into the repeater input audio and run it into a soundcard TNC on something like a PI or phone which could then relay all captured packets somewhere for near realtime visibility.  Do you know if that would be possible and/or if the site has Internet access?  Although for this use and the proper software, a cellphone with a reasonable data plan would probably work fine.

As a final thought, and this is really a stretch, is it possible that the audio from the digipeater radio is somehow being coupled into the repeater input audio?  That sort of thing could explain the packets without the N4FLA-3 in the path because it would be what the digipeater received, not what it transmitted.

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

On 9/22/2020 5:59 PM, John KC4LZN wrote:
Lynn,

I figured you could hear WC4PEM every once and a while and yes, I agree, they have been doing that for quite some time now and I don't suspect them as being the culprit. 

As for only two packets, that is all I got in a 24 hour period. With that, it tells me that I am on the fringe of the signal putting out that packet and explains why I'm only getting a few packets. Good propagation probably gave me those because after three days, those are the only two packets I could capture. While you mentioned utilizing other hams in the area, yes, it will probably take a team of listeners to resolve this. The timestamp on the string I provided was from yesterday and it being at 211337 means that it was received at 0937 local time yesterday morning if that timestamp is UTC or it was at 01:37 p.m. yesterday afternoon. 

The N4FLA voice repeater and N4FLA-3 are the same location. I believe it has a height of around 200 feet and would have a better reception than what I do at 12 feet. 

As for the station and ensuring no other data is being received, I have a TT4 hooked to my 2m rig with the squelch open on the input frequency of 147.855  with Tera Term running with an open log to capture whatever it can, whenever it can. I do not have the microphone cable connected so as not to transmit myself if a packet were to be received. 

I appreciate all the input and apologize for my mis-interpretation because after doing APRS since 1997, a lot has changed. After the New paradigm change and the introduction of many, many different devices, I stopped trying to keep up with all of the different codes and I applaud you Lynn for still trying to keep and make some sense of it because it is a chore with all of the changes. 

I will try to reach out to some other hams in the south part of Lake County and see if they can set up some monitoring stations so we can try to provide some better data. As Patrick and Randy mentioned before, I too, believe it is either a dual port or dual purpose device that is programmed where it is transmitting onto the input of the repeater. Not so much maliciously but by accident. Trust me, I've made my mistakes along the way setting stuff up and not having this or that set properly, only to apologize later.

If my setup hears anything else, I'll add as it comes. Thanks again for all the input.

73
John 

On Tue, Sep 22, 2020 at 5:01 PM Lynn Deffenbaugh <kj4erj@...> wrote:

Oh yeah, and a good timestamp on all received packets so we can go back through the various logs and know what we're looking at.

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

On 9/22/2020 4:43 PM, Lynn Deffenbaugh wrote:

And I think it would be best to have a bigger data set than 2 packets from a single station within 24 hours before we leap to conclusions as to what the source of the packets might be.

I know the D700 in my car "hears" my 144.390 transmissions when I'm monitoring the 146.610 voice repeater, but not when I'm monitoring 146.850.  I blame it on overdriving the receiver with nearby transmissions which is why I'm interested in the actual location of the N4FLA 147.255 voice repeater.

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

On 9/22/2020 4:32 PM, Randy Love wrote:
A 'friend' here locally had an issue with his APRS sending thru a local repeater.
He was using an IC-2820 with a TNC into the back data port, running APRSIS32, and had the packet band set to MAIN instead of the LEFT side of his radio.
Once he set it to left, the mystery packets disappeared.. 

You're probably gonna have to DF that signal... It does seem like it's porting to RF without the proper 3rd party headers.

Randy
WF5X


On Tue, Sep 22, 2020 at 4:19 PM Lynn Deffenbaugh <kj4erj@...> wrote:

when I shift over to the input of our repeater I have only captured two bursts of packets in a 24-hour period.

DFing or Fox Hunting something of that low a frequency will be nearly impossible, IMHO.

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

On 9/22/2020 2:57 PM, Patrick Connor via groups.io wrote:
Here's my interpretation:
WC4PEM-9 and WC4PEM-14 are the last Digis in each packet and neither of them remove the WIDE2-0 counter which is why you get WIDE2* at the end of each packet. (That also makes it appear as if there were 3 hops, and not 2). Of greater concern is the fact that these packets are getting into a repeater with tone squelch. The transmitter sending these packets must also be encoding a sub-audible tone. It could be an accident, or someone is experimenting and not realizing the consequences of their actions. But, it might also be malicious. So it sounds as if DFing and a Fox Hunt are required to resolve the situation. 

Patrick (N3TSZ)


On Tuesday, September 22, 2020, 02:34:05 PM EDT, John KC4LZN <kc4lzn@...> wrote:


The other thing too Rob, is, those repeaters are on very high towers. I can tune to $144.39 and hear them continuously over and over. when I shift over to the input of our repeater I have only captured two bursts of packets in a 24-hour period. That's why I don't think it is the broad-wide coverage digipeder for WC4PEM.

73 John

On Tue, Sep 22, 2020, 14:24 John KC4LZN via groups.io <kc4lzn=gmail.com@groups.io> wrote:
Rob,

Because the -9 and the -14 was heard on two individual packets, having come from two different locations is my reasoning thinking that it is not the WC4PEM repeaters.

I will confirm with the Polk County Emergency Management team that owns those repeaters and find out and make sure. 

Yes, understand that the WIDE2 is not a call sign but the injection of the last hop where it is in place in lieu of the call to end the digipeat, or at least that is what I remember so that is why I'm thinking this is going to be tough to trace out but we'll see.

73
John

On Tue, Sep 22, 2020, 14:05 Rob Giuliano via groups.io <kb8rco=yahoo.com@groups.io> wrote:
The WIDE2* is the path component of WIDE2-2 with all hops used.
The full trace would look something like this:
   WA4ISB-1>APMI06,WIDE2-2:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
   WA4ISB-1>APMI06,NI4CE-11,WIDE2-1:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
   WA4ISB-1>APMI06,NI4CE-11,WC4PEM-14,WIDE2*:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
So WIDE2* is not a callsign at all. 

How confident are you in the WC4PEM callsign not being the issue?
Since the DIGI's are all used up in what was recorded from the repeatrer, it is unlikely someone else would DIGI the packet again (shouldn't), so either it is the last callsign-ssid or it is more likley someone is injecting the packet from IS to RF which is not identified.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 1:50:47 PM EDT, John KC4LZN <kc4lzn@...> wrote:


Rob,

Agreed, the replication you made would be what I would believe to be true but because both -9 and -14 are repeating the signal, I don't think they are transmitting on the input of our local repeater. Both of those digipeaters have been in service for a very long time. I will reach out to the Polk County Emergency Management team and ask if they've made any changes but would think that to be unlikely but there is always that 1% probability.

I'm thinking the digipeating station's call sign is the inserted WIDE2 and it's going to be a tough one to track down, next to some type of triangulation along with a number of other hams participating in trying to isolate the source. A fox hound hunt would be a bit difficult too because there is no rhyme or reason to the transmissions.

Thanks for the reply and I'll keep working on it in hopes I can get a source.

73
John

On Tue, Sep 22, 2020 at 11:51 AM Rob Giuliano via groups.io <kb8rco=yahoo.com@groups.io> wrote:
Looking at the TX station on aprs.fi it appears he is sending with a path of only WIDE2.
I am not sure which day you copied the messages, so it is tough match timestamps.

For your data below, from a DIGI standpoint it was handled by NI4CE-11 and WC4PEM-14 (or WC4PEM-9 for second packet) which used up the 2 hops.
  So, it is most likley one of those 2 callsigns.

I am trying to remember the order of insertion, but I think it is left to right, so it would have followed this:
WA4ISB-1>APMI06,WIDE2-2:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather 
WA4ISB-1>APMI06,NI4CE-11,WIDE2-1:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
WA4ISB-1>APMI06,NI4CE-11,WC4PEM-14,WIDE2*:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather 

From that it appears WC4PEM was the last callsign (with SSID of 14) to handle the packet.
Of course it still could be someone gating from IS to RF incorrectly.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 8:30:41 AM EDT, John KC4LZN <kc4lzn@...> wrote:


First, this is one of only a few, active APRS channels that I have been a member of for some time and need some help with my memory in deciphering the packet string on an APRS system.

I live in Central Florida and in the past few months, I have been hearing the proverbial burst of packet on our local repeater. The repeater is N4FLA 147.255.

I set up my TT4 and tuned to the repeater output and captured nothing but garbage, thinking it was only capturing a portion of the string and it wasn't able to decipher it, missing the first part of the burst. 

Next test was to listen to the input at 147.855, squelch open, hoping that the station was close enough for me to hear so I could capture the full string. Well? Success, sort of.

One, I was able to capture a string and did a screen capture of the data but failed to save the file in its entirety but think I have enough to go on. But, because this identifying station was on the end of the string, I'm not sure I'm going to be able to ID just who it is that is digi'ing this signal. 

I have two  received packets and here is the initial part of the string.

WA4ISB-1>APMI06,NI4CE-11,WC4PEM-14,WIDE2*:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather 
 
WA4ISB-1>APMI06,NI4CE-11,WC4PEM-9,WIDE2*:@0211337z2720.62N/0823048W_358/ t077r000p000P000h76b10149WA4IS B weather

It is a digi of a WX packet. Most of it was trunked because I didn't have the window open enough to capture all of it. If memory serves me correct, the WIDE2* was the digi'ing station. The two strings are from what appears from two different digipeaters but I doubt both of them are trying to transmit on our input. My thought is, the WIDE2* is the digi'ing station without the identifier of who they actually are and that isn't unusual, if the protocol serves me correct.

DB0ANF used to be a database website, accessible to identify who was a digipeater but that site has since gone silent and I don't know of any other site that was doing things quite like he was. Is there another site like that one that collects data to possibly see data like that?

Can someone, one, refresh my memory on the protocol and two, possibly try and monitor the input of our local frequency to see if they can capture any more than I am in hopes to identify this station so we can correct their transmit digi?

73
John
KC4LZN
EL98ds

641 - 660 of 35468