JT's Custom Instrument Cluster Thread

[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.

[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]

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]

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]

Hehehe... let the firmware development begin!

[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]

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:

[E30m52b28]

I would be very interested in buying one of these!

[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):

[JehTehsus]

Been a busy weekend so far.

The backplane is totally routed and mechanically all dialed in. This means it is ready to order - I will likely do one final sanity check through it in the next day or two then order the board next week.


Here is the front of the PCB without any gauges in place. This shows the board with the connectors populated for the DTM configuration. There is not a ton to note about this view, other than the rotary pushbutton switch in the roughly-factory position and the LEDs and LCD display.




This is the board showing how the gauges will fit when configured for the DTM style.






This is the board showing the 'classic' configuration - dual large gauges and two small on the sides.





This is the back of the PCB. You can see the factory C1, 2 and 3 connectors in their roughly stock location. There are some important things to note here, though:

• There is no room for the giant waste of space green connector that outputs the speed signal on a single pin. This signal is now output on the AUX IN/OUT connector, which in the above picture is in the bottom left (there is no 3D model for the connector, just the labeled board footprint).
• The ABS light input obviously would not make sense anymore, since there are no bulbs on this cluster and everything is routed digitally. I believe there are also some E30s with a seatbelt light as well, which is done in the same way as the ABS - these are also now required to be run to the AUX IN/OUT connector.
• In total, the AUX connector has:
  • 2 PWM outputs (one of which should be normally used for the instrument cluster speed out signal, the other of which is a spare and can also function as an on/off).
  • 4 On/Off inputs. These can be used to pipe in factory signals like the ABS warning or for other desired inputs.
  • A CAN interface. This provides the option of a digital connection to an aftermarket EMS, such as a mega squirt. Obviously this means you can send a lot of data over the CAN bus - including all the engine information. This could make wiring a swap much easier, just get the two CAN wires from the cluster to the EMS and you probably don't even need to route anything else (although this will depend on the engine computer).
• Beside the AUX connector, there is an AUX POWER connector. This can optionally be wired with 4 ground wires and 4 power wires - this may or may not be required, but I built it into the prototype because the cluster is theoretically capable of roughly 40W of LED light output at once, spread across approximately 70 1W LEDs (i.e. a metric fuckton of light output). I am not convinced the factory wiring is sized for this, so the AUX POWER connector can optionally be used to allow for brighter lighting if deemed necessary. The only time I can imagine this possibly being required is a sunny track day.
• Up on the top left hand side of the above image is the ANALOG INPUT connector. This is just what it sounds like - 8 analog inputs you can use for whatever. They are also capable of acting as on/off inputs if desired, but note that they are configured for 5V operation. These could be used for things like exterior temperature or an ambient light sensor for automatic gauge dimming.
• The large black bits are power supplies and filtering, nothing exciting. There is also a relay that will be used to keep the cluster alive for a few seconds when shutting off the car. This ensures things like the odometer are always as accurate as is feasible, and makes the possibility of the processor having to perform error recover on startup much, much lower since it can do a controlled shutdown.
• You can also see the GPS on the far left hand side.

Anyway, once these are on order the next big push is for the mechanical enclosure design.

[IncogutheIII]

Simply amazing! Sub'd!

[powaz]

badass.

[moatilliatta]

Would be cool later on down the road to talk BMW CAN for M/S54 / N5X swap people for coolant temp and check engine, Maybe even configure a communications link for an AC input. Another option that would be neat would be a GPS Speed.

[JehTehsus]

Would be cool later on down the road to talk BMW CAN for M/S54 / N5X swap people for coolant temp and check engine, Maybe even configure a communications link for an AC input. Another option that would be neat would be a GPS Speed.

In terms of CAN capability, the chip selected is fairly flexible - I have an up to 1Mbit CAN transceiver on the frontend right now, and while I don't know a ton about the M54 I would not be surprised if it is nearly plug-in and go in terms of the physical layer. That just leaves actually programming in the support for the CAN messages, which with the right test setup (i.e. someone with said engine and ECU) would not be a big deal to do. Strictly speaking there are two more separate CAN bus ports on the main processor I am not using - with relatively little board work they could be brought out to physical layer transceivers and the cluster could have support for 3 CAN buses. At this point in time I am not going that route though, since this is really targeting E30's which (may) have stock, swapped in or heavily modified engines, and to the best of my knowledge even the newer motor control systems would only need the cluster on a single bus. I am not sure what you mean regarding AC input?

The GPS chip integrated onto the main backplane board has full support for up to 30Hz updates, which includes speed and 3 axis acceleration (as well as dead reckoning functionality, which I have actually tested and found to be remarkably good. At least during normal driving, not sure about motorsports though). There is a fair bit of code to write to get that all integrated, but I am familiar with the part and don't expect any big issues. Once that data is available it can be used like any other data source in the system, so driving the speedometer is certainly not an issue.

[JehTehsus]

Little bit of an update after this weekend:

• Cleaned up a final few things on the main backplane board after an extensive review, some of which would have been annoying to work around, so that is good.
• Not actually ordering boards yet (they won't even be started anyway until after chinese new year), but I have got the PCBs quoted and pricing looks good, even for the big back plane.
• Initial run will be enough for 5 clusters. I will build one up for the initial development/programming and testing stage, then once I am happy with it probably hand build the other 4 (assuming no major issues on the PCBs) and seed those out to a few testers to try and catch any big kinks. At some point I will throw together a few auxiliary very simple PCBs for mounting as child gauges inside the larger 104mm gauges, these are at this time planned as a 4 piece 7-segment display to act as a speedo on the DTM configuration and a secondary gauge to act as a fuel/econometer equivalent (or whatever it is configured as, but the intent is it will look similar) on the classic configuration.

Also been working on the mechanical design a bit for the enclosures, still nothing to show off but it is slowly moving. These will be 3d printed; I still have a fair bit of work to do playing with materials (never mind the actual design) but it will likely end up being either ABS or PETG, possibly CF reinforced (especially in the case of ABS, as it may be tricky to handle shrinkage on the relatively large cluster piece).
In terms of actual pieces, it will likely be similar to the factory cluster, essentially a large front piece with gauge cutouts, and either one or more backing translucent pieces that will provide 'light pipes' between the LEDs and front of the cluster, where whatever lettering or icons can be applied either directly during the printing process (dual extrusion of translucent and opaque material) or afterwards through silk-screening. The gauges themselves should fit a standard dial faceplate just fine - for which there are already lots of options for customization. This leaves the transparent plastic cover - while it may be possible to print a transparent cover it might also prove too finicky for something so large, so a flat piece may need to be cut and applied here.
The nicest thing about printing an entirely custom enclosure is it should drop right into the factory mounting position, which really means the only 'modification' required on the vehicle should be the unplugging of the ABS light bulb for example, especially if I can get it to work with simple soldered on 0.1" header pins.