JT's Custom Instrument Cluster Thread

[JehTehsus]

I would be very interested in buying one of these!

Awesome to hear! There is still a number of months of work left though, just so everyone is aware (I do work full time as well, so this kind of moves forward when I can get to it).

May as well use this as an excuse to pop out a few brief updates:

• Backplane layout is basically done, although I do think I am going to slightly shift indicator LEDs on the bottom down a bit more and then lower the inner small gauges on the DTM configuration a touch - they are quite close to the edge and another half a mm will provide a good safe margin for the cluster enclosure. Everything has actually been aligned at this point, setup should be entirely symmetrical.
• I have added the pushbutton/dial control (a rotary encoder/switch combination). This will stick through the faceplate in the roughly factory location and will allow for the usual, expected functions. Essentially it will let you clear the trip odometer, as well as flip between display modes on the lower LCD display. Obviously it is really just a generic set of inputs, so no reason not to have some customizability there as well, gives me more things to test ;).
• I have started roughing out the actual mechanicals in freeCAD, which has been a learning process, but I can happily say I feel I am quickly becoming more competent. Overall, the idea for the mechanicals is a back plate/piece, two front plate/shroud pieces (one for classic, one for DTM configuration) and then individual gauge faceplates. For prototyping, these will all be 3D printed, and for low volume manufacturing the shroud and and back piece will be 3D printed and the gauge faceplates will either be the same or, more probably, laser cut and/or silkscreened because it will look much better. For prototyping, I will just use ABS, but for actual production we will see what makes the most sense in terms of cost and reliability/quality.

This is what it looks like with all connectors and LEDs populated. Obviously the blue connectors interfere - only one pair will be populated on the DTM/Classic configurations. As well, some LEDs will not be in place on certain versions, as they will be occluded by the large gauges.



Shown with the classic configuration - I may move the dials slightly further apart, but regardless the overall layout is fairly close to factory.



The DTM configuration - again, the smaller inner gauges will likely move down ~0.5-1mm.



The rear of the cluster - nothing really exciting, except factory connectors in a quite-close-to-factory position (note - no speedo output for cruise yet, or ABS/belt light inputs). I also have a bigass inductor on there right now, which hopefully helps keep electrical noise down. You can also seem some other parts floating off in the ether, these are all just minor bits I have not roughed in on the layout yet - mostly things like input filtering.



And here is a quick snapshot of some rough mechanicals I have been experimenting with - these are not even remotely final, the actual version to be produced won't be done until the gauge position is totally finalized. The faceplates will actually extend all the way down to the PCB (and as shown here are levitating a bit too far up):

[E30m52b28]

I would be very interested in buying one of these!

[JehTehsus]

So, spent some time last night roughing out the mechanicals of the the backplane board, and I have good news - it looks like I should be able to combine the two types of configurations onto the same board (different connectors will have to be populated).

I did up some quick renders today - obviously there is still lots to be done on the backplane board, including actually fine tuning mechanicals (nothing in these renders is actually aligned, it is all approximate position) but things are still slowly creeping along.

Some notes: LED strings will likely move down just a touch, and the LCD display on the bottom will actually be mounted on standoffs so that it sits roughly at the level where the gauge faceplates will be (which is a bit above the motors, leaving room for a daughter board). Note that I am not showing any daughter boards plugged into the main boards either at this point. A few LEDs are missing as well, like for the factory turn signals

Other than the factory connectors, board connectors, LEDs and some chonky power supply bits there are no other actual parts shown on the board yet. I have attached two renders of each configuration - the one approximating the 'classic' look and the one approximating the DTM look.

Classic:



DTM:

[JehTehsus]

Quick update on where I got to last night/on the weekend:

Main board 'production' prototype revision is done layout and routing, just in final stages of tweaking and review. Won't order until backplane is mostly design complete in the event anything needs to shuffle around a bit.

I think after a lot of deliberation I am going to switch from the TMS MCU to the RM equivalent - what this means is changing to a processor in the sister family (basically the same chip, probably the same die in fact with a different configuration). Anyway, not a big deal, just more soldering for me. Should have the new chip in hand before the weekend.

