home register FAQ memberlist calendar

Go Back   Turbobricks Forums > Mechanical > performance & modifications > aftermarket engine management

Reply
 
Thread Tools Display Modes
Old 04-20-2021, 04:41 PM   #1
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default Arduino LH Jetronic interface: live data + MicroSD logging + ELM327

Hello everyone, my name is Diego and I live in the north of Italy. I recently posted a question in this forum about the reverse engineering of the Tq-signal that the LH Jetronic send to the EZK.
I've immediatly found some users interested when I described the project on which I'm working on and I was invited to open a new topic to create a place where to talk about and to share tech information and experiences.

Since it's impossibile to query the live data from the LH-Jetronic of my Volvo 945 I decided that I could try to build an interface that, acting like a network sniffer, decodes all the I/O signals directly through the control unit connector using my DIY breakout-box.

This is a picture of the board in the state it is today:


The project started last summer when I decided that it was the time to learn something about this Arduino who talk everyone. Today it's still under development and some parts are yet missing but the board is already usable for some tests and it is in a state that is much more than a proof of concept.

The board is divided in 3 main layers:
  • 12V car layer: here I put all the circuitry that is powered by the battery of the car. Here is where I put active filters, resistos, OpAmps and anything I need to drive the led of the optoisolators. I've also used some microswitches to be able to enable/disable each single signal without disconnect any wire.
    I still have to add an overcurrent protection circuit (a couple of fuses it could be the minimum)
  • Optoisolators layer: here I put the optoisolators (now I'm using both the 4N35 for the digital signals and the HCNR201 for the analog ones)
  • Arduino layer: here I put all the 5V circuitry from the transistors of the optoisolators to the input pins of the Arduino board

The Arduino board I used is an Arduino Mega 2560 since it supports 6 interupt pins and many digital and analog input pins plus the following shields:
Here some screenshots of the GUI I've designed with a brief description of the available functions:


Injection screen


  • Ton is the pulse time of injectors
  • Tq is the engine load (yet under reverse engineering, at the moment I read the raw pulse width in μs)
  • rpm is obvious
  • λ is a graphical tool that shows the deviation from λ=1 (stechiometric mixture), it uses a configurable lenght circular buffer to calculate a mobile avarage plus the voltage produced by the oxigen sensor
  • hummer is when engine is knocking (yet under reverse engineering)
  • switch is the idle switch on the throttle body
  • IAC is the PWM of the idle air valve that measures the opening %


Cooling system


  • 1 Fan: show when radiator fan is active at low speed
  • 2 Fans: the same at high speed
  • ECT voltage: voltage of the ECT sensor but I support the LH doesn't read a voltage but a current that I could measure using a breakout-box
  • ECT temperature (at the moment I use a quadratic interpolation function base on the voltage but I don't think that is too much precise)


Oxigen sensor


  • Media mob. (in english mobile avarage): is the configurable lenght in seconds of the samples
  • n. camp. (in english number of samples): report how many samples are in the circular buffer
  • The λ % indicator reports for how much time the mixtures was rich or lean
  • Oxigen sensor voltage
  • Same λ graphical tool of "Injection screen"


Tachimeter


  • Giri (engine rpm)
  • VelocitÓ (vehicle speed)
  • Nice To Have: instant fuel consumption, must be measured the opening and closing latency of the injectors with a scope or by consulting a tech paper (more documentation is need)


ELM327 Emulator



Report the status of the bluetooth ELM 327 emulator.
At the moment I support only the following PIDs but I want to supports as many as I can.
  • 010C engine rpm
  • 0105 Engine coolant temperature
  • 0114 Oxygen Sensor 1
  • 0D Vehicle speed (incomplete)

For this feature I made a derivated work from the library GTTurboEcu since the orginal version works only with SoftwareSerial and I had found some random hangs when the rpm signal that I was reading using interrupts changed quickly.
So I added the support to HardwareSerial too by introducing an abstract layer interface and in this way I solved all my problems.
NOTE: I've tested it only with Torque on Android but it may also work with other compatible scanners


MicroSD real time data logger



To be implemented.
I've some ideas to be developed, for example I could create the commands to start/stop the logging and to choose which signal include or the max leght of each recording.
I was also think at a injection map reverse decoder (by only driving the car it could be relative easy to rebuild the real injection map also without accessing to the memory of the control unit and it could also be possibile to measure the deviation (min vs max) of injectors pulse width that could help in diagnosys (for example in the case of a roughly engine)
Any suggestion here in usefull features is really appreciated.


Setup



To be implemented
For example I would like to add i18n support


That's all
I hope to finish the board within this year but I don't have none that runs me back so I will take all the time I need.
Anyway I'm curious to start testing it on the car (at the moment I tested it only on my desk using a signal generator and a DIY injectors emulator that I build using a fuel relay drived by a Darlington transistor with a zener 60V diode as overvoltage protection to replicate as much as possible the same waveform of the real injectors)
Finally I will return to work on the software Kikad becasue It could be fantastic to get a PCB and collapse this large prototype board into a little device that stays in the palm of one hand.


Opss... I was forgetting to share you at least one picture of my DIY breakout boxes.
Without them and the my friend Picoscope 2204A this project could be really hard to carry on, if not impossibile.
Here more pictures hoping they could be useful to someone: https://photos.google.com/share/AF1Q...lMZVRiMExMek9R

apollokid is offline   Reply With Quote
Old 04-21-2021, 07:50 AM   #2
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

Hi Diego, Wow, you've done a lot of work! Very nice.

A couple years ago, I started to work on a similar project to monitor LH2.4+EZK using a simple Arduino board. I wanted
- a dashboard Multi-Gauge LCD display for use while driving, and
- full speed logging for offline tuning and graphing

At the time, I was only monitoring the EZK signals, plus a Wideband O2 input and a MAP pressure sensor input. This is what my benchtop setup looks like, with a couple different displays (click pictures for bigger size).







The items shown are:
- RPM
- Load - the width of the ECU Tq Load signal in microseconds (proportional to injector on time)
- Vbat - battery voltage
- Idle - the TPS idle switch
- DegF - the coolant temperature, currently the raw ADC value, not yet converted to degrees
- AFR - Wideband O2
- Spk - spark advance in degrees
- Dwel - spark dwell time in milliseconds
- KpA - input from MAP pressure sensor (currently connected to pot for testing)

For testing, I have a LH2.4 ECU and a EZ116K connected with a chopped off harness to a simple engine simulator board. The switches are for some of the sensors (temperature selects 3 resistors -- normal, hot, cold), and the one knob is for the MAF (or AMM) voltage. RPM (60-2 wheel signal) is from my Hantek oscilloscope pattern generator.


To connect to the EZK signals, I soldered wires to the connector pins inside the box. I think this will work in the car, but it's not pretty.


After working on the project for a while, I ran into some problems:
- The Arduino Nano that I was using didn't have enough pins to monitor EZK+ECU and support a LCD display
- Updating the LCD display (over SPI) was much slower than I liked.
- The LCD library (Adafruit GFX) occasionally glitched when sharing the Arduino with my interrupt-based measurement code. I think this is a common problem for Arduino libraries, that they don't work well with other interrupt based libraries.

I got busy with other projects and this one has been gathering dust for at least a year. With your inspiration, I've started to work on the project again.

Instead of using a single Arduino to do everything, I want to change the architecture to use 2 Arduinos. One would do all the measurements and only use a simple serial port interface. This can be connected to a Bluetooth module for logging and display on a PC or smartphone. If I can figure out the protocol, and there are not any legal issues, it would be nice to support TunerStudio or MSdroid software applications. For the in car dashboard multi-gauge, a 2nd Arduino and a small LCD display would be used, with a serial interface to the 1st Arduino.



I need to work through the available pins on an Arduino Pro Micro (32U4) to see if they can monitor all the ECU, EZK, and extra signals that I want. I'll post a pin usage proposal when I'm done.

In Italy, what hobbyist PCB companies do you have access to? There are a couple Chinese companies that are now offering PCBs plus assembly with common surface mount parts. Can you get PCBs from jlcpcb.com or seeedstudio.com?

-Bob
__________________
'85 245glt b21ft aw71 k-jet -> lh2.4
bobxyz is offline   Reply With Quote
Old 04-21-2021, 10:12 AM   #3
esmth
Board Member
 
Join Date: Jul 2016
Location: MA/NH
Default

Very impressive, both of you. Definitely farther than I have gotten, mine is really only CLI software running on a laptop. I am especially jealous of those neat bread/perf boards. Mine always turn into jumbled messes.

I need to make me one of these bench setups to run LH and EZK out-of-car. My volvo is my second office!

It is news to me that the 'TQ' signal is proportional to injector open time. That is good to know.

For the OLED/LCD UI in the past I have used u8g2. I think it only supports mono screens but it is very lean and configurable. It leaves plenty of CPU time and memory for other things. I do like the idea of dual MCU boards with one being the data sampler and the other being the displayer/logger. Lots of room to grow

I am not a laywer but I think one can get around the fcc/radiation legal issues by just not including the bluetooth by default. Just let the end user source the bluetooth module separately and plug it in.
__________________
1991 244 LH2.4 M46 352k miles

Last edited by esmth; 05-10-2021 at 10:17 AM..
esmth is online now   Reply With Quote
Old 04-21-2021, 05:53 PM   #4
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

For the moment I didn't find flickering problems with the display but I'm using only 2 interrupt pins to read rpm, injectors pulse and Tq but may be I will need a third interrupt so I will have to find a solution.
My idea was to connect each digital signal to its own digital pin on the Arduino board and connect also each of these signal to an OR logic gate which output activates the interrupt pin.
The interrupt routine then should read all the digital pins of a port and then check each single bit in order, from the one with the hightest priority to the lowest.
It should not be a complex circuit in my opinion, and if the logic gate is sufficiently fast I believe that it should works.

For PBCs, I made only one little PCB in my life and for producing it I've used the jlcpcb.com service.
No SMD, only through hole components. Price and quality are very good in my opinion.
apollokid is offline   Reply With Quote
Old 04-22-2021, 04:41 AM   #5
Swedbrick
Board Member
 
Swedbrick's Avatar
 
Join Date: Oct 2016
Location: Netherlands, Source of Grolsch
Default

To chip in on the DIY PCB making, I've made several and prints through jlcpcb. SMD soldering is doable at home, just make sure you get thin solder, tweezers and a smaller soldering iron tip. I got a Velleman VTSS230, those also come with a hot air side so you can quickly reflow components to pull them into the pad nicely
__________________
Volvo 745 - IPD springs, 25mm/19mm swaybars, K-cam, LH2.4, M90 swap, 3.54 \w racingdiff lsd, track/daily
-------------------------------------------------------------------------------------
I sell LH2.4 Chips for Europe!
Swedbrick is offline   Reply With Quote
Old 04-22-2021, 08:06 AM   #6
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

Glad to hear that you can use jlcpcb.com. That makes it easier for anyone to order boards directly, instead of my needing to figure out customs and international shipping.

I was going to use KiCad, but I think we should try the online EasyEDA.com tools instead. I just setup an account at oshwlab.com so we can share design files. I've never used either of these before, so I hope they work well and have a high quality library of PCB footprints. It will be a learning experience.

My eyesight and nerves make surface mount assembly and rework challenging, but jlcpcb can do small volume SMT assembly with common parts. Are you OK with surface mount resistors/capacitors/diodes on the initial prototype boards? Probably 0805 and SOT-23 sizes (but I'll use bigger if jlcpcb has them in their common parts library). Or would you prefer all through hole so that you can assemble/modify it yourself?
-----
I'm still looking at the pin assignments for the Arduino. I'd like to monitor these signals:
- EZK: Vbattery, RPM, ignition, load, temperature, idle switch, knock enrichment
- ECU: MAF, injection, VSS (vehicle speed), IAC (idle air - optional?)
- Other: wideband 02, MAP pressure

Anything else I should try to include?
bobxyz is offline   Reply With Quote
Old 04-22-2021, 09:38 AM   #7
Wobsmangbaffler
Newbie
 
Join Date: Nov 2020
Default

How are you measuring the car speed? I am currently doing a similar project but it is only for measuring the speed of the car, and not inputs from LH / EZK.

The technique I used was:

- Take sine wave signal from rear axle

- Filter through a full bridge rectifier to make it all positive voltage

- Use capacitors to smooth the pulsating signal into a smooth voltage level

- Use analogread() to measure this average voltage, which correlates to vehicle speed

Does LH have a different way of measuring vehicle speed?

Interested to know!
Wobsmangbaffler is offline   Reply With Quote
Old 04-22-2021, 09:46 AM   #8
esmth
Board Member
 
Join Date: Jul 2016
Location: MA/NH
Default

Quote:
Originally Posted by Wobsmangbaffler View Post
How are you measuring the car speed? I am currently doing a similar project but it is only for measuring the speed of the car, and not inputs from LH / EZK.

The technique I used was:

- Take sine wave signal from rear axle

- Filter through a full bridge rectifier to make it all positive voltage

- Use capacitors to smooth the pulsating signal into a smooth voltage level

- Use analogread() to measure this average voltage, which correlates to vehicle speed

Does LH have a different way of measuring vehicle speed?

Interested to know!
if I recall, the VSS sensor in the diff produces an AC voltage that is wired to the cluster speedo/odo. Inside that there is a UAF2115 chip which converts the AC frequency to a open collector signal that LH weakly pulls high and counts when it is pulled down. It'd probably be best if you counted this post processed signal instead of trying to process the AC voltage yourself. The AC from the sensor is pretty high, I have measured over 90 volts from it with a high impedance meter.
esmth is online now   Reply With Quote
Old 04-22-2021, 02:40 PM   #9
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

If you're talking about a 240 with an electronic speedometer, then yes, a pre-processed and filtered VSS signal is easily available. The filtering circuits are on the speedometer PCB. The signal goes to the ECU as part of the 9-pin or 11-pin cabin/gauge connector that joins the engine harness near the ECU/EZK. Check your wiring diagram, but it's normally a blue-black wire. The signal also comes out the back of the cluster to 2 side-by-side spade tabs just to the left of the speedo housing.

On the face of the speedo should be a K10042 or K41068 number, or something close. The 10042 or 41068 is the number of rear axle pulses per mile. The pre-ABS cars use a 12-tooth differential pickup; ABS cars use 48-teeth. You can lookup the revs/mile online for your tire size, and multipy by 12 or 48, to get the Kxxx number. The speedo in the ABS cars divides the rate by 4 so that the VSS signal to the ECU is always for 12 pulses per axle rev.

As esmth said, the signal uses an open collector driver with a pullup resistor in the ECU. It will swing between ~0volts and ~13volts (IIRC). You can use a simple resistor divider to drop it down to 5volt logic levels (keep the combined resistance over ~20K to avoid distorting the signal still going to the ECU). You'd then want this to drive an interrupt pin, with a tiny bit of code that increments a counter on each pulse.
bobxyz is offline   Reply With Quote
Old 04-22-2021, 03:10 PM   #10
Swedbrick
Board Member
 
Swedbrick's Avatar
 
Join Date: Oct 2016
Location: Netherlands, Source of Grolsch
Default

Quote:
Originally Posted by bobxyz View Post
I was going to use KiCad, but I think we should try the online EasyEDA.com tools instead. I just setup an account at oshwlab.com so we can share design files. I've never used either of these before, so I hope they work well and have a high quality library of PCB footprints. It will be a learning experience.
I've used EasyEDA before, the installable version works well, however tends to force you to use their parts warehouse, which can lead to some interesting parts number variations. Especially transistors and small logic chips tend to have different pinouts on smd variants, so beware. Their routing software is great and the design rule checker is also accurate. It takes a bit to get used to how to use via's and create ground planes, but hey, it's free

SMD soldering does require a steady hand, I mostly stick to 0603 and 0805 for hand work. 0402 is doable, 0201 is insanity. This board is mostly 0603, with SOIC pin spacing, and done by hand in around 30m. I designed it in easyEDA and ordered through JLCPCB, to give an idea of the SMD quality.



A set of small tweezers and a ESD safe work area are very good tools to get for smd work, as the components are more delicate both in mechanical and electro static damage Also stuff like cleaning of small tin balls and flux become more significant, so for a first prototype through hole is probably a good option if you don't want to invest a lot initially and have space to debug.
Swedbrick is offline   Reply With Quote
Old 04-22-2021, 06:05 PM   #11
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

Also if I'm a newbie in electronics and I've never tried to connect my Arduino board directly to the car, I believe that is much better to decouple all signals using optocouplers also if it will increase the circuit complexity.
Car is a high noisy environment and all signals are full of spikes both positive and negative and the arduino inputs will be damaged from negative voltages (and also from voltages that exeed the power supply). May be I'm wrong, but I remeber that the voltage limits on input pins are -0.5V to VCC+0.5V max

Injector pulses spikes is an extreeme example (up to +60V) but spikes are also negative and afflict all signals due to cross talk and EMI interference.

This for example is the waveform of the real signal that the odometer send to the LH (taken from my 940 when was running at 40km/h) and as you can see the average of the negative spikes was -1.3V




Furthermore if it is used a voltage divider to derive a 5V must be aware that to not increase the impedance of the circuit under measure must be used very large values of resistors.

In my circuit for example I used to drive the optoisolator directly only for signal with a high current supply (eg. injectors, fan relays, ecc.) but for signals that come from electronics like this one I used a 1MΩ resistor to limit the impedance and then an OpAmp to drive the led of the optoisolator. And to be more safe, I connected a diode in antiparallel to protect also the led of the optoisolator from reverse voltage spikes since also leds will be easily damaged from negative voltages.
apollokid is offline   Reply With Quote
Old 04-23-2021, 08:51 AM   #12
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

I don't know how bad the electrical noise will be. I'm planning to start with simple passive filters (Rs and Cs), and just resistor dividers to get to 3.3v logic levels. For sampling the inductive signals, injection and IAC, diode clamps will be needed due to the big voltage spikes. I'm hoping this will be good enough.

Since this project is only monitoring the engine, and not controlling anything, "good enough" means that the board doesn't overload any ECU/EZK signals, and that the measurements are usable. An occasional glitch is OK, but I'd prefer no glitches. I may do an early prototype without any noise filtering just to see how bad it is. If noise is really bad, some filtering can be added to the Arduino code too. If needed for noise analysis, I have a big high-bandwidth Lecroy oscilloscope that I can haul out to the garage to see what's really happening.

My plans for the next week, assuming no bad Moderna#2 side effects, are:
- finish Tq measurements on '951 '937 and '954 ECUs
- draw up rough schematics, start searching for appropriate "basic" and "in stock" JLCPCB parts
- maybe work on a hand-wired prototype
bobxyz is offline   Reply With Quote
Old 04-23-2021, 12:56 PM   #13
142 guy
Board Member
 
Join Date: May 2014
Location: Saskatchewan, Canada
Default

Quote:
Originally Posted by apollokid View Post
Also if I'm a newbie in electronics and I've never tried to connect my Arduino board directly to the car, I believe that is much better to decouple all signals using optocouplers also if it will increase the circuit complexity.
Be aware that opto isolators have a down side. Their high frequency response is not spectacular. I use opto isolators on the inputs from the optical sensors on my tach and cam wheels on my MSII installation. The tach wheel is equivalent to a 12 tooth crank wheel and at 6000 RPM you can definitely see that the output of the opto isolator is starting to distort. Take that into consideration when assessing the use of the opto isolator

For analog input values an RC filter combined with a zener diode to clamp voltage spikes can provide provide good input protection. If you think your input might be exposed to some really nasty voltages you might want to consider an MOV on the input. If you have binary / digital inputs, you can also use schmitt triggers to condition the input. They are typically used to debounce contacts so they will eliminate crap showing up on the input to the controller. The Toshiba TC4584 is a hex schmitt trigger that has been around for 30 +years and is available in DIP and SOP packages. There are more modern versions available.

If you are dealing with changing analog level voltages, you might want to consider a level translator IC (not a level shifter which is for binary signals) rather than a resistive voltage divider if you have loading concerns. You can also design your own level translator with an Op Amp; but, you may need a large selection to input and feedback resistors to get the gains where they need to be.

I can't comment on the relative merits of the various PCB design tools; but, I am currently using the free version of Eagle. With their on-line tutorials I was able to enter a schematic, massage the traces on the board and generate the required gerber files to produce a board in two days. The free version of Eagle is limited to two layers if that is a consideration.

I have done SMD ICs down to a 0.02" spacing between pins. Being a shaky old guy, I glue the chip down on the board using a tiny dab of slow set CA (so I can get the chip into position). Once the chip is set, I slather the pins with flux using a flux pen. I have a small hot air rework station and using the smallest nozzle I heat the pins and dab each pin with some really fine 27 AWG solder wire. I can usually get by without bridging the pins; but, if I do, pressing some solder wick on the bridge while applying heat from a fine tip soldering iron usually fixes that. SMD resistors and capacitors are actually harder to install than the ICs because they are so small that placing them on their pads is difficult and it is really easy to get too much CA which can contaminate the solder pad. If space isn't an issue I will stick with through hole passives rather than using SMDs. Gluing down the parts is critical to my particular process since the hot air tool will blow the parts all over the board if they are not fixed in place. My hands are way too shaky to try and solder SMDs with a fine tip iron. A set of optivisors is also really useful so I can actually see the individual pins on the SMDs.

If you can find a board fab facility that can install the chips that you want for a reasonable price that is a good solution. I use OHSPark for my boards and they provide high quality at good prices with relatively fast turn around. But, they do not offer complete board fabrication services.
142 guy is offline   Reply With Quote
Old 04-24-2021, 05:13 AM   #14
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

Thank you very much 142 guy for your reply.
As I wrote my knowledge in electronics is limited (I'm not so young, I'm 49 years old and when I get my bachelor degree in informatics I didn't studied anything of electronics, just 3 years at the high school when I was young)
To build this project I had to relearn near everything from scratch (also C and C++ that I've never used in my whole job career, not only about ardunio and electronics) so every new information that can help me to improve is really appreciated.

I agree with you that for analog signals a low-pass filter that cuts high frequencies (for example greather than 10kHz) works very well and I admit that I have already used it to successfully clean the signal of the oxigen sensor that is one of the worst noised signals, full of spikes up to ▒5V also if the signal is between 0V and 1V

I want to show you why I've arrived to the conclusion that optoisolators could fit for my need, but I'm ready to restart from scratch if someone show me a better solution to handle signals.
When I started my project I searched a lot on internet and I subscribed to a forum of electronics trying to do my best to do the things in the right way but it was a so niche materia that I had to find a solution by my-self since I didn't find anyone who could had help me.
I used optoisolators, but I'm pretty sure that LH doesn't use them.

My worst throuble was how to read the pulse width of the injectors without damaging arduino, without affecting the circuit under measure and above all to not damage anything in the car.
The only things that I was able to understand is that zeners has some capacitance that slower the fall of square edge and diodes in general affect the speed of the magnietic field collapsing due to the recirculation of current inside the coil.
Since I was unable to determine how much energy must be released when the injectors close (and since my snubber circuit could have interfered with the electronics of the car) I decided that optoisolators could be the safer way.
I was too much scared to make stupid things and to damage something due to my poor experience.

You told me that you find problems using optoisolators for your tach and cam wheels on my MSII installation. Can you explain me better why?
A 12 tooth crank wheel and at 6000 rpm means a frequency signal of 1200Hz, before writing this reply I retested my 4N35 (that is not classified as a fast optoisolator) to see its performances and what you say is true, optoisolators start to distort the signal when frequency rises but up, but at 5kHz the signal shape, also is not perfect, is yet near accettable in my opionion.

1.2kHz Test
2kHz Test
5kHz Test

The other signals I had to sample are all at a lower frequency, eg. at 6000 rpms the rpm signal is at 200Hz frequency, and also the speedometer reaches 300Hz at 210km/h so it should be not a problem so I decided to use near the same system for al digital inputs.

The only signal that starts to beacame a problem is Tq-signal since I measured it and is in the range of 20Ás to 240Ás (on my car) and so near the limits of the 4N35 that has 10Ás of switching time. Also the way I used arduino is near its limits since I use interrupts with multiple digitalRead() that take near 5Ás for each execution.
For this reason I started to read the ATMega manual beacause I want to learn something about hardware Timers (all new thing for me, and not so easy to learn) to find a better way to take the measure of these short pulses.


About using of Schmitt triggers to clip spikes from rectangular signals seem a good idea, did you tried it?
All the things I've red about this type of comparators with hysteresis were only to square a sine signal but thinking about it they should also remove spikes that go outside the supply voltages (in theory also a standars comparator and may be also a simple BJT transistor used in bjt saturation/interdiction region)
A final question that scares a little to me: how is easy to lead IC to latch-up with spikes, especially after having connected the GND of the car to that GND of arduino? This is for me yet a dark area of knoledge but is another of the reasons for which I thinked that to keep a galvanic isolation between the circuit of the car and the circuit of arduino was a good idea.
apollokid is offline   Reply With Quote
Old 04-24-2021, 12:20 PM   #15
Swedbrick
Board Member
 
Swedbrick's Avatar
 
Join Date: Oct 2016
Location: Netherlands, Source of Grolsch
Default

For my thesis project, where I modelled a b230 engine and did some measurements to compare, this piggyback datalogger was used for real world measurements. It ran a arduino uno with a sd card shield, although I ended up using serial as it ran faster for the datalogs.


The schematics might help you out, I used comparator circuits directly connected with a relatively high imput impedance (10k ish). All circuits used a basic diode clamp to protect the chips and it held up well.


Another option you could explore is using 12v input comparators, as a buffer to the arduino and just using a resistive divider to convert down. Keep in mind that these spikes are a symtom of the high input impedance of your measurement device, and usually do not contain a lot of power. A simple capacitor or load resistor at the input could easily dissipate these energies before they reach your microcontroller
Swedbrick is offline   Reply With Quote
Old 04-24-2021, 05:30 PM   #16
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

Quote:
Originally Posted by Swedbrick View Post
Keep in mind that these spikes are a symtom of the high input impedance of your measurement device, and usually do not contain a lot of power. A simple capacitor or load resistor at the input could easily dissipate these energies before they reach your microcontroller
Yes, spikes on signals are mainly due to the cross talk, more a signal has a high impedance and more noise it captures. (That's why O2 is the noisest)
I used resistors much greather than yours because I thought that the interface must work like a multimeter and avoid to increase the load on the signal under measure since it could affect also the readings from the ECU and become cause of malfunctions.
It seems instead that for this application it is not so mandatory, and indeed, if I forget for a moment the signal of the injectors, only a couple of fast diodes is adeguate to filter the spikes of all other digital signal.
I believe I could simplify a lot the circuit with your tips.

Thanks
apollokid is offline   Reply With Quote
Old 04-25-2021, 12:14 PM   #17
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

@Swedbrick: since I had at home a few Schmitt triggers IC (SN74HC14) I built a quick&dirt circuit for injectors singnal and it works perfectly as expected.
I was shotting to mosquitos with a gun, I really thank you very much.

You didn't have an idea on how much time I spent on building the circuit for the HCNR201 using a single supply when it was so easy with a common GND

P.S. many thanks also to 142 guy and also to bobxyz that invited me to open this thread (when I say you I was thanking all of you, but is better to be explicit)
apollokid is offline   Reply With Quote
Old 04-25-2021, 01:02 PM   #18
142 guy
Board Member
 
Join Date: May 2014
Location: Saskatchewan, Canada
Default

Quote:
Originally Posted by apollokid View Post
Thank you very much 142 guy for your reply.

The only things that I was able to understand is that zeners has some capacitance that slower the fall of square edge and diodes in general affect the speed of the magnietic field collapsing due to the recirculation of current inside the coil.
Since I was unable to determine how much energy must be released when the injectors close (and since my snubber circuit could have interfered with the electronics of the car) I decided that optoisolators could be the safer way.
I was too much scared to make stupid things and to damage something due to my poor experience.

You told me that you find problems using optoisolators for your tach and cam wheels on my MSII installation. Can you explain me better why?
A 12 tooth crank wheel and at 6000 rpm means a frequency signal of 1200Hz, before writing this reply I retested my 4N35 (that is not classified as a fast optoisolator) to see its performances and what you say is true, optoisolators start to distort the signal when frequency rises but up, but at 5kHz the signal shape, also is not perfect, is yet near accettable in my opionion.


The other signals I had to sample are all at a lower frequency, eg. at 6000 rpms the rpm signal is at 200Hz frequency, and also the speedometer reaches 300Hz at 210km/h so it should be not a problem so I decided to use near the same system for al digital inputs.

The only signal that starts to beacame a problem is Tq-signal since I measured it and is in the range of 20Ás to 240Ás (on my car) and so near the limits of the 4N35 that has 10Ás of switching time. Also the way I used arduino is near its limits since I use interrupts with multiple digitalRead() that take near 5Ás for each execution.
For this reason I started to read the ATMega manual beacause I want to learn something about hardware Timers (all new thing for me, and not so easy to learn) to find a better way to take the measure of these short pulses.


About using of Schmitt triggers to clip spikes from rectangular signals seem a good idea, did you tried it?
All the things I've red about this type of comparators with hysteresis were only to square a sine signal but thinking about it they should also remove spikes that go outside the supply voltages (in theory also a standars comparator and may be also a simple BJT transistor used in bjt saturation/interdiction region)

A final question that scares a little to me: how is easy to lead IC to latch-up with spikes, especially after having connected the GND of the car to that GND of arduino? This is for me yet a dark area of knoledge but is another of the reasons for which I thinked that to keep a galvanic isolation between the circuit of the car and the circuit of arduino was a good idea.
First off, I did not mean to imply that you should not use opto isolators. Its just that you need to be aware of the frequency limitations. It seems like you are already aware of those problems so you should be able to apply the opto isolators correctly. I did a couple of posts about 4 -5 years ago in the Turbobricks Aftermarket Engine Management forum discussing the potential problems with the 4N25 opto isolators as used in MSII. I included waveform captures showing the signal distortion. MSExtra uses the cam 'tooth' to define the next tach tooth as the first tooth. You have the option of defining the tooth edge as the rising or falling part of the signal. The 4N25 opto isolator distortion was not the same on the rising and falling edge of the signal. I did a quick search; but, I am not able to find those posts that I did. However, I think my point at the time was that by picking the correct edge for triggering you could eliminate the impact of the distortion and it worked fine. Also, that it probably would not work if you used something like a 36 tooth wheel. As long as you are aware of the limitations then you can make use of the opto isolator.

As an observation, if you want to pick up engine speed or the output ignition timing by sensing the voltage on the negative terminal of an ignition coil, the opto isolator circuit as used in MSII would provide an excellent circuit for conditioning the input and on a normal B230 the switching frequency is well within the response range of the 4N25.

As a suggestion, if you want to pick up the duration of the injection pulse, the injectors are controlled by a power transistor or a power MOSFET. Why not measure the base or gate signal to the switching device? The base or gate signal will typically be at the logic level for the EFI controller (5 volts or 3.3 volts ??). It should be a clean signal and I expect that the input impedance to the Arduino is high enough that it will not affect the output drive current from the EFI controller significantly. The drive current on an opto isolator would probably be higher than the additional current being sunk into the Arduino. The datasheet for the ATMega should specify the input impedances. If you want isolation you could install a really high impedance op amp in voltage follower mode between the EFI controller and the arduino.

My experience with Schmitt triggers is primarily in debouncing on input contacts. The schmitt has two output levels, logic low and logic high which is what the arduino wants. You do need to respect the voltage limits on the schmitt trigger hardware so if you expect high voltage transients so you may still need to protect the input. Obviously the schmitt is restricted to cleaning up digital inputs only.

Input voltage protection could be as simple as a filter capacitor which filters out high frequency transients with a zener or perhaps a MOV if you think you have something really nasty. You are correct that zener diodes have junction capacitance; but, in reverse voltage mode the junction capacitance for low wattage diodes is typically less than 1000 pF which is likely not going to be a problem for lower frequency signals. The dual diode arrangement that Swedbrick shows for analog input voltages is excellent because it limits signal excursions to the magnitude of the supply rail voltages plus the Vfd of the diode. The supply rail will have some internal source impedance so the limiting will not be perfect.

Are you trying to use digital reads to capture high speed events? I am not a skilled C coder; but, I think the preferred way to do that is to attach an external interrupt to a digital pin and when the event occurs set a flag in the interrupt service routine. The main code uses the flag to start a timer (timers generally do not work in the ISR). Better yet to use hardware timers; but, those require more skill / knowledge as you are discovering. If you want to capture a leading and trailing edge on a pulse you may need to use two separate interrupts because you need to specify whether capture occurs on going high or going low. There are some interrupts that allow you to capture going both high and going low; but, you don't know which so you don't know whether it is start of pulse or end of pulse. As I recall the Arduino Uno only supports external interrupts on two pins which may or may not be sufficient for your use. The Teensy 3.2 has 23 pins that can be assigned as digital inputs and I believe all of them can be assigned as interrupts. The Teensy 3.2 also allows overclocking up to 96 Mhz which should eliminate any speed limitations. Of course, you could try the Teensy 4.x family which allow overclocking up to 912 Mhz - who needs coding elegance when you can just turn up the boost screw on the turbocharger! The Teensy 3.2 and 3.5 are 5 volt tolerant so if your ECU is 5 volt you can do digital interfaces directly. The other Teensy products are 3.3 volt only so you need to get into level shifters.

I have never experienced latch up so I can't help you. If you are logging real time data on the Arduino, I would connect the the electrical ground for the Arduino as close as possible to the ground for the ECU. I would also take the + supply for the Arduino from the same supply as the ECU. The best solution would be to make the + supply and ground connections right at or as close as possible to the board in the ECU. This eliminates problems with differential signals appearing caused by inductive or galvanic coupling into the separate ground or supply paths to the two devices.

Last edited by 142 guy; 04-25-2021 at 01:10 PM..
142 guy is offline   Reply With Quote
Old 04-25-2021, 07:18 PM   #19
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

Quote:
Originally Posted by 142 guy View Post
Are you trying to use digital reads to capture high speed events? I am not a skilled C coder; but, I think the preferred way to do that is to attach an external interrupt to a digital pin and when the event occurs set a flag in the interrupt service routine. The main code uses the flag to start a timer (timers generally do not work in the ISR). Better yet to use hardware timers; but, those require more skill / knowledge as you are discovering.

I'm not a skilled C++ coder too, previous time I used it was at university near 25 years ago. I used interrupts to measure times, this is how I read injectors pulse width and is pretty easy:



void LHJetronicDataReader::injectorsSignalChange() {
unsigned long enterTime = micros();
int injectorSignal = digitalRead(INPUT_PIN_ECU_INJECTORS_SIGNAL);
if (injectorSignal == HIGH) {
// injectors on
lastInjectorsActivationMicros = enterTime;
} else {
// injectors off
if (lastInjectorsActivationMicros > 0) {
injectorsTonMicros = enterTime - lastInjectorsActivationMicros;
}
lastInjectorsActivationMicros = 0;
}
}


and this is for rpm and Tq together:

void LHJetronicDataReader::tqSignalRise() {
unsigned long tqPulseWidth = 0;
noInterrupts();
unsigned long enterTime = micros();
while (tqPulseWidth <= MAX_TQ_MICROS) {
if (digitalRead(INPUT_PIN_ECU_TQ_SIGNAL) == LOW) break;
tqPulseWidth = micros() - enterTime;
}
interrupts();
tq = tqPulseWidth;

unsigned long currentRpmSignalRisingMicros;
unsigned long pulseDuration;
// to-do: dopo circa 70 minuti micros va in overflow e riparte da zero
currentRpmSignalRisingMicros = enterTime;
pulseDuration = currentRpmSignalRisingMicros - lastRpmSignalRisingMicros;
// un impulso ogni scintilla, ogni 2 impulsi un giro completo dell'albero motore
engineRpm = ONE_MINUTE_MICROS / pulseDuration / 2;
//Serial.println((String) "Last: " + lastRpmSignalRisingMicros + "\nCurrent: " + currentRpmSignalRisingMicros + "\nRPM SPEED: " + rpmSpeed + "\n");
lastRpmSignalRisingMicros = currentRpmSignalRisingMicros;

//Serial.println(totalTime);
}




If you whould like to see the whole C++ class that read the measures:

LHJetronicDataReader.cpp
When I will learn hardware timers probably I will rewrite this code.


For optoisolators... I'm yet undecided if it worth to totally aband them.
I'm testing the flowwing circuit based on tips I learned these days using an emulated injector that has the same 60V spike when the signal rises, the circuit seems to perform very well and it can goes up with frequencies without the limits of optoisolators and to maintain a perfect square waveform also at 15kHz and above.
Furthermore, thanks to the high impedance input it can be used without modifications also for any other 12V digital signal.
As you can seen I didn't cloned as-is the circuits posted by Swedbrick; I'm a stubborn and until I don't understand why only a 10kΩ can be used I preferer to continue to decouple with a voltage follower using a high impedance to minimize as much as possibile the load.
So why I'm still undecided? Because I found 2 or 3 times a spike that goes out of the 0-5V range, and one of them was -2V and I was unable to replicate it plus your observation on GND.
Quote:
Originally Posted by 142 guy View Post
If you are logging real time data on the Arduino, I would connect the the electrical ground for the Arduino as close as possible to the ground for the ECU. I would also take the + supply for the Arduino from the same supply as the ECU. The best solution would be to make the + supply and ground connections right at or as close as possible to the board in the ECU. This eliminates problems with differential signals appearing caused by inductive or galvanic coupling into the separate ground or supply paths to the two devices.
I have to say you that this conflicts with my "project requirements": I whould like that the arduino interface could be connected throughthe same D-SUB connector I've on my break-out box and since it will have near 1m meter of cable the GND will not be as closed as possibile.
A solution could be to remote with the cable only the LCD screen and the keypad, will it be sufficient?

EDIT: I've made a mistake in circuit diagram, I will redraw it

Last edited by apollokid; 04-26-2021 at 02:47 AM..
apollokid is offline   Reply With Quote
Old 04-26-2021, 11:08 AM   #20
142 guy
Board Member
 
Join Date: May 2014
Location: Saskatchewan, Canada
Default

The digital read may work if the event timing is relatively slow compared to the clock speed and you don't have many other code steps going on in the main software loop. As an example, if injectorSignal goes HIGH just after you execute "int injectorSignal = digitalRead(INPUT_PIN_ECU_INJECTORS_SIGNAL); " you won't capture the state change until the next time you run through that part of the code loop. If the software loop is small and the clock speed is high you may be able to go through the main loop fast enough that the timing error that occurs may not be large. However, the problem is that you will never know about the error. You would need to hook up an oscilloscope to the injector signal at the same time that the Arduino is logging the pulse duration and compare the oscilloscope results to the Arduino log to confirm the accuracy.
142 guy is offline   Reply With Quote
Old 04-26-2021, 11:54 PM   #21
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

Sorry, I haven't had as much time as expected to work on this project in the last few days, and haven't had time to fully follow all the recent discussions.

I'm still planning on using simple RC circuits, and a couple high-speed switching diodes for inductive clamps, to monitor the EZK/ECU signals. I'd like to keep the added loading on the EZK/ECU signals to only ~10uA to ~50uA, or ~200K ohms to 1M ohm (definitely high impedance). I need to trace the EZK Tq/Load signal driver to see if higher loading can be used since it's the fastest signal of the bunch. I also need to trace the IGN driver because I'd like to measure exact ignition advance, and may need lower RC delay for the desired accuracy.

For grounding, the Arduino board needs to connect only to ground in the EZK, or only to ground in the ECU. Any other connection may add a bad ground loop that might affect normal engine control.

For high speed timing measurements in the Arduino, you need to setup custom PCINT PinChangeINTerrupt code. This will trigger an interrupt routine whenever the logic level of one of the enabled pins changes. The interrupt routine then needs to keep track of the previous and current state to figure out which pin changed.

Here's what I have for the older IGN setup/interrupt code:
Quote:
[in setup section]
// Setup high speed digital inputs
pinMode(4, INPUT); // IGN sparkAdv

// Setup interrupt handlers for high speed signals: rpm (tach), vss, load, inj, spark
PCICR |= 0x04; PCMSK2 = 0x10; // IGN: pin D4, PCINT2_vect (D0-D7)

[in interrupt routine section]
//********************Interrupt Service Routines***********************
// For good info on setting up interrupts, including the pin change interrupts that aren't
// directly supported by the Arduino library, see: http://www.gammon.com.au/interrupts

// Interrupt Service Routine for pin D4, IGN input, PCINT2_vect (D0-D7)
// - enabled via direct interrupt register config in setup() section
// - triggers on both edges of IGN signal
// - Dwell is pulse width
// - Advance is updated here using falling RPM signal edge captured by RPM ISR

ISR(PCINT2_vect) // Pin change interrupt for pins D0-D7 (only D4 enabled)
{
boolean edge;
unsigned long edge_time;

// get interrupt edge and current time
edge_time = micros();
edge = digitalRead(4);

// Measure ignition dwell time as rising to falling pulse width (coil changes when signal is high)
// Measure ignition advance as previous falling RPM edge to falling ign edge
if(edge) {
ign_rise_edge = edge_time;
} else {
ignPeriod = edge_time - ign_rise_edge;
ign_fall_edge = edge_time;
advance = edge_time - rpm_fall_edge;
ign_int_flg = true; // set flag to indicate new ign dwell and advance measurements
}
ign_ints_processed++;
}
I'm still looking at the Arduino capabilities and how to monitor all the signals. I think it will work well, and that I can possibly leave the I2C SDA/SCL pins unused if someone wants to use them for expansion in the future (such as the Sparkfun Qwiic interface).
bobxyz is offline   Reply With Quote
Old 04-28-2021, 01:14 PM   #22
apollokid
Newbie
 
apollokid's Avatar
 
Join Date: Aug 2020
Location: Milan (Italy)
Default

@bobxyz: When you were talking about PinChangeINTerrupt I was thinking you were meaning about the https://github.com/NicoHood/PinChangeInterrupt library but from your snipplet I've understood that you are talking about a different thing and you want to use directly the registers.
I've not written yet any code that uses them but I read something about and I agree with you that could be the right method to get more interrupt enabled pins. (This is the link to the article I'm talking about: https://thewanderingengineer.com/201...ge-interrupts/)
In your snipplet I saw that you have used the function digitalRead() to read the status of a single pin, digitalRead() is not too much fast and if used to read the status of many pins inside the ISR its delay could became an minor issue. Do you have already searched for a faster way? It should be possibile to read the status of a pin reading the whole port as a byte and applying on it a bitmask instead of using digitalRead().


@142 guy: I don't understand what you mean with As an example, if injectorSignal goes HIGH just after you execute "int injectorSignal = digitalRead(INPUT_PIN_ECU_INJECTORS_SIGNAL); " you won't capture the state change until the next time you run through that part of the code loop.
Did you thinked that the function injectorsSignalChange() is called from the main loop as a polling?
No, both injectorsSignalChange() and tqSignalRise() are ISRs and not normal functions.
Since injectorsSignalChange() is an ISR is impossibile that the injectors signal falls down and rises up again in less than 5Ás (or a bit more), also when engine is at idle the pulse width of the injectors is near 2000Ás.
The slownes of the function digitalRead() is a limit in measuring very short pulses width with high precision but I don't think that is this my main problem to solve.
Infact I've better re-analyzed the Tq signal recordings I took two weeks ago with my oscilloscope and I found another issue.
I was thinking that the pulse of Tq and injectors were always in sync, in other words I was thinking that:
- at t0 injectors pulse signal falls down
- at t0 + approx 130Ás Tq pulse signal rises up
- at t0 + 130Ás + 20Ás...250Ás Tq pulse signal falls down
- at t0 + 2000Ás...8000Ás injectors pulse rises up
This is wrong because when the rpm and load increases the sync of the two signals change and there are situations when there is an overlapping.
For example the injectors signal could fall down when the Tq was yet high and according to my code the call to injectorsSignalChange() will be delayed until tqSignalRise() ends. I found also that also the sync of the Tq rise changes.
If I had more interrupt pins availabe I would never have calculated the rpms from the count of the Tq pulses instead of the rpm pulses and above all
written a busy wait inside an ISR. I did it to quickly test the performances of the optoisolator and believing that it could works, after all also the pulseIn() function do a similar thing to measure a pulse length.
This could drive to an error in the measure of the injectors pulse that could reach up to 250Ás and is not acceptable.
Pin Change Interrupts, as suggested by bobxyz, could help me to rewrite the code and to fix the problem, but I whould also to find the alternative to the digitalRead() function.


A bit off-topic: I also would like to add the the ignition advance measure, but I'm dreaming a totally different way from getting the crank signal from EZK. I believe that it could be possibile to detect the TDC by analyzing the AMM signal oscillations and I want to take more scope measures using AC coupling to better study it.
May be that it will drive me to dead-end road, but a few years ago I made a similar experiment using my oscilloscope and I was able to measure the ignition advance with a reasonable precision looking the current oscillations produced by the alternator that can show you when the piston reaches TDC and BDC (when there is the piston stroke the current produced is a bit more since the cranck shaft is accelerating, on the opposite, when the piston is compressing the crankshaft slow down a bit)
Also the air mass is not a continuosus flux but if you are able to zoom the signal just enough you can see that is alternating, in sync with the pistons that suck the air. One of the most difficult thing in doing this is that the amplitude of the signal changes not only with the load but also with the rpms as you have seen I'm a novice in designing electronic circuits.
apollokid is offline   Reply With Quote
Old 04-30-2021, 12:59 PM   #23
142 guy
Board Member
 
Join Date: May 2014
Location: Saskatchewan, Canada
Default

I had not read your code and had read into your comments that you were using the digital read inside the main loop. If you are doing the digital read inside the ISR then you have eliminated the timing issue that I raised.

A comment on your idea about using the AMM signal to detect TDC. I don't have any experience with AMM devices, just MAP sensors. With a common plenum intake manifold the pressure fluctuations pretty much disappear once the engine speed is above 1500 RPM. During engine cranking the cylinder filling events are very easy to spot; but, once the engine fires and comes up to idle speed it would be very difficult to reliably identify the cylinder filling events. Even when the cylinder events are easy to spot I think it would be difficult to get a precise measurement on TDC. The magnitude of the fluctuations will depend on the volume of your intake plenum with a smaller volume making the measurement easier.

If you have a high tooth count wheel on the crankshaft (36 tooth would be ideal) at idle it will be very easy to pick up the engine speed variations that occur at idle. I can do this with what is the equivalent of the 12 tooth wheel that I have. I have never checked to see what the speed variations look like as the engine speed increases because the stored energy in the flywheel increases which tends to smooth out the variations. Clearly a 36 tooth would be better than a 12 tooth wheel. OBDII compliant ECUs use crankshaft speed detection to detect individual cylinder misfires so it would appear to be possible; but, a complete misfire probably results in a much larger speed delta than that caused by the compression of the intake charge. That said, OBDII crankshaft speed misfire detection systems are a little notorious for their reliable signal measurement and to avoid false error codes typically require 3 detection events in a trip before they will trigger the CEL continuously.

I believe that Saab's Trionic engine management package used their ion sense cylinder pressure management system to detect #1 TDC firing in place of a cam position sensor; but, I don't believe that they used it as a precision measurement (exactly TDC).
142 guy is offline   Reply With Quote
Old 05-04-2021, 07:29 AM   #24
VB242
Beep beep zip tang
 
VB242's Avatar
 
Join Date: Sep 2011
Location: The Right Coast
Default

Quote:
Originally Posted by 142 guy View Post
I had not read your code and had read into your comments that you were using the digital read inside the main loop. If you are doing the digital read inside the ISR then you have eliminated the timing issue that I raised.

A comment on your idea about using the AMM signal to detect TDC. I don't have any experience with AMM devices, just MAP sensors. With a common plenum intake manifold the pressure fluctuations pretty much disappear once the engine speed is above 1500 RPM. During engine cranking the cylinder filling events are very easy to spot; but, once the engine fires and comes up to idle speed it would be very difficult to reliably identify the cylinder filling events. Even when the cylinder events are easy to spot I think it would be difficult to get a precise measurement on TDC. The magnitude of the fluctuations will depend on the volume of your intake plenum with a smaller volume making the measurement easier.

If you have a high tooth count wheel on the crankshaft (36 tooth would be ideal) at idle it will be very easy to pick up the engine speed variations that occur at idle. I can do this with what is the equivalent of the 12 tooth wheel that I have. I have never checked to see what the speed variations look like as the engine speed increases because the stored energy in the flywheel increases which tends to smooth out the variations. Clearly a 36 tooth would be better than a 12 tooth wheel. OBDII compliant ECUs use crankshaft speed detection to detect individual cylinder misfires so it would appear to be possible; but, a complete misfire probably results in a much larger speed delta than that caused by the compression of the intake charge. That said, OBDII crankshaft speed misfire detection systems are a little notorious for their reliable signal measurement and to avoid false error codes typically require 3 detection events in a trip before they will trigger the CEL continuously.

I believe that Saab's Trionic engine management package used their ion sense cylinder pressure management system to detect #1 TDC firing in place of a cam position sensor; but, I don't believe that they used it as a precision measurement (exactly TDC).
I know Toyota COPs have a feedback wire that are used to detect misfires, not exactly sure how, perhaps a piezo sensor in the COP?
__________________
Quote:
Originally Posted by 240240 View Post
I'm shocked someone actually took me seriously.
VB242 is offline   Reply With Quote
Old 05-04-2021, 11:12 PM   #25
bobxyz
Board Member
 
bobxyz's Avatar
 
Join Date: Aug 2014
Location: Boulder CO
Default

I'm making progress on the design, but am not quite there yet. Here's what the schematics look like currently (click for bigger):


For the initial boards, I picked a 15-pin Dsub connector to bring the EZK/ECU signals onto the board. A short wiring harness then splits this into 2x 9-pin connectors, 1 for EZK and 1 for ECU/extras. The resistor/capacitor/diode circuits in the schematics are about right, but the exact component values may change. I also expect to move some of the port assignments around once I get to layout.

The latest choice for an Arduino is a Leonardo 16MHz 5volt 32U4 board. I think I can fit all the Monitor circuits onto a daughterboard (aka shield) of about the same size if I use SMT parts (assembled by JLCPCB).

I thought I was close to done, but then realized that the Leonardo/32U4 microcontroller has NO hysteresis on the input pins, plus weird input voltage levels. The original Uno/328P boards have reasonable input hysteresis and levels. Without the hysteresis, the inputs will be _very_ sensitive to the slightest electrical noise. I'm really surprised that Arduino would pick a chip without any input hysteresis for hobbyist use. WTF were they thinking.

At this point, I'm trying to decide if I want to go back to a Uno/328P Arduino that has better noise immunity but doesn't include the 2nd serial port, or if I should just add an external schmidt trigger buffer chip to the schematics and move on.

Let me know if there are any [brief] questions or comments. If anyone is interested in more direct access, I think I can setup a Group on easyeda.com and add others to the project (you'll need to setup an account and PM me your user name, or maybe email).
bobxyz is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is On

Forum Jump


All times are GMT -4. The time now is 09:28 AM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.