Mustang Electronics Project - Arduino Controlled... well, electronics.

[digitalsolo]

So, fun stuff, I've been working on programming now that I have all of the beta hardware in front of me.   Here's what I've got so far.

1.  My input signal input mock up works properly.   I can run a switch to ground (I plan to ground switch all controls, so everything runs as limited load as possible) and it triggers inputs properly.
2.  I have a scaleable interrupt based switch status tracker.   I plan to scale to 25-30 inputs.
3.  I CAN SEND DATA OVER CANBUS.   w00t!   I am encoding button presses, tagging with a CAN ID that is configurable (I'm using "mod1" "mod2" and "mod3" identifiers to mark each downstream "slave").    You can use as many slave modules as you like, really.
4.  The data is FAST.   10ms between CAN transmit frames is doable, easily.   I am keeping code on the input controller as light as possible and will use the slaves to do the more complicated processing, that way there is no delay in different switch inputs.
5.  Slave inputs can filter messages based on ID, then track status of the data payload, so it only listens to messages sent to it.   You configure a module with a name/number (like mod1, mod2, etc.) and it will only listen to frames destined to it.   You configure which inputs go to which slave in the input (master) controller, so basically, you send buttons 1-4 to mod1, 5-12 to mod 2, etc., then each module ignores other messages.   You can send one button to more than one module, or make two modules "twins" pretty easily if you like, as well.

All in all I'm super stoked with progress.   Next is testing the filtering more, and running 2-3 slave modules at once, and making sure they can fire relays properly.   Then I need to design a PCB for the input controller (and get an Arduino with more inputs) and finally write all of the subroutines for everything so that the buttons actually... do... things.   The nice part of breaking up the modules is that each one only has to be responsible for it's local functions, which lowers load in the system as a whole.

[digitalsolo]

A bit more on this;  I was looking at a few things on my lunch break and I found that sufficient input count gets fussy once you get to lots of inputs, and I want lots of inputs... so.

I'm going to modify the design to use a pair of input demuxers;  basically I'll be able to send 32 channels of input signals (think 32 switches).  I'll built a bank of opto-couplers in front of those to filter signal and should be good to go.   I may run another 8 channels of inputs that are optocoupled direct to allow for variable resistors or something along those lines (or do 16/16 or something).    The hardware design work is mostly specific to the control (transmit) master device.   The slave (receive) devices look to be pretty well good to go, minus making the boards smaller/cheaper.

[halfspec]

IMO integration is overrated unless you're wanting to manufacture and sell these or you just want a tough process exercise. If your modular design works and this is only a one of or two of, I'd personally stop where you are. Once you do your 20th component footprint and circuit representation you'll be wondering what was so bad about V1

It's been a while since I was designing automotive friendly input buffers for µprocessors for if memory serves, optoisolators / couplers are expensive and have lifetime problems. Don't get me wrong, they're not an incorrect choice, just one I didn't make due to the aforementioned possible problems. Anything wrong with using resistors and clamping diodes? I think, when I built mine I spec'd them to be able to withstand 120VAC (yes, positive and negative) all day and ensure the input to the µprocessor was ~0 - 4.7VDC (my AVR was a 5VDC device but if you're using 3.3VDC devices / rails, the design would remain the same). I seem to recall mine being about $0.20 per input but I could be wrong. If you're interested, hit me up and I'll share what I've got.

Lane

[digitalsolo]

Lane,

If you can shoot me an email (digitalsolo@ls1fc.com) with whatever you have on those circuits, that'd be GREAT.   I just need to send a switch to vehicle ground, then send that to the digital pins on the Arduino (3.3V) (via a 16 channel MUX), the inputs can float when not pulled low.   My whole concept with the isolation is just to squelch noise and protect everything.

On a forward progress note, I can now hit a button on my input device, send data over CAN, parse it on the receiver and trigger hazards, turn signals and brake lights/blinky brake lights (center mount).   Next I'll get latching/momentary inputs functional, then I need to do headlights, running lights, maybe some RGB interior lighting, then power door locks and power windows.   Woohoo!

[markfluko]

I understand some of these words.

Nice work grinding out potential solutions... Excited to see the final product.

[digitalsolo]

Thanks!   Lane has helped me (both directly and by making me rethink things a bit) and I have what should be a MUCH simpler (both design and packaging) solution for input protection now.    I'll get some parts ordered for that at some point soon.

I'm working to make the code simpler and easier to work with now.

[kinger]

Awesome....that is all.   

[digitalsolo]

So I've taken a break from the output controls, where I'm working on breaking out my functions into classes to make configuration easier, to work on inputs.

Basically, I had done all my testing with 5-6 buttons of input.   That's dandy until I went to hook up like 25 inputs (because why not?) and realized...  shit, I have 10 inputs available, total, on this board layout.   Whoops.

