MPGuino release one workspace

[timgray]

I have had Zeniers fail to stop a transient voltage spike as they are not fast to clamp.

[ttoyoda]

So I request actual proof behind the statements requesting a change

I want to be very clear, I do not (and certainly and obviously have no right or power to ) ask for a change. I am only providing a warning of *possible* pitfalls. The final circuit is your decison. I do agree with simplicity, and support you staying with a 2 line display, especially since that is what I bought.

All my duino parts are sitting on my workbench and I have not assembled it yet.

My comments are based on making circuits for my cars in the past.

My *experience* with every circuit *I* have made to control something for a car (a windshield wiper delay, and a trailer light controller to go from the automotive 3 fillament circuit to the trailer 2 fillament circuit) using cmos logic is that it dies months later *unless* it is strictly isolated from/protected from the car, both the inputs and the outputs, (I use relays to isolate outputs, and optos to isolate inputs).

In addition, I have found thru bitter experience that my power supply must have an input choke and a range of capacitor sizes to trap the different harmonics of spikes and hash and trash that the automotive electrical supply is full of. I have looked at the automotive 12 V supply with my scope ( Tektronix 475 ) before and along with random noise, there are very narrow spikes whenever something inductive (motors, door locks) in the car switches off, and happens every few seconds on the car I tested.

Beyond that, I now use twisted pair wire for every connection, to avoid picking up all the radiated electrical noise, and I do not share share my power ground connection with my "input signal from the car" ground connection on my circuit boards, instead I route that back thru the twisted pair to the car body directly.

You are correct that I have no proof that your system will not work. I doubt it is possible to *prove* that. What would I do to prove it, put 100 duinos with zeners in 100 different models of cars as a field trial and see how many have died after a year? I have never tried zeners for circuit protection. I do know that special schottky diodes are used in circuits that must deal with very fast risetimes, like in switching power supplies. All I have to go on is my history of having circuits die after a few months, and having to re-make them. That has made me very, very cautious, perhaps overly so.

Being ship-a-product minded, I know my bosses boss (plant manager) will not be down in engineering yelling if I put in more parts, a bigger fan, a duct, a bigger heatsink. He has no idea what we put in, his degree is in accounting, he only *insists* on choosing the color of the paint on the cabinet and the heads of visible screws. Usually he is busy playing golf while giving passing out "perks" in white envelopes to the distributers he plays golf with. He WILL be yelling if the product starts having failures in the field and we get returns from distributors. THAT will interrupt playing golf.

[Yoshi]

Originally Posted by ttoyoda

The final circuit is your decison.

I think an open source project has never been decided by a single person.

Anyway, his original thought was using transistors.
http://ecomodder.com/forum/19866-post2.html
The circuit is same as my SuperMID.
http://priusdiy.fc2web.com/TACHO.html
http://priusdiy.fc2web.com/image/SCHEMA05.jpg

Yoshi

[ttoyoda]

I think an open source project has never been decided by a single person.

OK, but I guess I think of dcb as the Linus Torvalds of *this* project.


Thank you for the links.
While my ability to read Japanese is only as good as it ever was, I see from the data sheets that on A3 Injector you picked a transistor 2sa1015 good for a minimum of 50 volts, and a high speed switching diode 1s2076. So I assume you must have been aware of the possible spike, (or if you were like me long ago, you tried it first without one and fried the chip) and you specifically picked a high speed diode to clamp it. Can you tell if there have been any statistically significant in-the-field failures of the SuperMID that would trace back to a spike from the injector line with your current design?
Also, I understand that the poly-switch is a self-resetting fuse, but did you feel the need for it other than "good practice"? Is there some particular risk that mandates it?

[RuHaSs]

While we are on the subject of how harsh this environment is for electronics may I suggest LM2940T-5.0 as a replacement voltage regulator with the proper filtering. I too also agree with opto's maybe 4n35 or at the very least a transistors on the input. 3 or 4 bucks extra will go a long way in possibly saving to replace Atmega etc, just my 3.26 cents

