Date   

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


Re: APRS Passcode

Lynn Deffenbaugh
 

When you need a passcode, please follow the instructions at:

http://aprsisce.wikidot.com/doc:passcode

Casey's passcode has been sent off-list.

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

On 9/22/2020 1:10 PM, KC8HLU wrote:
Hello, my name is Casey.
New to APRS. I have been listening to a local amateur radio club station transmitting APRS data for a few days. I have set up UZ7HO soundmodem on my PC, and configured APRSIS32. All seems to be working well. It's been great fun listening and watching as signals are received and interpreted. I'm getting to a point now where I would like to start sending transmissions of my own. I understand I will need a passcode in order for my data to be accepted into the APRS-IS network. Could somebody here help me with getting the passcode?

KC8HLU
Grand Haven, Michigan


APRS Passcode

KC8HLU
 

Hello, my name is Casey.
New to APRS. I have been listening to a local amateur radio club station transmitting APRS data for a few days. I have set up UZ7HO soundmodem on my PC, and configured APRSIS32. All seems to be working well. It's been great fun listening and watching as signals are received and interpreted. I'm getting to a point now where I would like to start sending transmissions of my own. I understand I will need a passcode in order for my data to be accepted into the APRS-IS network. Could somebody here help me with getting the passcode?

KC8HLU
Grand Haven, Michigan


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

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


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


Re: Passcode

Greg D
 

If you have a passcode for other APRS software to access (send to) the APRS-IS, it is the same for APRSISCE/32.

Greg  KO6TH


Steve wrote:

you were sent a passcode

73
Steve,  KF6WAX

On Sat, Sep 19, 2020 at 8:17 PM Adam Wake <nicandad@...> wrote:
Hi 

Can anyone tell me if I need a passcode for the software or is it my aprs password please?

Many thanks,

Adam


Re: Passcode

Steve
 

you were sent a passcode

73
Steve,  KF6WAX

On Sat, Sep 19, 2020 at 8:17 PM Adam Wake <nicandad@...> wrote:
Hi 

Can anyone tell me if I need a passcode for the software or is it my aprs password please?

Many thanks,

Adam


Passcode

Adam Wake
 

Hi 

Can anyone tell me if I need a passcode for the software or is it my aprs password please?

Many thanks,

Adam


Re: Passcode for Gary N Evans; KO4LAX

Lynn Deffenbaugh
 

Ok, I think this discussion is ready to be put out to pasture.

Most of us understand the insecurity of the current APRS-IS passcode system.  An attempt was made to use certificates, but even that change ran into concerns about scalability and global reach (it was based on LOTW).  So unless you have a solution AND the ability to implement said solution, let's just let it go.

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

On 9/17/2020 3:05 PM, Mike Jordan wrote:
Yep, the software didn't add it. But if it makes you feel better... KJ4TX.

Mike

On 9/17/2020 11:32 AM, Glenn O'Connor wrote:
Says Mike w/o a callsign...





Re: Passcode for Gary N Evans; KO4LAX

Mike Jordan <mjordan@...>
 

Yep, the software didn't add it. But if it makes you feel better... KJ4TX.

Mike

On 9/17/2020 11:32 AM, Glenn O'Connor wrote:
Says Mike w/o a callsign...


Re: Passcode for Gary N Evans; KO4LAX

Glenn O'Connor
 

Says Mike w/o a callsign...


Re: Passcode for Gary N Evans; KO4LAX

Mike Jordan <mjordan@...>
 

This is such a non-issue. If the information is on the internet, it's too late... anyone that wants to take the time to find it will.  Anyone can request a passcode and there is no validation that the person asking actually belongs to the call sign they used to request it.  Why put a suitcase lock on a process if it's suppose to have tight security in the first place? To me, the process of having a passcode that can be easily obtained is no security at all, just a means to keep someone from accidentally connecting to the database when they test out their APRS setup.  If the system needs security then give it real security, don't put it out where anyone can find it and use it if they want. Other wise it might as well be 1234 for everyone or not even exist.

I'll do my part though to keep it secure... if I run across it on the internet, I won't look. ;)

Mike

1081 - 1100 of 35881