APRS.fi ignores packet sent in standard GPS mode, corrupt type field?

[OK2MOP]

Hello, I am not sure if this is the culprit as I cannot test it right now, but a week ago or so, APRS.fi stopped adding data from this tracker to maps. When debugging the issue, I have found out, that the type field does not conform to type rules found on page 96 in table Compression Type (T) Byte Format of APRS 101 as bit 6 is not 0.

The reason, IMO, is that on line 363 of APRSPacketLib.cpp there is following code, which may be a copy & paste error: encodedData += char(0x30 + 33); should it be encodedData += char(0x30); instead?

[richonguzman]

check APRS101.pdf page 40-41 where it shows examples how the T byte on the compressed position packet works

does this explain why it uses "encodedData += char(0x30 + 33);" to you?

[OK2MOP]

OK, so the data is correct (it is actually explained on boundary page 39-40), but then I do not know why the APRS.fi started to reject the packets.

[richonguzman]

post here the rejected packet please

[OK2MOP]

Example packets: 2024-06-14 08:41:37 CEST: OK2MOP-9>APLRT1,WIDE1-1,qAO,OK0DSK-12:!/5>TQS+7>EcQ Bat=4.00V (-82mA) SNR=-4dB RSSI=-91db [Packet corrupted by iGate]

2024-06-16 11:42:42 CEST: OK2MOP-9>APLRT1,WIDE1-1,qAO,OK2MOP-16:!/5IU:S-nG>I$Q SNR=13dB RSSI=-62dB [Packet corrupted by iGate]

But there are broken packet from packets with similar (different) firmware...

[richonguzman]

this was posted on Facebook a few days ago:

[OK2MOP]

Ah, I do not have Facebook, thanks for the explanation and finding it out.

[richonguzman]

So now you know, and please let the other Ham Ops know if they ask: no packet should be modded when received over an igate and uploaded into APRS-IS. Adding RSSI and SNR is modding it and make this duplicated or even triplicated when much igates do this