ECU Diagnostics - CAN Bus, hunt for answers

[aerobod - near CYYC]

The data following the # sign seems to be a full CANbus extended frame, as the maximum CANbus message (standard, not FD) can only be 128 bits, with 64 bits of that being the data payload. https://en.wikipedia.org/wiki/CAN_bus

There seems to be 6 messages that are generally stable, but some with small changes (as expected data values change) between the pair of #FF00000000000000 values.

The 10ms sample rate also seems consistent with the data sampling expected in Easimap. There may be multiple sensor values embedded in each frame, as Easimap typically can update all values in around 100ms or so.

[Purplemeanie]

Mark,

  before you bought the Korlan CAN-USB widget, did you try the SBD interface with the SocketCAN drivers for Linux? Just wondering if I need to buy the Korlan interface or whether I can hook up the SBD interface to a Pi.

  I presume you're using Linux to be able to use candump, right?

  Also, to get an EasyMap pcap, are you going to use the SBD interface and the Korlan interface connected on a OBD y-cable? Or have you got some other cunning plan? I presume Wireshark won't capture the SBD interface packets on Windows... or will it?

John

[aerobod - near CYYC]

I would say the second set of 4 messages are the ones likely to contain the interesting data (ones starting with 0x0), as the first 4 (ones starting with 0xF) don't change in your sample and probably just contain header or synchronisation info:

(1565269627.010027) can0 0CBB0001#FF00000000000000
(1565269627.020246) can0 0CBB0001#FF00000000000000
(1565269627.030032) can0 0CBB0001#FF46000000000000
(1565269627.040072) can0 0CBB0001#FF9C000000000000
(1565269627.050275) can0 0CBB0001#049CFF2800000000
(1565269627.060501) can0 0CBB0001#0327001E00000000
(1565269627.070820) can0 0CBB0001#020000007FD50000
(1565269627.080253) can0 0CBB0001#014F00003D009C46

Perhaps the meaningful repeating set is as follows:

Start of message stream:

FF46000000000000
FF9C000000000000

Sensor data:

049CFF2800000000
0327001E00000000
020000007FD50000
014F00003D009C46

End of message stream:

FF00000000000000
FF00000000000000

I think the ECU can handle up to 32 sensor values (can't remember where I saw that), so 64-bit data fields could hold 8 8-bit sensor values in each of the 4 data messages or various variable length values.

 

[Purplemeanie]

Mark,

  it looks to me as though the dump you've provided is:

29 bit ID: 0CBB0001

64 bit data: #FF00000000000000

Is that the way you're reading this? In which case the ID would stay the same if there's only one device transmitting on the bus??

John

[CharlesElliott]

My ECU publishes on two channels:

Engine RPM: CAN 0x280, start bit 16, length 16, unsigned, Intel Standard Byte Order, Scale 1, Offset 0

Water Temp: CAN 0x288, start bit 8, length 8, unsigned, Intel Standard Byte Order, Scale 1.75, Offset -30 (note there is some debate that Easimap actually has the wrong scaling for Water Temp and ends up about 10 deg out but the gauge is right....I've never spent the time checking, it's close enough)

A CAN message payload is 8 bytes, as you can see, most of the message is not used (1 byte for water temp, two bytes for RPM).

You need something that can usefully decode the bits in the hex data you are seeing, or write something in Excel to do it.

Charles

[CharlesElliott]

[CharlesElliott]

[Purplemeanie]

Looks to me as though the data portion of Mark's packet capture is set out something like how this document sets things out...

https://www.sbdmotorsport.co.uk/index.php/instructionpdf/index/186

The first byte of Mark's candump data output corresponds to the Identifier field in that PDF (01, 02, 03, 04 look the most interesting but there's clearly something also in the FF messages - which might be an end of stream message as mentioned earlier in this thread, but might also just be a NULL message dumped out at regular intervals if there's nothing else to transmit in that time slice). 

So as an example from Mark's data, 

#014F00003D009C46

might break down as:

01: Identifier 01

Which implies that:

4F: Engine Speed MSB

00 : Engine Speed LSB

etc

I guess the SBD PDF isn't actually the mappings used in the Caterham ECUs... but...

From what I can tell it looks as though that's all defined in Easimap under the System -> CAN Bus data stream menu and should be reasonably trivial to take the output from candump and parse it using the mappings from Easimap. Or have I got that all wrong?

John 

 

[CharlesElliott]

CAN config is locked and not readable on the Caterham ECU. 

[Purplemeanie]

That makes things a little trickier then :-)

I guess that's why Mark was trying to parse the Easimap config files.

John

[CharlesElliott]

Yes, although I think I already did the work some months ago and posted the answers above 

[Purplemeanie]

