You're not using ionic sensing are you?
I've noticed a lot of enthusiasts here and on other sites and probably the world over want a powerful communication link with their vehicle's control modules. wether it's grabbing data to display on our carpc screens, or trying to gain control of outputs without running wires or even adjusting tunes. in a lot of cases you really can't fault the enthusiast, because we all got to make do with what we got or what is available. and the vast majority of what is going on in a given vehicle's electronic control systems are proprietary to the vehicle manufacturer. but here, in this forum on this website, here at mp3car.com there is no excuse. it seems as the majority of people here are very electronics savvy. so I am completely stumped and do not understand why people here will go through all the work and effort to gut the oem entertainment system out of the car and build and wire up a carpc and then limit in a BIG way how they integrate carpc into the vehicle by use of a generic or global obd2 scanner. I do not understand why there is not a plethora of carpc's attached to standalone controllers. understandably some solutions can be very pricey. like aem, or some solutions from edlebrock or other big names. but there are solutions designed meant and intended to cater to the diy'er. a perfect example of this is megasquirt. for a small handful of franklins they send you components and a circuit board. and you build your own engine controller. if you have a 4 cylinder then you solder 4 coil drivers and 4 injector drivers, if you are gonna run egr, then you build the ckt to control that as well. and from that point forward your carpc will be so integrated with the ecu that you can command different afr's, change ignition timing maps, idle speed or anything else on the fly while you drive from carpc touchscreen. without having to worry about how making a sensor lie might impact other areas of the engine controller. and without having to worry about hunting down vehicle specific communication protocols and other hard to come by info. these standalone or aftermarket controllers are designed for people like us. and to that end most of them have auto tuning features, or a side bar that pops up and explains in great detail about the field or menu or tab you just clicked on.
obd2 was forced on the auto manufacturers. it was not their choice and they have been finding ways around it ever since. the latest thing is software updates. anybody with a newer vehicle that has not been back to the dealer in a year or two probably has outdated software in at least 1 module. most of the time there are tsb or service bullitens about this for certain symptoms that a car might experience. and it's big business because you can only get it from the dealer. even the mobile guys that ride around with a laptop or dealer specific scantool solution like the tech2 or drb3 even they have to buy that update from the dealer before they can flash it to your car. it is a bad joke the small datastream or low number of pids and all the codes that are only defined as "manufacturer specific code" I mean seriously, with your carpc connected to your car through generic/global solution if your electronic throttle body fails, you will never know why your vehicle is dead. because that p15xx code will just list as "manufacturer specific code" and how frustrating would that be dead on the side of the road with all that carpc hardware and not even have a clue as to whats wrong?
I am dubbing my controller obdx because its diagnostic capabilities are advanced to say the least. with the engine off I can control all outputs, pulse coils and injectors individually at any hz I like to test part and ckt. if a cylinder should drop compression, I can lean out that 1 cylinder and advance or retard timing to just that 1 cylinder to try to smooth out the engine enough to make it home. these solutions have pc datalogging speeds at a much higher rate than anything you will ever get out of a obd2 datastream so datalogs are more precise and catch momentary afr spikes and burst knock. and with all the general purpose input/outputs or g.p.i.o.'s it can be an extension to your carpc and can aid in further integrations. instead of just pulling a code before I call a tow truck, I have a chance and opportunity to setup my own limp home tune to whatever is failing. if my fuel pressure drops I can radically change my fuel map and double or more the pulsewith to the injectors. if the engine develops a serious vacuum leak I can trim down or completely turn off the idle air control valve. all right there on the side of the road with carputer. if a sensor starts failing like ect or iat or even tps I can simply change its calibration so the value it is reading is close to the value it should be at. and believe it or not guys computer programmers or IT guys make better tuners than auto mechanics. that is a fact. is there anybody else here with a standalone solution? and if so what are you running?
You're not using ionic sensing are you?
no, no. I use traditional knock sensor. and I tune my car to it and have it properly calibrated and when my ems picks up knock, it pulls an equal amount of ignition timing. I know so many people delete the knock sensor, and even less know about newer tech like running current through the spark plug when it's not firing to detect detonation based on ion levels within the cylinder. I am impressed OS. but I do run optical cam and crank sensors for a much cleaner squarewave signal at higher rpm's and lower voltages. oh and my ecu is actually using a wideband o2 sensor instead of just having a guage or for logging only. my car stays in closed loop at wide open throttle and can accurately trim fuel when it is commanded to 12.8:1 afr for my n/a motor. with the individual cylinder fuel and ignition trims, I wish I did have an ion sensing setup.
Optical for a cleaner square wave? Hmmm - that reminds me of those that used to argue optic and Hall were "more accurate" than reluctor because optic & Hall were "digital" LOL! (As if reluctor varies with temperature and diffraction etc as do optic & Hall... )
And those "lying sensor" things - like resistors or uPCs for AFMs etc. What - those vehicles did not use oxygen sensors? (Another money spinner for many.)
But it was because you mentioned compression drops etc, and individually trimmed injectors and ignition timing, I assumed ionic. (Not that you need positional sensors for that. And I'd only use a crank sensor and let the smarts figure out if compression or exhaust, but my systems are envisaged as a complete add-on system to older vehicles with no significant machining nor mechanical work.)
Not that I want to get into those old discussions again - that's long behind me.
well they are more accurate. or at least optical is. and especially when cranking the engine or with a dead alternator trying to drive the vehicle below 10v. that's no argument but proven fact. Chevrolet tried it for a few years on their lt engines with "optispark" but because it sat right below the water pump they were prone to failure from water intrusion and dirty lenses. my ecu will not tell me if I have reduced or no compression in a cylinder. I think I would use the starter for that diagnosis. or better my 2 channel lab scope and low amp probe around the battery cable and using the other channel to monitor cyl #1 coil so I can run a relative compression test by watching amp draw at each cylinders compression stroke while cranking and pinpoint cylinder without a single wrench or socket. I might also be alerted to weak compression with the 4 channel wideband controller seeing one cylinder going way rich. the individual ignition and fuel trims can be done by feedback(auto) or I can set trims. so because I only have 1 knock sensor, I do not have auto ignition trims on individual cylinders. and no matter how bad I want the new tech, I don't think my aem ems-4 supports ion or ionic sensing. think I would need aem's infinity controller for that.
Not that I want to repeat old arguments, but "proven fact"? One manufacturer's problems does not make it universal.
The only issue a reluctor may have at slow speed is low voltage output, but that's more a function of its sensing circuitry's sensitivity. But sensing the 0V crossover (maybe up to +/- 0.6V for poorly designed circuits) requires little voltage unlike Hall & Optic modules which usually require 5V or higher. Plus a reluctor can be its own power source - ie, no battery or supply required for sensing and output pulse - whereas Halls and optic obviously can't.
Accuracy - a reluctor is always more accurate. Whether that accuracy is taken advantage of is a different issue. (I have seen some pretty pathetic implementations.) Mechanically they all have the same rotary shaft variation, but only the reluctor is free from refraction etc issues though their modules (eg, Siemens HKZ series) are designed to minimise or eradicate those.
Your single knock sensor should be able to monitor individual cylinders - that's a software & hardware issue, though certain sensor locations may simplify the process greatly. But a knock sensor has so many noise inputs - which ones do you ignore?. And the sensor itself is often bandwidth limited - certainly its typical associated circuitry is - and what frequencies are required? Does it differentiate between pre-ignition and (pre) detonation?
But that's where ionic IMO is the solution. After all, knock detection itself does not reflect compression but a variety of factors (though like ionic, the knock waveform could be analysed, but let's keep it practical!).
Same with starter motor - too many variables (bearings; starter commutation & non-linearities; engine temperature & mixtures).
And O2 sensors - IMO too slow (not that I know modern 02 sensing times, but they were far from any sort of individual ignition analysis). And then there's the injector and splug issue.
All in all - way too complicated to analyse all the above for meaningful results. From what I've heard, many consider ionic analysis complex enough, and that's a single sensor with limited inputs.
Alas when I looked at ionic there was no commercial (nor production) product available - I was DIYing it - so I have no idea about this millennium's ionic sensing products (other than a revisit circa 2005).
Not that I'm suggesting what way you go. IMO ionic is the only method that is currently practical. The others IMO are fraught with heaps more analysis (and brain pain!) that will yield less accurate results AND are not transferable to other engines.
And I know many that have used novel techniques for the sake of it - ie, the fun of seeing how far they can go rather than having an effective end result (better fuel economy or power etc for worthwhile effort).
But I'll bug out. I was only interested if you were using ionic sensing.
Last edited by OldSpark; 11-25-2013 at 09:44 PM.
saab uses ionic sensing and a few saturns did. also my 4 aem uego wideband sensors and 4 channel wideband controller have no problems keeping up with individual cylinder fuel trimming. the standalone ecu I have is pretty recent tech. it's an aem built ems-4. it will drive an engine all the way up to 25,600rpm. so I am sure it could handle figuring out which cylinder fired just before the knock started. but for the individual trims to work and be accurate they need to be tied to different sensors, because knock retard lasts for more than 1 ignition cycle, if all 4 cylinders were tied to the same knock sensor than all 4 cylinders would retard when the knock event happened. also 1 sensor does not have the resolution to see if the next cylinder down the line picks up knock or if it is the first cylinder knocking harder. all it can see is globally, there is detonation in the engine. if it were available in the aftermarket world I swear I would hunt down that ionic sensing OS. that would push my build over the top. but I digress, for I am quite certain that when it does hit the market, I won't be able to afford it, lol.
and the only reason I haven't drilled and tapped my block and mounted a knock sensor at each cylinder is because to me that is a loosing proposition. I have an inline 4 cylinder, if let's say cylinder 2 only picks up detonation. maybe 3 or 4 degrees of knock retard. not damaging but substantial. then cylinders 1 and 3 will retard maybe 1-2 degrees because those cylinder's sensors will hear that noise, but maybe cylinder 4 won't hear it and will stay advanced and create a lope or imbalance to my motor.
As I wrote, that's a s/w issue, especially since the knock sensor itself does not control the retard.
The one sensor can detect all events, but obviously dedicated sensors make the s/w (read: research and analysis) much easier since propagation delay isn't an issue and the noise of interest is more similar for each cylinder.
I once proposed that one knock sensor would replace multi-sensors, but that was before ionic came along (ie, ionic should replace any knock sensor).
well, the industry sure didn't go that route. most cars today have 2 or more knock sensors so they can better determine which half of the engine is knocking by comparing it to readings from another sensor(s). I mean, I log my raw knock sensor value and study it. I would love to know how to determine which cylinder is knocking vs. varying amounts of knock by any means other than timing it to which cylinder fired before the knock started. and past that point how to determine knock from any individual cylinder once it started. I think this is the reason this new tech is coming to light. also knock sensors don't explain why the knock. from over advanced timing or short on fuel. but I think this new tech will have that resolution. and I mean no scarcasim, OS, I would love to hear your thoughts on using one knock sensor for individual cylinder knock detection. currently that is the only lead I have to follow to achieve individual ignition trims in feedback(auto)
Well ain't the industry lazy! (LOL) Though for V engines I reckon I'd use one per side - it isn't worth the effort (and risk) using one for all.
But does that one per side determine which of the 3 or 4 (V6 or V8) is knocking? If so, they are doing as I suggested - analysing the signal (Fast Fourier Transforms, DSP, etc - as done for ionic (I presume)).
Ionic analysis is "all are the same" whereas a single knocker for multi cylinders adds extra dimensions (like sound delay; attenuation factor & spectrum; etc).
What a manufacturer chooses is a function of the usual factors - time to release, initial versus long term cost, etc. I could imagine initial release of one sensor per cylinder else "bank retard" etc of cylinders based on a single (per side or per engine) sensor. Then if that model (engine) proves successful, they do the analysis and programming to bring nett production costs down - ie, one sensor per side or engine whilst achieving individual cylinder response - to improve "power" acceleration or overall fuel economy (whatever the aim is).
The beauty of the knock sensor is that it is another closed loop system that enables backing off - eg, retard the timing - irrespective of what the preset program thinks the (non knocking acceptable) result is. It's like 02 sensing except that preventing knock prevents damage. [Or in some (ancient?) systems, allows maximum advance and hence best power/efficiency. ]
I'm surprised some choose to disconnect the knock sensor, but maybe they want acceleration even if for mere seconds (tho knocking IMO usually means a decrease in output). But I've seen enough ignorants fit bigger injectors expecting more power (or add AFM resistors or disconnect O2 sensors just as I used to see bigger carbs fitted to older vehicles; or baffles pulled out of exhausts etc WITHOUT additional compensations), and I remain ignorant of newer valid reasons (ie, I was into all this before SAAB even had their trionic system).
Of course (tr)ionic systems should achieve all the above. (Don't tell me I'm still ahead of the pack?)
BTW - the knock sensor won't determine why, but in conjunction with the O2 sensor (else ionic, but that does both) you can eliminate lean mixture as the cause (assuming O2 sensors are as quick as you say, and exhausts are properly tuned and mapped).
Last edited by OldSpark; 11-27-2013 at 02:50 AM.