Timeline for U-blox GPS module (and TinyGPS library): altitude data getting stuck at strange values
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 28, 2021 at 11:29 | comment | added | Rustony | I've tried the module that appears to be genuine, but still get the same behaviour. Also, even if the modules are counterfeit (and some were purchased several years apart, and from different companies), it seems relatively unlikely that they would fail in exactly the same way, so it still seems like it is a coding problem of some kind to me. | |
| Feb 17, 2021 at 11:27 | history | edited | Rustony | CC BY-SA 4.0 |
added 4 characters in body
|
| Feb 17, 2021 at 8:31 | comment | added | Rustony | @StarCat hmm, you may be right, it does look like the module we are using is counterfeit (based on the label anyway, I will check the GPTXT data when I get a chance). We bought 2 modules at the same time, and the other one appears to be genuine (I'm just checking where we bought them from). I guess it's hard say whether this is the cause, but with the added observation it still looks like there is a coding issue perhaps? The lack of accuracy is fine, even it it's out by 100s of m. However there is a pressure sensor on the tracker, so I will add a "backup" altitude estimation from that. | |
| Feb 16, 2021 at 21:21 | history | edited | Rustony | CC BY-SA 4.0 |
added 2561 characters in body
|
| Feb 16, 2021 at 20:48 | comment | added | StarCat | Is this a real U-blox GPS module? There are a lot of fake ones around.. Altitude measured by GPS is generally not very accurate. Have you thought about measuring altitude with an altimeter (air pressure sensor)? | |
| Feb 16, 2021 at 20:24 | comment | added | Rustony | You're correct, the vertical lines are where it switches between realistic and nonsense data (and vice-versa). The smaller vertical lines (such as on the descent in the 2019 graph at around 39,000s) look like the altitude value is just "sticking" for a while (for example it stays at 29,732m for about 90s, before updating the value to 25,653m). Data packets are generated approximately every 11-12s. I will update the question describing what we're seeing in the packets, as there is something odd happening during these "stuck" values. | |
| Feb 16, 2021 at 20:12 | comment | added | jsotola | i am thinking that the long vertical lines are the transitions between valid data and invalid data (anomalies is not the correct term) ... i was trying to ask for infornation about the one or two data points before the vertical lines, and one or two points after the vertical lines | |
| Feb 16, 2021 at 20:04 | comment | added | Rustony | @jsotola the data is extracted from the logs, which doesn't save the millis() value. What do you mean by "either side of the anomalies"? The anomalies are the long stretches of data close to ground level (<500m), so I'm not sure what to say for values "either side" of them. | |
| Feb 16, 2021 at 19:31 | comment | added | jsotola | referring to the graphs ... what are the sample index numbers, sample values and milli() values on either side of the anomalies | |
| Feb 16, 2021 at 19:15 | review | First posts | |||
| Feb 16, 2021 at 19:17 | |||||
| Feb 16, 2021 at 19:15 | history | asked | Rustony | CC BY-SA 4.0 |