http://www.national.com/ds/LM/LM2940.pdf

[dcb]

part numbers = good Specific filter designs = good, if someone wants to put up the next strawman for these things, please do. I'd love to be able to focus solely on the code for a bit but want the hardware settled as soon as possible, with due stewardship for other peoples money of course.

if we go the opto route, which we may based on the applause meter, I would like to see a cheap dual opto package (< $1.00) that is available from the major distributors (digikey/mouser). I did not see one at the shack on the way home though, so we will be cutting into the "instant gratification" crowd a bit if we do go that route.

re LM2490, only concern is mouser doesn't have it. So our sourcing options get more limited. It wasn't immediatly obvious what it had over the 7805 to me, if someone can educate there. If the costs for bulletproofing the power supply are in the $3.00 range, I can probably be happy with that.

re: Linus, yah, right!

Edit: through hole only please, we scare a lot of folks off with the SMD stuff.

[Yoshi]

Originally Posted by ttoyoda

OK, but I guess I think of dcb as the Linus Torvalds of *this* project.

OK. I have to agree with you.

Thank you for the links.
While my ability to read Japanese is only as good as it ever was, I see from the data sheets that on A3 Injector you picked a transistor 2sa1015 good for a minimum of 50 volts, and a high speed switching diode 1s2076. So I assume you must have been aware of the possible spike, (or if you were like me long ago, you tried it first without one and fried the chip) and you specifically picked a high speed diode to clamp it.

Thank you for your comments. Your assumption is correct.
In addition to kill the spikes, we install the interface circuit close to the ECU, then the logic level square wave goes to SuperMID unit through LAN cable (twisted pair lines).
I didn't want to reach the noisy injector line to the unit.

Can you tell if there have been any statistically significant in-the-field failures of the SuperMID that would trace back to a spike from the injector line with your current design?

We delivered over 200 unit in the field, and we never heard any failures on the interface circuit.

Also, I understand that the poly-switch is a self-resetting fuse, but did you feel the need for it other than "good practice"? Is there some particular risk that mandates it?

Yes, it is 0.5 amp poly-switch and it's just for safety.
Without the poly-switch, the fuse for ECU will be blown when a power line short problem occurred, then we'll see critical vehicle failures.

Yoshi

[dcb]

06/17/08
Reverted back to double vsspulsespermile, seemed more reliable that way.

Added BIG NUMBERS (sorry, not a priority, I know).

Updated freeMemory function to not use malloc.

Did a bunch of ram optimizations:
Sketch size: 7990
Free Mem: 642 !
%CPU 52

Re orgd the displays to be more consistent with the original plan:
Instant/Current (instant mpg and speed , current mpg and distance)
Instant/Tank
BIG Instant;
BIG Current
BIG Tank
Current
Tank
Instant raw Data
Current raw Data
Tank raw Data
CPU Monitor

post 1 updated, tagged as v0.62


06/11/08
Fixed the runaway problem!!! (yay).
Added debug flag for serial logging.
put version # on opening screen (v0.60 currently).
Toned down the values in the brightness array.

Code in post 1[/url] updated

Developer note: On my breadboard model, I am now powering the LCD pin 2 from arduino pin 15, this allows the LCD to properly re-initialize between resets and makes development life much easier. Do Not try and power the backlight from an arduino pin or you will be shopping for a new atmega168.



06/07/08 More bench testing results:
I think I have the glitches out of the microseconds logic. It has been running for 635 minutes now with the signal generator.

Other quirks:
at some point during the long test, the trip mph dropped to 8.5mph instead of 20mph, probably overflowing, instant is fine. Another "if" statement in mph() might buy us some more range, or a generic routine for computing that which retains maximum resolution would be nice.

MPG figures are stable after 630 minutes, but there remains a discrepancy between instant and the trips. Instant is saying 41.67, the trips are saying ~56.74, and last I checked the raw data for both was right in both their actual values (signal input x time) and their displayed values based on the raw data and the vehicle parameters?!?

