Custom Digital Dashboard Project

[brentp]

Awesome. Keep us posted!

[brentp]

Great update! Some interesting displays can be found here as well : http://www.buydisplay.com/

We did some fun videos this weekend using the on-board lua scripting to control the sequential shift light for a variety of uses:
http://www.youtube.com/watch?v=Bpp8xIcs ... 4-overview

[emdash]

It was a rainy weekend, here in SF. So, I got some hacking done. I decided to tackle the communication side of things, setting aside design work. I have some bits and pieces lying around, like a 16x2 character display, and an arduino uno. So the first thing I did was get those hooked up to each other. I decided to implement a working prototype of a display with a series of "pages". So the first "page" displays lap times, the next displays engine stuff, with a final page for debugging.

[brentp]

Awesome! keep up the good work!

You don't get many rainy days down there, however

[emdash]

I looked at the firmware and analyzer code and discovered to my dismay that it's a pretty complicated JSON format. Arduinos are pretty resource constrained. Less than 2k or ram, not a lot of processing power. Plus we're writing C code. I have concerns about being able to parse JSON data reliably. Either I have to write some brittle, ad-hoc JSON parser, or else just accept that I'll need to modify the firmware for my own purposes.

Since I had nothing but time, I designed a binary protocol that would be easy to cope with. I settled on the following binary protocol, which is basically a sequence of independent samples. Each sample encodes a 32-bit value, which is treated as an int or a float depending on the associated channel id. The display redraws itself every 100ms, but values are updated in RAM as they arrive from serial. Each sample is 7 bytes:

