Hi,
in my Audi S5 2008 i use the OEM display. To have a proper fuelconsumption indication it needs a fuelflow from the emu. In general no problem, but it wants it in a special format:
It wants a continious fuelcount in microliters which counts up to 32767 and then starts from 0 again.
I could mimic this signal style with a function:
…which in general is working.
But the problem is the fuelcount channel of the emu. It sadly has just a resolution in 0,01 liters so it takes a while to count up/change and so i don’t have a continous signal. This doenst like the OEM display. It shows me 0 consumption during the time nothing is chnageging and when the count goes up in the next step i shortly get a plausible indication.
So my question is…is it possible to enable the full resultion of the emu internal fuelcount as a new channel? In best case in microliters?
My other option is to calculate the integral of the emu fuel flow with a different device and generate the fuelcount, but i expect problems with that due to limitations of my other device.
Hi,
Are you using VAG CAN stream from EMU?
Is this fuel count a part of the standard VAG stream?
If it is, we could add that functionality to our stream output.
It can also create issues if the same frame comes simultaneously from the vehicle stream and custom CAN export.
Please provide CAN frame information (ID, byte position) about the fuel count.
If the vehicle stream option is not viable, we could add a fuel count channel like that.
I am not useing the VAG CAN stream from EMU. I am manageing the CAN myselfe with a different device cause i need to do some more modifications on the CAN than just the engine stuff. Basically i pick specific stuff from the EMU and other ECUs and convert it in to the VAG format.
I think this type of fuelcount is an Audi standard for the MLB plattform…so A4, A5, A6…
Not sure if Golf, A3… use the same, but i think yes.
I have a dbc file from 2019 R8 GT2
GT2_CAN_Antrieb_20190120_V2.dbc (685.1 KB)
Which fits to my 2008 Audi S5.
The message for the fuelcount is ID 0x107
and an overflow signal in the last bit of this byte.
If it is already part of ur VAG CAN stream than let me know…maybe than i can use it from that. But sending the whole VAG CAN stream from EMU probably doesn’t fit in my CAN system.
Ok,
Now I remember that you have the OEM ECU and custom gateway.
I checked, and we don’t send the Motor_04 frame at all.
We will add the need for a microliter fuel count channel to the list of things to do.
If you are interested, we can work with you to make the VAG stream in PRO do everything that you need to simplify the system and get rid of OEM ECU. It should be doable unless there are some dynamic codes for the immo. We have pretty extensive implementation for PQ35 and MQB platforms and a good understanding of those streams.
Thx.
Long term it would be great if i could remove OEM ECU and with the dbc file i sent u it should be really easy (i could also also find the method for calculating the crc in the engine messages, if u dont have it for this plattform let me know) but i think the real neckbraker will be the immo. Need to check first what needs to be done for immo off in cluster or BCM.
How do u handle immo in MQB? Could u reproduce OEM ecu behaviour with the emu?
According dbc and CAN traffic there are just two messages the immo stuff is happening on…at ignition on and when starter is activated.
Here an example:
I will take some more logs…maybe it is decodable.
I talked with my colleagues about the immo, and I think we figured out how it works. First, one of the modules reads the immo code from the key. Next, it passes this code to other modules, which lock/unlock specific functions. All the modules work independently, so the BCM doesn’t need special communication with the ECU to unlock the starter. OEM ECU must receive the correct key to unlock the fuel pump/injection/ignition. With EMU PRO, you don’t need that key in ECU because you won’t be blocking anything there anyway.
With the basic stream for MLB from PRO and no OEM ECU, BCM should still unlock anything it controls after reading the immo code.
That is how we run our SEAT Leon Cupra Mk3. We had our first drive this week with EMU PRO and GDI working. Everything works without OEM ECU or any modifications to other OEM modules. We just implemented the MQB stream using the DBC file and things we checked in the real car.
Makes sense…looking at the messages there just seems to come a rqst msg from the engine and a answere from the vehicle. So u might be right that the other ECUs are not interested in the engine.
I was working in truck applications and there BCM was not only happy with the key, but needed the immocode from the ECM to unlock the starter output.
I think i can set up something preliminary to test the behaviour.
- Block all Immo messages from OEM ECM in my gateway
- The vehicle has 2 p2p wires between BCM and ECM which i think are the starter activation lines (need BCM cmd due to keyless go)…check if i get a signal when key pressed
- jump starterrelay and watch the behaviour.
Yes, I forgot to mention this.
We also have one direct wire between BCM and ECU.
ECU has to connect this wire to the ground to unlock BCM for engine start.
Thx for the info.
Throwing the OEM ECU away will solve a lot of problems in my current setup.
Will try the VAG stream of the EMU and compare it with OEM. But would be nice if u could also compare ur current VAG stream with the content of my dbc (this dbc is not handmade and comes from a good source). I think there are some differences between MQB and MLB or what expiriences do u have regarding MLB?
But i think only messages Motor_01-07 + TSK_04 (for CC) are really relevant.
The stream for PQ35 is implemented correctly.
The stream for MQB still needs a lot of work.
It’s more of a template for now.
I don’t know many details about the streams, but there are definitely differences between MLB and MQB. For example, engine torque information is sent differently for the newer DSG boxes in MQB.
We are interested in implementing the MLB stream, but we need to find some time for that and probably a car for in-house testing.
I just played around with the immo stuff and actually u are right…the vehicle isn’t interested in the absence of the immo informations of the engine. The whole startersystem seems a bit strange…the first of the two direct lines from BCM to ECM shows 12V when startingbutten is pressed, second one gives just a short 12V pulse. If both lines are disconnected, the engine is cranking anyways, so assume OEM ECU listens also to KL50 signal on CAN. Anyhow…so immo is no more reason to keep OEM ECU.
One small thing is left…Oillevel/temperature sensor. I thought it was a sent sensor, but the signal is something different:
It is from Hella and has number 6PR 008 079-081 or 6PR 013 680-011 (need to check detailed when im under the vehicle the enxt time).
Does anyone know what kind of communication this is and how to read it correctly?
Edit:
Found something. Seems to be a Hella specific kind of PWM signal:
This seems to be the evaluation logic of the newer sensors but i guess is similar but easier. With my CAN gateway i think i can setup something to read this.
We have an implementation for the Hella oil level sensor with that PWM signal.
But the signal you measured looks different.
Hella sensor should have 3 pulses every second (period 1000 ms).
Each pulse must be between 22 and 88 ms in duration.
Please make a new, zoomed-out screenshot to better see the period with more pulses.
This sensor is installed:
And it seems to have just a two pulse signal:
One pulse looks like that:
Other like that:
Probably the older Hella sensor have a different logic than the newer ones.
Output is a low side output.
Period seems to be around 1,4-1,5s
Stating pulse of the pulse has 80ms duration…then i guess the pause indicates if it is oil temperature or level and than the duration the actual value.
Are u interessted in implementing this for level and temperature?
I prefer to have it in the EMU, but i think i can handle it via my other ECU since the pulse durations are quite long.
