Go Down

Topic: Neo GPS Library complexity (Read 187 times) previous topic - next topic

Gerihatrick

I have been using Tiny GPS Lib from the time it became available.
I thought I would like to try some of the claimed benefits of Neo GPS particularly its ability To run a minimum configuration and the improved accuracy.
I am using the single hardware serial port on a Uno at 115200 baud and 10hz sampling of the RMC sentence only. Everything functions using the Tiny GPS library and I can view serial data on the monitor at 115200 baud. I remove the GPS TX when up loading code
I started to look at the Neo documentation and I could not even see how to configure the library to use hardware serial. Configuration looks to be very complex but is the journey worth the effort. Is there an idiots guide as I certainly would benefit from one. Am I missing something .....other than a better brain?

-dev

Quote
I could not even see how to configure the library to use hardware serial...  Am I missing something .....other than a better brain?
Your brain isn't the problem.  :smiley-confuse:   I always take the blame for not documenting something thoroughly enough.  Here's the current documentation:

Quote from: Installation guide
4. Review Libraries/NeoGPS/src/GPSport.h

This file chooses a default serial port for each type of Arduino. You can either declare your own gps_port variable in the .INO file, or you should confirm GPSport.h will choose the correct serial port for your GPS device.
GPSport.h never chooses to use Serial, so you have to change it.  You should delete all the code in GPSport.h and replace it with two lines that declare your serial port choice:

    #define gps_port Serial
    #define USING_GPS_PORT "Serial"

This will make all the examples use Serial for receiving GPS data.  The second define is printed during setup to make sure you know which port is being used.

The Installation guide also says to start with NMEA.ino (step 5).  This comment block is at the top:

Code: (NMEA.ino) [Select]
//-------------------------------------------------------------------------
//  The GPSport.h include file tries to choose a default serial port
//  for the GPS device.  If you know which serial port you want to use,
//  delete this section and declare it here:
//
//    HardwareSerial & gps_port = Serial2; // an alias
//          or
//    AltSoftSerial gps_port; // depends on Arduino - pins 8 & 9 on UNO
//          or
//    NeoSWSerial gps_port( rxpin, txpin ); // to GPS TX, RX
//          or
//    Search and replace all occurrences of "gps_port" with your port's name.
//
//  See Installation instructions for additional information.

#if defined( UBRR1H ) | defined( ID_USART0 )
  // Default is to use Serial1 when available.  You could also
  // use NeoHWSerial, especially if you want to handle GPS characters
  // in an Interrupt Service Routine.
  //#include <NeoHWSerial.h>
#else
  // Only one serial port is available, uncomment one of the following:
  //#include <NeoICSerial.h>
  //#include <AltSoftSerial.h>
  #include <NeoSWSerial.h>
  //#include <SoftwareSerial.h> /* NOT RECOMMENDED */
#endif

#include "GPSport.h"

You could edit NMEA.ino and replace all those lines with the same two defines.

However, you would have to edit each example program and do the same thing.  That why I added the GPSport.h file.  It's the one file you edit to make all the examples work for your port configuration.   All other libraries require you to edit each example.

Coincidentally, I'm in the middle of changing how the GPS serial ports are configured.  NMEAtimezone.ino has an expanded section on port selection:

Code: (NMEAtimezone.ino) [Select]
//--------------------------
//   PICK A SERIAL PORT:
//
// *Best* choice is a HardwareSerial port:
//    You could use Serial on any board, but you will have to
//       disconnect the Arduino RX pin 0 from the GPS TX pin to
//       upload a new sketch over USB.  This is very reliable
//#define gpsPort Serial
//#define GPS_PORT_NAME "Serial"

// Use Serial1 on a Mega, Leo or Due board
#define gpsPort Serial1
#define GPS_PORT_NAME "Serial1"

// Use NeoHWSerial if you want to handle GPS characters
//   in an Interrupt Service Routine.
//   Also uncomment NMEAGPS_INTERRUPT_PROCESSING in NMEAGPS_cfg.h.
//#include <NeoHWSerial.h>
//#define gpsPort NeoSerial
//#define GPS_PORT_NAME "NeoSerial"

//--------------------------
// 2nd best:
//#include <AltSoftSerial.h>
//AltSoftSerial gpsPort; // must be on specific pins (8 & 9 for an UNO)
//#define GPS_PORT_NAME "AltSoftSerial"

// Use NeoICSerial if you want to handle GPS characters
//   in an Interrupt Service Routine.
//   Also uncomment NMEAGPS_INTERRUPT_PROCESSING in NMEAGPS_cfg.h.
//#include <NeoICSerial.h>
//NeoICSerial gpsPort; // must be on specific pins (8 & 9 for an UNO)
//#define GPS_PORT_NAME "NeoICSerial"

//--------------------------
// 3rd best: must be baud rate 9600, 19200 or 38400
//   NeoSWSerial supports handling GPS characters
//   in an Interrupt Service Routine.  If you want to do that,
//   also uncomment NMEAGPS_INTERRUPT_PROCESSING in NMEAGPS_cfg.h.
//#include <NeoSWSerial.h>
//NeoSWSerial gpsPort(3, 2);
//#define GPS_PORT_NAME "NeoSWSerial(3,2)"

//--------------------------
// Worst: SoftwareSerial NOT RECOMMENDED

This matches the choices described in step 2, and will soon become the new version of GPSport.h.  Another minor change: the examples will all use the CamelCase name "gpsPort" instead of the snake_case name "gps_port".

And if you have other questions, please ask!

Cheers,
/dev
Really, I used to be /dev.  :(

Gerihatrick

Thanks for the info Dev
I'll be giving it a go shortly.
I can see by thumbing through the extensive documentation that this library is very capable indeed and I feel that when I get into it more it will be brilliant.
Of course I want to run before I can walk.
Are there any any pitfalls to be wary of in my desire to write efficient code to simply get Lat, Lon, speed, and distance only at 10hz via hardware serial. Any tips greatly appreciated
Regards


-dev

Quote
Are there any any pitfalls to be wary of
The Troubleshooting page lists the most common problems.  In general,

*  Don't use delay
*  Don't use String
*  Don't wait in a while loop for something to happen
*  Don't print too much

Work through the Installation steps (NMEA and NMEAorder) and then try NMEAloc or NMEAsimple.  They're pretty close to what you want.  Then try to send the 10Hz configuration command and see if it works.  Then take a look a NMEA distance to see how the various distance and bearing functions should be used.

Cheers,
/dev
Really, I used to be /dev.  :(

Gerihatrick

Thanks Dev
I'm now up and running. Didn't manage to get on with GPSsport so did a search and replace in each example to use hardware serial. Managed to get RMC data streaming at 10 hz and I now know the distance between Uluru and my workshop! One question regarding distance, is it possible to get distance to report better than just two decimal places. Four or five would be nice to make full use of the high resolution integer Lat and Long, recognising that improved resolution is not necessarily improved accuracy. 
I'm now starting to understand the methodology  and structure of the library and I think I may be on the way to being a convert.
Onwards and upwards
Regards

-dev

Quote
is it possible to get distance to report better than just two decimal places. Four or five would be nice to make full use of the high resolution integer Lat and Long
The distance has 6 significant digits because it is a float type.  If you are thousands of miles away from Uluru, that's 4 of the digits.  There are only 2 more significant digits.

If you calculate smaller distances, you'll get more decimals.  For example, if the distance is less than 1km, you could print 6 decimals.
Really, I used to be /dev.  :(

Go Up