Autosport Labs

*NOTE- Moved from General Question Area. This is a better place for this to go*

I'm building an interface to connect the RaceCapture to some external gauges. In particular I'm using the PLX MFD gauge displays.



You can read about these displays here:

These are OLED displays designed to work with the PLX sensor devices. The PLX sensors connect to the display system with a simple serial protocol, and the display system allows you to upload graphical screen data for each value.. so you can pretty much display any kind of data in any way.. for things like temp or pressure you can have the raw numbers, for things that would work good with analog gauges you can draw you own.. and you can do non linear things. Very cool overall.

I am going to build an interface from the RaceCapture to send data to the PLX displays in the PLX format. I'll also make some templates for the graphical uploads.

I have a few quick questions to make sure I am on the right track:

(1) Since I just need a stream of the captured data from the RaceCapture, it seems like the Telemetry port is the best option. Correct?

(2) The Telemetry port is just a TTL serial port at 115/N/8/1?

(3) The data sent over the Telemetry port is a JSON structure, and has all of analog, frequency, and GPS values?

(4) Is there any configuration on the Race Capture I need to do to enable the telemetry output, and to select what channels to output?

I'll post up complete source code, hardware schematics, etc. All Open Source of course.

Thanks for any guidance you can offer!

Jeff

sponaugle wrote: (1) Since I just need a stream of the captured data from the RaceCapture, it seems like the Telemetry port is the best option. Correct?

(2) The Telemetry port is just a TTL serial port at 115/N/8/1?

I did some investigation last night, so I'll go ahead and answer my own questions!

Yes, 115/N/8/1 on the Telemetry port. RS232 voltage (+/- about 6.5 volts).

sponaugle wrote: (3) The data sent over the Telemetry port is a JSON structure, and has all of analog, frequency, and GPS values?

Yep. An interesting JSON structure. Every 100 message lines there is a 'data element manifest' that tells you the field names/units/rate.

A few interesting things to note for others looking to read this data:

Here is a sample of the 'data element manifest':
*NOTE* I added CRLFs to make it easier to read. You can see that each field the listed with a name, unit, and sample rate attribute. It is important to note the order. In this case Analog1 is data element #0, and Distance is data element #23. Since each data element can have different sample rates, a bit mask is used to tell which what data elements are in a particular output sample.

For example in with the stream used above you might see:
The last element in the list is the bitmask telling you what fields were just transmitted. In this case the decimal number 30720, which in binary is 01111000 00000000. That tells you (starting right side bit 0 to represent data element #0) that this line has data elements #11,12,13,14 which happens to be
.

As you would expect those elements are sampling at a faster rate so they are transmitted more then the 10Hz lines.

For each line transmitted there is a mask. If everything on the device is set to the same sample rate, every transmitted line would be the same and include all fields.

There are a few quirks however:

(1) Even if you disable GPS and select only a SINGLE analog channel, "Distance" is always listed in the field manifest.
In this case the Distance is listed in the manifest, but it is never really transmitted since the GPS was disabled.

(2) If you have GPS enabled, the "Distance" value is always transmitted and it set to 10Hz. That setting can't be changed from the configuration app (although it is configurable in the API to the RCP). You could rebuild the firmware and change the default (#define DEFAULT_DISTANCE_CONFIG {"Distance", "miles", SAMPLE_10Hz})

This also means that if you have everything set to 1Hz but have GPS enabled, you will get all of your sensor readings in 1Hz increments but still get "Distance" readings at 10Hz.

(3) Data rates are interesting. If you put just the Accel X and Y at 10hz, you get almost exactly 10hz. If you put both at 20Hz, you get about 15hz output. If you do 30, you get close to 20. If you do 50, you get around 40. In looking at the code the telemetry logging is set based on the highest sample rate of a channel. I suspect if the channels are at 50hz and the telemetry at 50hz, there is some overlap in time where a sample isn't available or the serial port is busy, so you get a data rate a bit under that. At 100hz capture the telemetry is still limited to 50hz. I assume (but have not looked at the code to confirm) that if you set the analog capture sample rate to 50hz, you still get 50hz capture to the local log file (SD card).

(4) One unusual bug... if you set the sample rate to 100hz, it is reported as 50hz over the telemetry manifest. I have not tested to see if it is really doing 100hz to the SD card or not.

sponaugle wrote: (4) Is there any configuration on the Race Capture I need to do to enable the telemetry output, and to select what channels to output?

It appears if you enable a channel, it is added to the telemetry output. One note, with the 'Telemetry Mode' set to 'Bluetooth adapter' on startup the RCP first sends out an 'AT' Command over the telemetry port to look for the cellular modem. After a total delay of about 20 seconds, it switched to regular telemetry output.

More to come.

Jeff

Hi Jeff,

Thank you for the write-up! After reading your information I was wishing we had this protocol information in our wiki along with the rest of our documentation. Would you be interested in helping us in the area of documentation?

To answer some of your questions: The bitmask indeed indicates which fields are present in that particular sample record, to save space in the data packet. it correlates to the metadata section that is sent at the beginning of transmission in addition to periodically being re-sent.

Telemetry is auto-limited to 50Hz for bluetooth connectivity mode and 10Hz in cellular telemetry mode. SD card logging rate is not constrained.

The V2 firmware coming Real Soon Now will fix the bugs you're seeing in the sample rate information. Read more about it here: http://www.autosportlabs.com/racecaptur ... a-release/

The distance channel will be configurable in addition to the other lap statistics channels.