|
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
|
|
|
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.
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
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.
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
|
|
|
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.
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 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.
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
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.
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 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.
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
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
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.
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 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.
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
|
|
|
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.
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 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.
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 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.
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
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.
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 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.
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 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.
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 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
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.
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 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.
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
|
|
|
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.
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 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.
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 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.
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 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.
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
|
|
|
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
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
The WIDE2* is the path
component of WIDE2-2 with all hops used.
The full trace would look
something like this:
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.
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
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:
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.
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.
It is a digi of a WX
packet. Most of it was
trunked because I didn't
have the window open
enough to capture all of
it. If memory serves me
correct, the WIDE2* was
the digi'ing station.
The two strings are from
what appears from two
different digipeaters
but I doubt both of them
are trying to transmit
on our input. My thought
is, the WIDE2* is the
digi'ing station without
the identifier of who
they actually are and
that isn't unusual, if
the protocol serves me
correct.
DB0ANF used to be a
database website,
accessible to identify
who was a digipeater but
that site has since gone
silent and I don't know
of any other site that
was doing things quite
like he was. Is there
another site like that
one that collects data
to possibly see data
like that?
Can someone, one,
refresh my memory on the
protocol and two,
possibly try and monitor
the input of our local
frequency to see if they
can capture any more
than I am in hopes to
identify this station so
we can correct their
transmit digi?
73
John
KC4LZN
EL98ds
|
|
|
A 'friend' here locally had an issue with his APRS sending thru a local repeater. He was using an IC-2820 with a TNC into the back data port, running APRSIS32, and had the packet band set to MAIN instead of the LEFT side of his radio. Once he set it to left, the mystery packets disappeared..
You're probably gonna have to DF that signal... It does seem like it's porting to RF without the proper 3rd party headers.
Randy WF5X
On Tue, Sep 22, 2020 at 4:19 PM Lynn Deffenbaugh < kj4erj@...> wrote:
when I shift over to the input of our
repeater I have only captured two bursts of packets in a 24-hour
period.
DFing or Fox Hunting something of that low a frequency will be
nearly impossible, IMHO.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
On 9/22/2020 2:57 PM, Patrick Connor
via groups.io wrote:
Here's my interpretation:
WC4PEM-9 and WC4PEM-14 are
the last Digis in each packet and neither of them remove the
WIDE2-0 counter which is why you get WIDE2* at the end of
each packet. (That also makes it appear as if there were 3
hops, and not 2). Of greater concern is the fact that these
packets are getting into a repeater with tone squelch. The
transmitter sending these packets must also be encoding a
sub-audible tone. It could be an accident, or someone is
experimenting and not realizing the consequences of their
actions. But, it might also be malicious. So it sounds as if
DFing and a Fox Hunt are required to resolve the situation.
Patrick (N3TSZ)
On Tuesday, September 22, 2020, 02:34:05 PM EDT, John
KC4LZN <kc4lzn@...> wrote:
The other thing too Rob, is, those repeaters are on
very high towers. I can tune to $144.39 and hear them
continuously over and over. when I shift over to the
input of our repeater I have only captured two bursts of
packets in a 24-hour period. That's why I don't think it
is the broad-wide coverage digipeder for WC4PEM.
73 John
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
The WIDE2* is the path
component of WIDE2-2 with all hops used.
The full trace would look
something like this:
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.
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
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:
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.
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.
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,
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,NI4CE-11*,WIDE2-1:@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
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.
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
The WIDE2* is the path
component of WIDE2-2 with all hops
used.
The full trace would look
something like this:
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.
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
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:
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.
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.
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,
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.
toggle quoted messageShow quoted text
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:
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.
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
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.
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
The WIDE2* is
the path component of
WIDE2-2 with all hops used.
The full trace
would look something like
this:
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.
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
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:
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.
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.
It is a digi
of a WX
packet. Most
of it was
trunked
because I
didn't have
the window
open enough to
capture all of
it. If memory
serves me
correct, the
WIDE2* was the
digi'ing
station. The
two strings
are from what
appears from
two different
digipeaters
but I doubt
both of them
are trying to
transmit on
our input. My
thought is,
the WIDE2* is
the digi'ing
station
without the
identifier of
who they
actually are
and that isn't
unusual, if
the protocol
serves me
correct.
DB0ANF used to
be a database
website,
accessible to
identify who
was a
digipeater but
that site has
since gone
silent and I
don't know of
any other site
that was doing
things quite
like he was.
Is there
another site
like that one
that collects
data to
possibly see
data like
that?
Can someone,
one, refresh
my memory on
the protocol
and two,
possibly try
and monitor
the input of
our local
frequency to
see if they
can capture
any more than
I am in hopes
to identify
this station
so we can
correct their
transmit digi?
73
John
KC4LZN
EL98ds
|
|
|
And I think it would be best to have a bigger data set than 2
packets from a single station within 24 hours before we leap to
conclusions as to what the source of the packets might be.
I know the D700 in my car "hears" my 144.390 transmissions when
I'm monitoring the 146.610 voice repeater, but not when I'm
monitoring 146.850. I blame it on overdriving the receiver with
nearby transmissions which is why I'm interested in the actual
location of the N4FLA 147.255 voice repeater.
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
toggle quoted messageShow quoted text
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
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
The WIDE2* is the
path component of WIDE2-2 with all
hops used.
The full trace would
look something like this:
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.
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
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:
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.
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.
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
|
|
|
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
toggle quoted messageShow quoted text
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
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
The WIDE2* is the
path component of WIDE2-2 with
all hops used.
The full trace
would look something like this:
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.
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
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:
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.
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.
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
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
The WIDE2* is the
path component of WIDE2-2 with
all hops used.
The full trace
would look something like this:
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.
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
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:
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.
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.
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
|
|
|
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
toggle quoted messageShow quoted text
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
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
The WIDE2*
is the path component of
WIDE2-2 with all hops
used.
The full
trace would look
something like this:
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.
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
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:
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.
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.
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
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
The WIDE2*
is the path component of
WIDE2-2 with all hops
used.
The full
trace would look
something like this:
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.
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
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:
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.
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.
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
|
|
|
Good point!
Lynn (D) - KJ4ERJ - Author of APRSISCE
for Windows Mobile and Win32
toggle quoted messageShow quoted text
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
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
The
WIDE2* is the
path component
of WIDE2-2 with
all hops used.
The
full trace would
look something
like this:
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.
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
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:
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.
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.
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
|
|
|
