How to protect picaxe in vehicle use

salmve

Member
Hello

My project has progress to the test position. I attach very ugly shematic. Sorry for that.

All works fine until reason or other stop. Serial traffic stop. I put computer to TX chip to see what it is doing. All i get was communication error. I checked all solders and so on. All was ok. Then i changed new Picaxe and it works little time and same again.
Picaxe was broken again!. I think there is lots of current spikes and they burn Picaxe.
Tx Picaxe has two Adc input and one digital output in addition to this serout. They works after damage. Only Serout is dead. It is wired to output 0 so that's why i cannot get connection with PC.

There is two magnetic valves after Epec module and i am not sure is there flywheel diodes connected. I have to check that. PVG-32 valves has amplifiers inside.

What i should to do to protect my Picaxe?

Vekku
 

Attachments

BeanieBots

Moderator
So much missing it's hard to know where to start:eek:

A 7805 regulator is NOT a suitable device for use in vehicals.
I see absolutely ZERO protection on your diagram even for 'normal' use let alone use in a car.

This has been covered many times on this forum and the broad concensus is that if you don't know, you shouldn't be doing it.

Maybe some others will come in with some helpful tips but a good search of the forum should flag up some of the basics such as power supply.
 

MFB

Senior Member
Basically, I think you may have broken every rule of automotive electronics with just one schematic! Not sure were to start but, RS-485 should be used to drive the serial link over twisted and screened cables. An automotive grade regulator is required for the PICAXE and opto-isolation between the two systems might help as well. I’m other will spot additional 'issues'.
 

Dippy

Moderator
Oh dear. There is not enough information there to provide a full answer.
e.g. you have indicated+24V going to a PICAXE.
... basically, it's a mess. So many potential disasters waiting to bite you.

And you really should have researched this more before going head-first into vehicular operation.
I take it your electronics experience isn't a lot?

You should have checked the solenoid to see if there are spike/back emf issues.
You should have checked for induced and power line noise.
You should check that your regulation/protection is good and clean before connecting PICAXE.
You should have checked that the Logic line levels are correct and clean before connecting PICAXE.


For vehicular use you need a very protective power supply.
It needs to regulate but ALSO to protect the PICAXE side from transients, noise and ideally reverse polarity.
Have a look at the .pdf in this thread to give you some tips.
http://www.picaxeforum.co.uk/showthread.php?t=14228&highlight=automotive
Post #1 - attached pdf.
The top section is the protected PSU.
A 7805 is not enough.
And a 5A fuse for the PICAXE board (schematic unknown to us) is asking for trouble.

Then you need to check the logic side.
Noise, spikes, correct voltage levels.
If you haven't got an osilloscope then you need to 'over engineer' the circuit.

Consider opto-isolation for logic , much safer.
So many things to check.
The PICAXE must NOT have >5V going to any pin.

Did it work OK on test-bench before putting in vehicle?

If I were you I would go back to basics and design protection for each 'module'.
 

MartinM57

Moderator
Actually not a bad high level schematic IMHO.

