Turbobricks Forums

Turbobricks Forums (https://forums.turbobricks.com/index.php)
-   performance & modifications (https://forums.turbobricks.com/forumdisplay.php?f=13)
-   -   LH2.4: How does the "tq" signal correlate to load? (https://forums.turbobricks.com/showthread.php?t=337984)

Sjeng 11-28-2017 04:22 PM

LH2.4: How does the "tq" signal correlate to load?

My name is Frank and I own a '97 940.

I want to learn more about LH2.4 tuning and even though I have read lots about 2.4, I haven't found an answer yet to the following.

As I understand "load" is calculated using AMM voltage, RPM and the injector constants.
LH2.4 sends a "tq" signal to the EZK which is directly correlated to the calculated load.

Is the tq signal to the EZK scaled using the load axis in LH2.4?
Meaning: If the max load in the scale is 128 this corresponds to 100% tq signal send to the EZK.
Or is there a different relation?

Also, what exactly does the "tq signal to EZK adjuster" value do?

The reason I am asking this is because changing to larger AMM/Injectors (without software changes) skews the tq signal send to the EZK and I would like to know how to compensate for that.

I appreciate your help!

Kind regards,

lummert 11-28-2017 06:39 PM

There are write ups on certain pins of the LH 2.4 ECM retarding or advancing the ignition timing. Apparently its the pins of the EZ116K that require grounding.


bobxyz 11-28-2017 09:23 PM

I don't know the details, but can give you a hand-waving answer to some of your questions.

Early this summer, I looked at using a EZK-116 box as a knock detector for a MicroSquirt install. I dug into it far enough to figure out that re-creating the Tq/Load signal needed by EZK box was non-trivial. The Tq/Load signal is PWM encoded. The pulse width, after some scaling, directly selects the row in the EZK ignition table. As lummert mentioned, fixed adv/ret adjustments are available by jumpering 4 pins. These adjustments are directly added/subtracted to/from the table values.

You've probably seen these:

I have more notes somewhere, but my memory is that the Tq/Load value is essentially fuel per squirt.

brian smith 11-28-2017 11:10 PM

50% load signal, even if that "load" is higher with your higher throughput engine, should still probably call for a similar change to ignition timing that 50% calls for on a stock set of AFM/injectors. You probably would prefer to burn a new ignition timing map for your needs and let the "call for advance" run as it may. Perhaps if you find that your installation never hits on the cells near the lowest load, you would then benefit from a change. Basically, the full-load ignition timing map is probably the one that you are most concerned with getting right for your collection of components, given that you are increasing AFM size and injector flow, so that the lower-load areas of the ignition map are probably more minor refinements. You can convince yourself of this by pulling the load signal terminal out of your EZK connector and driving the car. This sends the EZK into the full-load timing map for the safety of the engine. Fuel economy may take a hit, but drivability is fine and possibly improved. Sorry if this is well-understood and I'm misunderstanding the question.

turbotankshane 11-28-2017 11:54 PM

In any of the custom lh2.4/ez116k mapping I've done I only ever needed to move the ezk tq signal adjuster once, IIRC the stock value for an 8v turbo bin was 20 and the value from a bin from an ecu originally calibrated for a 3" AMM was 22. The one time I had to change the value from 20 to 22 (on a car where the customer had installed a 3" AMM) it helped very slightly with engine speed slowing to idle without stalling, but I'm still not convinced that was the issue.

Basically, you shouldn't need to change that value. Compensate for the larger AMM by copying the values in the main 1x256 AMM signal lookup table and the AMM signal multiplication factors table, and adjust for your injectors with injector constants 1 and 4.

bobxyz 11-29-2017 12:28 AM

turbotankshane - I think you're saying that the LH2.4 ECU needs to be reprogrammed for the larger AMM and Injectors. Once this is done, the ECU will send the correct Tq/Load signal to the EZK, correct? (At least all ECUs have easily swapped chips, unlike most EZKs.)

If the OP runs a bigger AMM and bigger injectors without reprogramming the ECU, what will happen? I think a bigger AMM by itself would result in too small of a Tq/Load value (ECU thinks there is less flow than actual). Bigger injectors by themselves would result in too big of a Tq/Load value (ECU thinks there is less fuel than actual). What do you think?

Sjeng 11-29-2017 08:54 AM

Thank you very much for your replies.

I will burn a chip with the 012AMM linearization tables/constants and start from there.

Also I completely forgot about the jumbers adding/substracting timing. Anyone using this for switching between different fuel quality?

turbotankshane 11-29-2017 10:40 AM


Originally Posted by bobxyz (Post 5712360)
turbotankshane - I think you're saying that the LH2.4 ECU needs to be reprogrammed for the larger AMM and Injectors. Once this is done, the ECU will send the correct Tq/Load signal to the EZK, correct? (At least all ECUs have easily swapped chips, unlike most EZKs.)

If the OP runs a bigger AMM and bigger injectors without reprogramming the ECU, what will happen? I think a bigger AMM by itself would result in too small of a Tq/Load value (ECU thinks there is less flow than actual). Bigger injectors by themselves would result in too big of a Tq/Load value (ECU thinks there is less fuel than actual). What do you think?

Personally, I would agree with you, not everyone thinks so.


Originally Posted by Sjeng (Post 5712422)
Thank you very much for your replies.

I will burn a chip with the 012AMM linearization tables/constants and start from there.

Also I completely forgot about the jumbers adding/substracting timing. Anyone using this for switching between different fuel quality?

I ran a dual-fuel setup for about two years, but I used a pair of moates two timers.


One in the lh2.4 ecu, one in the ezk, then burn a 27sf512 chip with a stacked bin so you can ground the switch and access the other map. I had it set up for 91 normally, then with the switch grounded it was on the e85 tune.

apollokid 04-16-2021 04:08 PM

Hello everyone, this is my first post here on tbforum. I tried to search for a presentation thread but I didn't find it so I post my question directly.

I'm a software engineer and I'm building an interface for the LH Jetronic based on Arduino to be able to see live data on my smartphone using Torque (or any similar app compatible with ELM327 protocol) and to log hi-res data to a microSD for off-line analysis.
I've already built a working prototype and I was able to decode near all the I/O signals of the ECU but I've some doubts about the Tq-signal.
This is what the connector pinout says about pin #25: "Load signal (TQ). Digital output signal to ignition system (# 8) for engine load data"
What I discovered is that it is not a real digital signal, it is instead a 12V square wave with variable width and variable frequency so I tried to search in the internet for better documentation but without success.
I post this question here hoping to reach someone that has already tried to analyze this signal for other purposes. What I found is that:
- frequency is proportional to rpm and the signal is perfectly synced with rpm signal on pin #1 (rpm is also synced with spark ignitions and injectors opening, also if frequency of injectors opening is half of spark ignition)
- pulse width seems proportional to the engine load (~18Ás during fuel cutoff, ~40Ás on idle and ~240Ás during full acceleration with wide open throttle)

I made some live data recording driving car on the street but according to what says ipdown.net there is something that doesn't match.

This was what ipdown.net says: (now the site is down, but I made a local mirror a couple of years ago)

Load calculation

The exact calculation for determining load is unknown. Enough testing has been done to have a 'pretty good' idea about how things work though.

As Air mass increases, Load increases
As RPM increases, Load decreases
As Injector constants increase, Load decreases

What is your opinion?
I can share the .psdata and and some videos I collected and I could also take some other measures when necessary.

bobxyz 04-16-2021 09:09 PM

Sounds like a great project, please post a link to some videos!

Here is some info you may find useful.

The EZK-to-ECU RPM signal pulses twice per rev. The falling edge is nicely aligned with 0deg TDC and 180deg BDC. It shifts just slightly as rpm increases (maybe 50us delay at idle, up to 90us at 6000rpm). This may vary a bit depending on which EZK part number you're using.

The tq/load signal also pulses twice per rev. The width of the pulse is proportional to the load, or, I think, the amount of fuel injected per rev. This width selects the row in the ECU fueling map. This link shows some LH/EZK tables with Tq/Load along the left vertical axis: http://www.forums.turbobricks.com/sh...d.php?t=346790

I don't know the exact mapping, but might be able to figure out a few values for different RPM and MAF voltages. I think the load pulse width also varies depending on the ECU/EZK version and turbo versus non-turbo.

I've also thought about doing a blackbox logger for LH2.4, but have never followed through. Maybe now is the time to share information and actually do it.

For old Volvos, MegaSquirt is a common aftermarket ECU. I was going to use the same software for LH2.4 logging. MegaSquirt, Speeduino and RUSefi, all use TunerStudio software for setup and a realtime dashboard, using a serial port connection. Logging is either in Excel .csv format, or a custom format, using MegaLog Viewer to view the logs. This is a bit different than your Torque and ELM327 setup. Bluetooth wireless would also be nice, but may run afoul of FCC regulations.

[Where are you and is English your native language?]


apollokid 04-17-2021 02:28 AM

Hello bob, you discovered immediatly I'm not english, I'm italian and I live near Milano in the north of Italy.
I know about MegaSquirt and Speeduino, but those require modifications of the car while I want to keep my 945 Turbo as original as possible since it is in an excellent state of conservation, furthermore I'm more interested in diagnostics other than in engine tuning, also if the two worlds have many points of contact.

The rpm signal that EZK sends to the LH-Jetronic is in sync with spark ignition that is also synced with the injectors opening, that's why the signal changes according to the TDC when the engine is running (low rpm -> less advance, high rpm -> high advance but also the load is used to compensate the advance as made on old distributors with the pneumatic diaphragm)
Also injections are not fixed with the TDC but move forward and backward according with timing advance but this is not a problem since the pulsed injection system is full group and not in sync with the valves opening.

This is the documentation on how it works taken from the book "Bosch Fuel Inkection & Engine Management" - BentleyPublishers:

and this is the verification I made some years ago on my 940:

I don't know how the EZK decode the Tq-signal to make a lookup on the ignition table, but I'm pretty sure it doesn't read the voltage since it was too much simple and faster for a CPU to read the rises and the falls of the signal on a digital input without the need of any ADC converter.
In my opinion it reads only the square pulse width and converts this time in a load numeric value.
Please, take a look at the following pictures, data was acquired during a WOT 1░ gear acceleration test, the yellow waveform is a math function of the Tq-signal to better show the variation of the lengh of the pulses discharding the frequency that in my opinion has been used only as a simple methos to sync the reads and the writes on the channel between the two control units.
In your opinion it could be this yellow signal the true load signal? (With true load signal I mean a numeric value than changes in the range from 0% to 100%).
I've made also a test in highway at 120km/h and when I pressed the gas pedal to the floor the pulse width of Tq-signal moved rapidly from ~35Ás to ~240Ás that is the maximum I've registered also during the 1░ gear acceleration test.
I could also try to derive the load from the analog signal of MAF sensor but is not as simple as it could seems (it could need a dedicated topic to explain the reasons)




This is how I captured the data (For more pictures about my DIY breakout-box: https://photos.google.com/share/AF1Q...lMZVRiMExMek9R)


NOTE: in the blue signal is missing the classic spike when injector closes since the car was driven with the LPGi Vialle fuel injection system active

These are the two psdata files, you can open it with the Picoscope software that you can install also if you don't own a scope. You can download it for free here: https://www.picotech.com/downloads

tq-signal+injectors ___ 1░ gear WOT + release + neutral.psdata

tq-signal highway 120kmh WOT opening test.psdata

P.S. For the Arduino project I could open a dedicated topic, do you agree?

bobxyz 04-17-2021 10:01 AM

Thanks for the pictures! I really like the breakout box.

It's cold and snowy here today, so not a good day for the garage. But I have a ECU and EZK wired up indoors on my desktop, so I can play with them from the comfort of my desk chair. I'll try to measure Tq versus RPM and MAF. I'll post the results later today or tomorrow, plus a picture of my desktop.

Please start a new thread (in the aftermarket engine management sub-forum) for Arduino LH Jetronic Monitoring, or something similar.

Jaybee - if you see this post, do you know how the EZK firmware converts the Tq pulse width into a row selector for the ignition advance table?


apollokid 04-17-2021 12:27 PM


Originally Posted by bobxyz (Post 6176491)
Thanks for the pictures! I really like the breakout box.

Thanks Bob ;-)

Today I've an idea, I want to take a measures of both Tq-signal and MAF sensor signal.
I belive that having both Tq and MAF on the same diagram could really help in better understanding the meaning of this signal
I will share the new data.


P.S. Unfortunately I've recorded MAF signal + injectors signal only
MAF signal + injectors - 1░ + 2░ gear WOT acceleration.psdata


Originally Posted by bobxyz (Post 6176491)
Jaybee - if you see this post, do you know how the EZK firmware converts the Tq pulse width into a row selector for the ignition advance table?

Uaoh!!! It sounds like there is a software engineer here that has disassbled the LM of the EPROM? It is?

bobxyz 04-17-2021 05:13 PM

Hi Diego, I got my benchtop Arduino LH2.4 test setup working again - it's been gathering dust for at least a year. (click pictures for full size)


It currently has a '951 ECU and a '169 EZK, but I should change to a '937 ECU and '148 EZK to match the boxes in my '85 wagon. What ECU/EZK versions are you running?

I loaded the '169 EZK eprom .bin file into TunerPro, along with mrjaybeeze's (Jaybee) .xdf file. The .xdf file maps and interprets the tables in the .bin file. For the tq load signal, there is a small "Load def map" table that rescales the +pulse width of the incoming tq load signal. The rescaled load is then used as the left axis of the main ignition advance map. I don't know any more beyond this.


For today's experiments, I ran some tests at 1800rpm to see how they compare to the 1800rpm column in the TunerPro ignition map -- 23.25deg advance at minimum load, 20.62deg advance at max load, and max advance of 44.25deg at light load.

I ran the 1800rpm measurements using a Hantek 8-channel scope, and with some old Arduino software to measure ignition advance. Here's a scope picture showing, from top to bottom, TDC reference pulse from 60-2 wheel generator, RPM signal between EZK-ECU, Injector pulse, and MAF voltage:


At 1800rpm, the benchtop measurements are:
- MAF voltage in volts
- Load signal positive pulse width in microseconds
- Ignition advance in degrees
- Injector negative pulse width in milliseconds

[Sorry, I never remember how to format data nicely here]

If you pull these measurements into a spreadsheet, you can graph
- Load pulse width versus MAF voltage
- Injector pulse width versus MAF voltage
- Ignition Advance versus Load pulse width


It sure looks like the load pulse width is very similar to the injector pulse width. I think that there is a Bosch datasheet for the LH2.4 MAF somewhere on the ipdown/jetronic website. It would be interesting to find it and compare the MAF response curve (voltage out versus air mass flow) against the measured MAF to Load curve.

I still need to see if I can map the measured load pulse width to the ignition advance from the TunerPro ignition table.

apollokid 04-17-2021 08:05 PM

Great Bob, I'm really happy to see you equipment :cheers:
I believe we could have a lot of thing to talk about if we could meet one day :-P

I'm trying to follow you in the correlation between Tq and injectors pulse width and I've analyzed the moment when I relase the pedal.
In effect when pedal is release the pulse width drops like the Tq width


Usefull the multichannel function generator of the 1008C, I didn't believe it could be used a square wave to emulate the inductive crank sensor but you show me that it works.
Why you didn't measure the Tq pulse width when running the function generator? May be it cannot be used as a scope when the signal generator is active?

Anyway I made the test comparing between Tq and MAF that I told you this afternoon and the result seems quite similar to the previous one between Tq and injectors pulse.

Do you think it could be reasonably correct to display as a live data of the load a simple formula like the following one?

Load % = Tq pulse width Ás / 240 * 100

Or do you think it must be taken care in a some way also of the correlation with injectors pulse width?
I'm doubtful about this correlation for the reason that the injectors pulse width is yet the ouput of a math function that takes the load as an input.
A definition of load as a function where one of the input is a function where one of the input is the load itself isn't a infinite loop?

For MAF specification I own this PDF bosch_amm_012.pdf but the MAF of my B200FT has code 0 280 212 016 and is not listed
MAF analog signal is also difficult to read since when load is high and rpms are low the signal has very strong oscillations due to the air sucked by the pistons inside the cylinders.
That's why I will read the MAF analog signal from Arduino and I will display the voltage since it is usefull for diagnostics, but I prefer to display the load information decoding the Tq signal that LH send to EZK as better as I can

I left you the new psdata file and the video of the recording of today
MAF+Tq signal.psdata




apollokid 04-18-2021 02:54 AM

Please forget a part a my last message, I bad understand that you measured also the Tq an more the first chart plot the correlation between the MAF.
I was misled by the different values between yours and the one taken on my car (you reach near the double pulse width for the same MAF voltage) and since I was convinced of the relation between injectors pulse width and MAF (they look pretty similar too) I didn't take too much attention. The late hour finally do the rest.
So it seems that the relation between Tq and injectors pulse width is the more reliable...
What a strange thing...

May be for the moment that the best thing for my project is to acquire Tq as a row data and perhaps make other considerations in the future

I've also another dubt in the way the LH read the MAF voltage since you have used a fixed voltage but in the real world the pulsations are very high when rpms are low and for example I was unable to recreate on the car a situation like the one in your test (at near 1800rpm in 5░ gear the MAF was unable to reach the max and furthermore it oscillates so much that is difficult to understand which value it reads)
In the last psdata I share you is on the 6░ acquisition (here a zoom to better explain what I'm meaning)


esmth 04-18-2021 01:04 PM

hello, i too have been doing a very similar thing recently, except from the opposite angle. I patched in code in the ezk/lh program to dump data/values of interest over the repurposed OBD port.

I might be able help you from the ezk decoding of this "tq" signal side:

The signal enters the ezk on external pin 8 and enters the mcu on pin 23 (i have a circuit diagram of this somewhere.) This pin is configured as a falling edge interrupt pin (this may be reversed in hardware...). Every time this interrupt fires, ezk takes a sample from timer 0 which is it's general purpose always-running timekeeping timer. First the routine does some sanity checking, being making sure the pulse is not too short or long. it divides the sample by 4. it then stores this timer sample in ram in place of the last sample. The previous sample and the latest timer samples are added together and stored to a different area in ram. The interrupt itself is finished here.

Later, this load timer sample sum is run though another routine which 'linearizes' the load value. It is a 1x73 table in program memory where this summed timer value is the one axis. It linearizes the load-timer value from 0 to 28. This is the final 'load' value the ezk uses in pretty much all it's load calculations/corrections. It is used as the load axis of all of the big tables like main ignition angle table, dwell table, knock compensation table, egr table etc.

here are a couple snapshots of dumping/pulling the data from ezk in particular:

here you see processed RPM, the mentioned 0-28 load value, idle ignition target, main ignition target, per-cylinder knock retard values, and a bunch of other crap I was trying to figure out.
<video width="560" height="315" src="https://esmth.com/f/210418/IMG_3677.mp4" controls></video>
<video width="560" height="315" src="https://esmth.com/f/210418/IMG_3679.mp4" controls></video>

Here is a very slow live ram dump of ezk. The engine is running while this is happening.
<video width="560" height="315" src="https://esmth.com/f/210418/IMG_3890.mp4" controls></video>

Here is some other less processed values like knock, coolant temp, battery voltage, ignition/dwell values.
<video width="560" height="315" src="https://esmth.com/f/210418/IMG_2529.mp4" controls></video>

definitely would be interested/would like to help with a datalogging/reverse engineering project. Start a new thread

esmth 04-18-2021 03:06 PM

another thing I wanted to quickly add:

Here are the mentioned 1x73 linearize load plots.
Each single x axis 'unit' in the table I think is about load pulse time in microsecond divided by 6. (tq pulse in us / 6) (very approximated!) The y axis is the result linearized load value.
You can see the NA ezk expects a load pulse of atleast 48us for minimum load, and 384us for maximum load.
For turbo it is 42us pulse for minimum load up to 276us for maximum.

The pulses smaller than the minumum are probably decel/fuel cut.

And that looks like it sort of closely adds up to the data y'all have collected so far.



mrjaybeeze 04-19-2021 02:39 AM

Hi there

Interesting project !

Do remember that the EZK listen for noise/knock on the knock sensor for each ignition pulse, if no noise is captured it assumes the sensor to be dead and set a fault code and also goes into limp mode affecting everything.
The torq signal is read according to width of each pulse, the more modulated the higher load.
The torq constant is used as a scalar to adapt the load range sent from LH into the load scale on EZKs internal load scale axis for the ignition map.
It has never been verified if the EZK even has a map for setting the load scale.

It might be useful to do the work on the 954 binary since this always has the most updated XDF (this is what I run on my car) :cool:


bobxyz 04-19-2021 08:55 AM

apollokid - I agree that real measurements from a running engine are much better. My benchtop setup is limited. 3 temperature resistors (normal, hot, cold), no O2 control (sensor usually unconnected), and no knock noise. The benchtop setup is nice for simple measurements and for basic arduino code.

esmth - I thought about using a serial port monitor directly, but I want to be able to do full speed logging (2x per rev). I also hate reverse engineering 8051 assembly code.

Jaybee - glad to hear from the world's expert on Volvo Turbo LH2.4 :-P You're right about lack of knock causing a CEL. If I'm careful, I can get the benchtop setup up to ~3000 rpm before it gets a CEL. I may try adding a resistor from the RPM signal to the Knock signal to see if that will fool it.

I'll need to see if I have a '954 in my spare parts pile. I have a '937 in the car, and a spare, so I'll use those if I don't have a '954. (Or I guess I could burn a '954 prom for the '937 box?)

For this thread on Load versus Tq signal, I want to gather some additional data for:
- a couple different engine temperatures
- '951 vs '937 ECU
- 2 or 3 rpms -- I have 1800rpm, and I should be able to do 2800rpm, but faster may get an EZK CEL. I'll need to see if the EZK CEL triggers the knock signal. If not, I can still measure the ECU as long as it doesn't have a CEL.

For the full monitor, I'm thinking of starting with an Arduino Pro Micro (32U4 and 3.3v) with an ebay HC05 bluetooth module. This will provide serial port emulation on the PC or Smart Phone. Does anyone else have a preference?


esmth 04-19-2021 10:27 AM


Originally Posted by bobxyz (Post 6176906)
esmth - I thought about using a serial port monitor directly, but I want to be able to do full speed logging (2x per rev). I also hate reverse engineering 8051 assembly code.

speak for yourself hahah:-P, i find it absolutely fascinating trying to try to understand the LH/EZK assembly. It allows one to do funky things like light the CEL when knock is detected or timing being pulled. Very useful for tuning!

I can dump data out the 'serial' port fast enough to stall the engine! I use serial in quotes as i'm actually only using the usart hardware as a shift register and not a normal PC-compatible uart. I can get a byte in or out in 9 machine cycles. The old pc-compatible way that has been used in the past is limited to 3200/6400 baud while my method is about equivalent to 1 megabaud. It needs significant hardware modification though -- a real deal breaker for us trying to make a datalogger or the average tuner!


Originally Posted by bobxyz (Post 6176906)
I may try adding a resistor from the RPM signal to the Knock signal to see if that will fool it.

There are constants in the ezk bin to disable this check! Though, you may be able to fool it buy just adding some voltage to pin an5 of the mcu at the right time if you really want to get super accurate behavioral data. The knock circuit on ezk is a real bear. It has 4 (or 5?) bias settings that configure the sensitivity. It has a very small window after the ignition event that it samples.

If you tap a wire from p5.4 of the mcu, (or the base of T100 transistor on EZK) when the line is LOW, ezk is sampling the knock circuit, and here is when you should inject the voltage to the knock adc/circuit. (i think, logic may be reversed.)

In practice, I usually see knock signal ADC values from 0x0 to 0x40-ish while the car is running and driving. assuming the analog reference of the MCU is 5v, that should be a range from 0 to 1.3 volts it expects. Idle it averages like 0x05-0x10 so 0.1-0.2v give or take.


Originally Posted by bobxyz (Post 6176906)
For the full monitor, I'm thinking of starting with an Arduino Pro Micro (32U4 and 3.3v) with an ebay HC05 bluetooth module. This will provide serial port emulation on the PC or Smart Phone. Does anyone else have a preference?

I may be biased, but my day job is programming BLE devices with the nrf 52833/52840 chips. They are very capable and cheap, but they do not have the ease-of-use of the arduino software stack. There might be an unofficial layer though.

apollokid 04-19-2021 07:48 PM

Thank you esmth for your explanation and your video. I must tell you that my background on EZK and LH is mainly at a functional level I have never entered so deep in the tuning of the maps.
I'm a software engineer but I didn't work in the automotive field so I could say that for me a control unit is like a black box with inputs and outputs.
Take for example the linearization map of the load, I whould had think that it was only a way to translate the quadratic curve like the one of the MAF (or AMM as I see you call the mass air flow sensor in the USA) to be more clear and easy to be used in the fuel map but no more since the m^3 of aspirated air remain the same.

@mrjaybeeze: yes, I know that EZK has knock sensor but I don't know exacly how it works. I know that ignition should be retarded when knock occours and may be the LH should increase a bit the fuel injected but no more and I tested this signal I tried to drive in every situation of load but the signal remains fixed near 7,6V
May be that on stock maps its very difficult to make the engine knock?

@bob: your bench is great, I like it. To take signals from real car is better but time for testing is limited when driving. I made me too the experiments with the function generator on my desk
Please, can I ask you what is CEL?
For Arduino be aware of one thing: arduino nano has only two interrupt pins and to use the HC-05 to emulate an ELM327 device I had to use HardwareSerial since with SoftwareSerial I had many hangs when the rpm that I measured with an interrupt was changing too fast (I used the sweep mode of the function generator).
(NOTE: I use the great GTTurboEcu library but since it support only SoftwareSerial I had to refactor it so that now it supports both SoftwareSerial and HardwareSerial plus other minor improvements like the support of the status pin)

Now I'm using a Mega 2560 but of 6 available pins I can use only 2 for the LH signals, infact 2 interrupt pins are reserved for HardwareSerial and the other 2 are reserved for SDA/SCL (for real time clock and LCD screen)

P.S. i would tell you that I started learning arduino for fun in the free time only from last summer and so I'm still learning and faw away to be an expert (the same for electronics)
I feel that here in this forum the level of expertize is very very high and this for me is really exciting, but I hope to not make a bad impression :-P
I show you what I'm building since you tell me you are interested, but I ask you to wait for a few days since I would like to prepare the material before to open a new topic where exaplain what I'm doing (now in Italy it's 01:45AM, and I had also a work and a family :zzz::zzz::zzz::zzz: )


bobxyz 04-19-2021 11:10 PM

I didn't have time to take any additional measurements, but I did figure out how to easily fool the EZK Knock detection so that it doesn't cause a CEL. CEL is short for Check Engine Light, the dashboard problem light. Diagnostic blink codes are available from the engine compartment OBD box. Previously, I would get a EZK 1-4-3 "knock sensor signal missing - engine runs but timing is retarded 10deg" when I tried to run the benchtop setup faster than 3000rpm. With the new change, I can get to over 5000rpm without a CEL. I'll show the details shortly.

First, a couple follow-on comments and questions:

I like the Arduino's because the environment is pretty easy to use. This should allow other people to be able to modify the firmware for simple things like turning on and off LEDs at specific RPMs, or other conditions.

This is the Arduino board I'm thinking of using as a start: https://www.ebay.com/itm/Leonardo-Pr...o/401051391467
And this is an example HC05 bluetooth module: https://www.ebay.com/itm/Wireless-Se...e/200924726178

The ATmega32U4 processor includes 2 serial hardware ports (one is connected to USB). This is nice to connect to other processor boards or to wifi/bluetooth boards.

esmth - the HC05 bluetooth boards show up on the PC, or smart phone, as a serial port. This should be compatible with TunerStudio (commonly used for MegaSquirt, RUSefi, Speeduino), with MSdroid, and with a simple serial port Terminal program. Many of the BLE implementations do not support simple serial port access. Do you know of any bluetooth modules that support serial port mode on the PC/SmartPhone AND are FCC certified? The ebay HC05 modules are not certified and cannot legally be included in commercial products.

apollokid - for knock detection information, see the Volvo TP 31397-1 Ignition.pdf Greenbook.

Setting up Hantek Scope for 60-2 Wheel Generation
I have a Hantek 1008 USB oscilloscope. The Windows10 software for it is very buggy. In addition to 8 input channels (low bandwidth and only 2 screens of memory), it includes a 8-channel 5volt pattern generator for Automotive applications.

This is what the setup looks like for the Volvo 60-2 wheel (top signal), and a reference pulse at TDC/BDC:

Hantek 1008 pattern generator

The generated signals are the top 2 traces shown here:

To convert from the DC 5volt 60-2 pattern, to the required AC 60-2 CPS signal, a small circuit is needed:

Hantek_Pattern_Output --> 0.1uf capacitor --> EZK_CPS_input with a 1K resistor to ground

This is the 3rd trace shown above.

esmth - thanks for the knock window info. With this, I added a 270K ohm resistor from the 60-2 EZK_CPS_input to the Knock input. This is the bottom trace shown above. With this, the EZK thinks that there is a valid Knock signal, and I can go up to 5000+ RPM.

A zoomed in view of the same signals is:

For reference, the RPM signal from the EZK (channel 1) and the knock window signal from the CPU (channel 2) are shown below:

I'm guessing that the EZK does a differential knock measurement. It takes a no-knock measurement during the window=1 time (mid stroke), and compares it to the measurement during the window=0 time (near top of stroke).

[Time for me to go shovel snow so that I don't need to do it all tomorrow before work.]


apollokid 04-20-2021 12:33 PM

Ah, ok Bob, I'm used to name the CEL as MIL
I've read the TP 31397-1 many times and it describes what I wrote in previous post: EZK retards ignition and LH increase the fuel ratio. It also reports a brief description of the algorithm used by EZK for retarding in incremental steps but it doesn't enter so deep to describe the waveform of the characteristic signal produced by the sensor when knock occurs nor how it is the signal that EZK send to LH (may be analog or digital? I really unable to guess it).
If someone knows a way to force a stock engine to knock please let me know, I tried forcing load in all the possible ways without success (the signal to the LH on pin #28 remained always fixed near 7,6V also if on the LH pinout is written that when knock occours the voltage drops)

Finally, thumb up for the explanation with the scope screenshots, I live very much to analyze scope waveforms.
The way to simulate the CPS is smart but I note that the negative semiperiod is totally missing and also the upper one is not well rounded as it should be.
I was thinking about this: I believe EZK circuit try to square the signal using a Smith's trigger or something similar and then it reads the signal using interrupts.
Are you sure that emulating the CPS with that signal the EZK interprets it exactly in the way you expects?

NOTE: last night I coded the reading from the emulated Tq signal as a raw pulse width and I found that I cannot be too much precise in the reading. An error of 10μs is the best I was able to obtain.
To measure with more precision I believe that I must create an assembly routine since the digitalRead() function takes near 5μs to be executed.
I believe that hard coding an assembly routine like the one used to implement the pulsein() function could help, but at the moment I'm satisfied as it.
10μs is also the rise/fall time of the 4N35 I'm using to decouple all the digital signals and since I preprocess the signals with OpAmps I don't have so much electronics expertize to easily improve the frequency response of my circuits
I believe I't really urgent to open a dedicated topic. I will do all my best ;-)

mrjaybeeze 04-21-2021 03:12 AM


AFAIK the signal from EZK to LH is just grounded to zero volts when knock is sensed on all four cylinders.
The LH responds by dumping a massive load of fuel controlled by 1 map.
I suppose the map is used to multiply the fuel output pulsewidth.


All times are GMT -4. The time now is 06:24 PM.

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