Goblin

For anyone familar with the thread about getting the FJO to work right with a DataLogIt, this is the document I was putting together.

For anyone unfamiliar with it, I've been hacking the PowerFC/DataLogIt communications protocol.

These are the results so far (Ok, UBB, please don't mangle this too badly... <g>).

Goblin

************************************************** ***

PowerFC/DataLogIt Communications Protocol Description
-----------------------------------------------------
Revision History:
12/31/02 : Initial Revision - kp
01/08/03 : Document Format - kp
01/09/03 : Added Real Time Monitoring Packets - kp
------------------------------------------------------
Authors:
Kris "Goblin" Pelley
************************************************** ***

===================================
Table of Contents
===================================
1: Introduction
2: PowerFC/DataLogIt Communications
3: Data Types
4: Packet ID's
5: Real Time Monitoring Commands
6: Process For Working the Protocol
7: A Note About FCEdit


===================================
1: Introduction
===================================

This is a living document. As new understanding is reached about the
communications protocol, that information will be added to the document.
Please share any new information you discover. It benefits us all as
a community.

This document is written from a programmer's standpoint. As such it
is intended for programmer's eyes. If the words "packet", "byte",
"short word", or "fixed point" scare you, you'll have a bit of a
learning curve in front of you if you intend to keep reading.

This document is intended for informational purposes only.
Should you feel like writing software to communicate with your PowerFC/
DataLogIt, please check, double check, and triple check everything you
do. The authors of this document make no guarantees about the
information contained within it, and take no responsibility for anything
done with the information contained within it. Use it at your own risk.

Many thanks to Glen and Steve for their excellent DataLogIt device
and FCEdit software.


===================================
2: PowerFC/DataLogIt Communications
===================================

-------------
Packet Format
-------------

Any information sent to or received from the PowerFC/DataLogIt is done in a
standard packet format:

0xnn 0xss 0x..[0xss-0x02] 0xcc

0xnn - ID
0xss - Number of bytes in the command, excepting the ID
0x.. - 0xss-2 bytes of data. No bytes of data is perfectly valid.
0xcc - Checksum calculated as 0xFF-0xnn-0xss-0x..

If there is no data in the packet (0xss is 0x02), then the packet is a Read
Packet. Read Packets are issued to the PowerFC/DataLogIt by the software to
request data. The exception to this is the Acknowledged Packet (ID 0xF2) which
is sent by the PowerFC/DataLogIt in response to a write packet.

If there is data present in the packet (0xss is more than 0x02), the the packet
is a Data Packet. Data Packets are sent from the PowerFC/DataLogIt to the
software in response to Request Packets. Data Packets may also be sent from the
software to the PowerFC/DataLogIt in order to write data into the PowerFC/
DataLogIt. To make it easier to understand, we'll refer to Data Packets sent to
the PowerFC/DataLogIt as Write Packets.

There is one exception to this packet format. The first time a packet is sent
to the PowerFC/DataLogIt, a malformed packet is returned. I'm assuming this
is the DataLogIt box responding with some kind of version information. The data
that comes back is either 0xF0 0x56 0x32 0x4B, or just 0x56 0x32 0x4B.


-------------------
Reading and Writing
-------------------

To read from the PowerFC/DataLogIt, a Read Packet is sent with the ID of the
data being requested, and a Data Packet of the ID type is returned.

Writing to the PowerFC/DataLogIt is done by sending a Write Packet with the ID
and data in it, and receiving an Acknowledged Packet in response to indicate
that the Data Packet was sucessfully received.

For some reason, FCEdit sends a Map Indices Request before a group of Write
Packets. Not before every write Data Packet, just before every group of however
many Write Packets it happens to be sending. I don't know why. Oversight,
possibly. Or the Map Indices Read could be establishing some sort of baseline
ready state within the PowerFC/DataLogIt. Flushing the cache and making sure
the unit is ready for a new command stream. Or maybe it's to make sure the
PowerFC/DataLogIt is still available, and that connection hasn't been lost
prior to uploading a lot of data.

I'm not sure if it needs to be done or not, but FCEdit does it, so it's worth
mentioning.


---------------------------------------
Differences Between Reading and Writing
---------------------------------------

For some reason, FCEdit sends two 0xCB packets. The first one looks like:

CB 13 00 80 80 80 80 87 86 85 80 80 80 8C 98 94 Ë..?????????????
93 98 A8 84 ??¨?


While the second one is the 0xCB packet as discussed in the previous
section.

Additionally, during a "Write All", the following packets are not written:

0xD6 : Warning and Control Strings and Flags
0xD8 : <unknown>
0xD9 : <unknown>
0xDD : Sensor Strings
0xF3 : Init/Platform
0xF4 : <unknown>
0xF5 : Version


===================================
3: Data Types
===================================

There are more data types than you can shake a stick at. I wouldn't have
imagined there'd be quite this many. Some of these will probably turn out
to be much simpler to derive than I've described them, and it just hasn't
occurred to me yet. If you look at something and it goes click and you
get a better handle on the number format than is described here, please,
don't hesitate to speak up. I'm particularly unsure about some of the
more complicated formats. The way I've described them gives correct numbers,
but I'm sure there have to be simpler ways of getting to those correct
numbers than the ones I've got so far.

Byte: Simple unsigned character

Byte Percentage: Percentage value stored in units of 1/256. To convert,
(byte*(1.0f/256.0f))*100.0f. For instance, 37 is 14.4%.

Byte Float: A floating point value stored as a byte. The conversion from
byte to float is ((float)(byte value-128)*0.00390625f)+1.0f. Values may
differ in the thousandths place from those displayed in FCEdit or on the
Commander. So far, rounding up to thousandths has resulted in correct
values. But, I'm not %100 certain the conversion is correct. It looks
like it is, but there may be some insubstantial error. The conversion
from float to byte is ((byte)((float value-1.0f)/0.00390625f))+128. Same
caveat. Be sure to use the actual float, and not the rounded float, or
error is introduced. Additionally, there may be a much simpler conversion
available. This is a little complex, and I'm kind of suprised it's not a 1.7
fixed point value. Seems like the resolution would have been higher if
they'd gone fixed point. 0.5 (0x00) is the minimum value, and 1.5 (0xFF) is
the maximum.

Byte 2.6 Fixed Point: Aha. I figured there'd be some fixed point in here
somewhere. Don't know why the maps don't use it. The byte float format is
really strange. Why not just use a 1.7 fixed point? I don't know... Whatever.
We have this 2.6 fixed point for values that are 4 or less. To convert to
float, divide the byte value by 64. To convert float to 2.6 fixed point byte,
multiply by 64.

Byte 1.7 Fixed Point: Hey, wow, a 1.7 fixed point. AARGGH!!! Why are there
all these number formats? To convert from 1.7 fixed point to float, divide
by 128. To convert from float to fixed point, multiply by fixed point.

Byte RPM: Here's another fun little encoded number. To convert from byte
value to RPM, multiply by 40. To convert from RPM to byte value, divide
by 40.

Byte Idle RPM: To make things more interestng, there's another RPM format.
This one, to convert from byte to RPM, multiply by 4. To convert from
RPM to byte, divide by 4.

Byte Boost: I don't know what else to call this. Why are there so many
custom number formats? This number is boost expressed as kg/cm^2 (I think)
divided by 20. To convert from byte to kg/cm^2, divide by 20. To convert
from kg/cm^2, multiply by 20.

Byte Degrees: These aren't really any different to pure bytes, but, for
some reason, the ignition timing data has 25 added to it. For instance,
1, is actually stored 26.

Byte Temperature: To convert from byte to temperature in Celsius, subtract 80.
To convert from temperature in Celsius to byte, add 80.

Short Word: Two bytes arranged Big Endian style to form a standard short word.

Short Float: Stored the same way as a short word, because, well, it is a
short word. But it's a float. Conversion from word to float
(word value*4)/1000.0f. Conversion from float to word is
(float value*1000.0f)/4 (or, more simply (word value * 0.004).
This conversion appears really, really solid. I'm very confident about it.
The numbers that come out of it match FCEdit spot on. This says to me that,
given how complex the correction map conversion is, and the slight
innacuracy that's resolved with rounding, the correction map conversion
really must be something more similar to this. But I can't seem to figure out.
Applying this directly to it most assuredly does NOT produce the right numbers.
Hmmm.

Short 8.8 Fixed Point: Shiver me timbers, another fixed point number format. I
hope this one is used in more than one place. To convert from the short value
to float, divide by 256. To convert from float to short value, multiply by
256.

Short Word Degrees: Same as Byte Degrees, but stored in a short instead.

Short Word Temperatue: Same as Byte Temperatures, but stored in a short instead.

Goblin

=================
4: Packet ID's
=================

---------------
A Quick Example
---------------

Before diving head first into packet descriptions, we'll provide a quick
example of reading and writing some data. How about "Oiler vs Water Temp"?

To read "Oiler vs Water Temp", the packets going back and forth would look
like:

Send:

0x7E 0x02 0x7F

This is the Packet ID for "Oiler vs Water Temp" (0x7E), followed by the
remaining size of the packet (0x02 bytes), and the checksum (0xFF minus
each of the preceeding bytes).


Receive:

0x7E 0x09 0x..[0x07] 0xcc

This is the Packet ID that we requested to read (0x7E), followed by the
remaining size of the packet (0x09 bytes), followed by seven bytes of data
(We know it's seven bytes because when we take the number of remaining
bytes of data in the packet and subtract the one byte that tells us how many
bytes of data remain in the packet, and the one byte that is the check sum,
we get seven bytes.), followed by the checksum (0xFF minus each of the
preceeding bytes).

For the specific format of the data bytes in this packet, refer to the
Data ID's below.


------------------
Ignition
------------------
0x76..0x79 : Leading
0x81..0x84 : Trailing
------------------
20x20 Map, Byte per cell, column by column (Data comes in like n01p01 n01p02 n01p3, etc...).
0x19 is decimal 0. Subtract 0x19 (25) from the byte, and it's the integer degree (why 25?).
Data is sent in four packets. Each packet contains 100 cells (5 columns).

Each packet is a new ID.

Leading packet 1 is command 0x76.
Leading packet 2 is command 0x77.
Leading packet 3 is command 0x78.
Leading packet 4 is command 0x79.
Trailing packet 1 is command 0x81.
Trailing packet 2 is command 0x82.
Trailing packet 3 is command 0x83.
Trailing packet 4 is command 0x84.

Example, requesting packet 1:

Send:

0x76 0x02 0x87

Receive:

0x76 0x66 0x..[0x64] 0xcc


------------------
Injector Overlap
------------------
0x7B
------------------
See the note on Command 0x91 for interpretation of the boost values.
Data comes in as three pairs of byte 2.6 fixed point boost value, and byte setting.
Displayed top to bottom in FCEdit.
After you read that note in Command 0x91, it should be noted that I'm more confident
now that this number should be read as a 2.6 fixed point number. For this table, my
map indicates 0.906, 0.609, and 0.297. Those look like reasonable boost number values
for this overlap stuff. Still not %100 sure, though.


------------------
Injector vs Fuel Temp
------------------
0x7C
------------------
Data comes in as three pairs of byte temperature, short word 8.8 fixed point
setting. Displayed top to bottom in FCEdit.


------------------
Turbo Transition
------------------
0x7D
------------------
Data comes in three sets, top to bottom as displayed by FCEdit.
First, the three TPS% come in as byte percents. Then the three
low RPM values come in as byte RPMs. And finally the three high
RPM values come in as byte RPMs.


------------------
Oiler vs Water Temperature
------------------
0x7E
------------------
Data comes in three pairs of byte temperature, and byte 1.6 fixed point setting.
Displayed top to bottom in FCEdit.


------------------
Fan vs Water Temperature
------------------
0x7F
------------------
Data comes in as three byte temperatures, fan 1 with AC, fan 1 without AC, fan 2.


------------------
Injector Correction
------------------
0x86..0x89
------------------
20x20 Map, Byte float per cell, column by column.
0x80 (128) is 1.0.

Data is sent in four packets, each packet holding 100 cells (5 columns).

Each packet is a new command.

Packet 1 is command 0x86.
Packet 2 is command 0x87.
Packet 3 is command 0x88.
Packet 4 is command 0x89.

Example, requesting packet 1:

Send:

0x86 0x02 0x77

Receive:

0x86 0x66 0x..[0x64] 0xcc


------------------
Map Reference
------------------
0x8A
------------------
Short word per cell, boost, rpm.
Data comes in as P1, P2...P20, N1, N2...N20.


------------------
Cranking
------------------
0x8E
------------------
Six short floats
Data comes in as 80C, 50C, 30C, 10C, -10C, -30C.


------------------
Water Temp Correction
------------------
0x8F
---------------
Twelve byte 2.6 fixed point numbers, and two unknown bytes.
Data comes in as the left side of the FCEdit display 80C, 50C, 30C, 10C, -10C, -30C,
and then the right side of the FCEdit display in the same order. Then two unknown
bytes.


------------------
Injector vs Water Temperature and Boost
------------------
0x90
------------------
This a weird group of data. No idea how it works as a correction factor. But, here's
packet.
Data comes in as two pairs of byte temperature, byte 1.7 fixed point setting.
There are then two more bytes that, according to FCEdit are related to boost. See
the note for Command 0x91 about the interpretation of these values.


------------------
Injector vs Air Temperature and Boost
------------------
0x91
------------------
This a weird group of data. No idea how it works as a correction factor. But, here's
the packet.
Data comes in as three pairs of byte temperature, byte 1.7 fixed point setting.
Displayed top to bottom in FCEdit.

*There are then two more bytes. I don't know how to interpret these. I don't think
FCEdit knows either. It's showing some weird stuff. If they're intended to be boost
min's and max's, I could see that. Though, they don't look like byte boost numbers,
more like byte 2.6 fixed point (For my settings, the raw values are 58 and 19, which
would be 0.906 and 0.297 as 2.6 fixed point, or 2.9 and 0.95 as boost values. Fixed
point looks right. But I have no idea what the number is for in the first place, so
I'm only guessing about what right would look like to begin with...).


------------------
Inj Primary Lag (uS) vs Battery Voltage
------------------
0x92
------------------
Six short floats
Data comes in as 16v, 14v, 12v, 10v, 8v, 6v.


------------------
Accelerate Inject (mS)
------------------
0x93
------------------
Data comes in top to bottom, left to right as displayed by FCEdit.
First, are the five RPM values as byte RPMs. Second, the amount
values as short floats. And finally the five decay values as short
floats.


------------------
Injector vs Accel TPS
------------------
0x94
------------------
Contrary to everything else, data in this one comes in left to right,
top to bottom, as displayed by FCEdit.
Data comes in as Input 1, Setting 1, Input 2, Setting 2, Input 3, Setting 3;
The Inputs are byte values. The Settings are displayed in FCEdit as if they were
short words, but I think they're probably short 8.8 fixed point values.


------------------
Ignition vs Air Temperature (cold)
------------------
0x96
------------------
Data comes in as byte temperature, byte representing amount of retard, etc.
Two pairs of those, displayed top to bottom in FCEdit.


------------------
Boost vs Ignition S.F.
------------------
0x97
------------------
Data comes in as two byte values for "boost", the first for S.F. 1.0, the
second for S.F. 2.0.

*FCEdit displays these boost values weirdly. I've noted this discrepancy in a couple
other commands. This one seems really off, though. It's got a correct byte, but has
added a zero byte to it and then interprets as a short word. For instance, it shows
byte 0x0F as if it were 0x0F00, and as a short word (3840). Since I have no idea
what this table is, I can only guess at what these boost values should look like.
I'd think there were some bugs in FCEdit's display or interpretation, and that these
should be 2.6 fixed point numbers, or byte boost values.


------------------
Ignition vs Water Temperature
------------------
0x98
------------------
I'll stop saying "contrary to everything else" now (If I say it later in this doc,
it's because I figured that packet out previous to this point in time, but I'm
listing the packets in numerical order... <g>), but this one is, too.
Data comes in as byte temperature, byte representing amount of retard, etc.
Two pairs of those, displayed top to bottom in FCEdit.


------------------
Ignition vs Air Temperature (warm)
------------------
0x9A
------------------
Data comes in as byte temperature, byte representing amount of retard, etc.
Three pairs of those, displayed top to bottom in FCEdit.


------------------
Leading Ignition vs RPM
------------------
0x9B
------------------
Six bytes
Data comes in as 10000rpm, 8000rpm, 4000rpm, 2000rpm, 1000rpm, 480rpm


------------------
IGN vs Battery Voltage
------------------
0x9C
------------------
Six 2.6 fixed point bytes
Data comes in as 16v, 14v, 12v, 10v, 9v, 8v


------------------
Boost vs Ignition S.F.
------------------
0x9D
------------------
No idea what this table does, or what SF means.
Data comes in as byte idle rpm for S.F. 0.0, then byte idle rpm for S.F. 1.0, then
the "boost" value for S.F. 0.0, and then the "boost" value for 1.0.
See the note for Command 0x97.


------------------
Trailing Ignition vs RPM
------------------
0x9E
------------------
Six bytes
Data comes in as 10000rpm, 8000rpm, 4000rpm, 2000rpm, 1000rpm, 480rpm


------------------
Injector Secondary Lag (uS) vs Battery Voltage
------------------
0x9F
------------------
Six short floats
Data comes in as 16V, 14V, 12V, 10v, 8v, 6v.


------------------
Knock Warning
------------------
0xA9
------------------
Only half of this packet is known.
Data comes in as four bytes. Unknown, knock threshhold, unknown, knock setting.


------------------
Injector Warning
------------------
0xA8
------------------
Only most of this packet is known.
Data comes in as unknown byte, short word threshold times 10 (divide by 10 to get
the right number. I'd give it a new number format, but this is the only value to
use this format, so, we'll go with this), byte setting.
I'm not at all sure what these numbers mean. Or even if FCEdit is displaying them
correctly. If you don't read those second two bytes as a short word, then the
second byte itself is 82.81 if read as a percent byte, which could also be a good
duty cycle to warn about injectors at... I don't know what the third byte would
be, then, though. But, I also don't know what setting is, so. There you have it.


------------------
O2 Feedback
------------------
0xAA
------------------
Only most of this packet is known.
The data comes in as unknown byte, and then a short word 8.8 fixed point O2
feedback setting.


------------------
Boost control
------------------
0xAB
------------------
The first three bytes aren't entirely known yet. I think they're for
selecting the first and second boost settings, but there's three of
them for some reason. With boost setting one selected, the first value
is 255, and the second two are 0.
The rest of the packet is understood.
Data comes in as byte boost values, setting one primary, setting one
secondary, setting two primary, setting two secondary. Next are the
duty values in the same order. FCEdit displays them as byte values,
but they may be byte percents (I don't know enough about duty cycle
values to know whether these percentage values are reasonable control
numbers or not).


------------------
Base Fuel
------------------
0xB0..0xB7
------------------
20x20 Map, Short float per cell, column by column.

Data is sent in eight packets. Each packet is a new command.

Packet 1 is command 0xB0
Packet 2 is command 0xB1
Packet 3 is command 0xB2
Packet 4 is command 0xB3
Packet 5 is command 0xB4
Packet 6 is command 0xB5
Packet 7 is command 0xB6
Packet 8 is command 0xB7

Example, requesting packet 1:

Send:

0xB0 0x02 0x4D

Receive:

0x86 0x66 0x..[0x64] 0xcc


------------------
Rev Idle
------------------
0xB8
------------------
Seven short words
Data comes in as Rev Limit, FC AE, FC EL, FC AC, Idle AE, Idle EL, Edle AC.


------------------
Injector vs Air Temperature
------------------
0xB9
------------------
Six short words 8.8 fixed point.
Data comes in as 80c, 50c, 30c, 10c, -10c, -30c.


------------------
Injector vs TPS
------------------
0xBA
------------------
Contrary to most other types, data is left to right, top to bottom.
Data comes in as a byte percent TPS%, then a byte float Setting, top
to bottom as displayed by FCEdit, for six pairs of values.


------------------
Ignition vs TPS
------------------
0xBB
------------------
Four pairs of byte percent, byte float
Data comes in top down relative to FCEdit display (79.7, 1.0, 59.8, 1.0, etc...)


------------------
PIM Scale and Offset
------------------
0xBC
------------------
Five pairs of short words (Could be floats... FCEdit displays as short words.).
Data comes in as Normal Scale, Normal Offset, Option 1 Scale, Option 1 Offset, etc.


------------------
PIM Strings and Injector Adjustment
------------------
0xCB
------------------
This is a neat little packet. I was getting terribly annoyed being unable to find
the Injector Adjustment settings. There are all these packets that have a bunch of
strings in them. I figured they were just string packets, but, no there's data in
here, too. Interesting mix of information.
The comes in as one unknown byte, (possibly which "Option" you have selected in
the PIM menu, then five 18 character NULL terminated byte strings (stock, without
boost control kit, these are " 1 - Normal ", " 2 - Option1 ",
" 3 - Option2 ", " 4 - Option3 ", and " 5 - Option4 "), and then
eight byte floats (for percentage type values, multiply by 100.0f) that are Injector
Adjustment values for 8000 RPM, 7000RPM, etc, and then eight byte percent2's
that are Injector Adjustment values for 1.0v, 1.5v, 2.0v, 2.5v, 3.0v, 3.5v, 4.0v,
and 4.5v.


------------------
Warning and Control Strings and Flags
------------------
0xD6
------------------
This packet isn't entirely understood.
Data comes in as five bytes that are probably setting on/off flags, though 0xFF seems
to be "off", while 0x00 seems to be "on", then five sixteen character byte strings
NOT NULL terminated, that, stock, are "1.Seq.Turbo Cont", 2.Injector Warn.",
"3.Knock Warning ", "4.O2 F/B Control", and "5.Idle-IG Cntrl ".
The only part that's not understood is those first five bytes. And I just need to
change some flags and then check them to confirm what they are.


------------------
Sensor Strings
------------------
0xDD
------------------
This packet contains all of the sensor name strings displayed in the sensor watch
page on the FC Commander. I'll have to look at the Commander to check for sure what
the format is exactly. It's looks like it's four byte non null terminated strings,
and three byte non null terminated strings, with a '/' in the middle for some reason.
As a while, the packet is:
" PIMVTA1VTA2VMOPWTRTAIRTFUEL O2SSTRA/CPWSNTRCLTSTPCATELDHWLFPDFPRAPRPACCCNTCNPRC"


------------------
Acknowledged
-------------------
0xF2
-------------------
An acknowledged reponse packet will be sent after every write command to
indicate that the PowerFC/DataLogIt has successfully received the packet.
The response looks like: 0xF2 0x02 0x0B.
Presumably there is a "Failed" response packet, as well, but I have yet to
see one. I suppose I'll have to intentionally corrupt a packet to get one.

----
Note
----
There are very possibly more reponse packets and comm chains for error
handling, but all of the sample data this document was composed with is from
perfect communications.


------------------
Init/Platform
------------------
0xF3
------------------
This packet seems to serve two purposes. The first time it's sent, a non-matching
reponse is returned (0xF0) containing strange data. It's a malformed packet, for
one (no sizeof or checksum bytes).
The comm chain looks like:

Send:
0xF3 0x02 0x0A

Receive:
0xF0 0x56 0x32 0x4B

The second time the command is sent, an eight character non NULL terminated string
describing what platform this PowerFC is for is returned. For RX-7's, it's
"13B-REW ".

It's likely an initialization command in addition to being the platform command.
FCEdit sends an 0xF3 as the first thing it ever does.


------------------
Version
------------------
0xF5
------------------
This is a five character non NULL terminated string that is the version number. Mine
is "5.08 ".



------------------------------------------------------
These Packets Are Far From Being Completely Understood
------------------------------------------------------

------------------
Fuel Injectors
------------------
0x8D
------------------
This packet is not entirely understood.
There are two short words that might be 9.7 fixed point values that are to
be interpreted as percentage values (multiply by 100 to get percent) that
I think are the front and rear injector pulse correction values.
Then there are four more short words that might be the injector lag time
correction values.
Then there are two short words that are definately the primary and secondary
injector sizes.
The two more short words that are probably primary/secondary transition
percentage and millisecond values.
The data is annoyingly strange, though. It might be padded. It it were,
in fact, padded, I'd say it was:
<0 pad byte>
byte float front pulse (for percent multiply by 100 to get percentage)
<0 pad byte>
byte float rear pulse (for percent multiply by 100 to get percentage)
byte front primary lag time value (multiply by 0.004)
<0 pad byte)
byte front secondary lag time value (multiply by 0.004)
<0 pad byte)
byte rear primary lag time value (multiply by 0.004)
<0 pad byte)
byte rear secondary lag time value (multiply by 0.004)
<0 pad byte)
short word primary injector size
short word secondary injector size
short word primary/secondary transition percentage * 10 (divide it by 10
to get the percentage)
short word float primary/secondary tranisition milliseconds
<0 pad byte>
<0 pad byte>
<0 pad byte>
<0 pad byte>

