dword value translate into real

[todiboa]

Hello guys,
I would like to convert a dword that this case is a block as below:
In EFI Live to send to ECU f4 57 01 00 b4 receives 63 bytes below:
f4 57 01 00 b4 f4 95 01 0b 85 00 00 00 89 00 24
00 25 00 29 00 00 00 70 58 80 00 80 04 59 48 00
31 35 5a cf e7 00 00 8a 27 00 43 00 3a 80 50 00
68 08 48 04 24 07 01 02 5f 80 e0 00 a1 2c 30 88
bd c1 02 34 09 47 02 d6

Ignoring that in response to the request back ECU f4 57 01 00 b4 we f4 95 01, the rest of the data is from my ECU parameters:
0b 85 00 00 00 89 00 24
00 25 00 29 00 00 00 70 58 80 00 80 04 59 48 00
31 35 5a cf e7 00 00 8a 27 00 43 00 3a 80 50 00
68 08 48 04 24 07 01 02 5f 80 e0 00 a1 2c 30 88
bd c1 02 34 09 47 02

Ja paper could convert nearly all of that data set, e.g. the bytes 00 00 00 represent the code errors of the sensors, the next byte 89 is the engine temperature and byte 24 is the TPS volts...

But the first two bytes as 0B and 85 is a dword that rode in EFI Live and gave the final digits of my ECU is 2949, but on paper I can not convert this value ...

Can anyone here help me identify or translate as dword 0B 85 in 2949?

My intention is to develop its own software monitoring and lack only unravel this puzzle for me to start developing.

I count on the help of the guys in this forum

Looking forward.

[Blacky]

To decode a WORD value (16 bits), you need to set Start="the second byte - i.e. the byte position of the 85 in the reply" and Bits=16.
Use a factor of 1 and an offset of 0.

To display it as a hex number (i.e. 0B85) check the "Hex" checkbox.
To display it as a decimal number (i.e. 2949) uncheck the "Hex" checkbox.

Regads
Paul

[todiboa]

Paul, EFI has me the result of 2949, because the option is desmacada hex and offset is 0.

Now as I can get value in 2949 making this conversion in pencil, this is what I understand as this will help me to further refine my EFI and also help me with the work of the college is to develop a monitoring system sensors of the vehicle, understand ...

Can you help me with this?

Thanks!

[Blacky]

Paul, EFI has me the result of 2949, because the option is desmacada hex and offset is 0.

Now as I can get value in 2949 making this conversion in pencil, this is what I understand as this will help me to further refine my EFI and also help me with the work of the college is to develop a monitoring system sensors of the vehicle, understand ...

Can you help me with this?

Thanks!

I'm not sure what you are asking for.

Are you asking how to make the EFILive software display the hex bytes 0x0B85 as the decimal value 2949 or do you want it to display as the hex value 0x0B85?
Or
Are you asking how to convert all the other data bytes into their decimal values?
Or
Are you asking if anyone has information on the data stream format that matches your ECU with an EEPROM ID of 0x0B85?

Regards
Paul

[todiboa]

Paul is well, I already get that EFI 0b turn 85 in 2949, but what I want now and out of EFI.

What I want to know is how the EFI could translate 0b85 in 2949, because if you look at the ASCII table 0B is 11 in decimal and 85 is 133.

On the efficiency factor and offset left by 1 to 0 and EFI 0b85 translated in 2949, now look at the ascii table not of this result.

I want to convert 0b85 in 2949 is at hand, understand?

Sorry my english, but I'm Brazilian and do not speak English, I used the google translator to get me to communicate with you.

Would like to explain what I got?

Looking forward!

[Blacky]

0x0B85 is a hexadecimal number. Hexadecimal numbers are base 16. To convert base 16 numbers into base 10 numbers (i.e. decimal) you do this:

0*16*16*16
+
B*16*16
+
8*16
+
5

Where
A=10, B=11, C=12, D=13, E=14 and F=15.

So you end up with:

0*16*16*16=0
+
B (which is 11) * 16*16 = 2816
+
8*16 = 128
+
5

0+2816+128+5 = 2949

Regards
Paul

[todiboa]

Thanks Paul, you saved me ...

Thank you, thank you so much!

This helped me understand how and EFI is working, thanks!


Hugs!

[joecar]

Type either of these at Google:

0xb85 to decimal

2949 to hex

[todiboa]

Staff can someone help me convert the decimal 31 in ignition advance?

[Blacky]

Staff can someone help me convert the decimal 31 in ignition advance?

I'd need to know which data stream definition you are using.

The data streams are defined in *.ds files available here:
ftp://ftp.diy-efi.org/pub/gmecm/
Download the file ALDLstuff.zip
There is a word doc in that zip file that shows you the correct *.ds file for your application, based on engine size, 8th digit of VIN, year etc.

The correct data stream file will show you the translation for all the parameters. For example in A278.ds the spark advance is defined as:

33 SCVSATDC SPARK ADVANCE MSB
34 SCVSATDC+1 SPARK ADVANCE LSB
DEGREES = value * 90/256 (SIGNED)

That means it needs to be defined in EFILive like this:
14407
In the EFILive definition gm278.xml, the spark is incorrectly defined as unsigned. I just noticed that while creating this reply. The example image above has the signed check box checked correctly.

MSB is the most significant byte and LSB is the least significant byte.
i.e. if the MSB was 0x00 and the LSB was 0x47, the 16 bit hex value would be 0x0047 which converts to decimal 71.
For data stream definition A278.ds, to convert the raw value 71 to spark advance you need to multiply by 90 and divide by 256
so spark advance is 71*90/256 = 24.96 degrees.

Note: the spark advance may be (and probably will be) computed differently for different data streams. That's why I'd need to know which data stream you are using before I can explain how it is done for your particular application.

Regards
Paul

[todiboa]

Paul I do not know what extato DS, but I'm using is that this http://www.4shared.com/document/XdFPHr7n/ds_online.html aei on the internet that quasto the hit, but the advancement that mara is around 16.00 and idle and is actually around 4 , 5.
I know because I measured with the scanner workshop near here.

[todiboa]

Paul after much searching I found is A135.DS, but says that the advance is the byte 33, but even with the factor that made the DS the progress that brand is not the actual value, eg 31 x 0.3515625 decimal the result is 10.
I went in the shop and measure the advance at idle is at 4.5 to 5.
Another thing, if I lock the advance in the EFI indent marker must have the value 0 when locked Jump through the advancement AB?
Can you help me with this?
Thank you.

[todiboa]

Paul tells me something, because when I save the log in EFI 4 and saved for analysis on another day, when I opened the log in Dashbord he goes fast at the speed of light?
Already regulei the play speed to 0.5 and nothing has changed in speed viusalização.

Any idea why this occurs?

[Blacky]

Paul after much searching I found is A135.DS, but says that the advance is the byte 33, but even with the factor that made the DS the progress that brand is not the actual value, eg 31 x 0.3515625 decimal the result is 10.
I went in the shop and measure the advance at idle is at 4.5 to 5.
Another thing, if I lock the advance in the EFI indent marker must have the value 0 when locked Jump through the advancement AB?
Can you help me with this?
Thank you.

33 SAC SPARK ADVANCE IN DEGREES, N=E*256/90
DEGREES = N*90/256

Based on that text above (from A135.ds), 0.3515625 is the correct factor.

The SAC parameter shows the "commanded spark". That means when the ECM transmits 31 it is attempting to advance the spark to 31*0.3515625=10.9 degrees. I don't know why the measured spark advance is different to what is being commanded by the ECM.

Is it possible that A135.ds is the wrong data stream file for your vehicle?
Is it possible that there is a mechanical fault causing the actual timing to be different from the commanded timing?
Are you 100% sure you measured the timing accurately?

Regards
Paul

[Blacky]

