Go Down

Topic: NeoGPS - configurable, ultra-small RAM footprint (Read 1 time) previous topic - next topic

/dev

Both NeoGPS and TinyGPS just need to be fed bytes.  The example programs all use Serial and SoftwareSerial, though.

You should be able to do the same thing with SPI as a source of bytes.  It should be something like

void loop()
{
  spi.begin();
  while (something) {
    in_byte = spi.transfer( 0xFF );
    gps.decode( in_byte );
  }
  spi.end();
}


According to the ublox spec, section 4.4, 0xFF will be returned by the spi.transfer when there are no more available bytes.  Although the decode methods will correctly ignore the 0xFF bytes, you probably want to watch for them so you can do something else.  For TinyGPS, you will have to watch for consecutive 0xFF bytes:

void loop()
{
  uint8_t FF_bytes = 0;
  spi.begin();
  while (FF_bytes < 50) {
    in_byte = spi.transfer( 0xFF );
    gps.decode( in_byte );
    if (in_byte == 0xFF)
      FF_bytes++;
    else
      FF_bytes = 0;
  }
  spi.end();

  // Do something else
}


For NeoGPS, you can watch for a different return code:

void loop()
{
  spi.begin();
  do {
    byte = spi.transfer( 0xFF );
  } while (gps.decode(byte) != NMEAGPS::DECODE_CHR_INVALID);
  spi.end();

  // Do something else
}


This is just for reading bytes.  If you need to write bytes (like a configuration command or a poll), you'll do the same kind of thing... the output bytes are written out by the same transfer method:

  spi.begin();
  while (something) {
    spi.transfer( out_byte );
  }
  spi.end();


What complicates this process is that the Neo-6 can send a byte back at the same time, if it has something.  You have to continue decoding during a write:

  spi.begin();
  while (something) {
    in_byte = spi.transfer( out_byte );
    gps.decode( in_byte );
  }
  spi.end();


That's the basic idea, I think.  You'll have to fill a lot blanks!  :)  Keep us posted.

Cheers,
/dev

rockeronline00

Thank you for your code! Nice job  8)

I just realized that many Ublox neo 6m boards don't implement SPI wires..  They only have VCC, GND, TX, RX .


 :smiley-confuse:

I think I need to find the correct output wires from the main processor and solder some custom wires

/dev

A recent discussion revealed that some GPS devices may report a message like "GNRMC" instead of the common "GPRMC".  This led me down the rabbit hole of NMEA quasi-baz-standard... Oy!

It turns out that the first two characters are called the Talker ID.  In this case, a GPS device was reporting "GPRMC" when only GPS satellites were used to calculate a fix, and "GNRMC" when a mix of GPS and GLONASS satellites were used.  Furthermore, it could report "GLRMC" if only GLONASS satellites were used.

This variation also appears in the GSV sentences: GLGSV reports GLONASS satellite info, and GPGSV reports GPS satellite info.  There are other Talker IDs, as well: GA (Galileo) and GB (BeiDou).

To accommodate these devices, I have updated NeoGPS to parse, save or skip the Talker ID.

While messing with this part of the parser, I also noticed that proprietary messages (those beginning with "$P") are also supposed to have a 3-character Manufacturer ID.  For the ublox devices, these are the "$PUBX" messages.  NeoGPS will now parse, save or skip the Mfr ID as well.

Suprisingly, this change increased speed by about 10%.  It also eliminated the need to store the "GP" Talker ID, or any other talker ID, reducing the program space.  In fact, ublox devices do not even have a proprietary message table.  The first integer field after "$PUBX," identifies the proprietary message type: 0 or 4.

Woot.
/dev

/dev

One more iteration of squeezing better performance out of NeoGPS:

Configuration    Sentence    NeoGPS    TinyGPS    Performance
Improvement
MinimalGGA
RMC
436us
485us
   -70%
66%
DTLGGA
RMC
839us
859us
   -42%
40%
NominalGGA
RMC
913us
936us
1448us
1435us
37%
35%
Full1GGA
RMC
1094us
1075us
   -25%
25%
At less than 1ms to parse a sentence, that's about 0.1% CPU utilization, when the sentences are received once per second.  Even with 10Hz updates, that's only 1% CPU utilization per sentence!

Cheers,
/dev


1  While the Full configuration is "only" 25% faster than TinyGPS, it handles more message types and fields.  This configuration should probably be compared with TinyGPS++; the improvement would be much higher, as well as using 900 bytes less RAM.

Go Up