JT's Custom Instrument Cluster Thread

[bmwman91]

Ha damn, 100+ point mesh correction, fancy stuff. I just do a 3 point manual adjustment on my Makerbot clone lol. It's a heck of a lot smaller, so I guess that much makes it easier.

Bubbles under the film sucks. No luck poking through with an x-acto knife to deflate them?

[JehTehsus]

Aah, yeah leveling can be a pain. I printed a clip-on bracket that holds a dial indicator and slides on the linear shafts, so I do it that way. If the build plate itself is not very flat, or warps badly when heated due to thermal expansion mismatch between it, whatever it mounts to and the (guessing) FR4 resistive heater board, then printing the raft can help to "absorb" the warp. Sadly, that means printing a raft, and I hate them lol. I don't need one with PLA, but ABS seems to demand it more often than not, and aside from material waste it means that the bottom face usually has crap cosmetics.

Anyway, I do my leveling after pre-heating everything and sitting at operating temperature for ~15 minutes as I have found that the nozzle gap to the build plate changes enough to make problems if I level and gap it when cold.

The plate isn't too bad, the modix runs a 100 point (by default, I may bump it up to 400) compensation mesh on a duet 2 which after a few passed I managed to get dialed in quite well and it made a huge difference. It can't compensate very well for a couple of air bubbles I have under the sheet though, and my best attempts at removing them have been less than perfect. Overall I have only been printing with it since last week (first go with a 3d printer too) so there is still some learning on my end, but I feel I am making steady progress. I have only ever tried dialing in the offsets and leveling with everything being heated overnight and I noticed a pretty big difference between the offset adjustment during first setup and once everything had warmed up.

[bmwman91]

Aah, yeah leveling can be a pain. I printed a clip-on bracket that holds a dial indicator and slides on the linear shafts, so I do it that way. If the build plate itself is not very flat, or warps badly when heated due to thermal expansion mismatch between it, whatever it mounts to and the (guessing) FR4 resistive heater board, then printing the raft can help to "absorb" the warp. Sadly, that means printing a raft, and I hate them lol. I don't need one with PLA, but ABS seems to demand it more often than not, and aside from material waste it means that the bottom face usually has crap cosmetics.

Anyway, I do my leveling after pre-heating everything and sitting at operating temperature for ~15 minutes as I have found that the nozzle gap to the build plate changes enough to make problems if I level and gap it when cold.

[JehTehsus]

Nice progress there. Yeah, no matter how careful you think you are being, it's almost inevitable that you'll mirror a through hole footprint at some point lol.

ABS is a bit of a pain, I have found. My printer is a lot smaller and has walls enclosing it, and that seems to help a LOT with warping. The heated build platform is not, on its own, quite enough, but being able to trap a bunch of heat in there seems to improve things. Maybe you could try a tarp or something quick & dirty like that to see if keeping the interior of the printer warm would help. Thankfully, I mostly run PLA which actually requires the printer to be "wide open", but anything that goes anywhere near the firewall or under the hood definitely needs to be ABS.

Yeah, ABS has it's challenges for sure. I actually do have an enclosure, and the bed heater is as high as it will go (PEI on aluminium @~110-115C). I think my challenges are more so related to bed leveling - the large bed definitely isn't perfect, and what is less perfect is my application of the PEI sheet. I may have to drop on a piece of bs glass, but for now for prototyping it is not a big issue.

[bmwman91]

Nice progress there. Yeah, no matter how careful you think you are being, it's almost inevitable that you'll mirror a through hole footprint at some point lol.

ABS is a bit of a pain, I have found. My printer is a lot smaller and has walls enclosing it, and that seems to help a LOT with warping. The heated build platform is not, on its own, quite enough, but being able to trap a bunch of heat in there seems to improve things. Maybe you could try a tarp or something quick & dirty like that to see if keeping the interior of the printer warm would help. Thankfully, I mostly run PLA which actually requires the printer to be "wide open", but anything that goes anywhere near the firewall or under the hood definitely needs to be ABS.

[JehTehsus]

In terms of progress, things are moving along reasonably well.

