Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

$RC and NMEA mixed input questions

This discussion was created from comments split from: RaceLogger bluetooth input format.

Comments

  • Another bump to an old thread...

    I'm building some hardware that will be sending NMEA and RaceDAC style mixed output. I have a few questions after reading this thread.

    1) What NMEA sentences does RaceChrono accept? There's a bunch of them the GPS module I'm using can send but I'm not sure if RaceChrono uses them all, so I'd like to filter the unnecessary ones out to help limit the bandwidth over the bluetooth connection since I'll be using a 10Hz update rate.

    2) An RC3 format was mentioned. What's that look like and is it available for use in the current version of RaceChrono?

    3) When NMEA is mixed with RC2, the RC2 must include a timestamp. Why is that necessary if it's not used when the GPS is not mixed in? Is it satisfactory to just repeat the timestamp of the last NMEA sentence that included a timestamp?
  • 1) RMC + GGA and RMC + VTG + ZDA combinations will work. GSA and GSV are used only for satellite azimuth display.

    2) RC3 is coming very soon, on next update. It will have at least 12 analog channels and gyroscopes input. Rest of details are still to-be-decided.

    3) As the GPS and other data is coming from the same device, the device should determine the timestamps for the other data too. It's much more exact to determine the timestamps on the sending device, rather than at the receiving device after Bluetooth transmission. If the device sending the other data is separate, it doesn't know the GPS time.
  • Thanks for the info!

    For the GPS data, what sentence prefix is required? I found this: http://www.gpsinformation.org/dale/nmea.htm and it indicates they all start with $GP, but the GPS module I'm using uses $GN for the sentences you mentioned. Is that a problem? Or does RaceChrono ignore the third character?
  • $GPxxx sentences only are currently supported. Although if you need $GNxxx I could look in to that if you provide me a good sample data.
  • This: http://navspark.mybigcommerce.com/content/NMEA_Format_v0.1.pdf describes the formats output by all the devices from the manufacture of the GPS product I'm using. The document describes sentences for all the devices from the manufacturer, but I believe the only differences are which sentences are output, not the sentence formats. Specifically, I'm using a NavSpark-GL device (GPS and Glonass). It doesn't appear the $GN formats are that different from the $GP formats but I don't claim to have done a close examination.

    I don't actually have the device in hand yet, but I expect it next week. I'll be able to provide some real data then.
  • Took a little longer than expected, but I have sample output now. I don't see a way to attach a file, so here's a snippet:

    $GPGGA,023451.000,4238.1906,N,07334.4085,W,2,12,0.9,213.8,M,-32.5,M,,0000*6E
    $GPGLL,4238.1906,N,07334.4085,W,023451.000,A,D*46
    $GPGSA,A,3,15,29,13,24,18,20,21,,,,,,1.6,0.9,1.3*3D
    $GLGSA,A,3,75,81,66,67,76,,,,,,,,1.6,0.9,1.3*29
    $GPGSV,3,1,11,15,81,184,47,20,76,015,39,13,59,059,39,21,53,303,26*7C
    $GPGSV,3,2,11,05,33,079,25,18,32,282,28,46,32,212,41,29,27,211,39*7F
    $GPGSV,3,3,11,24,16,161,41,02,03,138,30,33,00,000,39*49
    $GLGSV,3,1,10,82,58,285,26,67,53,289,36,66,51,032,27,81,42,197,37*6F
    $GLGSV,3,2,10,76,19,098,24,75,16,039,34,83,15,333,25,68,07,257,*61
    $GLGSV,3,3,10,65,04,063,17,77,00,141,*64
    $GPRMC,023451.000,A,4238.1906,N,07334.4085,W,000.0,000.0,200716,,,D*73
    $GPVTG,000.0,T,,M,000.0,N,000.0,K,D*08
    $GPZDA,023451.000,20,07,2016,00,00*57
    $GPGGA,023452.000,4238.1906,N,07334.4085,W,2,13,0.8,213.8,M,-32.5,M,,0000*6D
    $GPGLL,4238.1906,N,07334.4085,W,023452.000,A,D*45
    $GPGSA,A,3,15,29,13,05,24,18,20,21,,,,,1.5,0.8,1.3*3A
    $GLGSA,A,3,75,81,66,67,76,,,,,,,,1.5,0.8,1.3*2B
    $GPRMC,023452.000,A,4238.1906,N,07334.4085,W,000.0,000.0,200716,,,D*70
    $GPVTG,000.0,T,,M,000.0,N,000.0,K,D*08

    Here's a larger sample file (823 lines): https://drive.google.com/file/d/0B4UDcivgBOvdT05MWkhINDFhRWM/view?usp=sharing

    I'm using the default settings on the device right now. Update rate is 1 Hz, but it goes to 10 Hz (and even 20 Hz for some models), which is what I'll be using eventually.

    Contrary to what the docs for the device indicate, it appears the prefix for most of the sentence types you need is $GP, so perhaps you don't need to make any changes. For the satellite fix sentences, the device uses $GL as well because of GLONASS support. I suppose it's not required, but if RaceChrono could count those satellites as well as the GPS satellites, that would be cool.
  • Looks like valid NMEA to me. Should work with RC. As stated before RMC + GGA and RMC + VTG + ZDA combinations will work, and GSV/GSA is used for lock status (only the $GPxxx currently, $GLxxx maybe later). You can filter out or turn off anything else.
  • Greetings. Bumping this thread back up. I'm working with a couple different hardware GPS solutions and was hoping there was a specification for messages supported over bluetooth. My current understanding is that the software only supports Bluetooth using the Serial Port Protocol (SPP) profile. NMEA sentences ($GPxxx) specifically GPRMC, GPGGA, GPGSV, GPGSA

    Your custom messaging protocols are described here - http://www.racechrono.com/forum/#/discussion/1380/input-format-rc2-and-rc3-used-by-racedac-and-diy-loggers

    Is any of this captured in a document/wiki etc? Or is this information only provided on these forums?

    Is there any interest in using BLE Devices (GATT Services)? You could still send NMEA sentences, but using the built in data structures from BLE one could alleviate your need to parse and decode long strings in the APP. Regardless this would be a code change for RC.

    What about a binary coded message set to reduce the load on the wireless links, optimize performance?
  • Only SPP is currently supported currently. In theory I could create a support for BLE, but I always need a working product to test against. I don't know of any NMEA BLE device so it's hard to test currently. I will be looking at BLE soon, so I might have some more insight on it later.

    Ideally binary would be best solution, agreed. Also no wiki/documentation other than the forum.
  • I'm glad to hear you have been looking into BLE, and certainly understand that you will need hardware to test against. I don't know of anything off the shelf that you can use. However it seems that the implementation would be very well standardized in BLE:

    https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.location_and_navigation.xml
  • I've now implemented support for one BLE device (an OBD-II reader). It's not a GPS device, so cannot comment on location characteristic implementation, but BLE in general seems straight forward.

    I think BLE GPS + data logger implementation should implement a standard location characteristic, as well as a one or more data logger characteristics. That way the GPS could be used directly by any other app or OS that supports the standard location. I'm not sure how good throughput we could get through BLE, but worth trying anyways.
  • I have a BLE GPS that can give you a test
Sign In or Register to comment.