8D 02 70 �.p
8D 1A 00 80 00 80 00 80 0A 80 00 80 0A 80 26 02 �..?.?.?.?.?.?&.
14 05 90 01 77 01 00 00 00 00 FA ..�.w.....ú

It's a very annoying and weird packet, to be sure.


------------------
Setting Protections?
------------------
0xAC
------------------
There are ten different protections and there are ten values here. All of my
protections are turned off, and all of these values are zero. I thought setting
protection was a software end sort of deal, but I suppose there could be something
in the firmware preventing memory from being written to depending on whether that
memory had been flagged for protection.

AC 02 51 ¬.Q
AC 0C 00 00 00 00 00 00 00 00 00 00 47 ¬...........G


------------------
Tuner String?
------------------
0xAD
------------------
It's eight spaces right now. FCEdit has a box it called "Tuner String" and says
it's eight characters...



---------------
Unknown Packets
---------------

No idea at all what these packets are. Presumably, some of these are for
DataLogIt features, like anti-lag.


------------
0x7E
------------
0x7E, 0x08, 0xC8, 0x8F, 0xAA, 0x87, 0xA5, 0x80, 0xCC,


------------
0xBD
------------
0xBD, 0x03, 0x00, 0x3F,


------------
0xBE
------------
0xBE, 0x03, 0x00, 0x3E,


