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.

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

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

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

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

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!

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

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

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

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