[info] Ublox NEO-6M GPS module

[AndreyB]

My Ublox NEO-6M GPS module has arrived!

It's pretty cool - I've plugged it into a USB-TTL dongle and after five minutes of me trying to figure out what's wrong it has started printing out data!

$GPRMC,0blahblah...
$GPVTG,,T,,M,0.139,N,0.258,K,A*27
$GPGGA,013141.blahblah...
$GPGSA,A,3,32,blahblah...
$GPGSV,3,1,blahblah...
$GPGSV,3,2,blahblah...
$GPGSV,3,blahblah...
$GPGLL,1234.34240,N,01234.44218,W,013141.00,A,A*7A

(I do not want to publish my coordinates so I have replaced some stuff with blahbla)

I have not yet found the description of the protocol - all I could find was this piece of code

Anyway, just wanted to share my excitement. @ is in charge of writing the source code under #13 and we still need to figure out how exactly we will use this data, but it is still pretty cool - even if it would be totally useless

[hasse.69]

And you could buy it here.
http://www.hobbyking.com/hobbyking/store/__31135__NEO_6M_GPS_Module.html
Or.
http://www.ebay.com/itm/Ublox-NEO-6M-GPS-Module-Aircraft-Flight-Controller-For-Arduino-APM2-5-APM2-HP-/161166905487?pt=AU_B_I_Electrical_Test_Equipment&hash=item25864bd08f

//Hasse.

[abecedarian]

http://www.u-blox.com/en/download/documents-a-resources/u-blox-6-gps-modules-resources.html

[AndreyB]

http://www.u-blox.com/en/download/documents-a-resources/u-blox-6-gps-modules-resources.html

This was helpful! I am attaching the document which has the protocol description - turns out what we see here is a NMEA-based protocol

[abecedarian]

Some GPS will 'remember' the last satellites they had acquired and will start trying to re-acquire those first, in order of RSSI / signal strength (strongest to weakest), others will survey and re-acquire on every start up and can take up to 30 seconds to fix position.

NEMA 0183 is a pretty standard protocol used with GPS receivers. More info here.

[AndreyB]

@ has made some progress on NMEA message parsing - we are now taking GPS and setting our own time based on it.

One pending question is configuring GPS update rate, so far we do this via their application but I think we should learn how to do this on our own.

PS:
http://www.rctimer.com/index.php?gOo=goods_details.dwt&goodsid=763

[AndreyB]

Looks like RC flying things community is the best source on information on these small GPS modules. Here is most relevant post I've found so far: http://www.multiwii.com/forum/viewtopic.php?f=6&t=1881&start=40#p28530

[Kot_dnz]

Dear All,

I found some new information
http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS
section: Configuration for a higher sampling rate

Code: Select all

The GPS chip can be flexibly configured for more than one sample per second. Sometimes I need a good GPS log for experimental projects, and I configure my Neo Freerunner's GPS to take 4 samples per second (the maximum it can do) and to send me nothing more than GPRMC (Date+Time+Lat+Lon+Speed+Direction) and GPGGA (...+Altitude+Sats+HDOP) messages - I disable the other ones because they are redundant.
These configurations have to be done via the u-blox binary protocol. So I just build the messages using the above "ubxgen.py" script like this:

# disable unnecessary messages:
ubxgen.py 06 01 03 00 f0 01 00 > CFG-MSG-GPGLL-OFF.ubx
ubxgen.py 06 01 03 00 f0 02 00 > CFG-MSG-GPGSA-OFF.ubx
ubxgen.py 06 01 03 00 f0 03 00 > CFG-MSG-GPGSV-OFF.ubx
ubxgen.py 06 01 03 00 f0 05 00 > CFG-MSG-GPVTG-OFF.ubx
ubxgen.py 06 01 03 00 f0 08 00 > CFG-MSG-GPZDA-OFF.ubx
cat CFG-MSG-GP*-OFF.ubx > /dev/ttySAC1

