Topics

Central Florida, Identifying a station in the packet string


John KC4LZN
 

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/ t077r000p000P000h76b10149WA4ISB weather 
 
WA4ISB-1>APMI06,NI4CE-11,WC4PEM-9,WIDE2*:@0211337z2720.62N/0823048W_358/ t077r000p000P000h76b10149WA4ISB 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


Rob Giuliano
 

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


John KC4LZN
 

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


Rob Giuliano
 

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


John KC4LZN
 

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


John KC4LZN
 

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


Rob Giuliano
 

WIDE2* is not the "injection" of anything, but the path element fromt he original packet with an indicator the full path has been used.

The original packet requested 2 hops.  NI4CE-11 used one, and WC4PEM-14 used the other - NONE LEFT.
As shown below,
  NI4CE-11 digi'ed the packet by inserting its callsign and reduce the path from WIDE2-2 to WIDE2-1.
  WC4PEM-14 heard the packet, and noticed that the path was not exhausted so DIGI'ed it.
  WC4PEM-14 inserted its callsign and reduce the path from WIDE2-1 to WIDE2* as shown.

The '*' means no hops left, so no other DIGI's will act on it.  No injection, it is actually 'the' used up part of the original packet path just as the WIDE2-1 would have been if you had capture the packet between digi's.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 2:24:31 PM EDT, John KC4LZN <kc4lzn@...> 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


John KC4LZN
 

Rob,

Maybe my explanation of "injection" isn't the proper terminology but I get that. 

What I was trying to explain was, ONE, trying to refresh my memory where the last station in the path taking it down to WIDE2*, inserted per protocol, in lieu of the call sign because it was the last digi in the string. 

That being said, the call sign that transmitted WIDE2* was the digi and that call sign is NOT KNOWN because protocol says to inject (insert) WIDE2* so that it doesn't get another hop. 

So we will really never know who the digi was that transmitted the WIDE2* because if it were WC4PEM-14 or -9, wouldn't there be an asterisk by their call? Correct?

73
John

On Tue, Sep 22, 2020 at 2:36 PM Rob Giuliano via groups.io <kb8rco=yahoo.com@groups.io> wrote:
WIDE2* is not the "injection" of anything, but the path element fromt he original packet with an indicator the full path has been used.

The original packet requested 2 hops.  NI4CE-11 used one, and WC4PEM-14 used the other - NONE LEFT.
As shown below,
  NI4CE-11 digi'ed the packet by inserting its callsign and reduce the path from WIDE2-2 to WIDE2-1.
  WC4PEM-14 heard the packet, and noticed that the path was not exhausted so DIGI'ed it.
  WC4PEM-14 inserted its callsign and reduce the path from WIDE2-1 to WIDE2* as shown.

The '*' means no hops left, so no other DIGI's will act on it.  No injection, it is actually 'the' used up part of the original packet path just as the WIDE2-1 would have been if you had capture the packet between digi's.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 2:24:31 PM EDT, John KC4LZN <kc4lzn@...> 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


Patrick Connor
 

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


Rob Giuliano
 

I took this from aprs.fi and they may not put the '*' on each call as it is used,
Most often, NI4CE-10 inserts gets it to the internet directly, but in some cases, it was DIGI'ed once or twice before getting to the internet.
   2020-09-22 14:22:15 EDT: WA4ISB-1>APMI06,WIDE2-2,qAR,NI4CE-10:@222114z2720.62N/08230.48W_358/000g000t084r000p000P000h49b10157WA4ISB weather
   2020-09-22 14:26:17 EDT: WA4ISB-1>APMI06,NI4CE-11,KK4ONE,WIDE2*,qAR,NI4CE-10:@222059z2720.62N/08230.48W_358/000g000t085r000p000P000h46b10159WA4ISB weather

This is how it was shown on aprs.fi, so I don't think these callsigns (NI4CE-11 and WC4PEM-14) were part of the original path but used elements of that path.

So from the first line it appears the original packet was:
   WA4ISB-1>APMI06,WIDE2-2:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
This was received by NI4CE-11 who DIGI'ed it by altering the received packet and sent
   WA4ISB-1>APMI06,NI4CE-11,WIDE2-1:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
This was received by WC4PEM-11 who DIGI'ed it by altering the received packet and sent
   WA4ISB-1>APMI06,NI4CE-11,WC4PEM-14,WIDE2*:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather

All path elements used after WC4PEM-14 sent it out and changed it from WIDE2-1 (from NI4CE-11) to WIDE2*. 
No DIGI will act on that packet because all elements of the path are used up.  It can't be taken down to WIDE2* again, it is ALREADY at WIDE2*. 
The LAST STATION who transmitted the packet (as a DIGI) from thsi line is WC4PEM-14. 

Again, I couldn't match the packet 'date' stamp (only time) to get the exact packet that was listed.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 2:53:54 PM EDT, John KC4LZN <kc4lzn@...> wrote:


Rob,

Maybe my explanation of "injection" isn't the proper terminology but I get that. 

