ublox GPS

neiltechspec

Senior Member
Has anybody managed to alter the NMEA message config on one of these GPS modules.

I only need GPRMC, but with no skipped fields - by default speed & course are skipped if not moving.

I need the skipped fields to read 000.0 & 000.0


Neil
 

hippy

Technical Support
Staff member
I do not think it is possible to alter the format or content of the message strings. There might be some other messages which have the speed and course fields present and zeroed when not moving, perhaps VTG or one of the other non-NMEA format messages.

The usual, and probably easiest, thing to do would be to change an empty field into a zero value when parsing or examining a received message.
 

srnet

Senior Member
I dont think you can change the format in the way you suggest, and if you could the sentances would not then be in standard NMEA format.

HABAXE reads both GPGGA and GPRMC from a Ublox 6, then reconstitutes the various fields into this format for transmission as RTTY;

$$HABAXE1,sequence,time,lat,long,alt,speed,track,GPSruntime,Fchanges,batterymV,temperature,GPSlock,
flags*CHECKSUM,CR,LF

To ensure the HABITAT system decodes it correctly, for the circumstances when speed and track are null, I put a single zero in those fields ",0,". And to cut down on payload length, some fields are stripped of the characters after the DP.

The payload part;

sequence,time,lat,long,alt,speed,track,GPSruntime,Fchanges,batterymV,temperature,GPSlock,flags

Is sent as RFM22 data telemetry, and a remote reciever then reconstitutes the data into GPGGA and GPRMC sentances which allows the receiver to act as a GPS and feed live tracking information into mapping applications.
 

neiltechspec

Senior Member
Not sure that the RMC fields should be skipped.

My old Haicom 203's don't skip them & neither does my etrex legend.

The documentation from ublox does indicate the flags can be changed, but it's not very clear on how you do it.

All the necessary info for tracking (I need) is in RMC. If it wasn't for the fact the old Haicom's pull 120mA, I would stick with them.

Neil.
 

hippy

Technical Support
Staff member
Not sure that the RMC fields should be skipped
By skipped; do you mean the field is not present or present but empty ?

My old Haicom 203's don't skip them & neither does my etrex legend.
It can be argued that, if the GPS device is not moving and it is not possible to determine a heading, then there is no valid heading data so the heading field should be left empty and presenting zero would actually be out of spec.

I don't know what NMEA standards says but, if there are standards for field contents, they seem quite loose or manufacturers are interpreting them that way or simply not complying with the spec.

When I scoured the web looking for message examples it seemed there was a wide range of field formats used. It differs between manufacturers, products and even versions of the same product. What is output doesn't always match what the product documentation indicates or suggests.

The only defensive approach to handling fields is to accept anything and adjust the data as required, noting whether a field is there, empty or not when that may be important.
 

srnet

Senior Member
It can be argued that, if the GPS device is not moving and it is not possible to determine a heading, then there is no valid heading data so the heading field should be left empty and presenting zero would actually be out of spec.
That would be my thoughts, as well.

The only defensive approach to handling fields is to accept anything and adjust the data as required, noting whether a field is there, empty or not when that may be important
Exactly.

And also the code can then be used for other GPSs
 

srnet

Senior Member
Not sure that the RMC fields should be skipped.
There not, they are null when there is no meaningful information. A direction of 0.00 degrees for COG, is not clearly not valid if the GPS is stationary, so how should it be indicated ?

Knowing there is a null field there is useful, since you then know not to use the field.

A lot of GPS fields are null when there is no information, such as the lat,long,alt,sats etc which will be null until there is a fix.

The documentation from ublox does indicate the flags can be changed, but it's not very clear on how you do it.
Can you say where in the manual it alludes to the 'flags that can be changed' ?
 

hippy

Technical Support
Staff member
The documentation from ublox does indicate the flags can be changed, but it's not very clear on how you do it.
It can get quite complicated once you step away from using NMEA messages.

CFG-NMEA "31.12.2 Set/Get the NMEA protocol configuration" seems to be what you need ( page 120 in my uBlox protocol datasheet ).

You should be able to send that as a simple SEROUT string and I am sure the example code ( or code on the forum ) shows how to send appropriate packets ( see below ). You will however have to calculate the checksum(s) and there's no guarantee what result you get once you disable filtering - It might not be the 000.0 you are after !