Bytes 0 - 5: Data
Byte 6: Channel id (currently these are letter codes, but I'll probably change that).
Byte 7: 0x00 terminator.

The first data byte encodes the high 4 bits of the data, and the remaining 4 bytes encode 7 bits of data each. All the data bytes are ORed with 128 (0x80). This ensures that samples don't contain embedded null (0x00) bytes (channel ID 0 is forbidden), which allows 0x00 to be used as a terminator. The data is big endian, which happens to be the arduino's native endianness.

The protocol allows the display to begin receiving in the middle of the data stream and still find its place. It also allows the display to easily discard samples it's not interested in, and it allows the sending unit to send samples in an arbitrary order. Everything is 32-bit simplicity's for sake, which seems to be the maximum available precision anyways (if you needed more, you could chain samples together with a designated channel id). You can have up to 254 channels, which should be plenty considering the data logger only has ~30 or so channels of actual data. Even with an expansion board, there are plenty of channels left over.

This all sounds complicated, but the actual implementation is about ~50 lines of C code on the receiving end, and ~10 lines of python code in the test app I wrote (not counting the code to set up the serial port). It's also pretty simple to implement in the RCP firmware. The data logger can just spew samples over serial in whatever order it wishes, and the display will pick out what it needs. No complicated bit-mask to deal with, no nested JSON data-structures.

[emdash]

So, with that out of the way, I wanted to tackle the electrical interface between the arduino and the RCP. Digging through the documentation, I determined that the telemetry port is basically a 2-wire RS232 serial port (no flow control). I hacked up a phone cable, and then soldered wires to 4 pins from a break-away header. Then I sealed the whole thing up with some sugru so it wouldn't be flake city.

I tried to build an RS232 level shifter based on schematics I found on-line, but something isn't working right. At the very least, I'm not getting data out of it. More progress will have to wait until tomorrow, when I can take the whole mess down to techshop and use their oscilloscopes to debug it. Once I get that going, I can move onto the next phase, which is reprogramming the RCP firmware to speak my binary protocol.

Also, for shits and giggles, I experimented with "converting" water-clear LEDs into diffused leds with a little sandpaper. The attached photo is a pretty dramatic illustration at how this improves angular brightness.

[emdash]

Awesome! keep up the good work!

You don't get many rainy days down there, however

And not many rainy days until the season starts, either

[brentp]

If you use a MAX232a like we have in the bluetooth module then you'd be able to get those levels back down. pretty straightforward.

[emdash]

If you use a MAX232a like we have in the bluetooth module then you'd be able to get those levels back down. pretty straightforward.

My goal is to get something working end-to-end before I buy any more crap I've already accumulated quite a few speculative purchases which I'll probably never end up using at this point - you know how it is.

On that note, I found a bluetooth arduino shield I'd quite forgotten about. The docs indicate I can put it into master mode and pair it with the RCP's bluetooth module. If so, I might be able to get this going without resorting to the kind of electronics hackery at which I'm admittedly not much good. Assuming all goes well, I'll resume design work.

Great update! Some interesting displays can be found here as well : http://www.buydisplay.com/

We did some fun videos this weekend using the on-board lua scripting to control the sequential shift light for a variety of uses:
http://www.youtube.com/watch?v=Bpp8xIcs ... 4-overview

Thanks for that link. They do indeed have some very cool options.

[brentp]

+1 on bluetooth master mode.

When we kick off our dashboard project we will be looking at CAN bus connectivity as an option. This will allow direct transmission of data from RCP as well as the ability to spy on communications between ECU and datalogger, or other devices. Because message bus network.

[emdash]

The bluetooth shield is proving to be quite recalcitrant.

I'm not sure what's going on, but software serial above 9600 baud seems to be completely broken. When I first bought the shield, I had no issue with 38400 bps (the default). Right now, software serial at 9600 baud is still really flakey. I'm forced to use the hardware UART, which means no serial debugging. This really is not a workable situation.

Another issue I'm having is that my laptop crashes periodically whenever I have an rfcom connection @#$($U@*#ing bluetooth, man.

I do have a display, but it's pretty hard to figure out what the hell is going on when you can only see 32 characters at at time. Even with hardware the hardware serial, I can't get the module to pair with the RCP bluetooth. It always returns connection fail, and it never asks for the pin. But I can at least see the RCP returned in the list of available devices, and the bluetooth module returns the correct device id.

I spent a whole evening, and I seem to have exhausted all my ideas. Not sure I can get much further with the bluetooth module. I've got to head up to Thunderhill this evening, so I won't be getting any hacking done before Sunday. Not sure how much I can reasonably expect to get done on sunday.

I may have to look at the SPI port on the RCP instead. My thought is that since there's a dedicated clock line, software-driven communication will work better.

When I set down to build the real device, I guess I'd better pick a micro-controller with multiple hardware UARTs. Not being able to debug over serial when you're doing other communication-related tasks is ridiculous.

[brentp]

Can you go to a better arduino with more hardware serial ports available?

Also, this can help you do a hard wired connection to the RCP serial port. easy peasy.
https://www.sparkfun.com/products/11958

I would really not recommend integrating with the SPI port. Primarily of the work involved to not interfere with Accelerometer and SD card communication - there is some critical code in there that would be easy to break things. Second reason, you can't run SPI for long lengths; 6" cable would be the max.

I would definitely focus on the serial connection. We can provide some docs/info on how to decode the stream, too. it's pretty easy.

Keep us posted!

[emdash]

Can you go to a better arduino with more hardware serial ports available?

Also, this can help you do a hard wired connection to the RCP serial port. easy peasy.
https://www.sparkfun.com/products/11958

I would really not recommend integrating with the SPI port. Primarily of the work involved to not interfere with Accelerometer and SD card communication - there is some critical code in there that would be easy to break things. Second reason, you can't run SPI for long lengths; 6" cable would be the max.

I would definitely focus on the serial connection. We can provide some docs/info on how to decode the stream, too. it's pretty easy.

Keep us posted!

I'm not sure how much that shield will help. It's hard-wired to the hardware TX/RX pins, which are the same ones that USB debugging uses. I'd have to get a leonardo to have simultaneous communication and debugging. As I've said, I really don't want to buy anything expensive (> $10) until I make some more progress -- otherwise this stuff starts to snowball.

Honestly, I'm not sure what the deal with software serial is. It used to work just fine. I'd rather like to get to the bottom of that.

That's a shame about the SPI port, though. I had hoped I would eventually be able to upload data over bluetooth to avoid constantly swapping SD cards.

[emdash]

Went to the track yesterday. I had an Aim Solo GPS unit for the day, so I got some data. Struggled to break 2:12, which is really pretty crummy. I blame slower traffic

The solo display looks like a ~240x128, and there's no issues reading it in direct sunlight. It's a decent size, and the characters are pretty reasonable.

Mounting is a problem, though, and the only available location is partially obscured by the wheel. Looking at the display was a special project involving peering around the wheel, I frequently couldn't risk it. Just re-iterates that my display is going to need to be short enough to sit above the wheel without getting into the slipstream.

I bought some MAX232A IC's off amazon. They're on their way, supposedly. I've completely given up on the bluetooth module. The firmware is appalling, and I can't get anything sensible to happen in either master or slave mode. And my laptop constantly crashes. Enough.

I've also given up on software serial. When the ICs get here, I'll hook one straight to the hardware pins and dump whatever comes in over serial to the display and iterate from there. I just want to get something working end-to-end, and then I don't have a problem going on another shopping spree. But first, I need to convince myself that I can do this.

[brentp]

Sounds good - keep us posted. We'll be spinning up our dedicated dash as well very soon, and if it's something that you'd like to help with on the firmware side we can take care of the hardware design, to avoid frustration.

As a side note, we'll also have the firmware updated for realtime predictive timing and realtime +/- offset from best lap. Seeing if I can work that into the soon-to-be released 1.2.7 firmware. \o/