I only found one referrence to this GPS module and there was no conclusion. The TinyGPS++ library does not work with this module and apparently needs some additional phrasing-
#define _GNRMCterm “GNRMC”
#define _GNGGAterm "GNGGA"
I am sure it needs more then that but I am wondering if anyone has used this GPS with the Electron sucessfully and how you did it? Or perhaps there is a link to the library that will work with Electron that I have been unable to find 
Thanks in advance
I’m using the NEO-M8N GNSS module with an electron as an asset tracker. I have made slight modifications to TinyGPS++ library to make it work with these two phrases you mention.
If you’re just interested in the modified TinyGPS++ library it’s here:
The project I worked on uses an electron to publish the location / speed/ altitude provided by the GNSS module, and then a node.js script on my home server (a raspberry pi) listens to those events and logs the data to InfluxDB for visualization with Grafana.
The project repository is here.
@jaafar, Thank you very much for your reply and the information you have provided. I will take a look at the project you have created and I will test your mods to the library. You have been a big help.
Thanks
@jaafar I have loaded your libraries and am running the firmware now with the NEO-8. It is a vast improvment in accuarcy over the NEO-6 so Thank you again.
Thanks for the help!
Does the TinyGPS++ library use the USA GPS Satellites & Russian GLONASS also?
I have this new GPS sensor that outputs all the same satellite services as the new Asset Tracker v2 but I am just using the TinyGPS++ library to parse the GPS data output from the GPS and I’m not sure if the TinyGPS++ library is using the GLONASS data also or not.
Seems like a shame to not take use of the extra GLONASS sat data if it’s available.
I would like to do a test of the Ublox-Neo8 vs this Titan X1 receiver also to see how they compared but need to get them on a level palying field first.
Have you been able to move this forward? I am looking to use UBLOX NEO-M8U connected via i2c and am wondering about the best choice of library. It seems that most choices assume you connect via serial not i2c and @rickkas7’s AssetTrackerRK supports my GNSS and i2c but has a bunch of accelerometer code I don’t need.
Chip
As long as you never call the AssetTracker::begin() method, it won’t initialize the LIS3DH and as long as you never call any of the accelerometer functions the linker will remove them, so it should have almost no effect on the size of your code or RAM usage.
That makes sense. I liked the fact that you use TinyGPS++ in your library. I will give it a shot using your i2c example sketch.
One other question on your library - and sorry if it is too basic - but why are your example sketches .cpp and not .ino files?
Thanks,
Chip
.ino files are just .cpp files that are run through a pre-processor to:
#include "Particle.h"
Since occasionally the pre-processor does things incorrectly and it’s a pretty minor benefit that mostly promotes being lazy about function declarations, I just make everything .cpp files.
I haven’t done much with the GPS since this post probably.
I adapted TinyGPS++ to run over I2C for that Titan GPS Module but never did verify if the GLONASS and other non-USA owned GPS satellite systems were being used also with that library.
Sounds like @rickkas7 coded it to use GLONASS so his library will be the next thing I try when I pull out the GPS sensor again which may be really soon.
Which GPS sensor are you going with?
@RWB,
I am using this little gem from Sparkfun:
I was able to get it to work quite easily using the AssetLibraryRK. I think because of the new compiler, I am getting some warnings:
But the GPS gets a fix quickly and is quite accurate. Next up is some field testing.
Thanks,
Chip
I wanted to let you know that there is something wrong with the AssetTrackerRK library in the build.particle.io library interface. You can add the library if you use Workbench but if you use the WebIDE, and select your library, the interface gets stuck here:
Also, any chance the warnings above could be connected to the new GCC compiler?
Thanks,
Chip
Could be, although I'd rather think at least the top four messages were there before too.
A non-void function should (better would be must) feature a return statement that actually returns a value of the correct type - even with the older compiler versions.
I see the functions do return the correct value, but it may be that the SINGLE_THREADED_BLOCK is not interpreted correctly by the new compiler.
The last warning may be due to a slightly stricter check. int on these 32 bit controllers automatically means 32 bit integers hence you should use "%ld" for the format string when using int (aka int32_t, aka long int - in this environment).
BTW, for me the library opens fine in Web IDE, but I have seen that behaviour before too.
I’m now using SparkFun library, slightly tweaked for better compatibility with Particle’s platform and augmented with a couple of features. I like that it’s well supported and constantly updated by the community. It’s also simple to integrate and performance is good. I’m using it with a SF ZOE-M8Q module and I’ve also tested it on a NEO-M8N module (but using serial bus).