I did encounter some issues with the connector pinout... naturally I spent much more time reviewing the mechanical board stackup than verifying all the electrical signals were going to the right places. Basically I flipped the signals on the main connectors, which means I will need to do at least one more version of the large backing board before the setup is vehicle ready. Definitely annoyed about this, but it just means I need to run a bunch of jumper wires for the prototype so not really a huge deal; I can still get everything working on the bench (and mounting the main control board on wires is actually good, because normally I cannot access most of it for testing with the scope).

In other bad news, I also shorted one of the MCUs after getting it all up and running. There are a grand total of 2 places on the board you can easily short the 5V power rail into the 3.3V processor I/O, I ham fistedly probed one of them and did exactly that. "R&D" everybody. Not the end of the world, but annoying since it is the worst part to change out.

In good news, the time spent verifying the mechanical stackup paid off! I have also been playing a bunch with the 3d printer and getting it dialed in for ABS. Still some warping and other minor issues, but it has only been a few days and I feel I am making steady progress in terms of quality, overall I am quite optimistic.

Here is a mechincal mockup of the PCB stackup. It won't actually run like this because I need to flip the connector signals, but it does fit together and mechanically no significant changes need to be made (note: there are no standoffs in place at the moment, so things are a touch loose, but it gives a good idea of how it will all go together):



This also shows off how the 'econometer' will be accomplished for the classic variant. The DTM variant will have the option to install a small display in this position on the large dial as well (I suppose I can do the same with the classic variant as well, if someone wanted a display instead of a gauge there for some reason):



You can see the (literally very first) proto run of the enclosure wrapped around the board here:





This is being printed in ABS, and as I noted there is some slight warping around the edges where they are curving back in, which obviously isn't what I want and will hopefully be eliminated soon.

So overall, things are moving along. Faster than usual now as well since my last contract ended rather prematurely (the one problem with startups I have found is they all too often run into money issues...) and I have a lot more time to pour into this. I am looking forward to making some really significant progress on the project before diving into more actual work.

[JehTehsus]

Short little update today.

The PCBs have arrived! Almost done finalizing the BOM for a prototype run; hopefully order those tomorrow and have them in on Monday. It is the ladies birthday weekend this weekend, so I can't go near any of my projects anyway.

Also, the 3d printer is coming together. I suspect this will be actually ready to print early next week as well, so once I run through all the calibration I can get started on enclosures.

The PCBs:


The printer:

[JehTehsus]

Short update this morning, mostly just to show firmware is slowly coming along. As I mentioned previously, I have been focusing mostly on low level/backend (i.e. all the boring stuff that makes a project tick) stuff that really does not seem to do anything, except make the rest of development much, much easier. Anyway, yesterday I decided to tackle some low hanging fruit, and implemented the low level LED driver along with some testing:





Even in the second picture (which is also a different time of day) the LEDs are not at max brightness. Currently the colours don't mean anything, the first picture I was fixing some of the control protocol and had an interesting unintentional purple color, the second picture shows a random ring of RGB colors I generated after everything was working.

It can be difficult to gauge how bright they are from pictures, but for reference it starts to become uncomfortable to look at, say, blue at 50% brightness (and the brightness scale is not linear), never mind easy to see even with the sun in your eyes. I watched the dial beside me on 87% brightness doing the random color cycle, and I have been blinking afterimages from my eyes for the past 60 seconds. When all three colours are active the things really are blinding. My tiny little supply I am using at the moment actually starts to brown out around 80-85% so I can't really bring the brightness above that (this is not the production power supply, just what I am using for the test board). Point is, even with a cover that diffuses a lot of the light, they are going to be more than bright enough IMO for both casual evening cruising and an oil pressure warning on a sunny track day.