Have not seen the fuel consumption runaway on the bench. Will update saturn guino with latest version.

Did some experimenting with the eprom library, will try and get a user input screen together for the fuel and distance parameters (it is taking a while to bake in my head).

06/06/08 Built signal generator from spare atmega168 using arduino code, detected and fixed glitch in microseconds() function as a result. Will be able to do more thorough bench testing now. code updated in post 1, will put signal generator in seperate thread. "Key off" hack won't work in all vehicles, will be removing it.

05/21/08 Fixed mph off by half, and mph overflow display when engine not running. Added tank time to cpu display. Code updated.

05/20/08 Hacked in some "the key is off" detection by utilizing the fact that the injector "seems" like it's been open for a long time with the key off "1.5 seconds". LCD turns of after about 20 seconds. Trips don't take a huge MPG hit when you turn off the ignition now. Could be better, but the concept is solid (would like to avoid ANY impact to consumption, and the "current" trip should reset on startup). Code updated.

05/20/08 added CPU Monitor screen (cpu utilization and bytes free), running simulation gives below reading, in car should have higher CPU%:
CPU%: 024.75
FREE MEM: 158.00
Might need to push some stuff into flash memory.
edit: took a test drive, the max cpu % was less than 25 and free mem stayed at 158 (as expected). So the interrupt handlers are pretty tight, and we can entertain upping the refresh rate to .5 seconds.

05/19/08 Added the updated mpg function, instant mpg is looking a whole lot better. Still issues with trip. Added 999999 display if there are no injPulses but there are vssPulses. Noticed that when I play with the injector kill switch while EOC (it interrupts the FI fuse), the MPG reading goes to single digits... hmm... Might have to recommend ignition kill switches or something. Code updated.

05/18/08 Stumbled on some vss info, my saturn is 5000 pulses/mile. If I set vssPulsesPerMile to 10000 then I have a pretty accurate speedo on the guino(counting 2 times too many pulses for some reason).

05/18/08 getting real close here, added scaling logic to mph function. mpg function looks good on the trips once they have some data (in simulation mode) but instant still needs a little work. trips are accumulating and displaying miles and gallons reasonably well too (again in simulation mode). code updated.

05/18/08 cleaned up the size of the code a bit (under 6k for now, 5996 bytes), added 3 new screens (formatted output for the trips). Got an ok looking mph display (from main screen, press right button, wait for the instant screen to draw, then press right + left to start the simulation). I think the display strategy will be to have simple ifs/elses in the trip functions (mpg,miles,gallons,mph,etc) to do the math based on pre-defined ranges to prevent overflows/underflows. Also mph is klunky on instant, we are dividing by the number of vss pulses but might want to time the pulses for low vss pulse counts (longer time between pulses=slower), instant accuracy will suffer till that is done.

05/15/08 calling the hardware good, I'm not planning on messing with it anymore for version one. Added a parts list and cleaned up post 1. Raw instant looks good, but the rest needs work yet.

05/14/08 Tried the zener trick on the vss signal, it works!! (getting about 25 tics/second at 10mph). Schematic and code updated. I want to see about replacing the 2n3906 with a 2n3904 (can get rid of one more resistor) before calling the interface board good enough.

05/13/08 found a useable VSS signal (was speedometer "output"), probing with the piezo indicates that it is a ground switch. Might need to redo the vss circuit for the saturn. there are probably going to be a few varieties of vss signal to sort out.


05/13/08 added a bunch of installation pictures to post #1 , no working vss signal yet however. I don't hear anything on the vss lead with the piezo so I think I need to try another wire.