But more detail is needed (actual schematics, component values - and that's before we get on to physical construction) as to what is inside the subsystems so that we can see what your design strategies are for transients, noise etc.

So are you actually controlling one of these or 'just' monitoring it? (oops - pic is a bit big, but it shows the size of the problem!)
 

Dippy

Moderator
Back to the Drawing Board is the concensus salmve.
You'll get many answers like the above, so no point repeating until you have the basics sorted.
 

BeanieBots

Moderator
This document outlines the sort of transients you are likely to encounter in a regular 12v system domestic car.
http://www.industrologic.com/autotransients.pdf

You clearly have something slightly different so there is lot of work that needs to be done on your part to identify what issues you not only have (use a 'scope) but are also potentially at risk from (vehical design analysis), once these have been established, you can then start to design your circuit to handle them.
 

matherp

Senior Member
This is the circuit I use for power conditioning my homebuilt aircraft electronics. This has been approved by one of the top guys in aviation electronics. Probably overkill but rock solid.

best regards

Peter
 

Attachments

matherp

Senior Member
Small aircraft Can be 12V or 24V DC like cars/lorries just change the version of the DC-DC convertor and transorb as applicable.
 

moxhamj

New Member
Yes matherp, I like that schematic. I particularly like the diode going back to 0V. The diode going into the circuit is good but one can never assume the 0V is smooth either. So two diodes is very good.

Of course, now the 0 is 0.6V and the 5V is 5.6V - relative to the battery. But it is probably a good thing too, because it then forces one to consider - how do you get data out of a module when even 0V is not necessarily 0V?

Two solutions spring to mind. Optocoupling? But I like MFB's suggestion of RS485. That uses differential signals. And if you use a proper converter chip, now the picaxe 'module' is protected from the outside world. Power supply is protected. And data link is protected too. Put that 'module' in a metal box. Do not bring any other wires out of that box unless you consider very carefully what might go down those wires.

BTW - I want one of those diggers! I think of those while I dig my 500 metres of road by hand down a steep hillside. I've been working on it for 3 years and now about 2/3 of the way down. I could do it with a digger though some of the slope is >60 degrees. But it is also good fitness. Though if someone offered me a digger...
 

salmve

Member
Thanks for many answers.
Good shematic, so many of yours waked up:)



Oh dear.

I take it your electronics experience isn't a lot?
It isn't. And that is only thing i am sure.

I think that RX board is enough protective except twisted pairs and optoisolators. Powerlines (+5 and +24V) comes direct from Epec with short wires. Epec modules has made exactly for vehicle use.
Here is brochure:
http://www.epec.fi/docs/052-3gn-Epec_2024_Universal_Module.pdf

I attach TX shematic. Ugly again

And here is code (sorry for few Finnish words):

Code:
#picaxe 08m
main:
setfreq m4
readadc 1, b1'lukee matriisin
readadc 4, b2'lukee joysticin
if b2 < 120 then pumppu'pumpun alaraja
if b2 > 130 then pumppu'pumpun yläraja
if b1 > 12 then pumppu
low 2 goto laheta
pumppu:
high 2
laheta:
if b1 < 10 then nollaa
serout 0, T2400_4,(0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55)
pause 3
serout 0,T2400_4,("data",b1,b2)
goto main
nollaa:
serout 0, T2400_4,(0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55)
pause 3
serout 0,T2400_4,("data",b1,b2)
goto main
At the RX side Picaxe outputs are connected via ULN2893 to Epec inputs
I will post shematic later. Maybe it is waste of time but still. Comments were so discouraging:eek:

Vekku
 

Attachments

papaof2

Senior Member
When I was a lowly tech in a relay-based telephone switching office, I came up with a circuit to monitor a specific failure mode of certain incoming lines. My design used TTL chips and the Bell Labs people said "You can't use 5 volt logic in an environment with hundreds of 48 volt relays."
With proper bypassing and shielding, my design worked 24/7 without problems - so much for the experts who had not actually tried it in the real world.

I think you'll find that the advice given here has a "real world" basis, so ensuring proper power conditioning, input spike protection, communcation line protection, etc, is the key to making your device reliable in an environment that is unfriendly to electroncs.

John
 

MartinM57

Moderator
£12.20 + vat from either Farnell or RS and that's what the transorb is for
Sure - I'm not poo-poo'ing them and they seem to be a good just-fit-it-and-forget-all-about-any-power-supply-issues (allegedly) solution...but spend <<£2 on a few discrete components put together in the right way you can do just as well, and know exactly what you have and have not got protection against.

EDIT - and for the nerds among us, and not wishing to digress too much from OP's real problem of actually destroying PICAXEs (which is a good case for not just sticking something in a real environment and hoping all will be OK). have a read of http://www.ce-mag.com/archive/03/ARG/jarvis.htm, especially the blue box. This highlights two interesting aspects
a) the R on the incoming line that limits the current into the transient suppression devices so that they don't blow open circuit and know one knows that they have done so (and you have no more protection) - what does your avionic electrician think of that?
b) that just one transorb might not be what you need
 
Last edited:

Haku

Senior Member
What about using a cigarette lighter to USB power adaptor? There's millions of them and you can pick them up for not a lot.
 

hippy

Ex-Staff (retired)
I think the problem is that you don't know what's actually inside a cigarette socket charger or adapter.

One presumes that big-name brands have designed them well but as there's usually a caveat 'only use official brand-X adapters with brand-X product' you don't know where they've designed protection to be; the equipment being powered or the supply adapter itself.