Code:
; Disable GPGGA
  SerOut GPS_TX, GPS_TX_BAUD, ( $B5, $62, $06, $01, $08, $00, $F0, $00, $00, $00, $00, $00, $00, $01, $00, $24 )
  SerIn [200,Initialise], GPS_RX, GPS_RX_BAUD, ( $B5, $62, $05, $01, $02, $00, $06, $01, $0F, $38 )
  SerTxd( "GPGGA disabled", CR, LF )
Added : This might be useful ...

http://www.picaxeforum.co.uk/showthread.php?23934-How-to-request-data-from-GPS010

Post 22 arguing the case for what srnet is doing above, combining messages into a user defined message, and

Post 30 detailing more of the protocol for CFG-XXXX
 
Last edited:

srnet

Senior Member
It can get quite complicated once you step away from using NMEA messages
Indeed.

CFG-NMEA "31.12.2 Set/Get the NMEA protocol configuration" seems to be what you need ( page 120 in my uBlox protocol datasheet )
Ah, got it.

Its clear how you make the change, but it does not say what effect the 'filtered' option for COG actually does see;

2.5 Low-speed Course Over Ground Filtering on page 3.

As for the checksum, the format for that is given in the manual, and I cannot find an online calculator for that, although the PCIAXE code is simple enough.
 

neiltechspec

Senior Member
0.00 is valid speed if not moving though. Therefore, COG of 0.00 is not meaningless with no speed.

Flags can be changed using CFG-NMEA - $b5,$62,$06,&17,with a payload of 4 bytes (4th being the flags) then checksum.
Page 120 of GPS010_max6_protocol.pdf

Anyway, giving up with this module as it doesn't do what I want & sticking with the Haicom ones.

This is what I get from the Haicom
$GPRMC,170707.998,A,5234.1028,N,00149.0697,W,000.0,000.0,211194,004.8,W*6B

This is what I get from the Ublox
$GPRMC,152724.00,A,5234.06421,N,00149.09604,W,1.590,,150714,,,A*68
 

srnet

Senior Member
0.00 is valid speed if not moving though
It could be, what if the calculated speed is 0.001 ?

This is what I get from the Haicom
$GPRMC,170707.998,A,5234.1028,N,00149.0697,W,000.0,000.0,211194,004.8,W*6B
I have looked at the output of a few different GPS, never seen one that reports a null speed and COG as 000.0, thats really wierd.

Why does the output have to be in 000.0 format ??

This is what I get from the Ublox
$GPRMC,152724.00,A,5234.06421,N,00149.09604,W,1.590,,150714,,,A*68
Looks about right, similar to the also popular MTK3329.
 

neiltechspec

Senior Member
Cars rarely go that slow, so speed of xxx.x is a useful range. 0.001 isn't.

The way I am using it, COG is only relevant if moving faster than 0.09 Knots (meaning 000.1 or faster)

The Haicom's use an Evermore 12 channel chipset, they must be at least 15 years old now.

Neil.
 

srnet

Senior Member
Well its your choice.

To me it would make a lot of sense to change the parsing software so that it can cope with variances in GPS output format, you are not then tied to one specific GPS with a not common output format and poor performance compared to modern chipsets.

I doubt that there are GPS out there that can replicate all the possible formats and behaviours for speed and COG, but the differences are simple enough to deal with in the parsing software.
 

neiltechspec

Senior Member
Points well made.

Think I might try changing the Ublox "Dynamic Platform Model" from its default "Portable" to "Automotive ADR" just to see what the difference is, if any.
 

neiltechspec

Senior Member
Downloaded the utility software from ublox.

CFG-NAV5 is the field I want to change, page 117 of the protocol doc. This says the payload should be 36 bytes long, but reading from the GPS only gives 24 bytes.

CFG-NAV5 - 06 24 24 00 FF FF 00 03 00 00 00 00 10 27 00 00 05 00 FA 00 FA 00 64 00 2C 01 00 3C 00 00 00 00 00 00 00 00 00 00 00 00

So, I'm well confused now

I did change the NMEA config flags and it didn't make any noticeable difference.

Note: The checksum is only generated when sending back to the GPS.
 

srnet

