GPS U-Blox Neo M8N parser

[dev_1]

My setup is a 4d systems screen and a spi connection to the arduino.

Ok, Arduino uses SPI to talk to the 4D Systems display shield...

Arduino hardware serial is in use by a bluetooth adapter and all works well.

Ok...

Any Serial read on the arduino messes things up.

Whut? You just said all works well.

The 4d systems screen receives the GPS data on a hardware serial port and does that job very well without any impact on the screen. I then send and receive an SPI packet where the GPS data is transferred to the arduino as byte arrays.

...and this makes no sense to me. You send and receive an SPI packet? The screen receives the GPS data without any impact on the screen?

If I could pass the whole byte array to the parser as ublox binary...

I do not understand the description of your system, so I'll give you an answer to a question you probably did not ask:

If you have the entire message in a byte array, including the SYNC bytes, you should verify the checksum. It's just the Fletcher checksum over everything except the first two bytes (SYNC 1 and 2) and the last two bytes (CS A and B). If that passes, you can simply "map" the buffer onto a struct you define that matches the UBX message:

   ubxMgaGPSephMessageStruct *mgaGPSeph = &buffer[2];
   if (mgaGPSeph->uraIndex == 7) ...

If you don't have the SYNC bytes, map it starting at 0:

   ubxMgaGPSephMessageStruct *mgaGPSeph = &buffer[0]; // no SYNC bytes at the beginning
   if (mgaGPSeph->uraIndex == 7) ...

If the message is one of the messages supported by NeoGPS (NAV POSLLH, NAV VELNED, NAV STATUS, NAV TIMEGPS, NAV TIMEUTC or NAV SVINFO), you can use ubxGPS.h to get the message structure definitions:

#include "ubxGPS.h"
    .
    :

    ublox::nav_posllh_t *posllh = &buffer[2]; // map the bytes onto a struct

    // just access the posllh structure members
    display.print( posllh->lat ); // integer latitude * 10000000
    display.print( posllh->lon ); // integer longitude * 10000000

There is no parsing required if you already have all the bytes. Just map it onto C data types in a struct. ubxGPS.h is a C++ way to declare the struct so that it matches the ublox message spec.

Did that help?

Cheers,
/dev

[clemeilio]

Hi /Dev,

Yes that helped a lot. I will give it a try later and let you know.

Sorry I didn't explain my system all that well.

The arduino (atmega1284P) is used for I2c sensor data collection because of it's floating point ability. The 4d screen can't handle that easily.

The 4d screen is an SPI master and will send SPI data and also retreive the sensor data in one function. If I have read GPS via the 4d serial port, it will send that at the same time. This is giving me about 18 frames per second on the screen.

The hardware Serial on the arduino is used for the bluetooth adapter and after receiving a 1 byte request for data, the arduino sends all available data to my phone via bluetooth. All very smoothly.

The second serial port on the 1248P is also int0 and int1 and I have a rotary encoder using int0/int1 so Software serial was the only option to connect the GPS to and that pauses data flow when a message is received. Reading the GPS on the 4d screen had no impact on screen framerate at all.

I am needing location and speed only from the GPS.

Many thanks

Paul

[clemeilio]

Hi /dev,

Managed to solve it. Using the 4d systems screen to take in data from the GPS was a bad idea, so abandoned that.

I connected the NEO6 to U center and switched off everything apart from speed and heading message and set my baud rate to 115200, at 4hz rate. At the moment I only really want the groundspeed.

I moved 1 encoder pin from int0 to int2 (the 1284p has 3 interrupt pins) and left the other encoder pin on int1 which is Serial1 TX.

I connected the GPS TX to Serial1 RX (int0) and wrote a routine to get speed from Serial1 GPS message.

Works a treat and I have a fast update rate. the converted to mph speed is then passed to 4d screen during it's spi data transfer.

I might do an interpolation to smooth out the 4hz rate so the needle on the screen moves smoothly between speed updates.

Very impressed with the NEO6 being able to get a fix indoors.

Thanks for your help.

Paul

[greenonline]

/dev:
For anyone else landing here, you could also modify TinyGPS.cpp to accept these messages by changing these lines:

#define _GPRMC_TERM   "GNRMC"

#define _GPGGA_TERM  "GNGGA"

Other libraries have similar literals that could also be modified.

The Bad News: they will then *ignore* the normal GPRMC and GPGGA sentences. If the receiver is not tracking any GLONASS satellites, it would emit GPRMC instead. Adding a check for "GNRMC" **or** "GPRMC" is not very difficult.