At the opposite extreme, the adapter may be extremely poorly designed, with the manufacturer not caring if damage is caused to your product.

You'd have to open it up and reverse engineer to see what they've used and assess what it does protect against and/or test it against the range of faults likely to be seen in a vehicle and measure how it performs.
 

matherp

Senior Member
Martin

The transorbs I use have a 500A peak current. The incoming power has a 2A breaker. The transorb is chosen to start conducting within the safe range of the DC-DC converter. This has all been tested and the breaker will open to cut off the supply as soon as the voltage rises too far. This by the way is the biggest risk to avionics - a failed voltage regulator controlling the alternator can allow the bus voltage to rise and damage electronics if not properly protected. Wire to the device is 22awg which has a finite resistance so the voltage can't rise too fast anyway given the large capacitor which takes care of spikes.

I'm sure you can do as well/better with discrete components but when a compass chip costs £100 then protecting it is important and not that price sensitive, the fact that the power conditioning also provides a rock solid voltage to the picaxe is a bonus.

regards

Peter
 

salmve

Member
Back from air to earth:)

Here is both rx and tx in same post, please comments.

Tx code:


Code:
#picaxe 08m
main:
setfreq m4
readadc 1, b1'lukee matriisin
readadc 4, b2'lukee joysticin
if b2 < 120 then pumppu'pumpun alaraja
if b2 > 130 then pumppu'pumpun yläraja
if b1 > 12 then pumppu
low 2 goto laheta
pumppu:
high 2
laheta:
if b1 < 10 then nollaa
serout 0, T2400_4,(0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55)
pause 3
serout 0,T2400_4,("data",b1,b2)
goto main
nollaa:
serout 0, T2400_4,(0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55)
pause 3
serout 0,T2400_4,("data",b1,b2)
goto main
Rx code: (and Finnish words again)

Code:
#picaxe 40x1
setfreq m8
main:
serin 4,T2400_8,("data"),b1,b2 
if b2<125 then ylos
if b2>125 then alas
alas:b3=b2-129*22/10:goto pulssia
ylos:b4=129-b2*24/10:goto pulssiy
pulssia:pwmout 1,99,b3
pulssiy:pwmout 2,99,b4
if b1 < 10 then goto zeroe
if b1 < 59 then yksi
if b1 < 65 then kaksi
if b1 < 74 then kolme
if b1 < 86 then nelja
if b1 < 102 then viisi
if b1 < 128 then kuusi
if b1 < 170 then seiska
if b1 = 255 then kasi
yksi:
high 0
goto main
kaksi:
high 1
goto main
kolme:
high 2
goto main
nelja:
high 3
goto main
viisi:
high 4
goto main
kuusi:
high 5
goto main
seiska:
high 6
goto main
kasi:
high 7
goto main
zeroe:
low 0
low 1
low 2
low 3
low 4
low 5
low 6
low 7
goto main
Attached both shematic also.

Vekku
 

Attachments

hippy

Ex-Staff (retired)
I'm not sure why you are using T2400 baud, nor why you have a preamble and pause which is only required for wireless transmission. I'm also not sure why the two separate routines for sending SEROUT are identical.

Both sets of code could be improved by using block structured commands, particularly by using SELECT-CASE in the receiver. The simpler and more understandable you can make the code the easier it will be to debug, maintain and code review.

Code:
#picaxe 08m
do
  readadc 1, b1'lukee matriisin
  readadc 4, b2'lukee joysticin
  if b2 < 120 or b2 > 130 or b1 > 12 then
    high 2
  else
    low 2
  end if
  serout 0,N2400,("data",b1,b2)
loop
Code:
#picaxe 40x1
setfreq m8
do
  serin 4,N2400_8,("data"),b1,b2
 
if b2<125 then ylos
if b2>125 then alas
alas:b3=b2-129*22/10:goto pulssia
ylos:b4=129-b2*24/10:goto pulssiy
pulssia:pwmout 1,99,b3
pulssiy:pwmout 2,99,b4

  select case b1
    case < 10  : pins = 0
    case < 59  : high 0
    case < 65  : high 1
    case < 74  : high 2
    case < 86  : high 3
    case < 102 : high 4
    case < 128 : high 5
    case < 170 : high 6
    else       : high 7
  end select