Senior Member
CFG-NAV5 is the field I want to change, page 117 of the protocol doc. This says the payload should be 36 bytes long, but reading from the GPS only gives 24 bytes.
Its says the last 12 bytes are reserved and always 0, so presumably the poll message response does not send them.
 

neiltechspec

Senior Member
Played about with the utility software a bit, I think I can do what I want with VTG & ZDA messages.

So, for info the messages available are :

GGA - B5 62 06 01 08 00 F0 00 00 00 00 00 00 00
GLL - B5 62 06 01 08 00 F0 01 00 00 00 00 00 00
GSA - B5 62 06 01 08 00 F0 02 00 00 00 00 00 00
GSV - B5 62 06 01 08 00 F0 03 00 00 00 00 00 00
RMC - B5 62 06 01 08 00 F0 04 00 00 00 00 00 00
VTG - B5 62 06 01 08 00 F0 05 01 01 01 01 01 01
GRS - B5 62 06 01 08 00 F0 06 00 00 00 00 00 00
GST - B5 62 06 01 08 00 F0 07 00 00 00 00 00 00
ZDA - B5 62 06 01 08 00 F0 08 01 01 01 01 01 01
GBS - B5 62 06 01 08 00 F0 09 00 00 00 00 00 00
DTM - B5 62 06 01 08 00 F0 0A 00 00 00 00 00 00


I have just ZDA & VTG turned on, the utility does give the option to make changes permanent as well.

Neil.
 

srnet

Senior Member
Having looked at the Ucentre manual and the Ublox hardware manual, its not clear.

The hardware manual mentions the external EEPROM as being used for storing configuration, and the 'Flash' (mentioned in ucentre) as being optional.

Confusing or what.
 

hippy

Technical Support
Staff member
It seems to me that EEPROM would be external and connected to SDA/SCL which are brought out to pads on the Rev-Ed module. Those pins are also used for the Display Data Channel (DDC).

That's also how it is described in the Rev-Ed GPS010 datasheet ! See "I2C and Configuration EEPROM" section.

Also have a look at the "max-6 hardware integration manual" which appears to include further details on connecting such an EEPROM ...

https://www.u-blox.com/images/downloads/Product_Docs/LEA-6_NEO-6_MAX-6_HardwareIntegrationManual_(GPS.G6-HW-09007).pdf

Note that only very specific EEPROM chips seem to be specified for use though there may be others which are compatible.
 

neiltechspec

Senior Member
Well, whatever.

The ublox S/W gives the option to store config into BBR/Flash.

I saved the config with just VTG & ZDA enabled & it remembered it after 6 hours of power off.

Neil.
 

srnet

Senior Member
I think you might be right, although that does make you wonder why the manual makes so much mention of fitting the EEPROM.
 

neiltechspec

Senior Member
Item No 271531889611 on the bay is the one I bought, came in a couple of days so must actually be UK stock.

According to the listing, it says - 32k I2C EEPROM for save configuration.

So it must be saving to that, or is it ??. I dunno. But for £13.99 delivered, that's cheap.
 

srnet

Senior Member
I was playing with the Ublox Neo 6, bought as a bare module fot my HABAXE tracker PCB.

Definelty no EEPROM fitted, I would have remebered designing it in.
 

hippy

Technical Support
Staff member
According to the listing, it says - 32k I2C EEPROM for save configuration.

So it must be saving to that, or is it ??
Could be. It has a battery on board so could be saving to BBR. It's also a NEO-6 and I'm not sure what the differences are to the MAX-6 we stock is. It may have Flash and EEPROM because EEPROM has a better update endurance.

But for £13.99 delivered, that's cheap.
Certainly is. Perhaps because they aren't the ones providing support for what they sell ;-)
 

srnet

Senior Member
Certainly is. Perhaps because they aren't the ones providing support for what they sell ;-)
You can get them a cheaper than £13.99, but the same would apply, as 'box shifters' you would need to get technical support from someone else, thant the problem with cheap.
 

srnet

Senior Member
From what I can tell from the data sheets, the later version 7 Ublox GPS come with either ROM or Flash, with the Flash version you can update the firmware and store the configuration:

Ublox Neo 7M - ROM based
Ublox Neo 7N - Flash based.

I can't see any indication that the older version Ublox version 6 GPS comes with a Flash option, hence the exteranal EEPROM.
 
Top