NeoGPS - configurable, ultra-small RAM footprint

Yep. I edited that file to use Serial1 and changed GPS baud rate to 38400. Like I said if I run the tabular sketch or use the data directly without the last sentence test no problem with the data or validity - less the err info since I messed that one up :frowning:

Quick update on lat/lon GST message. In ublox center I can not get it to permanently ungray the GST message. It looks like it has to be polled.

Update2: Got it all working, reduced print quantities on the tabular sketch and got the errors printing as well. Thank you. The only that doesn't work is the last sentence test.

Hi -dev. Me again. Been playing around rtklib (the rtkexplorer version) and now at a point where I want to send the solution back to the Arduino. To get that to work I can send the equivalent nema messages for decoding which is not a problem. What I want to do is send the messages back using two xbee pro's. The basic format is:

Start delimiter: 7E
Length: 00 13 (19) - for the test message I sent
Frame type: 81 (RX (Receive) Packet 16-bit Address)
16-bit source address: 00 01
RSSI: 24
Options: 00
RF data: Message
Checksum: A4 - message checksum.

I can get the message decode fairly easily but not sure where to make the modifications in the library to do the decoding. Any tips would be helpful

Thanks
Mike

not sure where to make the modifications in the library

Modify the library? What library?

I can send the equivalent nema NMEA messages for decoding which is not a problem. What I want to do is send the messages back using two xbee pro's.

Ok... you know I can answer questions about NeoGPS, not XBee, right?

It looks to me like the ublox GPS devices can receive RTCM messages (I do not know the format of these messages). The ublox device will use the corrections in those RTCM messages to slightly alter the data sent back to the Arduino in the standard NMEA messages (e.g., GGA). NeoGPS does not need to be modified to parse these "corrected" fields in the standard sentences.

You're going to have to be much more specific, because I can't see where you need NeoGPS help.

Modify the library? What library?

The NEOGPS Library decode/read message portion of the library unless it is currently setup to ignore characters before the $ of a NEMA message.