loop
I'm not at all convinced that the handling of 'b2' and setting PWMOUT is correct in the receiver ( what happens when b2 = 125 ? ) and you have possibly unintentional fall trough from 'pulssia:' into 'pulssiy'.

Noting that when 'b2' is zero, this causes a jump to 'ylos'. B4 becomes 129-b2*24/10, which is 309. I have no idea if that's right or not but that value cannot be held in a byte value and a number greater 198 won't have any affect on PWM which will max out at 100%. Similarly with b2 = 255, b3 overflows, and again PWM may max out.

Is comparing 'b2' against 125 and then using an apparent offset of 129 intended or is it a mistake ?

Without knowing what the code is meant to do related to what the values received are it's impossible to really assess that code.

I'm not sure what the system is doing, not sure what the PWM controls, but if it's in any way safety critical it would seem that you may have created a seriously dangerous program to put into live equipment.
 

salmve

Member
Thanks for constructive criticism.


Quote
"I'm not sure why you are using T2400 baud, nor why you have a preamble and pause which is only required for wireless transmission. I'm also not sure why the two separate routines for sending SEROUT are identical."



I forget tell that i have transmitter in the tx board and receiver in the rx board. I can change it easy with jumper, no need to change code. Same code works with both. Device in the boom head needs three wires (GND, +24V and pump wakeup) from main machine and i have fourpole cable only. So i think wired system is much more reliable and i use that with wired. My rx/tx pair max. speed is 2400. What it should to be with wired system?



Quote
"I'm not at all convinced that the handling of 'b2' and setting PWMOUT is correct in the receiver ( what happens when b2 = 125 ? ) and you have possibly unintentional fall trough from 'pulssia:' into 'pulssiy'."

Yes there is conflict. I noticed it now but nothing happened because pump is off in this value of b2'


Quote
"Noting that when 'b2' is zero, this causes a jump to 'ylos'. B4 becomes 129-b2*24/10, which is 309. I have no idea if that's right or not but that value cannot be held in a byte value and a number greater 198 won't have any affect on PWM which will max out at 100%. Similarly with b2 = 255, b3 overflows, and again PWM may max out."

Potentiometer in ADC 4 input is like this:
http://sakae-tsushin.co.jp/eng_page/pdf/pot/e_RMP30A_H.pdf

I have found those values with try and error method and watch them with debug command. Both pwm out goes 0-255 with this potentiometer. b2 max. is abt. 245 and min. b2 is 13.


Quote
"I'm not sure what the system is doing, not sure what the PWM controls, but if it's in any way safety critical it would seem that you may have created a seriously dangerous program to put into live equipment."

Pwm controls harvesterhead rotator and button drives 8 function in harvester head. All Volvos security systems are in function and there is extra emergency stop knob in cabin.

Vekku
 

PicKidAxe

New Member
i would like to add a few cents to this thread. i use 7805 in automotive all the time. some in all analog circuits and in analog/digital circuits. for critical function circuits i use a handful of components to protect the 7805 and to filter noise. on the noise front muRata is my friend (bnx line). bnx with some "bigger" electrolytics, a few poly caps and ceramics and the output voltage looks very clean vs. input. for protection 1n4004 for reverse blocking and a fast acting zener to clamp any meaningful voltage spikes, or Tyco ROV series. this gets the power past the regulator.... but it has to traverse traces in a circuit board, so i typically place a poly and ceramic on the +V pins of all IC's as close as possible to the pin. for current issues there are a few ways to handle that, from inline auto-resetting disc fuse to standard glass fuse (properly spec'd, etc).

in the end, the $ put into power filtering depends on how critical the circuit is to a particular application or function. and just a fyi, i have had my circuits in my vehicle now for more than 30k miles, not one failure or issue.

so as a comparison, i use LM78M05CTFS quite often, it works well in autmotive apps. i use it because it works, has good specs, and is cheap (~$0.65 vs LM2937ET which runs ~$2.00, @ 1000 pieces the 7805 is more than 4x less expensive !). i do also have to point out that just because the datasheet doesnt say "ideal for automotive use" this doesnt mean it's not a good choice if the specs are all there.
 
Last edited:

Dippy

