Duplicate position reports received via JS8Call

37 views
Skip to first unread message

Richard Murnane

unread,
Nov 14, 2022, 1:59:53 AM11/14/22
to aprs.fi
Hi all,

I don't think has mentioned this before, but I've noticed that position reports received via JS8Call are prone to "duplicates", apparently due to multiple stations receiving the posits, but having slightly different receive frequencies and including the rx frequency and RSSI in the relayed posit, thus rendering them "not-quite-duplicates".

By way of illustration, KD6XU/MM seems to beacon his location about once every half hour, but you can see below that the same position appears in his raw packets, as recorded at aprs.fi. I have highlighted in red the relevant bits in the first few posits:

2022-11-11 20:04:59 AEDT: KD6XU>APJ8CL,qAS,W7RLF:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079946MHz -18dB
2022-11-11 20:05:00 AEDT: KD6XU>APJ8CL,qAS,KD7WPQ:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079956MHz -18dB
2022-11-11 20:05:02 AEDT: KD6XU>APJ8CL,qAS,KL7R:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079948MHz -10dB
2022-11-11 20:05:08 AEDT: KD6XU>APJ8CL,qAS,AA0DY:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079955MHz -11dB
2022-11-11 20:05:08 AEDT: KD6XU>APJ8CL,qAS,N0JVW:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079941MHz -14dB
2022-11-11 20:05:13 AEDT: KD6XU>APJ8CL,qAS,K1OEV:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079949MHz +04dB
2022-11-11 20:05:16 AEDT: KD6XU>APJ8CL,qAS,KB9LX:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079951MHz -10dB
2022-11-11 20:05:17 AEDT: KD6XU>APJ8CL,qAS,WE4SEL:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079960MHz -07dB
2022-11-11 20:05:32 AEDT: KD6XU>APJ8CL,qAS,KY4HZ:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079948MHz +02dB
2022-11-11 20:05:40 AEDT: KD6XU>APJ8CL,qAS,VK3TTT:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079947MHz -07dB
2022-11-11 20:05:43 AEDT: KD6XU>APJ8CL,qAS,VK2SKY:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079933MHz +10dB
2022-11-11 20:05:55 AEDT: KD6XU>APJ8CL,qAS,NR9Q:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079952MHz -09dB
2022-11-11 20:05:56 AEDT: KD6XU>APJ8CL,qAS,N0GQ:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079965MHz -06dB
2022-11-11 20:06:06 AEDT: KD6XU>APJ8CL,qAS,K1TWH:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079953MHz -11dB
2022-11-11 20:06:32 AEDT: KD6XU>APJ8CL,qAS,N0KQX:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079948MHz -08dB

Some potential for saving a bit of disk space there HI.

73 Richard VK2SKY

Heikki Hannikainen

unread,
Nov 21, 2022, 1:58:03 AM11/21/22
to aprs.fi

Hi,

On Fri, 11 Nov 2022, Richard Murnane wrote:

> I don't think has mentioned this before, but I've noticed that position reports received via JS8Call are prone to
> "duplicates", apparently due to multiple stations receiving the posits, but having slightly different receive
> frequencies and including the rx frequency and RSSI in the relayed posit, thus rendering them
> "not-quite-duplicates".
>
> By way of illustration, KD6XU/MM seems to beacon his location about once every half hour, but you can see below
> that the same position appears in his raw packets, as recorded at aprs.fi. I have highlighted in red the relevant
> bits in the first few posits:
>
> 2022-11-11 20:04:59 AEDT: KD6XU>APJ8CL,qAS,W7RLF:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079946MHz -18dB
> 2022-11-11 20:05:00 AEDT: KD6XU>APJ8CL,qAS,KD7WPQ:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079956MHz -18dB
> 2022-11-11 20:05:02 AEDT: KD6XU>APJ8CL,qAS,KL7R:=2616.78S/17629.62EG#JS8 KD6XU/MM 7.079948MHz -10dB

This seems to be a bug in JS8Call. It is inserting unique data in the APRS
packet comment field (the frequency and received signal level), resulting
in multiple different copies of the same original packet, like
demonstrated here. Corrupted/modified duplicate packets.

On APRS, the original packet must not be modified by intermediate gateways
- an igate must not inject things like received signal level in the packet
data content. Each gateway must only forward the data received in the
packet, and if the gateway is doing a protocol conversion like this, each
gateway must perform the conversion exactly the same way.

This has proven to be quite difficult with protocol conversions, as
demonstrated by the weather sonde balloon receivers previously.

Richard, please post a bug report to JS8Call for this.

> Some potential for saving a bit of disk space there HI.

Yep, I'll look into this if JS8Call can't be fixed.

- Hessu

Richard Murnane

unread,
Nov 28, 2022, 4:30:30 AM11/28/22
to aprs.fi
On Monday, 21 November 2022 at 17:58:03 UTC+11 Heikki Hannikainen wrote:

This seems to be a bug in JS8Call. It is inserting unique data in the APRS
packet comment field (the frequency and received signal level), resulting
in multiple different copies of the same original packet, like
demonstrated here. Corrupted/modified duplicate packets.
 :
On APRS, the original packet must not be modified by intermediate gateways
- an igate must not inject things like received signal level in the packet
data content. Each gateway must only forward the data received in the
packet, and if the gateway is doing a protocol conversion like this, each
gateway must perform the conversion exactly the same way.

I concur.
 
Richard, please post a bug report to JS8Call for this.

Will do.

Just be aware that, according to https://bitbucket.org/widefido/js8call/commits/, JS8Call hasn't seen any activity since mid-202.

73 Richard VK2SKY 

Richard Murnane

unread,
Nov 28, 2022, 4:30:32 AM11/28/22
to aprs.fi
On Monday, 21 November 2022 at 17:58:03 UTC+11 Heikki Hannikainen wrote:

On APRS, the original packet must not be modified by intermediate gateways
- an igate must not inject things like received signal level in the packet
data content. Each gateway must only forward the data received in the
packet, and if the gateway is doing a protocol conversion like this, each
gateway must perform the conversion exactly the same way.

This has proven to be quite difficult with protocol conversions, as
demonstrated by the weather sonde balloon receivers previously.

Richard, please post a bug report to JS8Call for this.


Tnx & 73 Richard VK2SKY 
Reply all
Reply to author
Forward
0 new messages