GPSv2 inaccuracy

The GPS library with the rephone only returns decimal values from the gps - I’m not sure what you mean by raw values, unless you mean the NMEA strings which are captured and converted by the library itself. I will instrument the underlying library to print out those strings directly for comparison

Yeah, I meant that :slight_smile:
I think it’s a float conversion problem, since the CPU has no hardware-FPU. Or just the library has a bug.

It looks like the gps NMEA string parsing is done here

github.com/WayenWeng/Xadow_GPS_v2.git

The parsing/math in this file is incorrect:

github.com/WayenWeng/Xadow_GPS_ … rces/gps.c

When I run my longitude through the algorithm used in that file, it produces the incorrect decimal representation, as the indexes being traversed for the string are using the wrong range (longitude has three digits of degrees, not two, so grabbing the minutes part should start at index 3, not 2).

I cannot find where/how the code from that library is linked into my .vxp file; I need some guidance from that library maintainer on how to make change to it and deploy it to my part. Is this something compiled into the firmware image?

It seems it’s the gps module firmware. As soon as I get to a PC I’ll check everything.

this test code shows the good and bad value being generated; you can confirm by running any constant you use with the website above to convert from that format to the decimal format.

int
main()
{
char *longitude = “07218.57692”;

int Data = 0;

// BAD!

for (int i=2; i< 10; i++)
{
if (i == 5) continue;
Data = Data * 10 + longitude[i] - ‘0’;
}

Data = Data * 5 / 3;

printf("%d\n", Data);

Data = 0;

// GOOD!

for (int i=3; i<10; i++)
{
if (i == 5) continue;
Data = Data * 10 + longitude[i] - ‘0’;
}

Data = Data * 5 / 3;

printf("%d\n", Data);
}

Arguably, this parsing code shouldn’t live in the firmware, but in the user-space code. I think it would make more sense to have an interface from the firmware which returns the entire NMEA string, and allows user-modifiable code to do the parsing. Plus, there are many existing gps parsing libraries which already exist so they could be leveraged. If this does cause a firmware bump, I’d like to see a follow-on bump which exposes the interface to the gps chip a little more. This could also make it easier to send the gps commands for the different power savings modes more easily.

Thanks for pointing the issue out.

Wondering if there is any possible way to update the GPSv2 firmware without Freescale tool?

Hi,
I found the GPSv2 base on STM32F030, and the develop IDE is Freescale Kinetis Design Studio.
Maye we can build the project with KDS and flash the hex file with a j-link.

So the next task is to find, if it has a bootloader installed :smiley:

Is there documentation somewhere which shows how to take compiled code from KDS and upload it? Or is this something we need to the rephone development group involved in? Do they monitor these forums?

You just flash the new firmware via KDS. The user manual of the Kinetis SDK is really clear acout flashing and debugging. You can use Segger and OpenOCD too.

I see the new object and hex file posted to the github (where I found the source code). I have a bus pirate and OpenOCD, but I will need a little more direction in terms of how to do so. Additionally, everybody who has received one of these parts so far has the GPS library code in it which is inaccurate and will need to follow some directions for how to update this, so it seems like creating a step-by-step guide is in order.

My gps module is on its way, so I can’t make a tutorial this weekend. After that I can make something, but with segger (I got one with an infineon devboard)

I have ordered the GPS V2 about a week ago im not happy hearing this news, so ill take it that the one that i will receive will be inaccuracy aswell?

Has any contacted SeeedStudio about this issue?

Unfortunately all devices will have the faulty gps parsing code until they are reflashed. Presumably upgraded firmware will be made available at some point. I would like to see the interface changed to provide read/write access to the underlying GPS chipset (the NMEA strings directly) to allow more control. That seems to be a more common method of providing access.

@rhbroberg, and also it’d be nice if it will be some firmware-upgrade interface there, which would not require windows :’(

Is there a work around and till the firmware upgrade?

Anyone? This is delaying my project :frowning:

viewtopic.php?f=71&t=6722

I can confirm that flashing the GPS xadow board following the process defined in this other forum post:

viewtopic.php?f=71&t=6722

worked properly for me; my code changes I submitted above have addressed the longitude string parsing error.

The process is straightforward, assuming you have an 8266 board sitting around. Soldering 2 wires to the bottom pads of the GPS xadow part is required.

However, I have a new problem with the GPS code. It was true even before the flash of the fixed code. Every once in a while, the string returned for latitude or longitude is off by 2 orders of magnitude (e.g., 7200.ab rather than 72.yz). It’s not just a shift of the digits (as if the decimal place was in the wrong location).

More as I dig deeper

Same bug seen here also, one of ten telegram are wrong
I debug-print the I2C data coming from the Xadow GPS module, so the error must be in the parsing software in the module

3936332E343035353336
GPS latitude is N:63.405537
5A3031302E333137323733
GPS longitude is E:10.317273

39363332342E33323931
GPS latitude is N:6324.329102
5A30313031392E30333531
GPS longitude is E:1019.035095

So, digging here also :wink:
-Steinar