Moderator
Most of what you have said people have done already.
It's those little extreme moments that can catch people out and could have nasty consequences.
Anyway, this subject was done to death recently , so I'll leave it in your capable hands.
 

BeanieBots

Moderator
It's been said a thousand times and I'm going to say it again.
7805 is NOT suitable for automotive use.
YOU may have gotten away with it, but others may not.
 

manuka

Senior Member
I'd be more concerned that a whiff of digital may go (or NOT go) up the wrong wire at a critical moment. I've had ham radio mates experience twitchy engine running when they trigger their powerful in car transmitter. The good old cigar lighter was really only intended to light cigars with a hot wire !

To be frank I'd thought Rev. Ed's standard PICAXE/car alert was just to cover themselves, but the recent Toyota nightmare has very much shown that even the big boys may fall prey to errant bits. For those brave souls still driving a Toyota , apparently a brake override mod. may help. This allows the car's onboard computer to detect when the accelerator and the brake are being depressed simultaneously,and (if so) to then return the car's throttle safely to idle. Rectifying this "oversight" is looking to cost Toyota $BILLIONS)

Many of these car concerns were echoed by the lengthy time it took for airline adapters to be approved of course, although visions of having the port engine fail as you plugged in your ipod may have been overblown.

Stan.
 
Last edited:

papaof2

Senior Member
I'd be more concerned that a whiff of digital may go (or NOT go) up the wrong wire at a critical moment. I've had ham radio mates experience twitchy engine running when they trigger their powerful in car transmitter. The good old cigar lighter was really only intended to light cigars with a hot wire !
I've never run enough power mobile to encounter interference (always less than 50 watts). My experience goes back to a '57 Chevy with tube gear powered by dynamotors mounted under the hood and controlled by a relay.

In recent years the mobile gear has been 10 meter SSB (CB conversion was published in 73 magazine) or 2 meter FM - obviously all solid state.

I probably should do some RFI susceptibility tests on a semi-autonomous controller I'm building for someone else - time to fire up the low band and VHF transceivers and spray some RF around ;-)

John
WB4HLZ
 

PicKidAxe

New Member
I've never run enough power mobile to encounter interference (always less than 50 watts). My experience goes back to a '57 Chevy with tube gear powered by dynamotors mounted under the hood and controlled by a relay.

In recent years the mobile gear has been 10 meter SSB (CB conversion was published in 73 magazine) or 2 meter FM - obviously all solid state.

I probably should do some RFI susceptibility tests on a semi-autonomous controller I'm building for someone else - time to fire up the low band and VHF transceivers and spray some RF around ;-)

John
WB4HLZ
i myself would not be too concerned about RFI from RF power since placing the picaxe board into a well grounded steel case (or aluminum with mu shielding) should suffice to kill electromagnetic RFI..... i suspect there might be some elevated RFI induced right onto any wires leading in/out of the case, but i also suspect these are extreme cases needing extra attention if the application posed life threatening outcomes. and in such examples there might be more concern for the radiation being absorbed by the person driving, etc.

"not for automotive use" is kinda a general statement. sure, no one should just solder the pic onto breadboard and then shove it under the hood. proper supply filtering, io buffering, and case is probably prudent for just the basic use of picaxe for automotive use.

in general, i am still searching for examples of where/why picaxe failed in automotive use. please supply any links to any info or post here so i can read up on it. thnx.


To be frank I'd thought Rev. Ed's standard PICAXE/car alert was just to cover themselves, but the recent Toyota nightmare has very much shown that even the big boys may fall prey to errant bits. For those brave souls still driving a Toyota , apparently a brake override mod. may help. This allows the car's onboard computer to detect when the accelerator and the brake are being depressed simultaneously,and (if so) to then return the car's throttle safely to idle. Rectifying this "oversight" is looking to cost Toyota $BILLIONS)

Stan.
the Toyota ECM with all of its controls is probably 1000x more complicated than any simple picaxe circuit. i take a wild guess and say the Toyota issue of "SUA" is sensationalized driver error. if Exponent can find tin whiskering or perhaps finds a faulty proximity sensor in any vehicle that claimed SUA then my driver error stance will change.
 
Last edited:

papaof2