------------
0xD8
------------
0xD8, 0x03, 0x2D, 0xF7,


------------
0xD9
------------
0xD9, 0x03, 0x14, 0x0F,


------------
0xF4
------------
0xF4, 0x03, 0x02, 0x06,

Goblin

===================================
5: Real Time Monitoring Commands
===================================

When FCEdit is doing Map Watch, the comm sequence is Basic Data, Sensor Data,
DataLogIt Analog Data, Map Indices/Write Request, Advanced Data

<This section is under construction>

------------------
FC Commander Display
------------------
0xDA
------------------
short word : Injector % * 10.0f (divide by 10.0f to get percent)
short word : IGL (same as byte degree but in a short word)
short word : IGT (same as byte degree but in a short word))
short word : rpm (just as it is, read as a short word, rpm exactly)
short word : kph (don't know what the units are yet, I wasn't moving when I took the sample)
short word : boost (339...)
short word : knock (just as it is, I think)
short word : Water temp as temperature (same as byte temperature but in a short word)
short word : Air temp as temperature (same as byte temperature but in a short word)
short word : battery voltage * 10.0f (divide by 10.0f to get voltage)


------------------
MapIndices
------------------
0xDB
------------------
byte : MapN (rpm)
byte : MapP (pressure)


------------------
Sensor Data
------------------
0xDE
------------------
short word : pim * 100.0f (to get pim, divide by 100.0f)
short word : vta1 * 100.0f (to get vta1, divide by 100.0f)
short word : vta2 * 100.0f (to get vta2, divide by 100.0f)
short word : vmop * 100.0f (to get vmop, divide by 100.0f)
short word : wtrt * 100.0f (to get wtrt, divide by 100.0f)
short word : airt * 100.0f (to get airt, divide by 100.0f)
short word : fuel * 100.0f (to get fuel, divide by 100.0f)
short word : O2S * 100.0f (to get fuel, divide by 100.0f)
short word : bit flags for STR (0x0001), A/C (0x0002),
PWS (0x0004), NTR (0x0008), CLT (0x0010),
STP (0x0020), CAT (0x0040), ELD (0x0080),
HWL (0x0100), FPD (0x0200), FPR (0x0400),
APR (0x0800), PAC (0x1000), CCN (0x2000),
TCN (0x4000), PRC (0x8000)


