• Hello Guest, welcome to the initial stages of our new platform!
    You can find some additional information about where we are in the process of migrating the board and setting up our new software here

    Thank you for being a part of our community!

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

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!

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.

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.
 
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: )

ACtC-3est5gfAnHJWoI_6AQL3gM-RVA_jsc3-oxfPqrxHzMwSmE7TLXabjlyHOCq2MhLRvKRUU7iYXbZAXID7-5Qyo1B9NUU05GzXqWnenmAvlBXbM10QUQNAWF-r43mS9UzY5P29MurVghJvu04bQ0baKex=w1024-h576-no
 
Last edited:
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-Pro-Micro-ATmega32U4-8MHz-3-3V-Replace-ATmega328-Pro-Mini-Arduino/401051391467
And this is an example HC05 bluetooth module: https://www.ebay.com/itm/Wireless-Serial-4-Pin-Bluetooth-RF-Transceiver-Module-HC-06-RS232-With-backplane/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.]

-Bob
 
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 ;-)
 
Hi


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.


YS
Jaybee
 
Just came here to say I have no idea what you guys are talking about, but it's awesome seeing what you are doing.
 
I will move over to the new thread, just wanted to tie up loose ends here.

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.

I was not aware those HC05 were full packages of hardware + software to do serial port emulation over bluetooth. It does seems like the simpler/better way forward, compared to the BLE + mcu chip I mentioned.

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)

My car is NA but I have never actually witnessed the ezk calling the fuel enrichment pin for the LH box in practice. Well, without enabling it in the software and coaxing it:oogle:

I am pretty sure ezk has an open collector this pin and LH weakly pulls it up, but I do not have a diagram for this. I may be wrong. It is not any sort of data transmission or analog signal. Just pulled down when the all cylinders are knocking past a threshold in EZK.

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?
The VR sensor in EZK is run through a comparator and schmitt trigger as you mention, with the output of this attached to an interrupt pin. It doesn't do any advanced analysis of the waveform so his method should be just fine.

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.

As you noticed, the digital() functions in arduino are notoriously terrible/slow. They abstract a lot away from the user for easy-of-use and portability between MCUs. If you want to get super accurate timing, there are capture/compare timers on most arduino boards that are designed to do just as you are doing, but in hardware! Though it looks like 10us variance should be good enough in my opinion.
 
I will move over to the new thread, just wanted to tie up loose ends here.
I've opened the new topic as suggested by Bob (And I've seen his interesting reply...)

My car is NA but I have never actually witnessed the ezk calling the fuel enrichment pin for the LH box in practice. Well, without enabling it in the software and coaxing it:oogle:

I am pretty sure ezk has an open collector this pin and LH weakly pulls it up, but I do not have a diagram for this. I may be wrong. It is not any sort of data transmission or analog signal. Just pulled down when the all cylinders are knocking past a threshold in EZK.
May be you have hit the target, this could explain also why this unusual voltage of 7.6V
To take a look inside the ECU and follow the traces could bring to an answer...

As you noticed, the digital() functions in arduino are notoriously terrible/slow. They abstract a lot away from the user for easy-of-use and portability between MCUs. If you want to get super accurate timing, there are capture/compare timers on most arduino boards that are designed to do just as you are doing, but in hardware! Though it looks like 10us variance should be good enough in my opinion.
I've read about timers and how to improve performance on my O'Reilly book, I believe that I need to re-read it, may be I could improve precision and learn how to make things in a better way ;-)


To remain on-topic I whould like to share some new analysis I made on the scope recordings of the last days.
I've cleaned a bit the signals and rescaled them to be better comparable.

The first two images compare Tq signal with injector pulse width, the second ones compare Tq signal with the mass air flow sensor.
As found by Bob, injector pulses seems the more similar, also if not even them overlap perfectly.
If anyone whould like to make its own analysis on the real data I've sampled feel free to download the psadata I have shared and play with them.

ACtC-3c6JnFNRz0DC15gLaDVs2IW3MOu3dkUoFSMP0yo5cLXjGvI_0622k8mBVgAq_SZv1W4hEv4nH0EZ68S9ZHfI_VOhbxtw2t_iVJKgDHjgm0OrSftL0YWDSccP2dTFimO5hq2_mk4F-bjThbx_7rotzT7=w1024-h668-no

Figure 1:
Orange: Tq-signal pulse width
Black: Injectors signal pulse width




ACtC-3f_L0ZRpBGhVoFNXgI6twnURLvNC9uwe9ew2FHzsxhQ5U8l9-a-JzzU4BeOqvpELc3Qm3Jre92C9iD6COM9q_GoHizkZ860RtgUAPrnPp8r-lwV-JoT3dnJpuSDR0g4z3vTf5YvCa_6V0Ci4qCxFHll=w1024-h668-no

Figure 2:
Orange: Tq-signal pulse width
Black: Injectors signal pulse width




ACtC-3dOkaYGEpp0lAAvu9cN_t_VWDFZhLfZpLyvpCYzhiepvdMnIP1XEHOWTRYMREQeBgFHPQE3fjUwvkGTwRnJyhr3SbAyJ_xdwBEgas2FQoJjsK6CDyfYRIVnaj02nguYJNfU-7gAD9szYfnCTSXn4uxS=w1024-h659-no

Figure 3:
Black: Tq-signal pulse width
Red: Air Mass Flow sensor voltage




ACtC-3dfXawEuEJKNxbWEszeuymwsyRt9OC7K_XR1X8mMcsuQ9HMQeITGx9TvRqK4s8075Gcnn-Uh8pJWBvyZjQdMfNOp2JbB3fOgL6UQv2SKz4G92bF3ha2_EbKondkaU0eYX5oNecSRDVtTztFObGfxdlq=w1024-h659-no

Figure 4:
Black: Tq-signal pulse width
Red: Air Mass Flow sensor voltage
 
Just came here to say I have no idea what you guys are talking about, but it's awesome seeing what you are doing.

Thanks, just call us "geeks at play" ;)

If you're interested, here's the high level view. The LH Jetronic system splits the engine control between the EZK box (ignition) and the ECU box (fueling). The EZK box monitors the engine rotation, using the CPS sensor, and controls when to trigger the spark. The ECU box monitors the incoming airflow, using the MAF sensor, and controls the injectors to provide correct fueling.

For better engine control, the EZK and ECU boxes communicate with each other. The EZK box sends the current RPM, and knock detection, to the ECU. In the other direction, the ECU sends the current engine load to the EZK. If you're familiar with old school distributors, the engine load is the electronic version of the vacuum advance can. At light load (higher vacuum), timing needs to be advanced for best power. This thread is about the [painfully] exact details of how the ECU determines the engine load, and communicates that information to the EZK using the Tq load wire.

OK?

... now back to our regularly scheduled topic...

I was going to post some Tq measurements from a '954 ECU, but my buggy Hantek scope crashed Windows 10 before I saved. #*!%@! piece of junk. I'll redo the measurements and post them tomorrow.

The ATmega processors include "pin change interrupts" that trigger when any out of a group of pins changes. This allows more than the simple arduino INT1 INT2 processing. The interrupt routine needs to keep track of the previous pin states and compare them to the current pin states to determine which pin, or pins, changed and triggered the interrupt. There's a good, but long, description of this here: http://www.gammon.com.au/interrupts

I forget what I'm using on the benchtop setup, but I think some of the measurements are using the pin change interrupt.
----
D - Your plots are interesting, and show that Tq behaves a bit differently on a real car, instead of my steady-state benchtop measurements. Once the real monitor/logger are running, this should be easy to investigate.
 
Back
Top