Senior Member
the Toyota ECM with all of its controls is probably 1000x more complicated than any simple picaxe circuit. i take a wild guess and say the Toyota issue of "SUA" is sensationalized driver error. if Exponent can find tin whiskering or perhaps finds a faulty proximity sensor in any vehicle that claimed SUA then my driver error stance will change.
A woman my wife works with experienced "sudden acceleration" on her Toyota - after the car was at the deaer for a recall "fix". Her brother was driving and she was in the front passenger seat, so two witnesses. They were on the highway at steady speed, so no "right foot vs left foot" error. This person's "fix" was to go directly to a Honda dealer and trade it for a new Accord.

Based on this report, and the time that Toyota spent trying to hide the problem, I doubt that I will take my truck in for the "floormat fix" (they left out the hooks on the driver side but installed them on the passenger side - I noticed that bit of stupidity when I opened the door the first time). Why not get the fix? Because they now plan to incude the "brake overrides gas if both depressed" fix with any recall repair. I don't trust them to get it right in the short term of a recall fix, since they didn't get other things right in the much longer time of design, prototype, and test. There are occasions (positioning a trailer, especially on a hill) were gas and brake are needed simultaneously (may not affect you, but does affect some of us).

The Toyota debacle on recent models has been a great disappointment, considering that my wife's 1995 Camry is still running well...

John
 

PicKidAxe

New Member
A woman my wife works with experienced "sudden acceleration" on her Toyota - after the car was at the deaer for a recall "fix". Her brother was driving and she was in the front passenger seat, so two witnesses. They were on the highway at steady speed, so no "right foot vs left foot" error. This person's "fix" was to go directly to a Honda dealer and trade it for a new Accord.

Based on this report, and the time that Toyota spent trying to hide the problem, I doubt that I will take my truck in for the "floormat fix" (they left out the hooks on the driver side but installed them on the passenger side - I noticed that bit of stupidity when I opened the door the first time). Why not get the fix? Because they now plan to include the "brake overrides gas if both depressed" fix with any recall repair. I don't trust them to get it right in the short term of a recall fix, since they didn't get other things right in the much longer time of design, prototype, and test. There are occasions (positioning a trailer, especially on a hill) were gas and brake are needed simultaneously (may not affect you, but does affect some of us).

The Toyota debacle on recent models has been a great disappointment, considering that my wife's 1995 Camry is still running well...

John
John,
there is no fix for SUA as Toyota has yet to find anything that accounts for SUA. the Pedal and Mat fix (recalls) specifically address "sticky pedal" and "pedal entrapment".

perhaps the woman's brother was on cruise control, tapped the brake (which would have taken cruise off), and then hit 'up' on cruise lever? that would resume last speed which would cause the vehicle to accelerate w/o floor on gas pedal, seemingly SUA. so was this SUA reported to the NHTSA? or did she just take a defective vehicle to a Honda dealer to trade it in?

i am waiting for Exponent and NASA to come up with something that explains SUA, perhaps some malicious code inserted into a few ECM's by a disgruntled employee? perhaps tin whiskering? perhaps a faulty sensor? dunno yet. the jack-donkey guy in San Diego is a fraud, datalogger shows he kept stepping/switching between gas and brake countless times, which explains why he brake pads were shot and his speeds were high..... human fraud error.

i'm not saying SUA isnt real, just that from the stories i read and lack of data, the cases seem like sensationalized human error, with more proof leaning towards human error (san diego idiot, etc)

as it relates to picaxe, the same concerns apply to any electronics use in automotive applications. simple/careful safe guards will allow its use for non-critical functions (not on OEM scale, perhaps personal use and aftermarket, etc).
 
Last edited:

Dippy

Moderator
Well, I guess the Toyota debate will rumble on...
And we'll have the same mix of genuine faults and Comp-chasers trying to get some money.
And the 'conspiracy theory'....

All the ingredients for the Disaster Equation are there, including; Rush-to-Market , complex electronics, complex software and, of course, the Accountants.


Anyway. I will await the independent expert report before playing the Guessing Game.


"in general, i am still searching for examples of where/why picaxe failed in automotive use. please supply any links to any info or post here so i can read up on it. thnx."
-I don't know of any. But, then again, how many would admit to a fault which would expose incompetence? (or the smart-ass inability to take advice).


There are, without doubt, a few on here that good make a perfectly good device.
Protection for device and vehicle. Correct components, good design, good construction, good installation.


