Cubecell GPS devices provide bad data to TTN Mapper

[jpmeijers]

I'm not sure where exactly to report this, as it can more than likely be a hardware issue. But making a note here for reference.

While cleaning up TTN Mapper data I stumbled on a pattern where Cubecell devices regularly report locations in the Gulf of Guinea.

Is there maybe a way to make more sure the location accuracy is good before we send the packet? Does anyone know why the Cubecell specifically has this issue? Where can I report this to be properly fixed?

Three examples of Cubecell devices with this problem:

[Bwooce]

Eeek, that's no good. I will add some filtering to this code just in case, but I think a change to the base libaries not to return known garbage would be useful too. Do you know what the reported precision data for those reports is?

[Bwooce]

(I'll get both going, although it may take some effort to get Heltec to accept a library tweak)

Longitude of 0 with other values ranging from 44-100 degrees of Latitude, I will look for a bug that could do that.

[jpmeijers]

Unfortunately I deleted the data from the screenshots above. All I have is a csv export, but I'm not sure this one was for a cubecell device. If I stumble upon another cubecell I'll post the data here.

The csv I still have has an altitude that jumps very high when the coordinates are wrong and a satellite count that is way too high. Also i do not like that this specific device has a (hardcoded?) hdop that is always 1. I'm expecting an hdop to have at least one decimal.

latitude    longitude   altitude    accuracy meters hdop    satellites  location provider
4.394998    56.601383   3053        -       1   93      hdop
-31.809075  -71.294761  22990       -       1   201     hdop

[jpmeijers]

Ok I found a cubecell with wrong data points. raydeo-cubecellgps-ttnmapper-csv.txt

In this one it looks like the altitude jumps a couple of thousand meters. Luckily the hdop looks valid, and we can see the hdop is >20. It's strange that TTN Mapper accepted this data, as I normally require an hdop <5 (I actually prefer <3, but people complained that's too strict).

Another entry in this file has coordinates close to the 0,0 point, valid altitude, and hdop of 7.2.

[jpmeijers]

I'm wondering if the T-Beam and CubeCell might be using similar libraries or encoding/decoding techniques. Below a CSV for a T-Beam device with similar behaviour. Satellite count is normally >50 when the coordinates are invalid, making me think it might have to do with some decoding of the frame. Perhaps the devices are sending not only location data, and we are trying to decode these other messages as location. Maybe worth adding a check for the port in the decoder? wzab-ttgo-tbeam-2-csv.txt

[jpmeijers]

At this point I am pretty sure the issue is The Things Stack V3 that forwards port 0 data to the payload decoder, which decodes it incorrectly, and then that gets forwarded to TTN Mapper.

https://github.com/TheThingsNetwork/lorawan-stack/issues/4668

A workaround has been added to TTN Mapper to ignore all incoming data on port 0. This should fix the problem. But checking the port before decoding in the payload decoder is a more proper fix, but more difficult to roll out to existing users.