The other big item of interest with the LEDs is update speed. My driving motivation for the design (of the LEDs) is that they need to be fast enough to update that, even pumped full of adrenaline on a race track, things seem smooth. There are a few factors that play into this, but the biggest ones are the actual LED update time - i.e. if you think of the LED as a pixel, how long does it take to change from one commanded color/brightness to the next - and the processor control and communication time with the LEDs. These LEDs are quite common - built on the APA102 - and the update rate of the individual LED is 400Hz as per the datasheet. 400Hz is quite fast, I don't think this will be a limiting factor in the production design. This leaves the other half of the equation - i.e. how fast can the processor actually control and communicate with the LEDs? Now, of course, the CPU is going to be doing lots of things - measuring vehicle inputs, filtering and scaling these values, applying user configured transformations and then updating outputs, which consists of LEDs, PWMs, and stepper gauge controls. So the LEDs are only a small part of the equation. It is too early to say how long all of the LED update operations are going to take - I need to write the code that transforms the inputs for each string of LEDs to produce meaningful information, like current gear positions on the tach and oil pressure warnings. That said, another part is how long it takes the hardware to send all the data out to a string - this I have measured. In this case, on the test bench here with the prototype board, fully updating 16 LEDs takes approximately 100 microseconds. If I reduce the clock speed by a factor of ten (something I may do to reduce electrical noise) then the time climbs to ~650 microseconds. So long story short, in terms of hardware limitations, updating a full cluster worth of LEDs (~72) should take no more than 3 milliseconds, and since most of this is handled by a buffered output port, the actual processor time involved is on the order of tens of microseconds, with it going off to do something else while it waits for the message it has queued up to actually make it to the LEDs.

Overall I am fairly happy with things. I do need to add some termination resistors to the design to reduce ringing, especially at the higher clock speeds, and I may add a copper pour around the outer edge of the board to improve heat-sinking for the LEDs (heat is definitely a non issue on the bench, even running them as hard as I can they do not get more than slightly warm to the touch. But the actual operation of them in the car will be warmer - so more heatsinking is good). Once I get the next stage of prototypes built up I can also test the logic that controls LED selection, as well as proper tests across the entire brightness and power range.

[JehTehsus]

Progress continues!

Been a fair bit of work going into the firmware on the first batch of proto-boards lately, unfortunately nothing really to show as it is all groundwork type stuff and no fancy mechanical action or anything at this point. I probably won't actually show off the code running until I get the second 'form fit function' prototype boards built up and operating; at that point things are much closer to the final product (hopefully) and there will be lots of goodness to show off.

In other news, mechanical design has been moving along a lot in the last few days. I actually have a large format 3d printer I am going to be setting up very soon here (the kit is behind where I am sitting right now) that will be used to fabricate the majority of the enclosure. I expect printer setup and calibration to take around a week, after which I will start printing draft models.

Speaking of draft models... here we go:



There are obviously still some aspects missing - primarily dials and the front cover window (as well as the car chassis mounting points), but the general shape of things can certainly be seen. As well, the cosmetic tidbits (like smoothing/chamfering various edges and whatnot) are not in the model at this point, these are things best left until the very end.

I am going to be doing all the initial mechanical prototyping with the 'classic' layout. There are a number of things that will need to be fine-tuned by doing a few test prints, which include things like hole sizes and mechanical clearance between the printed assemblies. The enclosure is mostly going to be flame retardant ABS; but the light pipes and (if I can get it to work) window cover may well be something like polycarbonate. ABS isn't always the best for dimensional stability, especially larger prints, so tuning will definitely be necessary.

The enclosure itself has been broken down into a few separate parts that will all be printed individually. Taking some time to optimize this for the FDM process yields significant dividends in saved plastic (cheap) and printing time (never enough). You can see these parts in the following snapshots:



This inside view showcases the lightpipes (in green), the brackets/skirts between pipes to both hold them in place and to prevent excessive light leakage between LEDs (in dark grey) and the dial control knob (red).



The rear of the enclosure is two pieces - the large yellow main backing piece here which essentially just covers the circuit board and has connector cutouts, and a brownish piece that acts as a cover for the relatively large power supply filtering front end.

Here is a snapshot of the front cover piece in the slicer program, where it will be printed from:




Overall I hope to have the next draft of boards in relatively soon. There is still a fair bit of code to write, and definitely at least a few more days of drafting time in the enclosure (especially once the first few are built to validate clearances and everything), but things are gradually progressing towards a road*-worthy prototype.

*not public road worthy of course; this is not legal for street use (at least in Canada).

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

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

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

[powaz]

badass.

[IncogutheIII]

Simply amazing! Sub'd!

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