In order to accept BOTH GPS and GLONASS mesages, I think that the two fixes to TinyGPS.cpp are as follows:

#include "TinyGPS.h"

#define _GPRMC_TERM   "GPRMC"
#define _GPGGA_TERM   "GPGGA"

#define _GNRMC_TERM   "GNRMC" // *** added
#define _GNGGA_TERM   "GNGGA" // *** added

TinyGPS::TinyGPS()

and

  // the first term determines the sentence type
  if (_term_number == 0)
  {
    if (!gpsstrcmp(_term, _GPRMC_TERM) || !gpsstrcmp(_term, _GNRMC_TERM))      //modified
      _sentence_type = _GPS_SENTENCE_GPRMC; // *** modified
    else if (!gpsstrcmp(_term, _GPGGA_TERM) || !gpsstrcmp(_term, _GNGGA_TERM)) //modified
      _sentence_type = _GPS_SENTENCE_GPGGA; // *** modified
    else
      _sentence_type = _GPS_SENTENCE_OTHER;
    return false;
  }

[beryindo]

greenonline:
In order to accept BOTH GPS and GLONASS mesages, I think that the two fixes to TinyGPS.cpp are as follows:

#include "TinyGPS.h"

#define _GPRMC_TERM  "GPRMC"
#define _GPGGA_TERM  "GPGGA"

#define _GNRMC_TERM  "GNRMC" // *** added
#define _GNGGA_TERM  "GNGGA" // *** added

TinyGPS::TinyGPS()

and

// the first term determines the sentence type
  if (_term_number == 0)
  {
    if (!gpsstrcmp(_term, _GPRMC_TERM) || !gpsstrcmp(_term, _GNRMC_TERM))      //modified
      _sentence_type = _GPS_SENTENCE_GPRMC; // *** modified
    else if (!gpsstrcmp(_term, _GPGGA_TERM) || !gpsstrcmp(_term, _GNGGA_TERM)) //modified
      _sentence_type = _GPS_SENTENCE_GPGGA; // *** modified
    else
      _sentence_type = _GPS_SENTENCE_OTHER;
    return false;
  }

I try not work bro

[system]

(deleted)

[srnet]

toro:
i got this one in youtube
https://youtu.be/XN9PbmnRtW8

Congratulations.

[indologic]

I make this guys. maybe it will help you

- YouTube

[TegwynTwmffat]

Thank you SlashDev for the NeoGPS software - it works really nicely on Ublox M8M!

I've managed to get headings and distances to guide my machine but would like to see if I can sueeze out more info from the Ublox, for example number of satelites and whether there is a RTK fix between Base and Rover.

I'm probably just being stupid, but PUBX.ino won't compile:

Any suggestions? @-dev @/dev @TegwynTwmffat

[TegwynTwmffat]

@-dev @/dev @TegwynTwmffat

[dev_1]

would like to see if I can squeeze out more info from the Ublox, for example number of satellites

Yes, the number of satellites can be obtained with the standard NMEA messages (proprietary PUBX messages not required). If you look at this table, you can see all the fields that are available from standard NMEA messages.

and whether there is a RTK fix between Base and Rover.

NeoGPS does not parse RTCM messages that (might?) contain this information. There is a status field in the standard NMEA message GGA that indicates the device has a differential fix (see the "Fix Quality" field #6, in section 29.2.4 of the ublox NEO-M8 Protocol Specification).

There are 2 new values for this field in the NEO-M8 device: RTK_FIXED and RTK_FLOAT. These would not be recognized by NeoGPS, but I would consider adding them if that is what you are looking for.

Any suggestions?

Yes, attach the INO file to your post, if you modified it. And instead of embedding an image of the error messages, press the "Copy Error messages" button in the IDE and paste the text into your post, in between
** **[code]...[/code]** **
tags (like it was code), so...

  it looks 
    like this.

Otherwise, I think the error message is telling you exactly what to do.

Cheers,
/dev

[TegwynTwmffat]

There are 2 new values for this field in the NEO-M8 device: RTK_FIXED and RTK_FLOAT. These would not be recognized by NeoGPS, but I would consider adding them if that is what you are looking for.

It would be very much appreciated if these fields could be added. Thanks in advance!

[dev_1]

It would be very much appreciated if these fields could be added.

@TegwynTwmffat, just added these values. It is not a new release, so you will have to get the latest version directly from github. See Installation instructions for this manual process.

[TegwynTwmffat]

@TegwynTwmffat, just added these values. It is not a new release, so you will have to get the latest version directly from github. See Installation instructions for this manual process.

Thank you @-dev ..... I'll get it going tomorrow!