------------------
"Advanced" Information (Cooked Averages?)
------------------
0xF0
------------------
short word : rpm (just as a short word, not worked over)
short word : pim (don't know... FCEdit just displays it as a short word)
short word : pim voltage * 1000.0f (divide by 1000.0f to get the voltage)
short word : tps voltage * 1000.0f (divide by 1000.0f to get the voltage)
short word : InjFP ms (short float)
short word : INJ (inj what? dunno... FCEdit shows it as a short word...)
byte : IGL (byte degree)
byte : IGT (byte degree)
byte : Fuel Temperature (as byte temperature)
byte : oil (FCEdit displays as just a byte...)
byte : Precontrol % (FCEdit calls it a %, but looks like it's just displaying the byte)
byte : Wastegate % (FCEdit calls it a %, but looks like it's just displaying the byte)
byte : water temperature (as byte temperature)
byte : air temperature (as byte temperature)
byte : knock
byte : battery voltage * 10.0f (divide by 10.0f to get voltage)

NOTE: From here, FCEdit is unsure of what's what... Consequently, I'm unsure of what's what.

short word : kph (don't know the units yet)
short word : unknown
byte : O2
byte : unknown
short word : InjFS (ms)


------------------
DataLogIt Analog Inputs
------------------
0x00
------------------
byte : AN1
byte : AN2
byte : AN3
byte : AN4

I don't know what format these are in. FCEdit shows them as floats in the log.


===================================
6: Process For Working the Protocol
===================================

In order to assist anyone else wanting to figure out the communication
protocol of PowerFC/DataLogIt on other platforms (say, Hondas...), this
is the procedure that was used. I'm not sure how much the DataLogIt box
itself does. Obviously it adds functionality to the PowerFC, but it
wouldn't surprise me if it turned out much of the protocol was simply
passed through from the PowerFC, with the DataLogIt acting as a break
out box. Don't get me wrong, I love the DataLogIt, and treasure it. I
haven't got the hardware skills to figure out how to talk to the
PowerFC without it. And without FCEdit providing a meaningful
interpretation to backtrace the raw data from the port monitor, I never
would have bothered to undertake this. I'm just pointing out the
possibility that the protocol is passed through in case there are
PowerFC platforms out there that for some reason do not have
DataLogIt's available, if someone with one of those platforms wanted to
try talking to the PowerFC on his own, knowing the basic protocol is a
nice jumping off point. Plus, I've seen a Japanese website that included
a pinout diagram of the mini-din connector the PowerFC uses.

So this is what I did.

With a serial port monitor running (I used HHD Software's offering, found
via http://www.download.com with a search for serial port monitor), and
FCEdit running and connected to a DataLogIt, in turn connected to a PowerFC,
each command in FCEdit was issued in turn. Read All, Write All, Read Inj,
Write Inj, Map Watch Start, etc, etc.

The data exchanged between the FCEdit software and the DataLogIt was
captured, tagged as to what command process it was generated by, and logged
to a text file.

Once a suitable collection of data was obtained, the log files were analyzed.

First, packet structure was figured out. It's fairly obvious, thankfully.

Next, command/response pairs were examined, with the response data scrutinized
for length and repetition.

The map data was figured out first. Knowing the packet structure, byte count
per cell showed the ignition data to be bytes, and the fuel data to be short
words.

Repeating patterns in the data that matched repeating pattens in the maps
showed that the maps are stored as columns.

After that a quick program was written to interpret the remaining packet
data and output all the known number formats for each byte/short in each
packet to a text file for review.

The packets were looked at for size matches with groups of data and more
repeating patterns.

As new number formats were added, more conversions were added to the text
file output, which led to more packets being figured out, and so on, and
so on.


===================================
7: A Note About FCEdit
===================================

I have a concern that some of my numbers differ a bit from those displayed
by FCEdit. Some of these are simple rounding issues for fitting the numbers
into the provided spaces, those don't bother me so much. But there are cases
where FCEdit has chosen to display numbers in a very raw format. The Injector
Overlap Boost Settings for instance, are displayed as raw short words. I think
these values are likely to be some form of fixed point number, and I've
indicated such in the specific command packet descriptions. So why does FCEdit
display them as short words? I don't know. But the difference in understanding
of the numbers is there, so I thought I'd point it out. I'm sure FCEdit has
a good reason for what it's displaying, but without a deeper insight into
I can't guess what that is.

Badog

Nice work.

jeff48

YIKES!!!!!
But Kudos on a fantastic job

SPOautos

Holy **** man!!!!

I have no idea what I just read but it looks like it was very time consuming!!!!! I hope you can turn all this hard work into something usefull!!!!

STEPHEN

spoolin

what's all that mean in layman terms? i have trouble reading playboy....thank god for the pictures

Badog

What is means is, someone is going to come out with the same functionality that is in FC-Edit...but different.

That difference could be a "closed loop mode" where the car "tunes itself. "

My vision: A "suggested tune mode" which is 95% of the closed loop, but it logs over time and writes new value to a map on the laptop...and waits for user interaction before sending that map to the PFC.

nocab72

Tony (Badog) and I have closed loop tuning now, but there are a few "manual" steps associated, the above lays out the groundwork for automagic tuning...

K

Badog

AUTOMAGIC Tuning! I love it! We got us a name now, Kyle!

nocab72

Or even better yet,

AUTO(black)MAGIC Tuning

K

Goblin

Badog, NoCab, I'm guessing you're datalogging and filling out a current AFR map, and then using that data in an Excel sheet to calculate new base/correction maps? I was wanting to do that before I just decided to toss it all to hell and write my own software. I was worried about the math coming out wrong, though (Does an %0.5 change in fuel give the same change in AFR all across the board, or is it different depending on RPM/boost, and, if so, how? etc, etc...). I looked into what some of the other auto tuning software for other ECU's does (er, well, the one bit of auto tuning software I was able to turn up, anyway) and the description, while probably marketing-speak, made it sound really complex. Being a novice tuner, I didn't want to risk hurting my car with something I was unsure of...

Would you share your process with us, or do want to keep it proprietary?


What I'm planning on for the software is for it to sample AFR's while driving around, average them over N samples, and adjust the map up or down by some small percentage, then repeating until the target AFR map is met. Number of samples and maximum percentage to adjust each time would be exposed to the user to set. The user could also set an epsilon from target AFR that he'd consider "finished", say, 0.1 or something (I'm not sure how stable a given wideband is... Maybe 0.2 is more realistic?).

I'd also like to have the software aware of ambient temperature conditions, and then normalize the temperature correction values to 1.0 at that temp. It would then have another mode that would "auto tune" the temperature corrections after you'd established a basemap at a given temperature, you'd just have to wait until a warmer/colder day, and then haul out the laptop again. I'm not sure if that's feasible, though. Like I said, all this tuning stuff is still new to me.

Of course, if someone wants the software to work a different way, or they want a different feature, it's all free software, and it's all open source, so all they'd need is a compiler and some programming skills. <g>


Oh, and, a quick update. On reflection, that "byte float" number format is actually a 0.8 fixed point number, with a 0.5 base added to it. Couple other changes to the document that have been made since the post, and the beginnings of the software to talk to the thing and convert numbers around. I'm just waiting for my new ISP to get me rolling (still) and I'll have a web page up.

skotx

My hat off to you, Goblin. I've dinked around with some A/D conversion and logging of the stock sensors. That's a serious bit of reverse-engineering you've done.

You're project sounds very exciting!

-Scott

Badog

Goblin,

You have captured the general flow of the process I use. Nocab does about the same thing.

I have a series of equations to come up with the amount of fuel adjustment to reach a target AFR.

I approach the temperature correction factors as an equation, too.

The only thing missing for me is the communications layer component for reading and writing. If you wanted to approach this from an OO design methodology, there might be some interesting things come from it.

If you really want to tackle something that would be of great value (to me), figure out how to capture data to media, without a laptop in the loop! Picture a RAM card or a USB dongle-drive that can store an amount of data on it. It's probably more directed to Steve and Glenn, but they haven't been visiblely pushing thier product to the next level.

Tony K.

Goblin

Capturing data without a laptop sounds interesting. I've been looking for a microcontroller project that was actually useful and not just a toy. I may wind up giving that one a shot if I can find the PICs or the Stamps I've got laying around somewhere...

I'm curious what you mean about "OO Design Methodology" and a "component layer for reading and writing". That makes it sound like you've got some custom software running your fuel equations, not just using Excel for it?

The first thing I'm writing is the communications layer and data storage. It'd be finished already, but I got a little tricky with the data storage aspect and wound up building a small markup language in order to have a sort of "reflection" available in the data so that it self publishes everything the app needs to know about it in order to build a gui around it, edit it, and send it to and from the PFC/DLI. The class should hopefully wind up very well contained, and completely portable to whatever projects may exist.

Badog

Bumping this since it's so interesting to me.

Yes, formulas in Excel, and a "project" where the calculations and adjustments are done at designed intervals and with a sampling algorithm (think neighborhood relations).

Goblin

At least someone else finds it interesting...

I looked into what it would take to build a data logging box for the data logger (hmmm... <g>). With my lack of real EE knowledge, using the types of equipment I know about, it'd probably come out to about $150 worth of parts, unfortunately. And it wouldn't log much. Couple minutes. But that's me, I'm not a hardware guy. If there was someone with some hardware skills, I'm sure it could be built for much less, and would store much more.

So then I looked into palmtop solutions. Any palm with a serial port connection would do for DataLogIt logging. Anywhere from $100-$700 for the device. For my specific needs, I wanted two serial ports, though. One for the DataLogIt, and another for the FJO. That made the lowest price point about $500 once the cheapest unit that could support it and the expansion packs for the extra serial ports were purchased.

So I kind of stopped looking either solution for a logger.


Also, and I cringe typing this, I started looking at the AEM unit last week. It's very beautiful. I'm really shocked at how good it is, and how bad *** the software is. So shocked I sort of, um, bought one. I want to see how it compares with the PowerFC/DataLogIt combo.

nakasaki

Hey Goblin!

Excellent work with this document - I would never have started my projects without it.

You didn't put the COM port settings on your document though. I used the Serial Port Logger tool to figure it out though.. I think it is:
57600 baud, 8, n, 1

Took me several hours to figure that out! Thought it would be 9600 baud :p

Thanks again,
> Chaz <

Wargasm

I made a simple map generator program for my use... seems to work OK for P10-P20 which is the only place I use it. Not because I don't think it WILL work on the other areas, but I just haven't tried it yet.

Basically all you do is paste in the current map, and a GOOD SAMPLE of current AFRs from the Map Watch. I say GOOD SAMPLE because you don't want oddball datapoints in there messing with you To read more about what I consider good samples, go to the bottom.

So now you have your current map and your afrs put into Excel. I have a number at the end of each row with my desired AFR. Like 11.9, 11.8, 11.7 etc etc moving down from P10-P12. The spreadsheet looks at those, and calculates the theoretical change in AFR very simply by just looking at the % off you are from target. If you're at 10:1 and you want 11:1, that's 10% less fuel. So it will make a new map where that cell has 10% less fuel. Now before you go saying that that's a little too calculated and might be dangerous... I agree... I have a fudge factor built in where it takes a FRACTION of the maximum change. Right now I use 1/3rd.

So it figures out the change needed (in this example -10%) and then it takes a third of that. So my cell where I was at 10:1 and wanted to get to 11:1 would have 3.33% less fuel in it, not the full 10% less. This keeps things from swinging too much one way or the other.

Tony's system sounds more advanced, but my sampling methods are key to mine being a good estimator also I think.

Brian

** Good samples according to B (in no order)
----------------------------------------------------------
1) Car must be fully warmed up both on water temp as well as air intake temps. This means at least 20+ minutes of warming up and some boosting to heat everything up to realistic conditions. With the current weather here this means 82-85 C water temps with 35-45 C air intake temps. When the car is at 82 C water and only 17 C air intake, this is NOT warmed up yet!

2) All sample collections must be done in as high a gear as possible. This makes sure that you spend the longest time possible in each cell on your log so that the values are well-averaged. I usually use 3rd gear because it maxes out around 105 mph which you can do on most roads without drawing TOO much attention to yourself

3) Pulls should be done in a standardized fashion. Good pulls would be from 2000 or 2500 rpm up to 8000 rpm while holding your boost pressure at steady as is possible at about 2.5 PSI increments from 0-maxboost. So for my car, I do 0, 2.5, 5, 7.5, 10, 12.5, 15. Of course, it's hard to be perfectly steady, but keeping it close to steady helps make your data reliable. Flooring it from 4500, then going up to 15 PSI, then backing off to vacuum, then punching it to 10 PSI at 6500... does NOT give good data!

4) Keep driving around for a good while, but KEEP the DATA good! When I'm working on my boosting areas, I try to not boost unless it's a controlled pull. Getting on and off the throttle a lot under boost tends to put some odd readings in your averages due to sudden throttle changes.

