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 
I can confirm that flashing the GPS xadow board following the process defined in this other forum post:
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 
-Steinar
I’m pretty sure the problem is a race condition.
The gps.c file consumes 1 byte at a time from the UART polling, and parses it (ultimately calling the gps_data_convert() function which was fixed). However, the i2c callback (i2c_slave_callback) is invoked whenever the rePhone Wire library asks for some data, and there is nothing to protect the data field GPS_RMC_Data from being read by i2c at the same time it is being rewritten by gps_data_convert(). The default gps frequency is 1Hz, so that string is being rewritten every second.
Given that the string in GPS_RMC_Data is both the source and the destination for gps_data_convert() makes it especially problematic. I think if different strings were used, at least if i2c_slave_callback() was reading the string while it was in the middle of being written by gps_data_convert(), it wouldn’t be as incorrect.
I believe the correct fix is to change gps_data_convert() to write out its converted string to a different buffer, the buffer which i2c_slave_callback() reads, rather than re-using the buffer which is initialized from the UART data. That’s an easy fix, achievable by creating 2 GPS_RMC_Data static variables, updating the gps_data_convert() to read from the existing one, and write out to the new one, and let the i2c callback read from the new one.
A better, but more involved fix would be to move all of the NMEA string parsing to the RePhone side of things, and change the gps driver logic on the GPS board to simply have a buffer to hold each of the 6 NMEA string values, which it overwrites as each new one comes in, and use a standard arduino gps parsing library at the RePhone side.
I can confirm that using a different structure to hold onto the ‘converted’ data from the initial structure appears to have eliminated the problem for me - I ran with the modified firmware last night for an 8 hour stretch with no order-of-magnitude latitude or longitude data values.
I will fork and post my changes to github so they can be pulled into the maintainer’s repo for something official.
In the meantime, here is my updated hexfile with the changes
xadow_phone_gps_v2.hex.zip (21.3 KB)
I can seem to to get the program on the ESP8266 i have the following error below
I have a arduino uno i have connected the follow
I have removed the chip from the UNO and connected it up the following
Arduino UNO ESP8266(ESP-12F)
RX -----------> RX [size=50](Logic Level Shifter Converter) [/size]
TX -----------> TX
3.3v -----------> VCC
GND -----------> GND
3.3v -----------> CH_EN
and im getting the following error
warning: espcomm_sync failed
error: espcomm_open failed
error: espcomm_upload_mem failed
I’m not sure what am doing wrong.
I used a Adafruit 8266 Huzzah part. This series of web pages is a great introduction
learn.adafruit.com/adafruit-huz … t/overview
You may want to look at this page in there
learn.adafruit.com/adafruit-huz … odemcu-lua
showing the right way to connect USB to your 8266
My GPS modules return coordinates that are about twenty miles off. After reading this post from the beginning it isn’t clear to me what I need to do to fix this issue.
Would someone kindly point me in the right direction?
I see the .hex file above. Does it fix the GPS module’s inaccuracy? If so, what does one do with that file?
Thanks for taking the time to answer.
Someone needs to make a complete how-to. The problem is that there is flashed code in the xadow gps board and there is no easy way to re-flash it from the existing development environment.
I’ve posted a hex file which fixes both the inaccuracy as well as the race condition. The race condition can be seen by a random misplaced decimal point in the latitude or longitude. The inaccuracy is due to a boundary condition on a loop starting in the wrong string location for parsing.
You need a soldering iron, some small wires (i use wires I take from a cat/5 cable), an Arduino 8266 part, and (optionally) a breadboard (makes the various connections simpler), the Arduino IDE, and a little patience.
You have to solder two wires to the SWCLK and SWIO pins on the bottom of the GPS board, then hook up those 2 pins (and vdd and gnd) to another Arduino part to re-flash.
I took an Adafruit 8266 huzzah board, installed the board into my Arduino IDE, then loaded the arduinio code pointed to by the previous poster’s URL (looks like ardunio code). You map 2 gpio pins from the 8266 onto the the 2 soldered pins from the GPS board and run the little flashing program (for me on my part, gpio#0 and gpio#1). It takes just a minute or 2 for the actual flashing to occur.
That’s the overview. Going back and looking at previous posts and the URLs might make a little more sense now. The true error is not that there is a bug in the code; the issue is that no provision was made to more easily update the code on the gps part. Hopefully a future version of the part will allow you to bridge a few connections on the GPS part and allow the hex file to go across the little xadow connector from the 2502 (rephone) part; either that, or use the GPS part which Linkit has done all the work for already for the 2502 part; or change the driver to be much simpler and only provide a i2c mechanism to the UART on the GPS chip.
I have the same problem and do not understand the process to solve it. I think seeed should provide a How-To or replace parts per RMA.
I’ m facing the same issue, has anyone fixed it and have the step-by-step to get my xadow GPS v2 module updated?
A Step by step guide is available in the following recipe page:http://www.seeed.cc/project_detail.html?id=1731
Is there anybody here who could help me with a private consultation? I tried to follow the step-by-step guide but failed. It seems to me that access is restricted from my area worldpostalcode.com/united-states/georgia/atlanta. Can it be the case? Or what else can cause this issue? Please write to my private messages to discuss if you have a free hour this or next week. Thanks in advance.