But there are many who can't. And, disturbingly, there are some who think they know.
Then we have the liability question; in the event of an incident will the insurance company blame you and/or refuse to pay - even if unrelated to your circuit. Will they wriggle out? And, of course, it could be worse...

Testing? How can anyone do this at home other than chuck it in the car?
People with a decent budget can give the device a thorough beating before in-situ testing.
Your average hobbyist can't. Just stick 14V on it, wait an hour, yeah, that's OK. Pah!


Summary.
There are a lot of hazardous variables here.
They range from competence , through ability to develop/test , right up to legal.
The safest course is therefore to say We do NOT recommend... etc..


As someone posted before, READ what Manufacturers often put on the Data Sheets as a disclaimer.


Ultimately, it's down to you (plural).
Just don't come near me as I don't know how good you (plural) are ;)
This also applies to Mains electric or Medical projects.

This is another debate that will rumble on and go round and round, so I'm out.
Good luck and read your Insurance documents.
 

hippy

Ex-Staff (retired)
"not for automotive use" is kinda a general statement.
I think it's an issue of how "automotive use" is defined.

For me it means anything which connects to the vehicle power supply, signals or control lines or any controller within a vehicle, directly or indirectly, or to any mechanical mechanism of that vehicle. If it doesn't do any of that, is self-contained, even if used within a vehicle it's not "automotive use".

Where there's an interface to a vehicle that interface has a risk of failure, and that failure has a risk of greater consequences, and those consequences can be life threatening, hence the entire chain backwards is safety critical including the PICAXE and its circuit.

As PICAXE is not recommended for use in safety critical applications, "not for automotive use" logically follows.

Anyone who has worked on any software for long enough will recognise the potential for unexpected software bugs, realise that not all possibilities can or have been tested, that some peculiar combination of factors can cause a software system to catastrophically fail or behave in unexpected ways. Just because software doesn't fail in a billion uses doesn't mean there isn't a bug there waiting to bite. How many times have we seen buggy PICAXE code such as ...

ReadAdc10 1, w0
If w0 > 512 Then ...
If w0 < 512 Then ...

There's less than a one in a thousand chance of that failing. Add another similar bug and it could be one in a million chance of failure, and sod law's may make that even less likely in reality, but the bug really is there. When such bugs are revealed it often seems in hindsight incredible that they were missed and that they had such low impact.

Even if it were possible to ensure safety critical compliance with regards to hardware, that's almost impossible to do for software and certainly so for home and hobbyist programmers. Even if a programmer could guarantee their code we do not guarantee that for our firmware nor do Microchip guarantee their silicon.

Any software that affects a vehicle could affect it adversely, and that safety critical chain is again established, and "not for automotive use" kicks-in again.


in general, i am still searching for examples of where/why picaxe failed in automotive use. please supply any links to any info or post here so i can read up on it. thnx.
I don't think there will be many examples as automotive use is discouraged. There have been posts where people have done automotive projects and report 'no problems', though that should really be 'no problems, so far'. One can never tell if it's by luck or design that it has seemingly worked, whether it is actually okay or on the edge of failing, whether what they have is specific to their vehicle, that what works one day will work the next. That someone played Russian Roulette and lived to tell the tale doesn't mean all will.

I think there have been a few reports of failure issues in automotive use though I cannot point to them. I recall one was related to supply using a standard 7805 regulator.


the Toyota ECM with all of its controls is probably 1000x more complicated than any simple picaxe circuit. i take a wild guess and say the Toyota issue of "SUA" is sensationalized driver error.
It is possible, it's also possible that there is a fault which others are seizing upon which isn't actually to blame in their own circumstances.

I had a six month old car, driving at fairly high speed I had to brake quite hard and the car leapt into the lane of oncoming traffic. To most of the world it probably looked like driver error, failure to leave braking space and having to steer round the vehicle in front to avoid crashing into it, driver error-come-panic in doing that rather than crashing in-lane. Turned out to be the brake calliper sometimes seizing on one side.

It's easy to jump to conclusions, often wrong ones. I'd have assumed driver error as an outside observer of my incident, I don't think my passengers truly believed it was a, previously unseen, intermittent vehicle fault at the time. Even I wasn't sure what had happened at the time, couldn't definitely say it wasn't a subconscious knee-jerk response, though didn't believe it was. One second I was in this lane, the next in the wrong one. Thankfully I steered out of trouble.