5) Throw out any data with a small number of samples. After I get home and I put my AFRs in the Excel sheet, I look at the "number" on mapwatcher to see how many readings contributed to each cell. If I see very low numbers like 2 or something, I usually just delete the AFR reading from that cell. It's very easy to get one or two wacky readings in there and think you're way rich or way lean. I'd rather be looking at lots of data For the reason of sample number, I prefer to drive around for a LONG time and try to pack as much good data into one log file as I can. In many cells, I have hundreds of readings or even thousands in the vacuum area where you spend a lot of time. Even under high boost, I still usually get a few dozen readings per cell.

6) Label your log files! I like to name mine with the date plus some information about what I was trying to do with that session. So you might have "boosting" somewhere in the name or maybe "vactuning" or maybe "mixeddriving". This way when you go back later you know what part of the map is the "good stuff" you were looking for on that day.

7) Take a partner with you in the car. Show the partner how to look at the map watches and call it out LOUDLY if something is wrong. This is most critical when you have an untuned car or are making a major change where you might well see 12.5:1 under 13 PSI! Once your maps are dialed in pretty close this is less important since they should be pretty safe if you're only making small changes. It is very hard to watch the boost gauge, the tachometer, the laptop with the mapwatches and AFRs up... and oh yeah... the ROAD while doing this. Having the partner makes this stuff much easier

