LLM fake

Hi there!

I had another night of very little sleep and was thinking about all sorts of things. It occurred to me that I might try recreating an LMM (likely referring to a Lambda Measurement Module) on a microcontroller sometime this winter. It shouldn't be too difficult; there's certainly an analog output available on a PIC or, even better, an AVR. What would you use as control variables? The engine speed, the boost pressure, the throttle position? Individually, or in combination?
This would then provide a fairly accurate representation of the original LMM's characteristic curve, and it is also likely to be easier to implement than in traditional analog circuit design.

Hello Joergs,

We had a similar discussion about the analog fake before; there was a longer thread on that topic. To maintain the air mass, you would need the intake temperature, the outside air pressure, the boost pressure, and the engine speed. With those values, you can calculate the air mass.

However, this only applies as long as the EGR system is not active. If it is active, you would also need its recirculation rate, and then you encounter a completely different problem: The EGR control depends on the mass airflow sensor (MAF) signal, and if you try to simulate it along with the EGR output... it can easily go wrong and become unstable.

I would think along a completely different line, namely a digital implementation of Ulf's correction circuit idea.

Fuer den LMM gibt es ja Sollwerte, die unter bestimmten Bedingungen gemessen werden (IMO 3000 Umdrehungen und Vollgas im 3. Gang). Aus Ladedruck, Drehzahl und Gaspedalstellung sollte man solche Situationen erkennen koennen (bis auf den Gang, aber der ist IMO nicht so wichtig, bzw. liesse sich aus der Geschwindigkeit rueckrechnen). Der Mikrocontroller wuerde dann folgendes tun: Er ueberwacht das LMM-Signal und gibt es unveraendert weiter. Wenn er eine solche "Sollwert-Situation" erkennt (die kommt beim normalen Fahren durchaus vor, zudem kann man sie ja bewusst alle x km provozieren), dann vergleicht er den LMM-Output mit dem Sollwert. If the language model is working correctly, we can proceed; otherwise, we will make appropriate corrections from this point forward (which would require us to find a good...).(strategy to consider). A similar process occurs in every "setpoint" situation, and since an LMM (laminar mass flow meter) doesn't suddenly fail with age, but rather gradually degrades in its performance, the entire system works as long as the LMM values still react to changes in air mass. However, if this no longer happens, the controller will also detect it and can turn on an LED...

The advantage would be that you can use an LLM for a significantly longer period, it's less likely to gradually degrade in performance, and you won't encounter fake data, but instead receive usable signals that consistently stay within the acceptable range.

What do you think?

Best regards,

Jan.

Hello Jan!

That's a good idea! It's certainly much easier to implement than a complete fake. I'll think about it and study some diagrams.

It's me again!

Okay, if I expand on Jan's idea, even with a 'dummy' LMM, the correction function of the MC would come into play and provide the correct value to the control system! However, we're initially excluding the AGR (automatic gear range) or am I mistaken?

Hi Joergs,

The question is, what constitutes a dead LMM (Laminar Flow Meter). Isn't it more likely that the values simply get worse, but still react to changes? A completely dead LMM would more likely be the result of broken wires or complete contamination, rather than what causes the "death" of most LMMs.

If you're only correcting the values, you can safely leave the AGR (Abgasrückführung) active because you're simply calculating the original state based on the readings from a worn-out MAF sensor (Mass Air Flow sensor), but not artificially manipulating them.

If the mass airflow sensor (MAF) is completely dead, my idea is that the engine control unit (ECU) would trigger a "limp mode" or error state. Additionally, it might try to compensate in some way, but ideally, you wouldn't want to run without a functioning MAF sensor for an extended period.

The goal would not be to replace the LMM (likely referring to a lubricant monitoring module), but rather to enable significantly longer usage, perhaps even for the entire lifespan of the vehicle.

