I looked at the data file you posted and it looks like 9600 baud, 8 data bits, even parity, 1 stop bit. If you look at the bits, it's sending 9 bits then a stop/start pair in the blocks, and there's no parity errors. The logic program will actually show where it's sampling for the bits with little circles and squares if you zoom in enough. The actual baud rate is lower, but it corresponds to the H8 CPU data sheet for 5 or 10 MHz operation, and serial has about a 10% timing margin so normal 9600 should work.
The display signal is in 3 byte blocks, and the BCM/MCM is in 12-byte blocks. I didn't see cases where the 3rd display byte varied when the first 2 didn't, so it may be a checksum, but there weren't a lot of unique codes and the 12-byte blocks aren't similar groups of 3. Based on the timing I think one talks to the display while the other is talking on BATTSC, and they're just trading back and forth.
The next step would probably be to monitor the serial driver to see who's talking when. Either that or cut the display signal to one unit, and see what messages disappear. Then try spoofing the display to see what codes give what display.
The best way to get the data out is with the Logic program and your data files. Use the analyzer option with those serial settings and save the data file. It notes parity or framing errors, so you can see if the signal is noisy or the settings are wrong.
Here's what I get for the engine off positive recal capture file: The two non-inverted signals are labeled METSCI2 and BATTSCI1, but I'll only look at METSCI here. The Logic output file didn't list any parity or framing errors, except for 1 bad byte at turn on (which I don't count here). METSCI is in packets of 3 bytes, with 100mS from packet start to packet start (min 96, max 103mS).
The first packet of 3 bytes was: 0xE6 0x40 0x5A. This repeated every other packet sent (817 times total). I guess this is the assist/regen packet.
The even packets were more interesting. There were 18 different strings sent total. It had a 5 packet cycle that I'll call M1 through M5. M2 through M5 were the same every cycle, only M1 changed. It also repeated the same code for M2,3 and 5. The whole cycle repeats at 1 per second.
After 110 seconds or so, M1 started changing. First to 0xE1 0x25 0x7A, then after a second to 0xE1 0x26 0x79. The middle byte went up by 1 and the end byte went down by 1 until the code was 0xE1 0x33 0x6C.
The packets that start with E1 or E6 sum to 180 hex, the B3/B4 packets sum to 100 hex.
So that's the battery meter at least. It should be easy to get matching data from the Logic program.
Excellent effort thanks. I'll have another look at all this. I'm trying to duplicate your anaylsis initially but I can't at the moment.
Insert some headscratching and tinkering here!!
OK I've now replicated your data using the following settings in the Logic Software Analyser section. The bit rate as detected by autobaud comes out at 10000 baud, but 9600 works as you state. This will be useful as the picaxe chips can output data at 9600bps
Bit Rate 9600
8 data bits per transfer (Standard)
1 Stop bit (Standard)
Even Parity Bit
Least significant bit sent first (Standard)
Inverted or Non Inverted depends upon channel, see below!
Display in Hexadecimal
Both METSCI and BATTSCI channels now provide the same data with no errors!
For METSCI1 with the logic 0 idle state (Inverted)
For METSCI2 with the logic 1 idle state (Non Inverted)
For BATTSCI1 with logic 1 idle state (Non Inverted)
For BATTSCI2 with logic 0 idle state (Inverted)
Four exported simple text data files for MET & BATT are here. Both are in hex format, then same again in Decimal format. I find decimal easier to follow, anyone want to do a bit more patern analysis now I think we have reliable data?
I looked at the data file you posted and it looks like 9600 baud, 8 data bits, even parity, 1 stop bit. If you look at the bits, it's sending 9 bits then a stop/start pair in the blocks, and there's no parity errors.
Just to confirm are you saying 7 data bits and a parity bit or 8 data bits and a parity bit (Making 9 bits in total)
8 data bits, 1 parity bit. I said 9 because that's how I looked for the word size: look for 1/0 (stop/start) transitions at regular intervals. It always had a 1/0 then 9 bits, then another 1/0. The parity part is easy: just do a parity check, and if they all check out there must be a parity bit. The chances of an accidental match fall by half every byte.
The longer BATTSCI packets look related. They seem to trade off every other packet (0xAA or 0x87 for the start byte). All the ones I've looked at have summed to 180, 200 or 280 hex. Also, it seems like bit 7 (the last data bit, just before the parity) of the first byte of a packet (METSCI or BATTSCI) is always 1, and all other bytes of the packet have 0 in bit 7.
The BATTSCI bus is a two way comms between the BCM/MCM so I'll have to try and capture only what's sent by the units seperately now to help us make more progress . We don't know at present which unit is sending which packets when, and or what the responses are.
The METSCI may be slightly different, as although it may well be two way comms again between the BCM/MCM, looking at the circuit diagram the instrument cluster is listening in and certainly being driven by these signals. I doubt it (the cluster) is transmitting on this bus, in fact the diagram shows what could be an op amp/comparator input driven by the bus. This could just be another RS485 transceiver.
Anyone have a broken cluster they can look inside? What's connected to the METSCI inputs?
Looking at the rs485 driver IC's inside the bcm and mcm it may be possible to try and capture the data the cpu is feeding/recieving to/from them but it won't be easy and I might have to solder some minute contact points onto the chip legs to hook onto!
Been capturing a bit more data today, and added an event button on channel 5 as suggested by Malcolm so I could try and flag things as they happenend.
I need some physical help now to capture some events whilst driving, so I need a co-pilot to operate the laptop and button etc. Any volunteers?
Anyway as requested I pulled the fuse and reset BCM to empty, and with a nice full battery just switched ignition on and let it do a pos recal to 19 bars. I pressed the event button for about a second each time a bar appeared on soc display. So first button press indicates first bar appearing allowing a few 100ms for my response time!! last button press indicates 19 bars.
I then tried interrupting the METSCI lines this gave an instant P1648 error whichever line I opened SCI1 or 2. Clearly indicates a comms error.
I then put the logic analyser on both sides of the BATTSCI 1 & 2 interrupt switches to collect data from either the BCM or MCM depening on who was talking first. I opened both switches to break the connection betwen BCM & MCM and turned on ign.
It gave an instant P1648 as expected, but the display shows no activity from MCM (other than rs485 line drive pulling lines high/low on powerup) and BCM is clearly transmitting first.
Date in zip file including exported decimal data in txt form.
Please have a look and feedback any specific requests for analysis.
You will have to ignore the warning that comes up from google when you try to download this file, got hacked a while back and takes weeks for google to sort itself out after I re-uploaded my site!!
Data all appears to analyse correctly using settings as previously mentioned.
The AutoGuide.com network consists of the largest network of enthusiast-owned enthusiast-operated automotive communities.
AutoGuide.com provides the latest car reviews, auto show coverage, new car prices, and automotive news. The AutoGuide network operates more than 100 automotive forums where our users consult peers for shopping information and advice, and share opinions as a community.
Rs485