What I was trying to explain was, ONE, trying to refresh my memory where the last station in the path taking it down to WIDE2*, inserted per protocol, in lieu of the call sign because it was the last digi in the string. 

That being said, the call sign that transmitted WIDE2* was the digi and that call sign is NOT KNOWN because protocol says to inject (insert) WIDE2* so that it doesn't get another hop. 

So we will really never know who the digi was that transmitted the WIDE2* because if it were WC4PEM-14 or -9, wouldn't there be an asterisk by their call? Correct?

73
John

On Tue, Sep 22, 2020 at 2:36 PM Rob Giuliano via groups.io <kb8rco=yahoo.com@groups.io> wrote:
WIDE2* is not the "injection" of anything, but the path element fromt he original packet with an indicator the full path has been used.

The original packet requested 2 hops.  NI4CE-11 used one, and WC4PEM-14 used the other - NONE LEFT.
As shown below,
  NI4CE-11 digi'ed the packet by inserting its callsign and reduce the path from WIDE2-2 to WIDE2-1.
  WC4PEM-14 heard the packet, and noticed that the path was not exhausted so DIGI'ed it.
  WC4PEM-14 inserted its callsign and reduce the path from WIDE2-1 to WIDE2* as shown.

The '*' means no hops left, so no other DIGI's will act on it.  No injection, it is actually 'the' used up part of the original packet path just as the WIDE2-1 would have been if you had capture the packet between digi's.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 2:24:31 PM EDT, John KC4LZN <kc4lzn@...> 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 Deffenbaugh
 

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


Randy Love
 

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 Deffenbaugh
 

John,

You're confusing two different approaches to digipeating.  The preferred method is callsign insertion which is what all three digipeaters in these two packets seem to be doing.  They decrement the first unused alias (originally WIDE2-2 from this station) and INSERT their own callsign BEFORE the decremented alias.  As Rob said, the progression would have been:

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 

The only thing he missed is that the NI4CE-11 would have had a used bit (*) set as I corrected above.  In actual fact, the two digipeaters in the final packet would also have been "used", but this is sometimes not done and/or not shown by the software translating the AX.25 header components into the humanly readable packet.

That being said, the call sign that transmitted WIDE2* was the digi and that call sign is NOT KNOWN because protocol says to inject (insert) WIDE2* so that it doesn't get another hop. 

This is another approach to digipeating where the unused component is decremented, but the digipeater doesn't insert its own callsign.  This makes troubleshooting very difficult but should not be the case with this particular packet.

The powers behind the WC4PEM* digipeaters know what they're doing and have been doing it for many years, so I suspect it's not -9 or -14 at fault.  And as John observed, they are so busy that the voice repeater would likely never drop carrier if they were actually transmitting on the input frequency.

My question for you John, is: Are you SURE these two packets were actually captured on the voice repeater input frequency?  There's nothing else in your shack or the PC's audio path that could have confused whatever software you are using to decode the errant packets.  Have you copied any other packets from the voice repeater input frequency yet?

The only approach I can think of is to have a bunch of stations do this same APRS monitoring on the voice repeater input frequency from a range of locations around the repeater's location.  Then slowly widen the route away from the repeater's location in the direction(s) that errant packets are copied.  This will take LOTS of folks willing and able to monitor for APRS packets on the voice repeater input frequency and LOTS of time as the direction from which those packets are copied is established.

John, do you have the coordinates of the N4FLA voice repeater so that we can an APRS object on the map to see where it actually is located relative to the WC4PEM-9/-14 digipeaters?

I do see a N4FLA-3 digipeater on the map, but suspect the voice repeater may be in a different location.

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

On 9/22/2020 2:53 PM, John KC4LZN wrote:
Rob,

Maybe my explanation of "injection" isn't the proper terminology but I get that. 

What I was trying to explain was, ONE, trying to refresh my memory where the last station in the path taking it down to WIDE2*, inserted per protocol, in lieu of the call sign because it was the last digi in the string. 

That being said, the call sign that transmitted WIDE2* was the digi and that call sign is NOT KNOWN because protocol says to inject (insert) WIDE2* so that it doesn't get another hop. 

So we will really never know who the digi was that transmitted the WIDE2* because if it were WC4PEM-14 or -9, wouldn't there be an asterisk by their call? Correct?

73
John

On Tue, Sep 22, 2020 at 2:36 PM Rob Giuliano via groups.io <kb8rco=yahoo.com@groups.io> wrote:
WIDE2* is not the "injection" of anything, but the path element fromt he original packet with an indicator the full path has been used.

The original packet requested 2 hops.  NI4CE-11 used one, and WC4PEM-14 used the other - NONE LEFT.
As shown below,
  NI4CE-11 digi'ed the packet by inserting its callsign and reduce the path from WIDE2-2 to WIDE2-1.
  WC4PEM-14 heard the packet, and noticed that the path was not exhausted so DIGI'ed it.
  WC4PEM-14 inserted its callsign and reduce the path from WIDE2-1 to WIDE2* as shown.

