Arduino interface project
Posted: Mon Nov 19, 2012 12:39 pm
Howdy all
The past few weeks i've been busy learning more code and electronics to play with on my roadster.
The main motivation was randomly finding some large RGB 20x4 character LCDs off ebay - i dont know what made me look for it, but I found it, and havent seen any since. Its not common to find many LCDs with RGB backlights, so I thought about what projects i could make...
One of these projects is my "Sensor metrics" display.
This is something i've wanted to do for a VERY long time (20+ years) but never really had the means or access to knowledge to do it. Enter the Arduino microcontroller and everything changes! I started playing with these about 2 years ago but my programming really sucked.. I was only using what was demo'ed on various websites, its taken me a while to find out how to go a bit deeper into it.
The programming heart of what i've done here involves having a menu structure made, and without that, the functionality of everything is very limited and if functionality *is* there, the code becomes hideously messy. Once i worked out how Arduino tabs worked and linking to them, i was able to make progress - neat code, neat menus, everything sectioned off nicely in the programming.
Then there was the matter of making pushbutton switches that didnt "bounce" and result in screwing up button presses.
Driving the LCD and interfacing the switches is straight forward, very few components.
Yep there are a lot of jumper cables but most are for linking the LCD and it's backlights. When you're building the bits in sections, honestly it does all make sense and isnt complicated despite it looking a little overwhelming in this pic...
a video of the menu structure demo is here. (mp4 video)
The best bit about this is the code is easily able to extend beyond 4 options, and i can also nest in submenus where they're needed.
I also wanted to control various lighting and other random bits from a simple three button interface, (up, select, down).
A goal is to keep the final menu structure ergonomic with no unnecessary complication.
As this is still in development, i'm likely going to move, merge or remove some options depending on their importance.
I wanted to get readings of various temperatures around the vehicle, as well as read the AFM and TPS
signals to see what i can learn off them as i get nerdy curious about various things every now and then..
a video of the AFM/TPS demo is here. (mp4 video)
The issue there is i needed to isolate the TPS/AFM signals from the arduino so the arduino didn't effect the voltages required for the ECU! Directly hooking them in did work but also made the car run rich, and also had the unfortunate impact of killing the engine when the arduino was turned off/unplugged. Not good!!
That test didnt last very long before i realised i needed something to buffer it. Also, the TPS/AFM signals would occasionally overload the arduino, apparantly delivering a bit more then 5v from time to time. A little more research and i used a few opamps configured with slightly negative gain, so the readings from the TPS/AFM fell between 0.5 and 4.5 volts (well within the range of the arduino's analogue inputs).
I know the tps/afm readings are meant to be within approximately that range anyway but i was having spurious signals coming through - nothing that effected engine operation, just the arduino..
I then had issues of random spikes along the TPS line and a big spike from the AFM when the vehicle ignition went on. A little more research and i made a 1hz RC filter which took care of all of that. The filters roll off meant that sudden throttle changes would still show but the spikes were gone. And you cant really go from 0 to WOT 10 times in a second short of being electrocuted or experiencing epilepsy.
Clearly the ECU already has such inbuilt filtering and isn't really surprising now that i think about it, with an engine bay being exposed to so much electrical noise from startermotors, alternators, coilpacks etc..
My test circuitry is now looking a little messy but it's working and its solid and I was after a result so i didnt care what it looked like.
This signal filtering applies also to the fuel tank and lambda sensors too. The Fuel tank signal needs averaging over a 30 second period as the fuel sender responds instantly to fuel sloshing about in the tank where as the fuel needle on the dash cluster is heavily filtered and takes about a minute to do a full sweep from empty to full. It's also interfaced via an inverting op-amp with negative gain also. It doesn't read correctly until the car is running as the voltages change by about a volt - enough to screw up readings.
The lambda sensor, will be bar graphed and will have a 0.5- 1 second rms average applied for a digital readout.
With being super anal about mapping my fuel economy the past few months, I've been mapping out the fuel needle versus my mileage and working out a pretty accurate represenatation of litres in the tank versus the needle position. Knowing this allows me to make an older style bmw-esque fuel display.
a video of the Fuel tank demo is here. (mp4 video)
With the RGB backlight, i can change colours, display stuff to screen, sound alarms etc when certain conditions are met. This demo was just starting out what i wanted to do with it and have a little fun.
A little further thought - knowing the litres left, and getting an average reading of afm/tps values means i can then work out a projected mileage based on current driving style.. This is partially reflected later on.
In doing the coding, i learnt to play with loops to make audio from the PWM output.
I made this super annoying TCAS alert sound (mp4 video)- not sure what i'd use it for but the code is only a few lines..
Getting this all together was the next thing, building a veroboard to mount it on was straight forward but putting it in the car was a bit messy, but was necessary to get real world usage and operations under a range of conditions.
Fortunately there were some fairly hot days and leaving my car at work in the sun yielded some 50 degree dashboard temperatures. The LCD liquid didnt deform and was still easily legible in that heat. The arduino which was fully exposed to that heat also functioned flawlessly.
All of the temperature sensors in engine bay along with the TPS/AFM sensor lines are using shielded cables but as the temp sensors run on the I2C serial bus, their signals are more susceptible to electrical noise, specifically coming from my COPS. Im going to investigate using Cat6 shielded twisted pair. (or maybe super duper shielded cat7 network cable.
Earlier in the week, my 3 gauge lid arrived, and i'd began trimming it to suite the dashboard.
I'm really honestly hopeless at this sort of work and lack the skills to do it properly but it didnt stop me from giving it a go.
I didnt think to photograph the original piece, so heres a bad photoshop of what i'd removed..
the rear of the lid was designed to wrap over a lower part of a dashboard, as the NA dash is raised at the rear, i needed to remove a lot of plastic.
this is looking at the top of the lid
This is sort of what the lid looked like when i bought it.. I've tried to make it look like what it was before I trimmed it..
this is it prepped to hold the LCD.
and a slice of perspex to fit over the top
Heres a rough cut of how i need to shape the perspex to fit in.
And the perspex trimmed to fit, heres the LCD viewable area mapped out on the perspex. I'll use this as a mask to paint the surrounding area black. The perspex protector sheet is very uniformly stuck on the perspex so it makes an excellent mask (that was the plan/thought!)
The LCD panel with it's screen protector and desoldered from my test rig setup.
Peeling off the rear cut out for the lcd masking.
spraying the perspex with a light coat to start with.
and after being sun dried with a heavy coat.
I've had to bevel the rear side edges of the perspex to better fit the gauge lid.
Using a scalpel to peel back the mask
still slowly peeling to not upset the paint edge.
now peeling off the front. No spray paint entered the edges here, the perspex protector works a treat, just as i hoped!
oooh perdy!
by this point i was getting a little excited!
having only seen the LCD with its now well worn protector on, it was amazing to see the screen so clean and pristine behind it!
now getting more excited.. a silicon carbide moment..
i cant hold it anymore..
crisis...
at this point after i cleaned up, i soldered on a ribbon cable to the required LCD pins, tested it out on the arduino, then siliconed the display carefully to the perspex, waited to dry, then siliconed the display panel to the gauge lid. The silicon is there to make the surfaces dust proof.
There is one area unsealed between the LCD and perspex, hopefully moisture wont build up and dust one get in. As it's my first time doing this, i wont know until 12 months down the track when this setup has experienced cold weather.
i left this in the sun for a good 6 hours to tack dry before temporarily siliconing it on the dashboard...
At this point, it is still only a test fit, as i have ribbon cabling all over the place but its much safer then having the exposed circuitry on the dash.
The circuitry is now in a small cardboard box in the glovebox, much more accessible and with all the cabling joining it via connectors.
This starts out with a little homage/pisstake of an Aston Martin's V8/V12 Vantage dashboard..
(http://www.youtube.com/watch?v=B7ORWhWEcHc)
(in this video the gauge lid is siliconed in but is also supported by tape to stop it sliding while it dries! - it has since been removed and is less ugly/moar neater!)
When it's time to be made permanent, i'll be drilling the cabling directly through the dashboard to keep it neat and out of sight, adding an antimoisture pack inside the gauge lid and siliconing it all tight.
The best part about this is the extras that arduino can talk with, realtime clocks, GPS, datalogging via SD cards, RFID comms, load sensors, anything off an I2C serial bus. So much awesome but best of all, so much fun to play with. What is seen here is setting a basis for more, and i'll make an effort to update this thread when i add new bits to it.
Also in the works is a switch array which i'll be fitting in a surprisingly nice ergonomic position on the dashboard exploiting an 'issue' many NA owners suffer! This array will be replacing my 3 pushbuttons stuck on beside the gearstick. Again, as this is a physical item, i'm taking my sweet time to make it as nice as possible, as again, i'm really crap at building neat things and i want this one looking decent.
The past few weeks i've been busy learning more code and electronics to play with on my roadster.
The main motivation was randomly finding some large RGB 20x4 character LCDs off ebay - i dont know what made me look for it, but I found it, and havent seen any since. Its not common to find many LCDs with RGB backlights, so I thought about what projects i could make...
One of these projects is my "Sensor metrics" display.
This is something i've wanted to do for a VERY long time (20+ years) but never really had the means or access to knowledge to do it. Enter the Arduino microcontroller and everything changes! I started playing with these about 2 years ago but my programming really sucked.. I was only using what was demo'ed on various websites, its taken me a while to find out how to go a bit deeper into it.
The programming heart of what i've done here involves having a menu structure made, and without that, the functionality of everything is very limited and if functionality *is* there, the code becomes hideously messy. Once i worked out how Arduino tabs worked and linking to them, i was able to make progress - neat code, neat menus, everything sectioned off nicely in the programming.
Then there was the matter of making pushbutton switches that didnt "bounce" and result in screwing up button presses.
Driving the LCD and interfacing the switches is straight forward, very few components.
Yep there are a lot of jumper cables but most are for linking the LCD and it's backlights. When you're building the bits in sections, honestly it does all make sense and isnt complicated despite it looking a little overwhelming in this pic...
a video of the menu structure demo is here. (mp4 video)
The best bit about this is the code is easily able to extend beyond 4 options, and i can also nest in submenus where they're needed.
I also wanted to control various lighting and other random bits from a simple three button interface, (up, select, down).
A goal is to keep the final menu structure ergonomic with no unnecessary complication.
As this is still in development, i'm likely going to move, merge or remove some options depending on their importance.
I wanted to get readings of various temperatures around the vehicle, as well as read the AFM and TPS
signals to see what i can learn off them as i get nerdy curious about various things every now and then..
a video of the AFM/TPS demo is here. (mp4 video)
The issue there is i needed to isolate the TPS/AFM signals from the arduino so the arduino didn't effect the voltages required for the ECU! Directly hooking them in did work but also made the car run rich, and also had the unfortunate impact of killing the engine when the arduino was turned off/unplugged. Not good!!
That test didnt last very long before i realised i needed something to buffer it. Also, the TPS/AFM signals would occasionally overload the arduino, apparantly delivering a bit more then 5v from time to time. A little more research and i used a few opamps configured with slightly negative gain, so the readings from the TPS/AFM fell between 0.5 and 4.5 volts (well within the range of the arduino's analogue inputs).
I know the tps/afm readings are meant to be within approximately that range anyway but i was having spurious signals coming through - nothing that effected engine operation, just the arduino..
I then had issues of random spikes along the TPS line and a big spike from the AFM when the vehicle ignition went on. A little more research and i made a 1hz RC filter which took care of all of that. The filters roll off meant that sudden throttle changes would still show but the spikes were gone. And you cant really go from 0 to WOT 10 times in a second short of being electrocuted or experiencing epilepsy.
Clearly the ECU already has such inbuilt filtering and isn't really surprising now that i think about it, with an engine bay being exposed to so much electrical noise from startermotors, alternators, coilpacks etc..
My test circuitry is now looking a little messy but it's working and its solid and I was after a result so i didnt care what it looked like.
This signal filtering applies also to the fuel tank and lambda sensors too. The Fuel tank signal needs averaging over a 30 second period as the fuel sender responds instantly to fuel sloshing about in the tank where as the fuel needle on the dash cluster is heavily filtered and takes about a minute to do a full sweep from empty to full. It's also interfaced via an inverting op-amp with negative gain also. It doesn't read correctly until the car is running as the voltages change by about a volt - enough to screw up readings.
The lambda sensor, will be bar graphed and will have a 0.5- 1 second rms average applied for a digital readout.
With being super anal about mapping my fuel economy the past few months, I've been mapping out the fuel needle versus my mileage and working out a pretty accurate represenatation of litres in the tank versus the needle position. Knowing this allows me to make an older style bmw-esque fuel display.
a video of the Fuel tank demo is here. (mp4 video)
With the RGB backlight, i can change colours, display stuff to screen, sound alarms etc when certain conditions are met. This demo was just starting out what i wanted to do with it and have a little fun.
A little further thought - knowing the litres left, and getting an average reading of afm/tps values means i can then work out a projected mileage based on current driving style.. This is partially reflected later on.
In doing the coding, i learnt to play with loops to make audio from the PWM output.
I made this super annoying TCAS alert sound (mp4 video)- not sure what i'd use it for but the code is only a few lines..
Getting this all together was the next thing, building a veroboard to mount it on was straight forward but putting it in the car was a bit messy, but was necessary to get real world usage and operations under a range of conditions.
Fortunately there were some fairly hot days and leaving my car at work in the sun yielded some 50 degree dashboard temperatures. The LCD liquid didnt deform and was still easily legible in that heat. The arduino which was fully exposed to that heat also functioned flawlessly.
All of the temperature sensors in engine bay along with the TPS/AFM sensor lines are using shielded cables but as the temp sensors run on the I2C serial bus, their signals are more susceptible to electrical noise, specifically coming from my COPS. Im going to investigate using Cat6 shielded twisted pair. (or maybe super duper shielded cat7 network cable.
Earlier in the week, my 3 gauge lid arrived, and i'd began trimming it to suite the dashboard.
I'm really honestly hopeless at this sort of work and lack the skills to do it properly but it didnt stop me from giving it a go.
I didnt think to photograph the original piece, so heres a bad photoshop of what i'd removed..
the rear of the lid was designed to wrap over a lower part of a dashboard, as the NA dash is raised at the rear, i needed to remove a lot of plastic.
this is looking at the top of the lid
This is sort of what the lid looked like when i bought it.. I've tried to make it look like what it was before I trimmed it..
this is it prepped to hold the LCD.
and a slice of perspex to fit over the top
Heres a rough cut of how i need to shape the perspex to fit in.
And the perspex trimmed to fit, heres the LCD viewable area mapped out on the perspex. I'll use this as a mask to paint the surrounding area black. The perspex protector sheet is very uniformly stuck on the perspex so it makes an excellent mask (that was the plan/thought!)
The LCD panel with it's screen protector and desoldered from my test rig setup.
Peeling off the rear cut out for the lcd masking.
spraying the perspex with a light coat to start with.
and after being sun dried with a heavy coat.
I've had to bevel the rear side edges of the perspex to better fit the gauge lid.
Using a scalpel to peel back the mask
still slowly peeling to not upset the paint edge.
now peeling off the front. No spray paint entered the edges here, the perspex protector works a treat, just as i hoped!
oooh perdy!
by this point i was getting a little excited!
having only seen the LCD with its now well worn protector on, it was amazing to see the screen so clean and pristine behind it!
now getting more excited.. a silicon carbide moment..
i cant hold it anymore..
crisis...
at this point after i cleaned up, i soldered on a ribbon cable to the required LCD pins, tested it out on the arduino, then siliconed the display carefully to the perspex, waited to dry, then siliconed the display panel to the gauge lid. The silicon is there to make the surfaces dust proof.
There is one area unsealed between the LCD and perspex, hopefully moisture wont build up and dust one get in. As it's my first time doing this, i wont know until 12 months down the track when this setup has experienced cold weather.
i left this in the sun for a good 6 hours to tack dry before temporarily siliconing it on the dashboard...
At this point, it is still only a test fit, as i have ribbon cabling all over the place but its much safer then having the exposed circuitry on the dash.
The circuitry is now in a small cardboard box in the glovebox, much more accessible and with all the cabling joining it via connectors.
This starts out with a little homage/pisstake of an Aston Martin's V8/V12 Vantage dashboard..
(http://www.youtube.com/watch?v=B7ORWhWEcHc)
(in this video the gauge lid is siliconed in but is also supported by tape to stop it sliding while it dries! - it has since been removed and is less ugly/moar neater!)
When it's time to be made permanent, i'll be drilling the cabling directly through the dashboard to keep it neat and out of sight, adding an antimoisture pack inside the gauge lid and siliconing it all tight.
The best part about this is the extras that arduino can talk with, realtime clocks, GPS, datalogging via SD cards, RFID comms, load sensors, anything off an I2C serial bus. So much awesome but best of all, so much fun to play with. What is seen here is setting a basis for more, and i'll make an effort to update this thread when i add new bits to it.
Also in the works is a switch array which i'll be fitting in a surprisingly nice ergonomic position on the dashboard exploiting an 'issue' many NA owners suffer! This array will be replacing my 3 pushbuttons stuck on beside the gearstick. Again, as this is a physical item, i'm taking my sweet time to make it as nice as possible, as again, i'm really crap at building neat things and i want this one looking decent.