I was perhaps lucky that the engineers did investigate and report honestly, not come back with 'nothing wrong, mate'. If they had and some systemic problem did later emerge I'd reflect back on that possibly having been the cause, but no one would ever really know if it was or wasn't, incredibly difficult to prove either way.
 

PicKidAxe

New Member
i think for the most part the anti-automotive sentiment is due to the "dirty" power supply from automotive generator. clean/filter the power and isolate io pins and it should be fine to use picaxe in automotive applications (personal projects, etc, not OEM production scale, etc). if you say "not for automotive use" because depending on how its used it may fault and cause death. same logic applies if picaxe was being used in robotics, if the function can cause death then it doesnt matter where picaxe is used, you now need to change the disclaimer to "do not use in any application or control which if fails could cause bodily injury or death to yourself or others".

i dont see picaxe being any more susceptible than a 555, HEF4520B, LM78M05CT, 74ACT11032, or INA114 op-amp. i use these (less picaxe) quite often in automotive pcb's, some having lots of power filtering, some having none. havent ran across one failure yet, and i have been building for years now.

i think it would be prudent as a test to place picaxe into automotive use with and without power filtering / io buffering, just to see what happens.

as for "what is a automotive application?", i think anything that connects to a vehicle (be it mechanical or electrical) is considered a automotive application.

as for the code example hippy - that is independent of picaxe running on automotive power. having a ut-oh when w0=512 is a coding issue irregardless if picaxe was in automobile or not. and its not just isolated to picaxe uC, any uC having bad code like that is a problem.
 

SgtWookie

Member
So let's say, for instance, that you used a PICAXE to do something like control a fuel injector using PWM.

And let's say that you made a coding mistake or the PICAXE failed, and you had a fuel injector energized during a power stroke, so that your fuel rail became pressurized to several thousand PSI, causing the fuel rail to burst and spray hot fuel all over the engine compartment.

I don't suppose you see any safety issues there?
 

boriz

Senior Member
Is that possible? I’m assuming the thousands of PSI you refer to is exploding fuel/air. Wouldn’t it have to get past the closed valve first? I thought injectors squirted into the inlet manifold before the valve. Could be wrong.
 

SgtWookie

Member
Is that possible? I’m assuming the thousands of PSI you refer to is exploding fuel/air. Wouldn’t it have to get past the closed valve first? I thought injectors squirted into the inlet manifold before the valve. Could be wrong.
The way the manufacturers design it, there's little chance with the OEM setup. The injectors just give a brief squirt during the intake stroke.

But, PicKidAxe seems to think that he can simply apply PWM using a PICAXE to a 2nd injector in each cylinder, reading wideband O2 sensors all the while, to adjust the A/F ratio.

It just isn't that simple.

The injectors actually should be on the manifold side of the intake valve, so they really aren't in the combustion chamber.

But, from the sounds of his original post, he wants to simply apply PWM to a 2nd injector so that it dribbles fuel on the backside of the intake valve continuously. Not a very good plan. I can imagine he'll get some pretty spectacular backfires out of it.
 

Dippy

Moderator
PicKidAxe: The point that hippy was trying to make was how 'easy' it is to have an error in the code that produces an intermittent fault.
Whilst this could be quite amusing when controlling your curtains/blinds/drapes it may be more signifcant in other apps.

I agree with a lot of what you say, but you have forgotten one important issue: and that is the impact of a failure (electrical or code) could have on the vehicle systems.
This will depend on age/make/model of cars.
I've heard several wierd stories about odd effects on car electrics even with simple things like trailer electrics.

Yes, I agree that you can protect just about any device under most circumstances, but a good designer will go for the belt&braces 'worst case' approach. Protect your device AND protect your car.
There is nothing magic about all this, it just requires GOOD design by a GOOD designer who has all bases covered and installed by someone with a brain.
Legal / Insurance is another matter...

I understand Wook's comments re injection. Briefly OT, don't forget that injectors aren't much more than a release valve, the pressurising is done by a pump. i.e. the injector isn't a high-pressure water pistol - unless you have something different? And don't forget DI.
 
Top