Instrument cluster design (seeking feedback!)

Projects General Guidance
1

Hey! First, thanks for checking out my post :slight_smile: In particular I'm looking for feedback on my on wether or not my use of Serial and I2C and layout of the components is the best strategy. Below is some background information on the cluster design, it's not particularly important to my real question so skip to the orange section if your not interested in all the details.

So I've been working on this project for about a year now, all by my lonesome. When I started I had very minimal programming experience and zero background with electronics. To date, I made a glowy halloween costume with neopixels and a LCD. And now this is my second project, obviously much bigger and a little unwieldy, so I'm looking for anyone with more experience to chime in.

WHAT I'M MAKING

An Arduino based instrument cluster, taking some off-the-shelf open source schematics (lots of adafruit stuff) and reworking them onto a few custom PCBs. Custom housing/face built with some 3D-printed pieces and CNC cut acrylic.


Higher resolution here

  • 2 "hybrid" gauges - each with an OLED display, outer ring of neopixels, and a needle pointer.
  • 3 additional OLED displays across the top-center area.
  • 37 indicator lights, some of which have 2 different colored LEDs behind them. So that means a total of 47 individual LEDs. Of which 9 are "hard-wired" and the rest are controlled by software.
  • Ambient light sensor, for backlighting adjustment / whatever future use
  • Absolute Orientation sensor (magnetometer+accelerometer+gyro) for determining wether car is going uphill/downhill/etc. Which may help in adjusting the fuel level reading to be more accurate and again for whatever future uses. Also for a digital compass.

• Center LCD Information Center
The center display will have a GUI with on-screen gauges, notifications/alerts, and a menuing system for changing options accessing features. It will be comprised of an Arduino Due and Gameduino for graphics. It will use the steering-wheel controls for interaction.

I want the Information Center to be kind of on it's own (both physically and in functionality), but obviously it needs to communicate with the cluster in order to display on-screen gauges, alerts, and ability to change settings on other parts of the cluster (ie: switch speedometer between metric/imperial)

WHAT I WANT IT TO DO

• Everything the stock cluster does
• Look cool, obviously

• Car Diagnositcs & Analytics
A big goal would be monitoring the data from the car's sensors (via CAN) and looking to see if anything has moved out of it's normal range, read any trouble codes, and basically keep a lookout for abnormalities.

