Ublox Neo-6M stalled after a few Hours

[jeferson_lucio]

Hi Guys, so, I have this old GY-GPS6MV2 module which I'm trying to make it work with Arduino Nano. It used to work pretty well some 6, 7 years ago or so, but I let it in storage, the battery leaked and it shows some signs of age (like a bit of rusting).

The thing is, it works pretty well and default factory settings were restored by me (took me a while to find the correct version of u-center that would work with it, also the software only works well on Win 7, but that's alright). The factory default baud rate is 9600, sample rate of 1Hz.

I only changed a few things, like under "NAV5" -> "Navigation Modes" -> "Dynamic Model" to "Airborne < 2g" and "Fix Mode" to "3D-only" (I thing that's OK on a RC Model that doesn't engage in violent maneuvering, really, I just wish the RTL function to work and nothing else).

The only other thing that I changed, was under "RATE", I set the "Measurement Period" to "500ms", doubling the sample rate, from 1Hz to 2Hz, something that a baud rate of 9600 wont have problems dealing with, I do not feel confortable setting up higher speeds once I'm running it over SoftwareSerial.

When I save, of course I save it to BBR, FLASH, I2C-EEPROM and SPI-FLASH, just to be on the safe side. And when changing settings I'm always using a USB-to-TTL converter set to 3.3v logic. I always unplug it, and let it rest for a few minutes, before reconnecting, pulling the configuration and check if it has indeed changed.

The thing is, I wrote code for both, TinyGPS and TinyGPS++. Both work just fine until 1h or 2h of running time.

With TinyGPS, "gps.satellites()" and "gps.hdop()" both will freeze to a certain number and stay there, sometimes hdop() returns a bizarre stuff like negative values, but the most common thing is for both methods/functions to return the same value for hours, and they wont change on TinyGPS, unless, you re-upload the sketch to the board, after the Arduino Nano boots, you gonna have new values for satellites and hdop on your serial monitor, however, they will stay the same for hours and hours, for instance, HDOP: 144, Satellites: 8, even if you cover the module with a tick frying pan. Longitude and Latitude values seem to return pretty much OK, and the funny thing is that "gps.f_altitude()" will freeze in place as well, just like "gps.hdop()" and "gps.satellites()".

With TinyGPS++ things go a little different. The "isValid()" and/or "isUpdated()" methods/functions from the library properties start to fail, one after the other. And then it will just stay like that.

Does anybody has something to share? Anyone with experience with this module?

PS.: The Date and Time comes OK on the Serial Monitor(TinyGPS), the "Age" varies between 32 and 40, but mostly it stays at 34. Just now I had "SATS: 7. HDOP: 144. (Altitude 19.40m)" on the console, I clicked to re-upload the sketch and now I see "SATS: 7. HDOP: 173. (Altitude 0m)".

[srnet]

And if the GPS is re-intialised back to its default setup, and you use one of the TinyGPSplus example programs, unaltered, do you get the same behaviour ?

[jeferson_lucio]

Hi @srnet , after trying, trying and trying, I've found the culprit(or at least a culprit).

float distance = (count == 0) || (lastLat == 0 || lastLon == 0) ? 0 : TinyGPS::distance_between(flat, flon, lastLat, lastLon);

In the case of TinyGPS, once I add this line of code, things start to go bad immediately. The number of satellites, the value of hdop, they will stay the same until I re-upload the sketch to the board, reset the Arduino Nano, or unplug it and re-plug it.

I suspect memory, the Nano must be running out of it. Is there a way to be sure? lastLat and lastLon are two global float variables initialized with 0. They basically keep the last position from the previous loop iteration in order to check against the current position and have an idea of the deviation. If the deviation is lets say, >= 5 meters, I reject the fix and start looping again from scratch. If the deviation stays < 5, I accept that I have a good fix. I loop 50 times until I'm satisfied, of course, there are other checks in place, like (satellites >=4 && hdop <= 160).

[jeferson_lucio]

I'll try the same code on a Pro Micro 5v. It has a bit more memory than the Nano, and also an independent hardware serial available to the developer(Serial1), where I can plug the module in, and test stuff.

[jeferson_lucio]

Hi again @srnet !!

So, I reset the module back to factory settings, saved the configuration, unplugged it and let it to rest. Meanwhile, I took a chinese copy of a SparkFun Pro Micro 5v/16Mhz and started soldering the wiring, voltage divider for TX pin, and a plug to easily attach and detach the module from the Pro Micro when I needed/wanted to.

Next I created a copy of the source code adapted to the Pro Micro, "Serial1.begin(9600);", coz when you reset this particular GPS module, it changes itself back to that baud rate.

So, in the end, I don't know if it was that bit of extra SRAM the Pro Micro comes with compared to the Nano, or if the advantage of having a hardware-based TTL serial interface did the trick, what I see now is the code running and flowing smoothly, as intended, and its output coming out on the Serial Monitor(I only had time today to test it with TinyGPS tho).

Now only time will tell. I'll let it running for a couple of days non-stop, and lets see what happens.