Analysing the BCM/MCM Signals

[retepsnikrep]

Breaking News from CNN

My little Picaxe 18X and RS485 METSCI driver works!! and I've had the gauge showing 19 bars soc on the bench.

Logic analyser saved the day after I forgot to change the byte being sent. Duhh!

Need to work on the Picaxe 18X code now to flex the Gauges muscles with a nice light show demo for Youtube!.

Then start work on receiving side if it can manage it.

I could really do with working out why the gauge on the bench goes off after 5 seconds, come on guys ideas please.

Edit

5 seconds of video showing Gauge being driven by Picaxe18X via Ltc1487 RS485 Driver chip.
Just some random values I picked from the now known Assist/Regen/Soc code lists

http://www.youtube.com/watch?v=OO8CP6qY90c

[retepsnikrep]

I'm probably going to move later to a 28X2 picaxe for my pcb version of the rs485 device as it has a number of commands that will be very useful to the project. Including interupts and plenty of ram to manipulate the BATTSCI data with a decent turn of speed.

Nearly finished my 18X transmit demo software for the gauge. Probably tomorrow with luck.

[E27006]

I could really do with working out why the gauge on the bench goes off after 5 seconds, come on guys ideas please.

Had a look at the circuits in the manual, can't come up with much to suggest.

How does Vss (vehicle speed sensing) come into play? Is there a pulsing signal even when the car is stationary?.

Also fuel gauge sender (page 80-1 of electrical manual) A3 needs to see a resistance between 11 to 132 ohms to Ground (see page 80-5) . If A3 is open circuit could it crash the programme?

There are so many other signals too, B3 and A27, connect to MCM and ECM,

[Mike Dabrowski 2000]

Peter,
Where does the MPG get computed, in the guage, or is the result sent from the ECM or MCM?

[retepsnikrep]

Randy

Just looking through your very interesting excel data and explanation. That is a real great effort. Thanks.

A few queries you mention bytes 3 & 4 in code 87 as being current, I think that's a typo and should be 5 & 6? As that matches the AA current codes.

I see the METSCI data is down the right hand side, but the third column is greyed out, is that because you think this is a checksum for the three byte packet?

How is that being calculated?

Can excel work on the data using the current formula you postulated to provide another column for current on the right hand side? I a virtual novice with Excel, my wife is fairly clued up though.

A current value and a meaningful voltage/temp column etc would aid reverse enginering.

Can we use the known METSCI values for the various soc/assist/regen gauge positions and convert them to a meaningful figue in another column? Three columns in three colours with Assist/Regen/Soc value say 0-20 bars.

I will ask my wife about all this as well.

Cheers Peter

Mike I don't know the answer to that but suspect it is calculated by ECM.

[Fjord]

Originally Posted by retepsnikrep

A few queries you mention bytes 3 & 4 in code 87 as being current, I think that's a typo and should be 5 & 6? As that matches the AA current codes.

You're right. 3 & 4 are where I think battery level is. I'm not sure how I missed that twice.

Originally Posted by retepsnikrep

I see the METSCI data is down the right hand side, but the third column is greyed out, is that because you think this is a checksum for the three byte packet?

Yep. It's exactly like the longer message checksum. All bytes added up need to have the lower 7 bits be zero. So add up the other 2 bytes, negate, AND 0x7f. I have that logic in the excel file, but it's weird without a bit-wise AND available.

It should be easy to program. Your serial interrupt will need logic for counting bytes sent anyway. Just set aside a byte to accumulate sent bytes, and for the last byte negate/AND it and transmit.

Originally Posted by retepsnikrep

Can excel work on the data using the current formula you postulated to provide another column for current on the right hand side?

Yes. I was going to do that, but the file was big enough as-is. If you look on the 'Cur' sheet, it's calculating it in column H. The formula would look like this (aiming at the first current columns in the drive sheet, line 2):
=( HEX2DEC(F2)*(2^7)+HEX2DEC(G2)-2048 )/20.48

Originally Posted by retepsnikrep

Can we use the known METSCI values for the various soc/assist/regen gauge positions and convert them to a meaningful figue in another column? Three columns in three colours with Assist/Regen/Soc value say 0-20 bars.

That file doesn't really have the METSCI and BATTSCI lined up... I recorded them separately, and only approximately lined them up (it will be especially bad near the top where I was fiddling with the wires). I want to try it again with a time code to actually sync them up.

The MCM is filtering the battery level at least (when the battery level jumps, the display seems to go at a bar per second). I think the only real way to get the cutoff points is to bench test it.

[retepsnikrep]

Originally Posted by Fjord

You're right. 3 & 4 are where I think battery level is. I'm not sure how I missed that twice.