• Support future projects in the car / be extendable
You'll probably notice all the extra indicator lights that aren't on the stock cluster. For example that rain cloud icon is there for an automatic wipers system (which doesn't exist). It'd like to add a separate "auxiliary" CAN network that future extensions can plug into and communicate with the instrument cluster. Adjusting settings through the information center.

THE REQUIREMENTS

So this cluster is to replace the factory one in a 2007 Ford Focus. I have the wiring diagram and workshop manual that gives me a good amount of info on it. I actually feel like I have a pretty good grasp on it now. The basic connections of the factory cluster (to be replicated):

  • Almost all the vehicle data comes over the CAN connection, with the exception of:
  • 6 Ground-switched indicator lights: Speed Control, Brake Fluid, Park Brake, Antitheft (PATS), Door Ajar, and Oil Pressure.
  • 3 powered indicator lights: Left/Right Turn Signals, and High Beams
  • PWM feed for backlighting/illumination (comes from the car's dimmer switch)

** Then some more particular interfaces: **

  • Fuel tank level sensor (signal and return line): The sensor is a variable resistor ranging from 15 ohms when low to 160 ohms when full. The instrument cluster needs to forward this information to the Powertrain Control Module over the CAN bus.
  • Tone request: outgoing signal to the body control module (GEM) to request playing tones/chimes. I think this is PWM based? I don't have an oscilloscope so I haven't figured it out yet.
  • Liftgate Inhibit signal: also haven't figured this out yet, but has to do with disabling the trunk opening button when vehicle speed is over a certain amount.

** I also have a chart that describes the CAN traffic the instrument cluster is involved in, pretty minimal, about 20 unique messages that I'll need to decode. **

THE CURRENT PLAN
Hopefully this makes sense, I call it a "functional diagram". It doesn't reflect the actual circuitry or location of things but kind of demonstrates the "Principals of Operation".


Higher resolution here

Microcontroller A (2x, one left, one right)
Reads in data from serial, controls the neopixel rings and OLEDs for each "hybrid" gauge.

Microcontroller B (2x, one left, one right)
Reads in data from serial, controls the motion of the gauge's pointer needle.

Microcontroller C (On center board with the 3 OLED-only gauges)
It does many things:
• reads in data from serial and controls the 3 OLEDs.
• Reads in data from serial on when to illuminate an indicator (ie: traction control icon).
• Reads in data from I2C on when to illuminate an indicator (ie: the auto-stop-start indicator).
• Detects when one of the hard-wired indicators is activated (passively) and then relay that information to the other microcontrollers via I2C.

Microcontroller D:
Interface with the vehicle's CAN network: retrieving data from the car and transmitting data and responses back to the car. Simultaneously analyzing the data and looking for any abnormal readings.

Microcontroller E:
Handles the special purpose interfaces (fuel tank sensor, tone request, liftgate inhibit). Interface with a "auxiliary" CAN network to connect with future peripherals.

MY QUESTIONS

So, looking at that functional diagram, and reading the microcontollers' roles, does it seem to make sense? Is one of the microcontrollers being asked to do too much?

Does the communication scheme between the microcontrollers make sense? The one-to-many serial setup is probably a little odd but It I think it makes sense in this situation. I also don't know which controller should be the Master on the I2C bus.

Any feedback is greatly appreciated! If anyone wants to join in on this with me, or would like some of my files I'm happy to collaborate :slight_smile:

2

Looks like an interesting and ambitious project, and there is no doubt you'll learn a lot about electronics and programming along the way.
I can't help much on vehicle electronics, but critical to this whole project is being able to interface to the cars CAN bus. I any proof of concept you should focus on that to start with and ensure that you can acquire sufficient published information to support this and can receive/transmit all the required information maybe using either special CAN Bus interface chips or even decoding/encoding the signals directly using a microprocessor.

3

Wow, I have to say that is probably the best diagram I've ever seen here. You put so much work into this that I felt compelled to try and absorb some of the project and comment if possible.

At first glance I would say that A and B could be combined, and maybe even C as well. Depending on the type of OLED all the display stuff is little more than turning on/off a few LEDs, and if the OLEDs are intelligent then they just need the occasional (by uC standards) writing of a few bytes.

I've never driven a stepper motor but once again I think that's just the occasional update.

Even if you have to do all these things 10x a second that's still only maybe 100 jobs a second, most micros could do that and spell-check "War and Peace" on the side :slight_smile:

Use a nice fast ARM (like a Teensy) just to be sure, although you may run out of serial/I2C ports. They don't make an Arduino based on the SAMG55 yet, but that would eat this for breakfast.

I see a MUX for the middle OLEDs, what is their interface?

4

6v6gt,

So here's my plan for CAN:

Use the SeeedStudio CAN-BUS Shield for prototyping, then integrate into custom PCB for final product. Here's what the car's CAN network consist's of:

Higher resolution here

And, in my workshop manual, in the section on the module communications network. There's a chart that describes the messages going on over the CAN. Here are all the messages that the instrument cluster is involved in:


Higher resolution here

So obviously I need to do some sniffing around to figure out what the PID for each message is. But I know what I'm looking for :). So this info, plus seeing some other OBD projects other arduino-ers have done leave me to think this shouldn't be too hard.

But when I plug in my CAN shield to the car, it makes things go crazy. The instrument cluster (the factory one installed now) lights up random lights and sometimes the odometer displays "-----". So not sure what's going on there, thought it was the extra terminal resistor on the shield messing things up, but no, removing it made no difference. So it's funny you mention that as being a top priority because at this point it is not cooperating at all. I'm gonna have to post on SeeedStudio and try to get to the bottom of that little issue.

5

Graynomad,

Thank you :slight_smile: graphics design is my home truff so I try to keep the diagrams pretty.

So those OLEDs, they're supposed to all be I2C interface. Which you kind of pointed out a problem because processor C only has one I2C interface and that's already spoken for to be the "inter-microcontroller communications" bus. So pre haps I should switch those middle ones to run on SPI (The OLEDs support multiple protocols)

I originally planned to have A and B combined, but keeping the neopixels and stepper motor in sync was a problem. Especially because if you want smooth, fluid movement of the stepper you have to include things like acceleration/deceleration and having the code bounce back between the neopixels and stepper gave it delays. There's probably an elegant software solution but, I don't mind throwing an extra chip on there.

What are your thoughts on how Serial is being used here, the one-to-many thing? I know serial is usually 2 devices. I did a simple blinking LED trial on my desk here, one serial out split to two other arduinos. Seemed to work fine, but this is split 7 ways :roll_eyes:

6

DCodomo:
What are your thoughts on how Serial is being used here, the one-to-many thing?

That's no problem, "serial" used to really refer to RS-232 and as you say that was usually point-to-point, but that was more a limitation of the 232 technology more than anything I think, because the drivers could not be tri-stated.

You will (presumably) be using something like RS-485 or at least some nice robust buffers as the modules will be very close to each other, either way a multi-drop system is very common, and yours only talks one way so it should be a piece of cake.

I still reckon you can do the steppers and the LEDs with one CPU, BUT, software is way harder than hardware and if you can get it working quicker by adding a $10 CPU then why not. I assume this will not be a product, it's a one-off just for you.

7

To deal with the impact of the CAN Bus shield on the existing instrument cluster, the only thing I can suggest is ensuring that your test rig shares a common ground with the rest of the car's electrical system if you have not already done that.
Otherwise, good luck and keep the information flowing here. I for one will certainly be watching this project with great interest.