Isn't your ECU a different one to Mark's though? Yours is putting out two channels, Mark's seems to be dumping way more than that and with a different CAN format?

What ECU are you running CharlesElliott (sorry if I missed that somewhere in this thread)?

John

[CharlesElliott]

Standard Caterham MBE ECU. It's a 1.6 Sigma for me but I don't think Caterham change the CAN config. It was pumping out one or two more channels but the data was always 0x0 or some other fixed value. 

[aerobod - near CYYC]

Looking back at a few data dumps I did over the years, consistently (with either the locked 992 or unlocked 9A4 ECU) the sampling rate for each sensor is between 75 and 100ms with 30 data channels selected, although the minority of those channels are derived as opposed to transmitted data. Bearing in mind that would mean a CANbus frame every 4ms or so if each frame contained a unique data value for one sensor and including the overhead that Mark's trace seems to show, a frame transmitted every 2ms. As the trace shows a frame every 10ms, I think MBE is combining multiple sensor values into each frame for efficiency, making it difficult to decode using any conventional scheme.

I'm sure the bit offsets in the data fields should be consistent, so it will just take more time to reverse engineer.

 

[CtrMint]

John,

"did you try the SBD interface with the SocketCAN drivers for Linux?"  Yeah, it was a complete dead end unfortunately.  I could see the SBD device was there, say through dmesg, but couldn't initialize it in any way.  The Korlan device was up and running in seconds, no faff. 

I'm still undecided about pcap'ing Easymap.  In theory, a Y cable should work, the termination of the bus is already there stopping reflections etc, and the Y cable is basically providing two points to tap the bus.  However I am a little cautious about the approach. 

As a long shot I thought Easymap might simply look for a standard interface, and permit use of the Korlan device but it hasn't worked that way.  If it did Korlan provide a Windows tool/plugin which permits Wireshark to see the USB CAN device, and so that would have provided an environment running Easymap and Wireshark.  Bit of a dream that one!

Plus even if I could do something fancy to permit RO access to the SBD device from my Host and RW access from the Guest, I think that would still be a dead end as I couldn't drive the SBD device from Linux. 

[Purplemeanie]

Thanks Mark. FWIW, I would have thought a Y-cable would be fine... it's not a particularly fast bus and I would have thought the resistive pull-up and active pull-down mechanism should play fine with the Korlan sniffing while the SBD/Easimap is doing its thing. Would be cool to find out what magic Easimap does to turn on all the goodies it can record. I haven't seen anyone else post the exact mechanism yet, but I may have missed it.

Where did you get the Korlan from... the US link you provided? or was there a UK/EU site?

John

[CtrMint]

Here's a packet in Wireshark,

I think there is agreement the 8 bytes/64bits Data payload starts 014F..... etc.

The constant value 'identifier' I'm assuming is the ECU on the bus, and in my normal world that would be similar to a MAC address.

[CtrMint]

Charles, 

Where did you find 0x280 and 0x288?

 

[CharlesElliott]

I've only got a few seconds as about to leave for work but I see 280 in the link layer address type. Depending on how Wireshark is displaying the byte ordering, the relevant data element for RPM is byte 2 and 3 which on the face of it is 0....but maybe the car wasn't running.

I will dig out my CAN dumps later - you really need something that will do a more readable first level of CAN decode.

[CharlesElliott]

If you see packets with 0x288, that should be water temp and the data packet is only one byte (byte 2, MSB on the left) - although it does then need a scale and offset to convert to deg c.

[CharlesElliott]

Here's a screen shot of what I found when I sniffed the CANbus with the car running. It's decoded at a higher level than you see in Wireshark.

1 x 29 bit address and 3 x 11 bit. Only 0x288 and 0x280 had valid data with 0x280 being RPM and 0x288 being water termperature. Note that both byte ordering and bit ordering can vary so it is easy to end up with something that makes no sense I posted the correct decode options above.

Charles

[CharlesElliott]

I just noticed that none of my screen shots are showing up which probably explains why no-one is commenting on them!!! Let me try and fix that.....

EDIT - can you see them? They are hosted on OneDrive so might not be visible from a work PC where OneDrive is blocked.

[Purplemeanie]

All your screen shots have shown up for me. I've been pondering them so haven't commented.

The last one you show makes some sense now. You've got the same 29 bit ID that Mark was reporting but you've got additional devices on the bus. Makes a lot more sense now. Not sure why Mark wasn't seeing the same but maybe he didn't have the car running or something.

[CharlesElliott]

The amount of CAN data published by Caterham ECUs has varied over the years from a little (like mine) to nothing. I don't know what their latest view is. On the new race cars they will change the ECU to publish more data if you pay them and promise only to use a VBox!.

[Jonathan Kay]

... can you see them?

All showing for me.

Jonathan