Paul tells me something, because when I save the log in EFI 4 and saved for analysis on another day, when I opened the log in Dashbord he goes fast at the speed of light?
Already regulei the play speed to 0.5 and nothing has changed in speed viusalização.

Any idea why this occurs?

I'm sorry, I don't know. Can you send me a log file so I can test it here?

Regards
Paul

[todiboa]

Paul, follow my log for you to analyze the playback speed.
http://www.crocko.com/68917D8A72F1467A825C82D01040DCF3/MULTEC_700_20130121_154032.alg

as the ignition advance so I know if it really is mechanical failure if I take the mechanic to check, because it is not really my area the mechanical part.
Thank you.

[Blacky]

Paul, follow my log for you to analyze the playback speed.
http://www.crocko.com/68917D8A72F1467A825C82D01040DCF3/MULTEC_700_20130121_154032.alg

as the ignition advance so I know if it really is mechanical failure if I take the mechanic to check, because it is not really my area the mechanical part.
Thank you.

Can you please send the file to me via email at paul@efilive.com, thanks.
Regards
Paul

[todiboa]

Paul, already sent the log in your email, ok?
Thank you.

[Blacky]

Paul, already sent the log in your email, ok?
Thank you.

I received the log file, thanks.

I opened the log file and clicked on the "Play" tool bar icon and it played back correctly at about 10 frames per second.
I'm not sure why your install plays back at fast speed.

Regards
Paul

[todiboa]

Okay Paul here in Brazil I'm not the only one that uses EFI Live, has another guy that uses and also happens to play the same log.
This other guy tried to play the old log into a machine and repdução was normal, ie 10 frames per second.
Already in most modern machine like mine that is Pentium Dual Core 2.1GHz speed and 4GRAM vai a snap.

Do not know why, is it something operacial system, I'm using Windows 8 and Windows 7 using the same result is the same.

What is your operating system and configuration of machine?

Thank you.

[Blacky]

The machine I tested it on was: Windows 7 64-bit Intel i7 dual 3.4GHz, 12GB RAM, so I don't think it is the speed of the computer that is causing the problem.
The only setting that controls the playback speed is shown below:
14411

Regards
Paul

[todiboa]

Paul next guy wanna know if the injection time is this right here:
* 11 OLDRFPER TIME BETWEEN REFERENCE PULSES (MSB)
* 12 +1 OLDRFPER TIME BETWEEN REFERENCE PULSES (LSB)
************************ MSEC = ([N11] * 256 + [N12]) / 65,536

This information is contained in A135.DS that matches my powerful Chevrolet Kadett GL 1.8 EFI Petrol.

I mounted the macro and now need to make sure if that's right. As to factor too have doubts, did seguite:
TI = ((11 * 256) + 12) / 65536, the result was 0.043151855. Is that correct?

I ask this because I want is to calculate consumption liters per hour and according to information I passed the time should be used for injection.
Besides, you know the formula to calculate the consumption of liters per hour at injection time?

Thanks!

[Blacky]

"Reference Pulses" refers to the pulses from the crank sensor on the flywheel and is used to calculate RPM.
It provides a higher resolution signal than the previous byte, which only shows RPM in increments of 25.

The formula is actually
((11*256)+12)*65.536 (sixty-five point five three six) = 43.151855

To convert references pulses to RPM you need to do this (assuming the crank trigger has 60 teeth):
One complete revolution will take 43.151855*60 teeth = 2589ms
So in 1 millisecond the crank will complete 1/2589 revolutions.
Multiply that by 60,000 to convert milliseconds to minutes and get rpm = 23 rpm

23 rpm seems a bit low so maybe your crank does not have 60 teeth.

------------------------

Injector pulse width is defined here:

36 BPW BASE PULSE WIDTH (MSB)
37 BPW+1 BASE PULSE WIDTH (LSB)
mSEC = ([N36]*256 + [N37])/65.536

To convert from pulse width to fuel flow in liters you must know the "flow rate" of your injectors.

Regards
Paul