Ok... you know I can answer questions about NeoGPS, not XBee, right?[

Yep. This is a Neogps question.

NeoGPS does not need to be modified to parse these "corrected" fields in the standard sentences.

What I am doing is using rtklib to generate a kinematic solution using two Neo-M8N GPS's using the info from the base station for the rovers position. The output of RTKLIB can be NEMA0183 sentences with the new information (cm level accuracy). No data is sent back to the rover gps. DGPS (if I can get a lock) does those corrections, better but not that good.

So what I want to do is send the NEMA message from RTKLIB through the XBEE back to the rover for accurate positioning which is then decoded by NEOGPS for further action by my rover (waypoint navigation, etc).

Using the XBee, it sends out packet that has seven characters before the NEMA message and 1 trailing character. What I need to do is to strip out the first 7 characters and the last to get the actual NEMA message for NEOGPS to process.

Hope this explanation is sufficient, I can go into more details if you want.

Merlin513:
it is currently setup to ignore characters before the $

Yes, NeoGPS is the most reliable library in this respect. It will ignore characters until the $ starts the parsing process.

There are additional validation checks you could enable, if the XBee messages do not have error correction and detection. NeoGPS can detect invalid characters (like a '-' in the year) and even invalid values (latitude > 90). You should not enable this if the XBee packets are guaranteed to be error-free. The XBee may have its own checksums, acknowledgements and resends.

what I want to do is send the NEMA NMEA message ... to the rover for accurate positioning which is then decoded by NEOGPS

What message?

I'm confused, because there is a way to send correction data to the ublox device for it to use for improving its "navigation solution" (aka fix). That way is by sending RTCM messages from the base to the rover (via XBee) and then from the rover Arduino to the rover GPS.

I do not understand why you are sending an NMEA sentence from the base to the rover, nor how an NMEA sentence could improve the rover's location.

There is a way to use the base station as a stationary reference point ("surveyed in" over a period of hours). After it is locked in, you could send the detected difference between the base station's current GPS fix and the (calculated) reference point to the rover. That delta could be applied at the rover, assuming that it is "near" the base station. This is not as good as sending the RTCM data for the GPS device to use, if I understand correctly.

I should point out that sending raw NMEA data over an XBee channel is 10x to 80x slower than parsing the information at the base and sending a compact binary message with the parsed field values.

For example, you don't need to send the NMEA sentence type, all the commas and the checksum. The latitude field could be sent as 4 binary characters instead of 13 text characters. You could send a binary message with just a few values as a struct. Then the receiver reads the same, complete struct, without having to parse anything. The struct members could be used to correct the fix from the rover's GPS.

Need more input.

NeoGPS is the most reliable library in this respect. It will ignore characters until the $ starts the parsing process.

That is one of the reasons why I like NeoGPS so much. Its the best library around for doing work with GPS's.

What message?

GPRMC and GPGGA messages

I'm confused, because there is a way to send correction data to the ublox device for it to use for improving its "navigation solution" (aka fix). That way is by sending RTCM messages from the base to the rover (via XBee) and then from the rover Arduino to the rover GPS.

I haven't figured out away to do that. Still learning rtk and how to use rtklib.

I do not understand why you are sending an NMEA sentence from the base to the rover, nor how an NMEA sentence could improve the rover's location

My actual set up is a base station with a M8N and another M8N mounted on the rover. The M8N on the rover is sending its info back to the base station for processing to get an accurate fix using rtklib. rtklib (rtknavi) generates the solution (Fix) giving me the precise position of the rover. I am then sending this back to an Arduino (at least compatible) for waypoint navigation. I am doing zero processing at the rover for getting the rtk fix. In addition using the M8N is using undocumented commands if you have FW2.01.

The M8N on the rover is sending its info back to the base station

What info?

I'm not familiar with RTK corrections, but according to Wikipedia,

In practice, RTK systems use a single base station receiver and a number of mobile units. The base station re-broadcasts the phase of the carrier that it observes, and the mobile units compare their own phase measurements with the one received from the base station.

So I do not understand how the base can calculate the position of the rover, unless the rover is sending RTCM info to the base (my first question). It appears that the rovers' GPS devices should use the base's data, not the other way around.

But why send a 72-byte GGA sentence to the rover? As I said, there are much more efficient ways to send a loc/alt to the rover.

"The M8N on the rover is sending its info back to the base station for processing to get an accurate fix using rtklib."

Well, within a couple of meters anyway.

Thanks @CrossRoads .

@CrossRoads is correct.

With a M8N you have you don't have that option. You have to do the processing at a base station to get the fix and yeah in my tests it looks like a foot or two so a meter would be about right. The M8P which is a real ppk and costs about $240 each (would need 2) can accept a RTCM3 stream so you can set the M8P up for a correction stream using RTCM3.

The M8N on the rover is sending its info back to the base station

Now I have two people to ask:

WHAT INFO?

This presentationmay answer your questions on what info. Basically gps raw data - pseudo range, etc.

A good source for getting started with rtklib is rtkexplorer

Hi -dev and CrossRoads. Gave it a try with sending back position (nmea) messages from the base station (PC running rtklib) worked like a charm. To keep it even simpler I changed the xbee mode to transparent (AP=0) to avoid the issue with the xbee header info that I mentioned earlier.

Maybe I should post a schematic of the set up in case some else goes this route. Let me know.

Thanks
Mike

Yes please, share the knowledge.

Merlin513:
Maybe I should post a schematic of the set up in case some else goes this route.

Please start a new thread, as this is deviating quite a bit from the NeoGPS library topic.

Release v4.2.8 adds quite a few new features:

* New derived class and example sketch for Garmin proprietary $PGRMF message

* New fix members for Velocity North/East/Down. Parsed from ublox $PUBX,00 (NMEA text message) and NAV_PVT or NAV_VELNED (UBX binary messages)

* New fix members for Speed, Heading and Time error estimates

* Data Model and Choosing Your Configuration pages updated to match.

* New reset, trace and help commands in ubloxRate example sketch.

Cheers,
/dev

I found neoGPS after digging around, it's quite the impressive project but at this point it won't build for me, throwing errors about being unable to find a serial port.

Lolu1:
I found neoGPS after digging around, it's quite the impressive project but at this point it won't build for me, throwing errors about being unable to find a serial port.

The compiler and the linker have no use for a serial port. avrdude does.

Your error has nothing to do with NeoGPS.

If you want help, post your code and your EXACT error messages.

Hello dev, thanks for good neogps lib.
Why is it that the lat and lon drifts always. Is it caused by my neo6m. E.g of what I mean.
Lat:5.6412454
Lat:5.6413455
Lat:5.6413555

As you can see this values are not constant, and gives me slightly position shift when I test it on google map.

I'm using latest June commit and I ran tabular e.g with no modifications, just to see my lat and lon. I have already set last sentence to gll. Waiting for your reply. Thanks

Hello dev, thanks for good neogps lib.
Why is it that the lat and lon drifts always. Is it caused by my neo6m. E.g of what I mean.
Lat:5.6412454
Lat:5.6413455
Lat:5.6413555

As you can see this values are not constant, and gives me slightly position shift when I test it on google map.

I'm using latest June commit and I ran tabular e.g with no modifications, just to see my lat and lon. I have already set last sentence to gll. Waiting for your reply. Thanks

SAMUELCHIJI:
Hello dev, thanks for good neogps lib.
Why is it that the lat and lon drifts always. Is it caused by my neo6m. E.g of what I mean.
Lat:5.6412454
Lat:5.6413455
Lat:5.6413555

As you can see this values are not constant, and gives me slightly position shift when I test it on google map.

I'm using latest June commit and I ran tabular e.g with no modifications, just to see my lat and lon. I have already set last sentence to gll. Waiting for your reply. Thanks

Presuambly because the position the GPS reports is moving, which is absolutly normal behaviour for a GPS.

A variation in location of 5 - 10m over a few seconds is usual even when a GPS is outside with a good view of the sky.

When GPS reception is not so good, then the variation in location can be much greater.