I haven't had any experience with the LMM yet (mine only has 31,000 km), but based on everything I've read here (see also the thread with Ulf's analogous correction), something like that would probably be a good idea.

Best regards,

Jan.

ok einigen wir uns auf korrektur !

Here's another approach: If I read the calculated quantity from the system and adjust the delivery accordingly, wouldn't that involve relatively little effort?

Hi Joergs,

It would also be possible to calculate it based on engine speed, boost pressure, and possibly the throttle position. However, this approach would have the advantage of being able to achieve the same result without communicating with the engine control unit (ECU), because these signals can be directly provided to the motorcycle's controller.

Aeh... oder ganz anders: Wir basteln uns aus einem MC ein eigenes Steuergeraet und werfen das originale raus...

Best regards,

Jan.

Hi Joergs,

It would also be possible to calculate it based on engine speed, boost pressure, and possibly the throttle position. However, this approach would have the advantage of being able to achieve the same result without communicating with the engine control unit (ECU), because these signals can be directly provided to the motorcycle's computer.

Aeh... oder ganz anders: Wir basteln uns aus einem MC ein eigenes Steuergeraet und werfen das originale raus...

Best regards,

Jan.

die letze variante gefällt mir auch sehr gut !

Let's see, I'm going to sue myself, and then we'll see what happens!

@jan6k

'I think the idea of reading the target value calculated within the control unit is brilliant. It eliminates a huge amount of computational effort and complex data logging. You would only need the curve for air mass and voltage, and that's it! Consider the 1Z and AWX engines, for example. They are two completely different engines with vastly different air mass sensors. If you want to apply this correction to both, you would have a huge amount of work and totally different calculations. However, if you extract the data from the control unit, you only need to deal with converting the air mass into an output voltage.'

Here's the translation:

'For example, Opel uses the same Bosch mass airflow sensor (MAF) as the Volkswagen Group (VAG). With relatively little effort, you can adapt the communication to the control unit and then implement the rest identically!'

What do our experts like Ulf, Rainer, Bertil, Disel_Gustav, and Gremlin think about this?

Hello,

@Jan6K: For the intake air temperature, the TDI does not have a sensor that could be tapped into when there is a missing mass airflow sensor (MAF).

My mental LMM "fake" has now shrunk to a boost pressure implementation using the normal LMM voltages, of course as a purely analog solution.

Basic principle:
1. Without boost pressure, the mass airflow sensor (MAF) sends a signal voltage to the engine control unit (ECU) that corresponds to the engine's idle speed.
2. At full boost pressure, the mass airflow sensor (MAF) input to the engine control unit is approximately 4.8 volts, which is similar to the reading at full load and high RPM.

Between these points, the simulated mass airflow (LMM) voltage increases linearly with the manifold absolute pressure sensor (MAP) voltage.
This can be achieved with a simple op-amp and a feedback circuit, using two potentiometers for precise adjustment.

The engine shouldn't produce excessive soot, because even if the engine control unit (ECU) theoretically reports, for example, 1800 mg/stroke at full boost pressure and 2000 rpm, the torque limiter will kick in, and as a result, no more fuel will be injected, just like with a normal mass airflow sensor (MAF).

If the engine computer performs a stricter plausibility check of the MAF sensor voltage, this system would naturally fail .

To simulate the AGR (Abgasrückführung - exhaust gas recirculation) control, one could convert the "valve opening pulses" directed against the mass flow into a DC voltage, which would reduce the boost pressure voltage at the positive input of the operational amplifier.
Here's the translation:

"This way, the engine control unit receives what it wants to see as a successful EGR activation: a decreasing mass airflow sensor voltage. For fine-tuning, another trimmer would need to be installed somewhere between the EGR control terminal and the oxygen sensor."

If you're interested, I can outline the basic principle and post it online here.


Currently, I'm working on a different project: trying to restore an old, bulky Pierburg mass airflow sensor that's showing its age by increasing its output voltage to a level comparable to a new one.
Based on my previous attempts with the measurement table, it seems sufficient to solder just one resistor in place .
Diagnostic tests using VAGCOM are still pending. If the results are positive, I will publish a technical article about it here online.

I'm going to hit the brakes .

The FAKE should not cost more than a new LMM .

Otherwise, I would use engine speed, turbocharger boost pressure, and turbocharger temperature for a calculation (without considering the exhaust gas recirculation system).
'Because the amount of fuel injected into the diesel engine is determined solely from this data (with correction factors, of course). Since we also have vehicles that are functioning correctly, we can use them to determine the target values.'

All of this data can be read out or tapped directly from the wiring harness.

CU Gremlin.

I'm going to tap the brakes .

The FAKE should not cost more than a new LMM .

Otherwise, I would use engine speed, turbocharger boost pressure, and turbocharger temperature for a calculation (without considering the exhaust gas recirculation system).
'Because the amount of fuel injected into the diesel engine is determined solely from this data, with correction factors applied. Since we also have vehicles that are functioning correctly, we can use them to determine the target values.'

All of this data can be read out or tapped directly from the wiring harness.

CU Gremlin

ok ist ne klare position ! ich sehe nur das problem diese 3 angesprochenen größen vernünftig mathematisch zusammenzufassen. leider läßt sich auf nem mc keine oracle-instanz implementieren !

Regarding the cost, I think we might be able to keep it within the price range of the DC version! It's certainly more expensive than Ulf's variant, but I believe it represents a kind of optimal balance. Let's see what happens!

joergs wrote:

ich finde die variante mit auslesen des im stg errechneten sollwertes genial. damit fällt enormer rechenaufwand und aufwendiges datenlogging weg. du brauchst dann nur noch die kurve für luftmasse und spannung und damit war es das !

Hi Jörg,

Have you considered that the engine computer outputs a target value per intake stroke }, while the mass airflow sensor (MAF) provides an input of "mass airflow per stroke multiplied by RPM"?