Solution:  16 channel multiplexers.   Basically that lets me use 10 pins on the Arduino and read 32 channels of data.   I'm planning on 24 channels of digital input (basically a switch) and 8 channels of analog inputs (for whatever).    It's hella fast on the channel roll for picking up the signals, but I'm not sure how fast it'd be for a really quick sensor, but, honestly, is that needed?   Probably not.     The inputs will be ground switches, so basically you can hook up a bunch of stuff like window switches, power door lock switches, turn signal, headlight, whatever, and just set them up with a ground on one side and this box on the other side.   

Basically you can then send the input pin that you plugged that into to a downstream module (just one command to edit) and save the code and it'll tell the downstream module it was pressed (within about 30 ms at the slowest), and then you can have that box do whatever you want with that data and then trigger an output to ground itself (to fire a relay, or you can pulse width modulate or whatever).   Right now I have it set to be a momentary switch (think headlights of power windows), a virtual latching switch (so you can hit a momentary switch but "latch" the relay, locking it on until you hit the button again), and special functions for hazard lights, turn signals and a flashy center brake light.    A little code will allow custom power window functions (working on how to do intelligent one touch controls soon) and power door locks, etc.

Anywho, it's come out pretty well so far.   I have 3 assembled boards with boxes, so I'll address each one differently and validate that the traffic behaves like I expect.    I will probably tweak the current downstream box design to allow 4-5 channels of analog input on those as well so that they can process some more specific data for their area.  Mostly relevant for stuff like current load feedback for power windows or servo control for an HVAC box, which I'd like to look at as well.

Okay, bed time.

[digitalsolo]

I had an idea...

So, if I control variable resistance outbound from the Arduino, I can use signal inputs to emulate pressure gauge senders.   I can use other methods to run square/sine wave gauges.  This means I could use my ECU to run analog gauges via CANbus.    Add a couple outputs for LEDs and I can light SES, TRAC and other stuff via CAN from the ECU, too.

That means I can use my Speedhut gauges, but feed them from the ECU so that they represent exactly what it sees instead of needing 2 sets of sensors for everything.

That seems wicked cool to me. 

[digitalsolo]

So, the "soft gauge controller" is on the "eventually" list, but for now I've been working on getting the last of this stuff that I've been working on production ready.

Last night I did the first round of PCB work on the current "CANbus OLED Gauge Controller".   I added 4 LED outputs and redesigned it to use a Teensy LC (Low cost) as it's only 11-12 dollars instead of 35 dollars and is a lot smaller.   I need to add the circuits for the screen change button and convert the schematic to a proper PCB (adjust component locations and draw traces), then I can have these produced.

Once these are "final" I'll go ahead and finish up the BCM control box, which should finalize the majority of this from a hardware perspective, at which point it'll just be tweaking code from here on out.   I'm really wanting to get these to a usable state, as I need to start doing chassis wiring on the car and these are a pretty key element. 

[kinger]

That is all wicked cool for sure.  My only hesitation is with reliability of these systems.  Its hard to keep stability and it takes a lot of tweaking.  Just turning the key and having the gauges fire up with their own sensors seems to add a titch of reliability..maybe?  Its hard when you start and stop so much I think (like pulling the car from the driveway into the garage).  still so badazz!

[digitalsolo]

Well, at the end of the day, as long as this is electrically stable, the functionality should be pretty reliable.

What I'm doing is basically running loops on microcontrollers to read data, process it and kick it out.   It's the same thing that is happening inside of a modern gauge or an OEM body control module.   Most of the work is making sure that error conditions are properly handled and that electrical behavior is addressed.       The code that runs on these boxes is only a few hundred lines before compilation, likely less after.    Time from ignition activation to these boxes being functional should be less than 1 second.

The big difference is I can't hack the OE systems however I want.

[mdickw]

So, if I control variable resistance outbound from the Arduino, I can use signal inputs to emulate pressure gauge senders.   I can use other methods to run square/sine wave gauges.  This means I could use my ECU to run analog gauges via CANbus.    Add a couple outputs for LEDs and I can light SES, TRAC and other stuff via CAN from the ECU, too.

You don't even need to bother with variable resistors for traditional analog gauges. PWM will usually do the trick. I use the stock LS1 oil pressure and coolant temp and drive the stock FD gauges using PWM.

[digitalsolo]

Yeah, I realized that a little later on.   Pretty easy setup.   Not many people seemed very interested in the functionality when I asked, so it'll go on my "at some point" list. 

[digitalsolo]

Soooo, this morphed quite a bit.   I'm no longer using CANbus relay controllers.   Well, I'm no longer using standalone relay controllers and relays, I'm using these:

https://www.waytekwire.com/item/46066/EATON-31M-000-2-Mulitplex-Vehicle-Electrical/

Along with my Arduino powered controller, which picks up ground signals from factory switches and then sends signals to the Eaton/Bussmann box to turn relays on/off.    These boxes are way cool and can actually report back the status of the relays, and send alerts if a relay fails, etc.

I plan to eventually add this to my Android dash display, so that I can see a screen that shows the health/status of all aux system (headlights, turn signals, horns, etc) relays and fuses, which will be pretty damned cool.   Yay, technology.