Yep. It's exactly like the longer message checksum. All bytes added up need to have the lower 7 bits be zero. So add up the other 2 bytes, negate, AND 0x7f. I have that logic in the excel file, but it's weird without a bit-wise AND available.

Care to give me an example of that forumula in action (Negate?) are we talking about a bitwise NOT?

The bitwise NOT, or complement, is a unary operation that performs logical negation on each bit, forming the ones' complement of the given binary value. Digits which were 0 become 1, and vice versa. For example:

NOT 0111 (decimal 7) = 1000 (decimal

Originally Posted by Fjord

I want to try it again with a time code to actually sync them up.

Any timescale for this?

Originally Posted by Fjord

The MCM is filtering the battery level at least (when the battery level jumps, the display seems to go at a bar per second). I think the only real way to get the cutoff points is to bench test it.

The 10 x 3 byte packet METSCI message is only sent once a second, and only contains one Soc message packet, so although it could jump up to 19 bars, it can only increment at one bar a second to show a linear progression.

So the MCM is just incrementing the gauge until reaches the correct Soc.

Edit

My wife (Good with Excel) has been looking at this data and we now have three columns for the Gauge values in bars.

I think we do need to capture a big session from both buses together to really get a grip on the comms.
I might try this later in the week. If you get a chance as well then great.

I'll post the modified excel file when I have finished tinkering. There are some strange areas in it when data goes awary/missing.

[E27006]

Reading through Drive excel spreadsheet, there are a few instances of b3 26 27 and instances of b3 06 47 on Mettsci

Peter, if you send either of those that strings to the gauge, do they illuminate upshift or downshift indicators?.

[Fjord]

Originally Posted by retepsnikrep

Care to give me an example of that forumula in action (Negate?) are we talking about a bitwise NOT?

It's the 2's compliment, just the minus sign in high level languages. It's the bitwise NOT, then add one, so a 4-bit 7 becomes a 9 (or a -7 in 4-bit signed form).

I'm going to try for another run this weekend. Right now I've got the other end torn apart working on the EGR valve.

[retepsnikrep]

Originally Posted by E27006

Reading through Drive excel spreadsheet, there are a few instances of b3 26 27 and instances of b3 06 47 on Mettsci

Peter, if you send either of those that strings to the gauge, do they illuminate upshift or downshift indicators?.

I'll try that Malcom this week. But I would expect that data to come from ECM which does not communicate on METSCI bus.

I've now sorted a caluculate checksum routine which works thanks! Randy, I understand that now as well.

b0 = $E6 ;Calculate Checksum Routine
b1 = $40
b2 = b0 + b1 ;Add all bytes of packet together b2 = value + value + value + value etc
b2 = NOT b2 ;NOT result
b2 = b2 + 1 ;Add 1 to result
b2 = b2 AND $7F ;AND result and checksum in b2

I've just captured a short video for youtube of gauge under my control!!!!! LOL

Audio is rubbish. Sorry!

http://www.youtube.com/watch?v=Q9-Qda-6to4

My 18X Picaxe basic code for the gauge driver is here in case anyone wants to take a look. (Ignore Warning!)

http://www.solarvan.co.uk/insight/ME...040709_V11.txt


Thinking ahead now about removing the BCM what comms will I need?

I'll need to capture the messages from the MCM to the BCM on METSCI.

I will need to send messages to both the Gauge/BCM on METSCI and the MCM on BATTSCI.

So I think I need three or four RS485 serial channels.

1) Receive from MCM on METSCI. This is only 10 x 3 byte packets with 100ms gap between packets so 18X can probably cope with this.

2) Transmit to Gauge on METSCI. As above 10 x 3 byte packets with 100ms packet gap. In fact I might try just sending E1 (Soc) and E6 (Assist/Regen) codes on METSCI bus to see if gauge just ignores fact B4 & B3 code packets are missing. I'll also try to work out the max refresh rate, can I send more Soc packets per second, in fact can we send back to back packets for instant gauge response? Again 18X can cope with this. In fact 18X may just sit in between i.e.

METSCI MCM ---> Picaxe18X ---> BCM & GAUGE

It can forward BCM specific data to BCM but also drive gauge with our own data!!

3) Transmit to MCM on BATTSCI bus. This is more complicated 2 x 12 byte packets with 16ms packet gap. So probably need a 28X2 as the data will have to be modified on fly depending on info from BMS current etc.

I could of course leave the BCM in situ but insert the 28X2 into the BATTSCI between them.

BATTSCI BCM ---> Picaxe28X2 ---> MCM

4) It looks at data comming in from BCM and BMS and then sends out to MCM. Keeping the current readings comming in from BCM and simply forwarding, that but sending modified soc/voltage data as reqd!! Similar to METSCI above.

Looks like this all requires four RS485 channels, probably an 18X for METSCI and 28X2 for BATTSCI.

I might start on a pcb for this later this week.