Can an Igate that is delivering bogus data be filtered out?

[Patrick Bryant]

Igate W6PW-10 is delivering packets to APRS-IS that are hours delayed, in addition to garbled packets ("unsupported packet format") that are degrading the integrity of data.

I have written the club that operates the Igate, but received no reply.

Can the packets be filtered out of aprs.fi data please?

Example: 

2021-06-06 20:21:58 PDT: N8QH-9>APOT30,WA6TOW-2,WIDE1,KJ6DZB-4,WIDE2*,qAR,W6PW-10:/113801h/;Qr!/Qw7YX!G 13.1V 57F HDOP00.6 SATS12  [Delayed or out-of-order packet (timestamp)]

That packet was sent at 11:38:01 UTC (my GPS-generated timestamp), but delivered to APRS-IS at 13:21:58 UTC. This is a continual problem that has been ongoing for days.

Thank you! 

[Heikki Hannikainen]

On Mon, 7 Jun 2021, Patrick Bryant wrote:

> Igate W6PW-10 is delivering packets to APRS-IS that are hours delayed, in addition to garbled packets
> ("unsupported packet format") that are degrading the integrity of data.
>
> I have written the club that operates the Igate, but received no reply.
>
> Can the packets be filtered out of aprs.fi data please?

Right, I checked the data, and it indeed is passing just badly delayed
packets.

I've added a filter configuration for the W6PW-10 igate now.

- Hessu

[Porco Porco]

I have idea how to filter those bad packet , I send timed stamped APRS packet   such as starting   :/150730h   , so may be from that information, it  can determine which I-gate is bad one, and exclude from using data from that particular i-gate station ( call sign ).  in Orange County Calif USA,  we have several I-gate receive station who has packet delay to internet of over 20 minutes.

[Heikki Hannikainen]

Hi,

Yes, I have considered something like that. There is a precondition that
I'd need to first detect which stations are sending valid timestamps;
there's quite a few stations out there sending timestamps which either
don't change, which are wrong, or which are badly encoded. The most common
misencodings are using the 'z' timestamp to send HHMMSS UTC timestamps
while the 'z' identifier is for DDHHMM UTC timestamps. :)

Just today someone with a DMR radio was complaining, his DMR rig sends a
local-time HHMMSS timestamp claiming to be UTC when he tells it to send
fixed user-selected coordinates, and a valid UTC HHMMSS timestamp when
sending coordinates from the GPS. Go figure.

If there are good igates in the area, it should be possible to detect
packets from stations with correct fresh timestamps (a few seconds old at
most), and then detect their badly-delayed copies coming through the bad
igates.

> --
> You received this message because you are subscribed to the Google Groups "aprs.fi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to aprsfi+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/aprsfi/c3498f6d-caea-4f04-9b03-4eae3871d131n%40googlegroups.com.
>
>

- Hessu

[Porco Porco]

I believe , it is possible to find which I_GATE is bad, measuring time difference of first PACKET of same kind  to next packet of same data, such as exact same Latitude, longitude, speed, direction and other info  so on.  I think any Data which are exactly same came within 1 hours are probably badly delayed i-gate data.  such bad i-gate  can be put into ( ++i_bad_i_gate_counter  [ i_gate_station_ID ]  ).

[Heikki Hannikainen]

It is more complicated than that. There are a lot of stations which go
back and forth between a few coordinates, for example due to GPS drift.
And then there are some packets which are delayed due to buggy digipeaters
(would be suboptimal to block all igates in an area because there's a
digipeater delaying packets). And some other corner cases.

> To view this discussion on the web visithttps://groups.google.com/d/msgid/aprsfi/e0ba193c-a7ae-459b-979c-460f1246f8d7n%40googlegroups.co
> m.
>
>

- Hessu