In order to calculate a fake voltage for the LMM (Ladedruckmesser), you would need to at least correlate the desired LM value with the current engine speed and generate an analogous voltage from that data, which would then be fed into the engine control unit.

Is there a way to extract an "unfiltered" mass airflow sensor (MAF) value from the engine control unit (ECU), one that hasn't been adjusted for engine speed, so that it can be directly converted into an input voltage?

But never mind:
If the boost pressure is too low, the engine computer still "senses" a sufficient amount of air based on its own target value and releases the full injection quantity -> resulting in soot.
To prevent that, you would also need to deal with the actual boost pressure... but you can also get that information from the engine computer.

What about the sampling rate of such a overall system (including the output of the engine control unit)?
Could it also follow faster dynamic processes – e.g., full throttle from a partial load condition – without, for example, excessively prolonging the turbo lag?

ok ist ne klare position ! ich sehe nur das problem diese 3 angesprochenen größen vernünftig mathematisch zusammenzufassen. leider läßt sich auf nem mc keine oracle-instanz implementieren !


No... it's actually quite simple.
Engine displacement multiplied by engine speed equals the mass of air per unit of time. Multiply that by the boost pressure, and you're done.
Correction factors include intake air temperature and filling losses (which increase with engine speed).
The target values can be obtained based on a 'good' motor.

I'll put together some formulas next week .

BTW: Reading data from the control unit is likely only feasible via CAN. Otherwise, you'll block the K-line, and it will also be very slow.

CU Gremlin.

Sorry, I'm in the middle of moving right now and just got back to answering.

@ulf

'I understand about the voltage related to the air mass. I think I can get the RPM from the same measurement group as the calculated air mass value, so it should be straightforward and the RPM can be included.'

Okay, I hadn't yet considered the issue of insufficient boost pressure. However, that shouldn't be a problem because I can read both the target and actual boost pressures and compare them. If the actual boost pressure is xx% below the target, it indicates an error, and either the original value from the mass airflow sensor (MAF) is passed on, or a default value is used.

Regarding the sampling rate, I don't have a very precise reference point. In my experiments with the EL323 and OBD-II (see obd-2.de), I achieved approximately 3 measurement values per second. However, there's additional overhead involved, such as graphics processing and accessing the serial interface through indirect methods! According to the specifications, the response time of the device should be a maximum of 0.1 seconds. Assuming this is accurate, and theoretically allowing for 10 measurement readings per second, I think that after considering conversion, calculations, and other factors, you might realistically achieve around 6-8 measurements per second! I believe that should be sufficient. Or do you think so?
@gremlin
'Your formulas are interesting, but in my opinion, too simple! If they were as straightforward as described, it would be hyper-genius and easy! It would be interesting to see your written formulas with the inclusion of correction factors. CAN communication would be great, but unfortunately, it's not available everywhere. The K-line, on the other hand, is readily available. You are right that using it would then be too restrictive. However, with a thread-safe communication interface, it could be made to work, and each reading process would receive its requested data. It's a bit of effort, but it's solvable!'

ok ist ne klare position ! ich sehe nur das problem diese 3 angesprochenen größen vernünftig mathematisch zusammenzufassen. leider läßt sich auf nem mc keine oracle-instanz implementieren !


No... it's actually quite simple.
Engine displacement multiplied by engine speed equals the mass of air per unit of time. Multiply that by the boost pressure, and you're done.
Correction factors include intake air temperature and filling losses (which increase with engine speed).
The target values can be obtained based on a 'good' motor.

I'll put together some formulas next week .

BTW: Reading data from the control unit is likely only feasible via CAN. Otherwise, you'll block the K-line, and it will also be very slow.

CU Gremlin


@gremlin

Are you sure that the formula is correct?
Let's assume everything is running in idle mode.

Engine displacement: 1900ccm = 1.9 liters.
speed = 830 RPM = 13.83 RPS
Air density: 1.87 g/l.
lodeddruck = 0 bar

If I plug this into your formula and ignore the air pressure, I get g/s as a unit. However, the value of the airflow is only about 1/5 of what the engine control unit (ECU) calculates. If I add the air pressure for any given RPM, the units no longer match!