NefMoto

Has anyone created an A2L to ECU converter for measurements?

I'm 3/4 of the way through creating a Perl script which does exactly this but there are a couple of values that are giving me issues.  I think I have most of the columns sorted expect for the offset column (B) which is giving me some issues.  Does anyone know how the formula for calculating the offset based on the A2L description?

As an example, tv2

A2L def:
/begin MEASUREMENT

    atv2
    "aktueller Lernkennfeld-Integratorwert der Regelung hinter Kat Bank2"
    SBYTE
    t100msxs_sb_q0p01
    1
    100
    -1.28
    1.27

   
    FORMAT "%5.3"
   
    ECU_ADDRESS 0x3829FC
    /begin IF_DATA ASAP1B_ADDRESS  KP_BLOB 0x3829FC /end IF_DATA
    /begin IF_DATA ETK  KP_BLOB 0x3829FC 0x1 0x1 /end IF_DATA
/end MEASUREMENT

/begin MEASUREMENT


ME7info .ECU output
atv2            , {}                                , 0x3829FC,  1,  0x0000, {s}       , 1, 0,         0.01,      0, {aktueller Lernkennfeld-Integratorwert der Regelung hinter Kat Bank 2}

Current version of Perl Script
atv2             , {}                    , 0x3829FC,  1,  0x0000, {s}       ,1, 0,          0.01, 1.28, {aktueller Lernkennfeld-Integratorwert der Regelung hinter Kat Bank2}

When I have a couple of little calcs figured out I will be making this available if anyone wants it

Very interesting. i am also interested in the a2l format, but for different reasons: i'd like to make an xdf to a2l converter so i can import xdfs into winols and create .kps.

Yeah that would also be interesting.

I'm trying to do this so I can import A2L defined variables into IDA, which I can pretty much do now.  But the second part is to have every A2L measurement definition in ECU format for logging without having to manually create the entries (worst case change the address from the A2L bin address to my 558B-002 address)

atv2 offset appears to be zero...
-1.28 1.28 are NOT offsets in a2l, they are possible min/max values ... i.e. atv2 is a single signed byte that ranges from -128 (0x80) to 127 (0x7f), and scale is .01...

so technically 1.28 (should be 1.27) is wrong but hey, thats just nitpicking.

i dont think there is a way to encode offset in a2l, but i could be wrong.

I think I getting there, it has to do with the Coeffs in the Compu Method.  If you look at the compu method name most are actually defined with factor and offset in the title!

t100msxs_sb_q0p01
Offset 0
Factor 0.01
(atv2)

temp_ub_q0p75_o48
Offset 48
Factor 0.75
(tmotlin)

OH duh. there you go

youll just have to make a compu look up table in perl and deref it.

should be cake.
any chance you can post the perl on github or something?

I will def make it available one way or another but the calc is not that easy as the title is only approx, to get it correct it needs to be calculated from the Coeffs themselves, will try and have it done by tomorrow. Will keep posting on progress

easy enough to make a hash table with the factor/offset in it.

Yeah the actual Perl side is not the issue it's the figuring out how the Coeffs work together to give the Factor and Offset.

In the ASAP2 defs the formula is f(x)=(axx+bx+c)/(dxx+ex+f), this does not work for all cases using the ECU from ME7Info as a guide.

I'm slowly getting there

At this point looks like it might be

factor - f/b
offset - c/b

That matches 10 CompuMethods that use RAT_FUNC, more to test to make sure

assuming a, d, and e are always zero (linear transfer function), shoudlnt it be f(x) = (b/f)x + c/f, so facctor is b/f and offset is c/f?

Ok, I'm 90% of the way there but there are a few entries that are not matching the ECU file from MEInfo.

As an example:  A2L then .ECU
frkte_w   0.0001667    frkte_w   0.0001111

Now the interesting thing is when I check my XDF for the krkte factor it is 0.0001667.  I would have thought it should be same as frkte,  as they both use the same CompuMethod:rkti11_sy, so factor should be the same right?

Could the .ECU output be wrong for these measurements?  Or am I thinking about this wrong?

Yeah agree, but unfortunately they are not always 0

frkte factor depends on processor ticks and will different if MCU use different clock frequency.

if any are non zero you cannot represent the transfer function via factor + offset.

if a, b and d are zero, but e is not, then the transfer function is a linear inverse.

Yep, I will try inverse function tomorrow, thanks

Totally agree and understand but the A2L should have been written with the correct MCU, so it should be correct.  I will do a little bit more digging to figure this out.

I now only have 3 that don't match from A2L generated to ME7Info

frkte_w
tevfakge_w
tevfa_w


The following were because ME7Info converts to g/s from kg/hr, I will add this conversion to make it easier
dmletanf_w
dmletan_w
mldmn_w
mldmx_w
mlhfmm_w
ml_w
msabg2_w
msabg_w
msdk_w
mshfm_w
msl
mslift
mslift2
mslt2_w
mslt_w
mslv2_w
mslvt2_w
mslvt_w
mslv_w
msndko_w
mspcv
mstedtef_w

Interesting... Looking at the ME7_std.map

In this map file, the conversion factors for 24MHz are inserted as default.
# The ME7Info tool will automatically determine the used cpu speed and put the
# correct conversion factors into generated ecu characteristics files!

The conversion of injection time internal value -> physical value  depends
# on the ecu's cpu speed:
# 20 MHz -> factor = (1/312.5)   = 0.0032     (3.2us/TickTime) 
# 24 MHz -> factor = (1/375)     = 0.00266667 (2.667us/TickTime)
# 32 MHz -> factor = (1/250)     = 0.0040     (4us/TickTime)        (*)
# 40 MHz -> factor = (1/312.5)   = 0.0032     (3.2us/TickTime)      (*)

I will double check my cpu but I'm pretty sure it's 32Mhz 7.1.1 which would make sense, hence the factor from the A2L would be correct

Will check tomorrow morning, getting too late over here...

Just FYI.
me7info extract frkte factor data from ME7.1.1 dumps incorrectly.
You can check it on 4Z0907551N/P/T/R/S dumps for example.
me7info says it equal to 0.0001111, but really value is 0.0001667

   

Yep, that's what I figured out last night, thanks to your comment about being CPU dependant

Well that makes my values match up 100% with ECU file!

Do you know if there are any other variable's factors that are incorrect?

Super old thread but did this tool ever release?