# reduce measurement time and message cycle to 250ms (4Hz):
ubxgen.py 06 08 06 00 fa 00 01 00 00 00 > CFG-RATE-4HZ.ubx
cat CFG-RATE-4HZ.ubx > /dev/ttySAC1

# alternatively:
# reduce measurement time and message cycle to 500ms (2Hz):
ubxgen.py 06 08 06 00 f4 01 01 00 00 00 > CFG-RATE-2HZ.ubx
cat CFG-RATE-2HZ.ubx > /dev/ttySAC1

Using this setup, the output of "gpspipe -r" will dump around 600 bytes per second (4 GPRMC + 4 GPGGA messages).
To recover the default values, just turn off the GPS or let the FR suspend.

And full protocol explanation:
http://www.u-blox.com/images/downloads/Product_Docs/u-blox5_Protocol_Specifications(GPS.G5-X-07036).pdf
page 104, section: Get/Set Port Configuration for UART

Code: Select all

Message CFG-PRT
Description Get/Set Port Configuration for UART
Firmware Supported on u-blox 5 from firmware version 4.00 up to version 6.02.
Type Get/Set
Comment Several configurations can be concatenated to one input message. In this case the payload
length can be a multiple of the normal length (see the other versions of CFG-PRT). Output
messages from the module contain only one configuration unit.
Header ID Length (Bytes) Payload Checksum
Message Structure 0xB5 0x62 0x06 0x00 20 see below CK_A CK_B

It's a ublox/neo6m dependent protocol.
Theoretical we can detect UBLOX.

Question: are we need implement this future to code?

[AndreyB]

Question: are we need implement this future to code?

We probably do not need UBLOX detection, but we definitely need the code to increase navigation rate (I think that's what they call this 5Hz options): that's because I've seen a .pdf which describes how you can hack a NEO module in order to add EEPROM which makes me think that without the EEPROM the device would not remember the properties.

I really need a working datalogger by the middle of April - I am planning to use a data-logger as a PR effort in my racing community. I am now waiting for the Frankenstein board to arrive - I hope to build the datalogger using Frankenstein, but if this falls apart I would build it from pieces.

[mck1117]

Holy 5.5 year thread resurrection, Batman!

The GPS code parses NMEA input, but does nothing with it. Even the compiler figured this out--it optimizes most of it out!

Even if we ignore the part where it didn't actually work, is an ECU the right place for GPS parsing? What's the proposed consumer of GPS data inside rusEfi?

Any actual opposition to removing GPS from the firmware? (and no, sentimental value doesn't count, because it doesn't make my car faster!)

[AndreyB]

What's the proposed consumer of GPS data inside rusEfi? Any actual opposition to removing GPS from the firmware?

I come from road racing. The dream was to know your position on the track based on GPS and adjust something based on GPS. Since the dream is still alive I would really prefer to keep GPS in for now, even while it's not used yet.

There are other dreams all over rusEfi at the moment.

[mck1117]

I come from road racing. The dream was to know your position on the track based on GPS and adjust something based on GPS.

There are other dreams all over rusEfi at the moment.

I come from the racing land as well, and I completely agree - having a data solution is a huge advantage on track. The RaceCapture is also open source, and works really really well. I've chatted with the developers at a few races local to me (they're in WA near me), and they have a great community. Here's their site: https://www.autosportlabs.com/

It would be much more worth our time to develop a CAN format so that rusEfi is natively supported by RaceCapture, so people can very cheaply integrate rusEfi in to the data system they might already have.

[AndreyB]

having a data solution is a huge advantage on track

My bad not communicating in clearly - the dream is not about data logging, the dream is about using position on the track to adjust some (whatever) settings.

Let's postpone this discussion for a few months at least, now is not a good time. We have so many things in motion I would rather stay focused.

[AndreyB]

GT-U7 GPS Module Navigation Satellite Positioning Compatible with NEO-6M 51 MCU STM32 High Sensitivity Low Power Consumption High-Precision Positioning Suitable for Vehicles was recommended

https://www.amazon.com/gp/product/B08MZ2CBP7