8) Explore the boundaries of your map. Once you have gotten the critical areas to a safe level (around peak torque seems to be the most critical... ), you will want to spend some time making sure the little areas you will rarely drive in are correct. In my single turbo, I'll go out and put it in 4th or 5th and floor it from 2000-5000 RPM. Lag? you bet... but once the boost starts creeping up, you get to see how fast you can get into the bottom left area of the map. You will find that by doing it this way, you might move one "N" to the left and get into higher "P" rows faster than if you were driving from 3000 in 2nd. Lugging the engine like this lets you stress the car some and see where you "might" go if you're being lazy or careless and aren't keeping in your powerband.

9) Pay attention to intake air temps. Some maps have very strange air temp correction factors in them. These can make it hard to tune because you're always chasing a moving target. As the air temps go up or down on say a hot day compared to a very cool night, if the air temp corrections are wrong, you will see your AFRs swinging all over. If you don't have stock air temp corrections you might want to CAREFULLY think about fiddling with them. GO SLOWLY.

10) This should be obvious... change only one variable at a time. Loading up a brand new fuel map, putting in 5 more degrees of ignition advance, and dropping your split from 14 to 8 is not a very good idea. Change one thing... drive it for a while... look at what it did... maybe then change another thing. Slower is better!

Anyhow those are some of the basics... I probably left something out... but those should get people that are new to this thinking in the right direction.

nakasaki

That's some great tips - cheers Brian!

Right now I'm trying to get data from the Datalogit using Goblin's reverse-engineering. I send a request packet and I get a reply no problem. If I send another request though I never get a reply.

Anyone know why this might be?

I'm tearing my hair out and it's a pain trying to code in the passenger seat of the car with a laptop on your knee!

Thanks,
> Chaz <

Wargasm

Sounds to me like you need a 50 foot long null modem cable or whatever... That way you could sit in a nice comfy chair inside the house!

B

radkins

Could this software also react quick enough if something drastic happens to the AFR's, say a fuel pressure problem, and tune around it, and/or notify user via warning lamp ect? Although, you would really have to trust you sensors to give a computer that kind of power.

nakasaki

I think you would only make a lot of tiny changes to the values instead of a few large changes so that the maximum change in the AFRs is small. You just check on every sample batch that the AFRs are heading *towards* your target value rather than away, otherwise the computer would undo the change it just made.

I definitely think it is feasible to write a really decent auto-tune system

> Chaz <

rxrotary2_7

WOW this is some good reading. i want to play with a PFC/ datalogit instead of the e6k