NeoGPS Not Returning fixes when incorporated into obs avoid sketch about neogps

[SlashDevin]

Do you get the startup prints, but you don't get any prints from doSomeWork? From reading the sketch, the GPS should be on Serial2 (GPS TX to Arduino RX2 [pin 17]), and you should have configured your GPS to power-on at 115200. Some GPS devices start @ 9600, and you have to send a command to change it, but it's not permanent.

First, verify that the LAST_SENTENCE_IN_INTERVAL is correctly chosen. The coherent option watches for that sentence. Try NMEAorder.ino, and compare what it displays with what you have in NMEAGPS_cfg.h, line 29.

If that's correct, I would suggest trying NMEAdiagnostic, modified to use Serial2. Delete lines 23-35:

#if defined( UBRR1H ) | defined( ID_USART0 )
  // Default is to use Serial1 when available.  You could also
   .
   .
   .
#include "GPSport.h"

... and insert your hard-coded port:

HardwareSerial & gps_port = Serial2; // an alias

You could also try the first sketch, NMEA.ino, which displays a little extra debug information

[mjs513]

The listed sketch works fine. The real problem is with the following function in my rover code:

void gps_ready() {
  telem.println(gps.available( gps_port ));
    while(gps.available( gps_port )){
    coherent = gps.read();
      if(coherent.satellites < 8 || coherent.valid.location == 0 || coherent.hdop > 1100 ||
           coherent.pdop > 2000) {
        telem << "Acquiring GPS Fix => " << coherent.satellites << ",  " ;
        telem <<  ",  " << coherent.hdop <<  ",  " << coherent.pdop;
        telem <<   ",  " << coherent.valid.location << endl;

        if(telem.available() > 0 ) {
          int val = telem.read();  //read telem input commands  
          if(val == 'p') {
            telem.println("Returning to main"); 
            return;
          }
        }
  #ifdef NMEAGPS_PARSE_GST
    // Now is a good time to ask for a GST.  Most GPS devices
    //   do not send GST, and some GPS devices may not even
    //   respond to this poll.  Other may let you request
    //   these messages once per second by sending a 
    //   configuration command in setup().
    gps.poll( &gps_port, NMEAGPS::NMEA_GST );
  #endif
        delay(100);
          } else {
        return;
          }
    }
}

I use the same startup process as in the example sketch except I am using #define gps_port Serial2 which seems to work fine. On startup I get the startup prints which match the standalone version I used to test the lib. When I call gps_ready() the port is not available so nothing is ever returned. The other issue I expect I will have is I also have a telemetry function call which I call every 100ms that reads gps info as well as other info. I haven't tested that since I can not get past this initial issue. I also tried it with and without the delay(100) call.

I used the ublox control center to set the options so 115200 is set and works fine again using the standalone version. Connections to serial2 were verified against the standalone version that I posted in the original issue.

I will run into a problem if I use the isr version since I am using a PinInterrupt library that also uses attachinterrupt and detachinterrupt. Had the same problem with the time calls since I also have a RTC using RTClib.

[mjs513]

I implemented the isr version but I wound up getting data over flow all the time. So now the question is how to get it working. Any help would be appreciated.

[SlashDevin]

The listed sketch works fine.

I listed 3 example sketches. Did all 3 work fine?
Did you verify that LAST_SENTENCE_IN_INTERVAL is correct?

Unfortunately no data is ever returned [from gps_ready]...
When I call gps_ready() the port is not available so nothing is ever returned...
I implemented the isr version but I wound up getting data over flow all the time.

These are all symptoms of Trying To Do Too Much at the wrong time.

In general, you have to continuously check things and not spend too much time on any particular task. You can never wait for something to complete, and you can never use delay. While you are doing those things, the GPS characters continue to come in, and the Serial2 input buffer will overflow (it can only hold 64 characters). If an overflow happens, some characters have been dropped, and the NMEA checksum will not verify, so no fix data will be parsed: gps.available will always return 0.

Also, it is very bad that you are getting data overflow with the ISR version. That means you are spending more than one second doing other tasks. That is a very long time for the Arduino to be doing other things!

The NeoGPS example programs are structured to check a few things quickly and then return to loop. Occasionally, a new fix is available and the example does something quick with it. You should be doing the same thing:

void loop()
{
  GPSloop();
  TelemetryLoop();
  RTCLoop();
}

Each of those xxxLoop functions can only check to see if something is ready, they cannot wait or delay or call a library function that takes too long (e.g., printing 100 characters or writing to an SD log file). I recently discussed this here and in reply #10.

If you still have trouble after doing some reorganization, or if you're not sure what needs to change, I think we should move this discussion to the Arduino forum. This is not a bug in the NeoGPS library, you are really asking for help in using it in your sketch. I'm happy to help, but that's really a forum activity. Other users on the Arduino forum also have expertise on the Dagu Rover platform. They may notice a problem that I would miss.

In your forum posts, be sure to either put your main sketch in between [code] ... [/code] tags (if it's not too big), or attach the file. Most people will not download files from another site. Providing a link to any libraries you are using will also help (github links are ok). I would suggest starting a new post in the Networks, Protocols and Devices area, with the title of this issue. Thanks.

[mjs513]

Thanks @SlashDevin Figured as much after trying the ISR sketch.. Just to give you an idea the rover has a lot in it. Thing the real problem is that I can not feed the beast fast enough. And you are right probably should move to the Arduino forum.