The '*' means no hops left, so no other DIGI's will act on it.  No injection, it is actually 'the' used up part of the original packet path just as the WIDE2-1 would have been if you had capture the packet between digi's.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 2:24:31 PM EDT, John KC4LZN <kc4lzn@...> 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 Deffenbaugh
 

Rob,

I totally concur with your path analysis of this station's (WA4ISB-1) packets.  Unfortunately, the NI4CE-11 digipeater covers a lot of territory.  Here's a picture of the past 2 minutes of paths from that digi:

And here's the past 30 minutes of traffic originated by WA4ISB-1.  If you look closely, there's a thin red line from WA4ISB-1 to NI4CE-11 indicating the first hop from the source was copied simplex by the NI4CE-11 digipeater.  And a bunch of the WC4PEM* digipeaters handled the packet from various paths as well.


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

PS.  "ME" on the east coast is my home QTH.  I copy some of the WC4PEM* digipeaters, but haven't copied any of these packets.  "Glen's IGate" to the south is my son-in-law's KN4EOG-10's IGate in Bonita Springs.

On 9/22/2020 4:17 PM, Rob Giuliano via groups.io wrote:
I took this from aprs.fi and they may not put the '*' on each call as it is used,
Most often, NI4CE-10 inserts gets it to the internet directly, but in some cases, it was DIGI'ed once or twice before getting to the internet.
   2020-09-22 14:22:15 EDT: WA4ISB-1>APMI06,WIDE2-2,qAR,NI4CE-10:@222114z2720.62N/08230.48W_358/000g000t084r000p000P000h49b10157WA4ISB weather
   2020-09-22 14:26:17 EDT: WA4ISB-1>APMI06,NI4CE-11,KK4ONE,WIDE2*,qAR,NI4CE-10:@222059z2720.62N/08230.48W_358/000g000t085r000p000P000h46b10159WA4ISB weather

This is how it was shown on aprs.fi, so I don't think these callsigns (NI4CE-11 and WC4PEM-14) were part of the original path but used elements of that path.

So from the first line it appears the original packet was:
   WA4ISB-1>APMI06,WIDE2-2:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
This was received by NI4CE-11 who DIGI'ed it by altering the received packet and sent
   WA4ISB-1>APMI06,NI4CE-11,WIDE2-1:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather
This was received by WC4PEM-11 who DIGI'ed it by altering the received packet and sent
   WA4ISB-1>APMI06,NI4CE-11,WC4PEM-14,WIDE2*:@211337z2720.62N/08230.48W_ 358/ t077r000p000P000h76b10149WA4IS B weather

All path elements used after WC4PEM-14 sent it out and changed it from WIDE2-1 (from NI4CE-11) to WIDE2*. 
No DIGI will act on that packet because all elements of the path are used up.  It can't be taken down to WIDE2* again, it is ALREADY at WIDE2*. 
The LAST STATION who transmitted the packet (as a DIGI) from thsi line is WC4PEM-14. 

Again, I couldn't match the packet 'date' stamp (only time) to get the exact packet that was listed.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 2:53:54 PM EDT, John KC4LZN <kc4lzn@...> wrote:


Rob,

Maybe my explanation of "injection" isn't the proper terminology but I get that. 

What I was trying to explain was, ONE, trying to refresh my memory where the last station in the path taking it down to WIDE2*, inserted per protocol, in lieu of the call sign because it was the last digi in the string. 

That being said, the call sign that transmitted WIDE2* was the digi and that call sign is NOT KNOWN because protocol says to inject (insert) WIDE2* so that it doesn't get another hop. 

So we will really never know who the digi was that transmitted the WIDE2* because if it were WC4PEM-14 or -9, wouldn't there be an asterisk by their call? Correct?

73
John

On Tue, Sep 22, 2020 at 2:36 PM Rob Giuliano via groups.io <kb8rco=yahoo.com@groups.io> wrote:
WIDE2* is not the "injection" of anything, but the path element fromt he original packet with an indicator the full path has been used.

The original packet requested 2 hops.  NI4CE-11 used one, and WC4PEM-14 used the other - NONE LEFT.
As shown below,
  NI4CE-11 digi'ed the packet by inserting its callsign and reduce the path from WIDE2-2 to WIDE2-1.
  WC4PEM-14 heard the packet, and noticed that the path was not exhausted so DIGI'ed it.
  WC4PEM-14 inserted its callsign and reduce the path from WIDE2-1 to WIDE2* as shown.

The '*' means no hops left, so no other DIGI's will act on it.  No injection, it is actually 'the' used up part of the original packet path just as the WIDE2-1 would have been if you had capture the packet between digi's.

Robert Giuliano
KB8RCO



On Tuesday, September 22, 2020, 2:24:31 PM EDT, John KC4LZN <kc4lzn@...> 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 Deffenbaugh
 

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 Deffenbaugh
 

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


John KC4LZN
 

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 Deffenbaugh
 

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


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


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