From: Kris Pelley
To: rx7@rx7-world.net
Subject: [3][pfc] Hacking the PowerFC/DataLogIt
Date: Thu, 9 Jan 2003 19:14:23 -0600
So, alright, I'm not sure how many people out there are going to be intested
in this, but...
I've been unsatisfied with some of the way FCEdit (the software that runs
the DataLogIt) works. In particular, the difficulty in getting an FJO
Wideband to work right with it. Knowing the FJO has a serial output that
will provide an always accurate air/fuel number was frustrating. Getting a
new feature added to FCEdit seems to take awhile, and I didn't want to wait
that long. In addition, there are several other features I'd like to see
added to FCEdit. Features I'm sure those guys just don't have time to worry
about adding and testing.
I love the DataLogIt, and I love FCEdit. Glen and Steve (how come I don't
know their last names?) are complete badasses for making this product
available. It should be a mandatory purchase for every PowerFC owner. I just
wanted faster turn around on improving the software.
With that in mind, and in the interests of getting the serial output from
the FJO integrated into a data logging environment, and in getting those new
features added to that environment, I've set out to do what I said I'd do
back when rumors of the DataLogIt first hit the List/Forums.
I hacked it.
In case anyone else out there is interested, I'm sharing everything I've
discovered so far. In a case like this, open source feels like the right way
to go. So, here's the document I've cobbled together describing the
communications protocol that the DataLogIt uses. I think it's high %90
complete. Most of the work I want to do can be done with this information.
I know the data's different, but, hell, this may even turn out to be useful
information to people using PowerFC's on other cars.
I'm working on software, as well, which will also be open source, and,
hopefully cross platform. No idea when it will be usable, though.
I don't like taking up all this mail bandwidth. If I had a website, I'd just
point a link, but, ah well. I'll just post it here once, and revisions will
show up on the forum (http://www.rx7forum.com). And sorry about the
formatting. That's what happens when you build a document in MSVC...
*****************************************************
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 K..?????????????
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 :
0xD9 :
0xDD : Sensor Strings
0xF3 : Init/Platform
0xF4 :
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.
=================
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... ), 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.....z
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,
===================================
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
------------------
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.