05/13/08 Bypassed the ecu injector lead and got a solid signal straight from the injector wire. VSS still needs work (I don't think my cheesey clip is making a good purchase on the conductor). Switched in a zener on the injector lead and the fuel monitoring started working much better (I must have messed up the transistor). Added a couple screens for debugging and button commands, described in post #1, including tank and current resets and brightness control.

05/08/08 Couple of code tweaks and a test run in the car (97 saturn s2) was promising. The miles reading is in the ballpark, but the gallons was at least an order of magnitude off. Also everything was in whole numbers, will need to include floating point routines or device an integer based strategy.


05/07/08 removed 10k resistor from vss circuit and turned on internal pullup resistor.


05/06/08 update: I Took Coyotes suggestion and used two arduino pins for the injector. With one interrupt watching for rising and one watching for falling, the hardware handles the state management.

Added the button interrupt logic since I needed a vss interrupt handler, and moved the vss pin to pin 14 (all the pins for the buttons and the vss are read with one call to PINC).

Updated vss and injector hookup locations in the wiring diagram and the code. Changed brightness resistor to 100 ohms.


05/06/08 update: Updated wiring diagram, changed the 2.2k to 2.7k resistors (it's what I had laying around), and changed the 100k connected to pin 9 (brightness) to 430 ohm and got brightness control (can easily go down to 200 ohm for a brighter display). Put all the extra components on a small project board. So now it is just a matter of seeing if the other circuits and the code work.

05/05/08 update: Updated wiring diagram to include CPU control of the LED backlight via a transistor (completely untested). Also indicated ground path and voltage source and added optional (for now) buttons. The 7805 can handle 15 volts, so I'm just going straight to the car battery, will cut a power plug off an old wall wart or something to connect to the 'duino.

05/04/08 update: Added wiring diagram

05/04/08 update: the LCD code is behaving much more reliably now. Added vehicle interface picture.

05/02/08 update:
just fyi, the serial port version of freeduino is on sale for $14.49 at nkc
http://www.nkcelectronics.com/arduin...omplete-k.html
*not for legacy free homes

grab a $9.99 LCD while you are there
http://www.nkcelectronics.com/16x2-l...backli162.html

and another $8 worth of stuff from the shack or mouser or digikey and we are right about at $35.

[awillard69]

On Ubuntu 8.04, it compiles to 8094 bytes.

Mine reports C% 47.24, and FREE MEM of 630. And I don't get the reset - Woo Hoo! Good job.

With this version, 0.62, the reset button does not leave the LCD in a one line state, so that's improved on my setup anyway. Actually, it didn't occur on 4 out of 5 resets, versus happening on 4 out of 5.

The BIG numbers look great.

You might want to trim down these update posts, and just include the latest few notations.

[awillard69]

I let it run, just to watch it. The large display is almost mezmorizing, on bench inputs anyway. After a while, I don't know really, but about 90 minutes later I checked on it and the LCD was dark - as in off looking.

I repowered the device - nothing. I tried to redownload the program, thinking that maybe the program had been corrupted. But, I couldn't connect with the protoshield interface attached. Once I disconnected the shield, it downloaded just fine. I was able to send the program again, but upon power up the LCD would not come on.

Poking around with a logic probe to try to do a sanity check (nothing was hot, smoking, melted, etc.) and when I touched the high side of the resistor for the brightness display, the LCD appeared to glow. No display, just the backlight. Curious.

I powered it down and swapped out the Freeduino board (thinking it may be toast) for a spare, flashed the program, attached the shield - nothing different.

While I dug around for some documentation, it was sitting there unplugged, i.e. no power.

After a few minutes, I tried it again, ready to test something else. Viola! The LCD came up and it began to display active data -- for about 10 seconds before it shutdown again. Curious.

This time I left it down for about 20 minutes. Upon restart it ran for a few minutes before stopping.

So, that leads me to think that there is a thermal problem. Is it the LCD or something else? Does the 2X16 LCD from NKC have a thermal safety state? Has anyone else encountered this?

Mine may be different as I have a ribbon cable hot glued to the back and it is covering up one of the epoxy spots. It is not glued to the spot itself, just the edge of the board, but there is not much air in between. Might that be contributing to an overheating condition? It was just sitting on the bench, not in an enclosure.

Any thoughts?