So after a lot of tinkering I've been able to get the unit working somewhare reliably (pre-installed firmware had a whole lot of issues, but the v3 firmware behaves much better).
I wrote a simple GPS only sketch using the ATGPS command to get the GPS information, but it appears that the GPS position given to me is off by approximately 20km...
Is this a failing of the MTK-3329 chip, the code on the STM32 that is getting/sending the data, or something else?
Is it something I can fix or am I going to have to RMA this device/seek a refund?
GPS ~19km Off
Re: GPS ~19km Off
Are you using V2 or V3 hardware? You can obtain raw NMEA data output by MTK3329 by sending ATGRR command and parse it with TinyGPS. This is proven to be more accurate. It's also better to log raw NMEA data than micro-controller parsed data.
Re: GPS ~19km Off
Hi, i've Vehicle Data Logger v3 with the latest firmware from github and there is something wrong with parsed gps data.
I've logged both parsed and nmea gps data, and while the nmea position is correct, the parsed one isn't.
For example:
NMEA: 01002.8984,E (10.048306)
PARSED: 104837 (should be 10048307)
I've logged both parsed and nmea gps data, and while the nmea position is correct, the parsed one isn't.
For example:
NMEA: 01002.8984,E (10.048306)
PARSED: 104837 (should be 10048307)
Re: GPS ~19km Off
That might be a bug in the parsing code (in firmware). We will look into that. Are you having 5Hz or 10Hz GPS module?
Re: GPS ~19km Off
With 6-axis or 9-axis?
Re: GPS ~19km Off
Before we work out the solution, a workaround is parsing NMEA with TinyGPS library in ATMega328p.
Re: GPS ~19km Off
Finally back and interested in the project again (long story, old vehicle had a wiring issue that made the obd port completely unusable, but I've got a new(er) car now!)
I ran the ATGRR command and parse the output with TinyGPS I do ineed get the correect values. This is when the GPS is configured to use 10HZ.
According to the official NMEA docs $GPGGA/$GPRMC transmit lat/long as complex values not just a float/long representing the degrees. For example one of the values returned for me from the NMEA data is 4414.0164. The ATGPS command simply moves the decimal place and says that my Lat/long is 44.140164, which combined with the other value (which I'm leaving out to somewhat protect my location) accounts for the ~20km discrepancy.
TinyGPS takes this values and passes it into it's internal parse_degrees function
which returns 4423360, which translates to 44.23360, which is the correct value.
I think that should be enough to fix the issue with the ATGPS command, but I'm wondering if it's possible for us to flash the firmware of the MTK3329 chip ourselves (providing you release the firmware binary of course). If not I guess I can work around the issue now that I understand it, but it would be better if I didn't have to devote the limited arduino program space to this workaround.
I ran the ATGRR command and parse the output with TinyGPS I do ineed get the correect values. This is when the GPS is configured to use 10HZ.
According to the official NMEA docs $GPGGA/$GPRMC transmit lat/long as complex values not just a float/long representing the degrees. For example one of the values returned for me from the NMEA data is 4414.0164. The ATGPS command simply moves the decimal place and says that my Lat/long is 44.140164, which combined with the other value (which I'm leaving out to somewhat protect my location) accounts for the ~20km discrepancy.
TinyGPS takes this values and passes it into it's internal parse_degrees function
Code: Select all
unsigned long TinyGPS::parse_degrees()
{
char *p;
unsigned long left = gpsatol(_term);
unsigned long tenk_minutes = (left % 100UL) * 10000UL;
for (p=_term; gpsisdigit(*p); ++p);
if (*p == '.')
{
unsigned long mult = 1000;
while (gpsisdigit(*++p))
{
tenk_minutes += mult * (*p - '0');
mult /= 10;
}
}
return (left / 100) * 100000 + tenk_minutes / 6;
}
which returns 4423360, which translates to 44.23360, which is the correct value.
I think that should be enough to fix the issue with the ATGPS command, but I'm wondering if it's possible for us to flash the firmware of the MTK3329 chip ourselves (providing you release the firmware binary of course). If not I guess I can work around the issue now that I understand it, but it would be better if I didn't have to devote the limited arduino program space to this workaround.