Here are some renders of the updated primary control board:




You will likely notice the much beefier connectors. An EE friend of mine suggested them and I think they are the right approach. Note that this shows all the connectors populated - in reality the 'slave' version of this board will have only the two small grey ones on the back populated, where as the master/main controller will have the two large grey back connectors populated and the front black connector. The smaller connectors are used for the small, 54mm gauge and the optional secondary LCD/gauge that mounts inside the large 104mm gauge.

[JehTehsus]

Hehehe... let the firmware development begin!

[JehTehsus]

So, small update today:

The main proto board is a 'little bit' assembled - the MCU is on, along with some other key bits. Still a few things to do, as well as waiting on some other parts that are taking a bit longer to get in hand than I had hoped.

That said, the design portion is going well. I have at this point finalized the board-to-board interface specification, which is a fancy way of saying I know what pins are used for what on the main connectors.

I have also managed to go through and capture what I believe to be all the relevant E30 signals and map them to the factory connectors.

There is still a bit of design work to do - I will definitely need to do a finalized version of the main control board, which will eat some time, as well as finish the E30 backplane PCB. The backplane PCB is the furthest away - I am still working on the schematic (a snapshot is below) and layout at this point is just roughed out connector positions. There may have to be two variants of the board, which I would rather avoid, but it is a bit early to tell (specifically these variants will be for a single central tach vs a classic layout. I would like to support both on one PCB, just populate different connectors, to reduce cost). The final big bit is ironing out all the kinks in the mechanicals, as well, which will take me a while.

The small 54mm gauge design is nearly finalized, and I will likely do a proto run sooner than expected since I managed to get it all on a two layer PCB, and it is quite cheap. I attached some renders below.

At this point the picture is growing much more complete, and I can speak more to what the final feature set and options are going to be. Here is a breakdown:

• Two configurations, either a central DTM style 104mm tach with 6 smaller 54mm gauges or a 'classic' dual 104mm gauge setup with 2 54mm gauges.
• Factory connector support - this will 'plug right in', no cutting/rewiring etc, with the exception of the ABS/brake warning lights (these are actually bulbs on little two wire cables that plug into the cluster housing, but not the cluster). I am trying to figure out if I can get a 'bulb socket' type connection that you could plug the bulb wires into, but this is proving difficult, so it may be that for those they will need to be modified.
• Fully configurable RGB lighting - I have evolved the design to use *solely* 1 watt (i.e. fucking bright) multicolor LEDs. This means that all the lighting, from gauge backlighting to indicator 'lamps' can be configured (note: strictly speaking power to all the LEDs will be limited in software. There will be roughly ~70W of LEDs on a cluster, which if all on at max brightness will temporarily blind you, but also means multiple power supplies are required which is $$$ and essentially wasted since I understand most people can't drive well with a miniature sun behind their steering wheel).
• Independent lighting strings with failure detection/fault scanning - Lighting is divided up into various 'strings' - the idea here is if something fails it doesn't necessarily darken the entire cluster. Specifically, every gauge is it's own region, and the backplane has separate regions for general indicators, turn signals etc. If an LED module 'dies' it will take out everything after it in a string. This will also be detectable via software via a loopback mechanism, which will allow for asserting separate error outputs. To be clear, I don't really expect a bunch of random LED failures, but they will be used for critical indicators, and I want the driver to be able to know the second one of those indicators is no longer working.
• Excessively fast response to fault inputs. The firmware (and hardware) is being designed to support a completed notification output (either via LED or another output) within the millisecond that the fault value is received. Realistically there will be some lag due to filtering of the inputs (you don't want false notifications), but it will be *quick*.
• The available indicators are as follows:
  • 7 RGB indicators on the left hand side of the dash (think factory cluster foglights location)
  • 7 RGB indicators on the right hand side of the dash (PARK BRAKE, oil pressure, etc)
  • 4 general indicators. In the factory configuration, these correspond to the turn signals, high beams and check light. In the DTM configuration, these will be in the four corners around the central tach.
  • Ring indicators on the large gauges, a total of 16 RGB LEDs each. These provide the actual gauge backlighting, as well as fancy features like letting you know the ideal engine speed for various gears on an up/down shift based on current vehicle speed. Gotta hit those perfect rev matches.
  • 4 RGB LEDs per 54mm gauge. These are, again, for backlighting, but they could also optionally be flashed or color changed to indicate various states (i.e. when the boost is gonna hit). Obviously with only 4 LEDs you won't get the kind of same fine-grained resolution as the large gauges.
  • The large 104mm gauges also have support for a 'child' gauge - this can be either another motor/needle pointer (think factory econometer) or a different type of instrument, such as the 4 red seven segment speedo indicated in the early design for the DTM style cluster or a rough emulation of the factory odometer. Realistically this is a small, simple PCB (similar to the 54mm gauge) and could also support a fancier, small LCD display or something. Generally these are being avoided at the moment though, as I can only easily get my hands on simple character displays that are rated to -40C, and I do live in Canada. I don't want the cluster to fail on some hypothetical, polar winter rally session.
• These indicators are full RGB with controllable brightness - I am designing the software so that they can be assigned any sort of output. Generally brightness will not be directly controllable via the planned 'user interface' (due to power limitations), but the cluster will be dimmable via the factory input or another source, and I will likely allow for a limited number of signals to prioritize 'super bright mode', where a handful of LEDs can be maxed out at a time to really get your attention on low oil pressure or something.
• All factory instrument cluster inputs are available and configurable. These signals can be assigned to any sort of output, or none at all. They include:
  • Turn signals
  • Fog lights
  • Headlights/lights
  • Highbeams
  • Light brightness (i.e. twisting the headlight knob)
  • Parking brake
  • Engine Temperature
  • Engine Speed (This is adjustable, it will be a 'quick' software setting to configure the engine speed, no more coding plugs)
  • Brake fluid warning
  • Brake pad sensors
  • Fuel level and fuel low switch
  • Oil pressure switch
  • Vehicle speed (also 'adjustable', i.e. if you have bigger or smaller wheels changing scaling will be trivial)
  • Fuel rate input (with configurable rescaling for the OBC)
  • Factory charging circuit and charge light
  • Odometer reset button.
• Additional, 'custom' inputs are available as well. These custom inputs will be on a separate connector (one for which I will make sure pins, part numbers etc. are easily accessible so someone can readily build their own). All of these inputs will be mappable to various functions as well - this includes things like having an oil temp gauge, or having your oil pressure light start out blue and move to green depending on oil temp before going out, and only turning red when there is an issue (just an example, this obviously requires a separate oil temperature sensor). These inputs will include:
  • 8 analog inputs (0-5V). Generic analog inputs. Some of these I may actually configure so that you can 'drop in' a VDO pressure/temperature sender. These can be setup to read 'on' or 'off' signals as well, although the general I/Os are better suited to that.
  • A number of general purpose on/off signals, including at least one higher frequency pulse input. There won't be a ton of these (most are eaten up by factory functionality), but there will be a few. I will have an exact number once I finalize a little more of the backplane.
  • A CAN bus input. If you are running an aftermarket EMS then you will likely have a CAN bus available. The idea here is various sensors could be hooked up to the bus and read by the cluster, and used in the same manner as the other sensors.
• There will be a separate, optional 'extra' power connector - the cluster will require higher power levels than the factory one, especially to get to brighter levels. I don't want to risk factory wiring or connectors melting, so a separate optional connector is in place that can be connected to a (fused) battery connection.
• Configurable fuel rate output scaling: Long story short, the E30 MCU feeds an 'injector on time' pulse into the cluster that is used for fuel gauge rate calculations, and also sent out from there to the OBC. This gets screwy with any different injector sizes. If for some reason you run this cluster and also have different sized injectors, I plan on supporting outputting a modified fuel rate signal that is 'regenerated' from fuel rate information, either received over a pulsed wired, analog input, or CAN, which will be made available to the OBC so the values are correct.
• A 2 line alphanumeric display. This will sit where the factory maintenance indicator currently lives, and is a bit bigger. This display can be used as an odometer, for example, or to print dirty messages when your wife isn't around (note - this feature requires a separate wife presence detection sensor, which is not included).
• Provisions are in place to support an ambient light sensor. It is uncertain if this will actually make it into the final design - the idea is you plug in the optional sensor, it consumes one of the 8 additional analog inputs, and it can automatically adjust cluster brightness within a set range.
• I managed to fit a micro SD card into the design. This can be used to log data, believe it or not. Note that I can't guarantee the SD card will work down to -40C, so if you are in freak polar rally conditions please warm up your interior before attempting to log data.
• GPS and accelerometer integration. I can optionally add a GPS module to the board (you will need to hook up an antenna mounted somewhere). These modern modules do more than just rough position though - the one I am using (and have worked with in the past) provides full dead-reckoning as well as ~30Hz accelerometer data in the X, Y and Z directions. This can all be logged alongside position information.
• Provisions are in place for one of two control/configuration interfaces - either a standard serial port connection in the 115200+ baud range, or a USB connection. These are used to setup the cluster, and if available, download logged data. I will likely not end up making a GUI - configuration will be done via a command-line type interface. I will, however, support saving and loading configurations which could theoretically be edited in an external program.
• Gauges (54mm) and 104mm 'child' boards will be swappable. I.E., if you have a coolant gauge you could swap it over the other side by just undoing a couple of screws and popping it into another 54mm gauge connector. The gauges have unique ID chips on them that store configuration information - so you literally will not have to do anything else if you decide you want your engine temp and fuel gauges swapped for the day. Remember that the gauges are also programmable - you can always just swap the faceplate on your coolant gauge to read boost pressure and adjust the firmware accordingly, for example.

In terms of availability and costs, I will be offering a few options. Since I did actually recently start a company (strictly speaking the company offers embedded systems design and consultation services, you may be able to tell from the thread that this is my core skillset, but it will also offer this cluster) I will be doing build to order options if people really want. These won't be cheap, and since they will be build to order I will do all the setup and assembly etc. Obviously I will offer full support, feature additions/customization and so on for these clusters. These really aren't meant to be a mass market product though, and costs here will vary depending on the final configuration. Disclaimer: Race use only, not for public roads, yadda yadda yadda.

The second option is a 'build it yourself' kit, sorta megasquirt style. I will have unconfigured main control boards built up and available (this is the one board you probably don't want to build yourself, unless you have a pick and place) and will offer the other components as bare PCBs with assembly instructions. I probably won't provide actual full component kits because you can save a fair bit of money during personal assembly by not using AEC qualified parts everywhere (much of the time this is about supply chain as much as it is about actual part ratings - if my company is building something for someone to use I want to ensure it is reliable, if you can find a generic replacement and save 30 cents on it, it will probably be fine), as well as potentially not populating some things or using different drop in replacements, which I will specify. Obviously I will have BOMs available with ordering information for digikey, etc. I don't have final costing information at the moment, but this will be much cheaper - I don't really care if I don't make a significant margin on these because I am not going to pick up the phone at 3 am if you are having an issue. Obviously I won't leave people totally high and dry if they are having problems, but the support I provide will be at a fellow enthusiast level. In all, I am really aiming for costs here for a fully built setup (i.e. you buy parts in low volumes and pay more, and build it by hand with the soldering iron you already have) to come in well under the $800 US/1000 CAD mark. It will likely be quite feasible to achieve that, and even a fair bit lower, but again this depends on how it is all setup (i.e. maybe you don't want a GPS and SD card logging (can always solder it in later!), so you save $150).

Anyway, that is roughly where the project is at. Some eye candy below:




Don't go to my website yet, it is still under construction...

Man I love spaghetti

[JehTehsus]

Well, good news, proto PCBs arrived ahead of schedule.

I will be ordering the parts for the board this weekend. Only issue I have found thus far (naturally) after ordering boards is one of the diode footprints is wrong... which figures, but should still be workable. Hopefully I can get the power supply section working without too many issues, but if I can't my fallback plan is just a few extra monolithic DCDCs

Here are the bare PCBs:

[JehTehsus]

Boring update, but the revision 0.1 proto boards (for the central, most complicated PCB, the main gauge dial/powersupply/controller) is ordered. Hopefully see them in about a month and have the engineering prototype built up a few days after that.

[JehTehsus]

Thanks!

Slowly getting there (found some minor issues I need to fix, should have them resolved in the next couple weeks) but it is still moving along.

[eternal24k]

this is really cool

[JehTehsus]

So, a bit of an update here.

I spent some time reworking the design, primarily due to cost and fabrication considerations. The big issue with large PCBs is they get expensive fast, and the big issue with my instrument cluster PCB was that it was large. And primarily empty space. So to that end, I decided to split the project into multiple boards. These include:

• A relatively high density, primary PCB that acts as the brains of the operation, in addition to providing power and all that good stuff. This is the primary dial gauge.
• A breakout board that acts essentially as a backplane PCB with larger connectors and possibly a small display mounted to it. This should be imagined as a rectangular PCB running along the bottom of the cluster, that includes E30 factory connectors and the LCD display.
• Simple PCBs that can plug into the backplane, either directly or via wired connectors, which act as other individual gauges.

The big advantages of the above are flexibility and reduced cost (like a third, if not less, for the bare board. Out of house assembly costs drop dramatically as well, and the remaining cost to assemble a simpler, slightly larger backplane board is still better than one massive board with a high density area, primarily due to components all being on the same side) - different gauge configurations are relatively straightforward to do, and at most require re-routing the relatively simple backplane PCB. And yes, this supports either a mounting orientation identical to the factory or (my personal preference) a DTM style sideways tach orientation.

Some other minor notes, I broke out one of the stepper control signal groups to the 20 pin header for the 7-segment LCD board. This means that it should be possible to actually mount a separate stepper motor there and drive a gauge, similar to the mileage indicator on an e46 cluster, for example. This PCB shows the 20 pin as populated, in the end those will be holes and the daughterboard will mount almost to the main PCB.

Anyway, I have actually finished off the primary controller, which is where the vast majority of the work still needs to be done software side. I am currently planning to do a final quick review this coming weekend, then getting some PCBs manufactured starting next week. This will let me get moving on the firmware side of things, as well as debugging all the complicated hardware bits, while bringing up the base board (which includes the logic necessary to interface with the E30 signals) in parallel.

Still not very exciting, but here is some more renders:




I need to do a bit more cosmetic cleanup on the schematic, but if there is interest I can throw that up too.

[JehTehsus]

Is it too late to add a gear display?

No - the only issue is where I would put it (my current intention was to flash gear in speedo on change). I have some free bandwidth on the digital communication bus that is used for the LCD at the bottom, as well as another free bus that is doing nothing - this could easily be used to drive a secondary display.

I think the biggest challenge would be mechanically where it needs to go. If I was going to add a display for current gear and keep everything else I would probably lean towards a 1 or 2 digit 7-segment similar to the speedo (which, to be clear, can be re-purposed to either permanently show current gear or flash the current gear on change). As for mounting, possibly on the other side of the tach, although that would feel like it is getting busy. Alternatively it would be easy to simply not populate one of the smaller gauges and replace with a face-plate that mounts a display of some sort. Mechanically you could pick off the mounting holes for the stepper motor, and bring data/power to it by wiring off one of the spare bus connectors. This is something I can give more thought to if there is interest.

[mutty]

Is it too late to add a gear display?

[JehTehsus]

Need to take a break, so I figured I would throw up a few more renders quick and a brief status update.

Mechanicals are essentially done on the PCB at this point, maybe hole positions will need to be tweaked but currently it *should* fit into the stock cluster PCB position. Review of some of the power stuff is ongoing, hopefully my friend has that wrapped up in the next couple weeks. A few other things need some cleanup, and I will probably convert a couple of the LEDs in D42/41/40/39 positions to a couple push buttons or something for setting trip/odo/race timer whatever, but overall I am closing in on ordering the first prototype PCB run.

More eye candy below:

[mutty]

Awesome!