Would anyone know the message used to control the reversing lights in an E65? Thanks.
Hi, I am trying to understand CAN BUS message from 0x1D0 id, to see interesting information with Arduino. Maybe anyone know what are the meaning of these:
?
So far I know the meaning and formula of these:
Code:TEMP_EOI Coolant temperature. (Byte[0] - 45 = temp in C) TEMP_ENG Oil temperature. (Byte[1] - 45 = temp in C) ST_SW_WAUP ??? ST_RBMCYC ??? ST_END_RUN ??? RPM_IDLG_TAR ??? RDUC_DOCTR_RPM ??? OPMO_FU ??? IJV_FU Amount of fuel injected (Byte[5] * 256 + Byte[4] = in microliter) ??? CTR_SLCK ??? ALIV_COU_DME ??? AIP_ENG Air intake pressure (790 + Byte[3] = in hPa) ???
ST_SW_WAUP - Software wake up.
RPM_IDLG_TAR - Engine idle speed target.
ALIV_COU_DME - Alive counter.
Where did you get those labels from? Do you have more? DBC?
No I don't have more, found them in another forum, but no one has more there too, I would be interested to get more also. If anyone has more decoded KCAN messages please share. Would be nice to know how to get Air fuel ratio, oil level, coolant level, washer fluid level and other parameters on KCAN.
I have an e82 135i I swapped with a 2jz and kept everything as factory as possible. I have a Link Fury ECU with the CAN Bus capability. Right now we streamed the can data for the bmw throttle pedal ( the data matched the E46 ) and now we are full e throttle with no cable and works amazing with the 2jz throttle body. Since we used the factory transmission so speed works fine on the cluster. So far we need to get proper data for AC RPM and Fuel. Right now fuel is full power on a switch wired from the Bus controller.
i'd like to find more info on which address the AFR is broadcast if anyone knows?
Does any one know what does K-CAN BUS message ID 0x332 (DME1/DDE1 - Fahreranzeige Drehzahlbereich = Driver display speed range) means?
It seems that byte 0 value 0x79-0x83 moves M cluster dynamic red line:
hqdefault.jpg
But what does it value mean?
Does any one know how to decode 0x1A6 message?
It suppose to be "distance", but I am not sure what kind of units are used here and it seems to be strange value.
Does this help? http://www.loopybunny.co.uk/CarPC/can/1A6.html
Has anyone decoded DME messages? for example id 0x1B6 (Heat flow engine)
I suspect there could be air and exhaust temperatures?Code:438 0x1B6 Wärmestrom Motor [11] 18 0x12 DME1/DDE1
Is there CAN message for BC button? Or its only passed directly to KOMBI not through CAN BUS?
No it is connected direct with pin 16 on the cluster connector: pin16 with 1K resistor to ground = BC button, pin 16 with 2K resistor to ground = UP, with 3K = DWN
- - - Updated - - -
I have bought an E90 cluster too, and controlled with an Arduino Mega,I have switched off all alarm lights including electric steering that was enabled on my cluster;
i'm able to control speed and rpm needle, fuel needle too but I'm searching for a CAN ID that control the MPG needle... Someone have found this ID?
thanks in advance
How did you switched off all alarm lights?
Its easy to control fuel needle, you need to sent message with id 0x349 every 200ms
I switched off airbag, abs, TCS and finally active steering light...there are no indication about it, I finally found the CAN ID 0x1FB looking in a E90 log on the web.
I have controlled the fuel needle, but I want also to move the consumption needle on the right, I have seen in the BC that consumption remain all the time at 0.0Km/l
Before I start reverse engineer,.. do you guys have an idea if traction control state can be changed via CAN (same as pressing DTC button)?
I know JB4 piggyback was able to do it, but I am not sure how it did it.
It seems like it is n K-CAN, but also probably mirrored to PT-CAN. I am not sure at which ECU is the state of the button held though.
can we have some more info in the coolant temp tap. been looking for a way to monitor coolant temp in my e82.
I'm trying to do things the other way around; swapping an E90 powertrain into another vehicle. So far I have the JBE awake & the DDE powered up, and I'm seeing 0x130,c5,42,ff,ff,ff on the D-CAN at the OBD connector.
When Protools tries to talk to the DDE (sends 0x6f1,...) there's no response. I'm wondering if my Terminal control message is wrong? I've been using Thaniel's 45,42,69,8F,E2 sequence, which has worked to keep JBE alive, and I'm seeing plenty of traffic on PT-CAN from the DDE, but obviously something is missing.
I get the same result (i.e. no response from the DDE) if I leave the JBE out of the equation and just connect directly to the PT-CAN.
'02 M Coupe
Last edited by hotter; 01-11-2021 at 10:30 AM.
FWIW, I don't think the JBE is actually on F-CAN, it just passes it through between two connectors. I'm fairly sure I've identified all of the CAN transceivers on the board, and they're all spoken for (PT, D and K).It might allow sending same message from K-CAN to F-CAN.
'02 M Coupe
Still no luck getting the DDE to respond to 0x6f1, but I did find a trace with some real 0x130 messages in it. The last byte is not constant, it's actually two separate counters. The low nibble just counts 0...E, changing every message, and then rolls over. The high nibble is more complex; it also counts, but skips a different value based on the message. It's also offset differently based on the message, in a fashion that seems to be derived from the other bytes in the message (though I haven't worked out the derivation yet). The high nibble also changes every message, so for a given 0x130 message there are 15 possible values for the last byte.
Based on the trace I analysed:
// 41 42 21 0F off (steady state)
// checksum base 2,0 high skip E
// sequence 20 31 42 53 64 75 86 97 A8 B9 CA DB FC 0D 1E
// 41 42 61 0F clutch depressed before starting
// 41 42 61 1F starting (2x)
// 55 42 69 2F starting (1x)
// 55 42 69 6F starting (8x)
// checksum base 9,E high skip A
// 55 42 61 9F starting (2x)
// 45 42 61 9F early running, clutch depressed (26x)
// checksum base 4,0 high skip B
// 45 42 61 8F running, clutch depressed
// checksum base 3,0 high skip A
// 45 42 21 8F running, clutch released
// checksum base F,0 high skip 6
// sequence F0 01 12 23 34 45 56 77 88 99 AA BB CC DD EE
// 45 42 21 4F turning off (1x)
// 45 42 29 6F turning off (3x)
// 41 41 29 6F turning off (1x)
// 41 42 21 5F turning off (2x)
// 41 42 21 1F turning off (24x)
// checksum base 3,0 high skip 1, F, double 3
// 1 skip may be timer artifact, not enough samples?
// 41 42 21 0F off (steady state)
In the second last message (41 42 21 1F) the trace suggests that both 1 and F are skipped, and 3 shows up twice. There's only one record that looks like this, so I'm not sure what to make of it, but it's not a simple bitflip:
130 4142211FEB
130 4142211F0C
130 4142211F2D
130 4142211F3E
130 4142211F30
130 4142211F41
'02 M Coupe
Getting the DDE happy via CAN is difficult. If it were not then anyone could tap the CAN bus and simply drive the car away. There are a bunch of CRC's and Security information and the CAN message stream has to be perfect with all CRC's correct passed for the DME/DDE to be fully operational (the KOMBI doesn't care that much as turning it on is a low security issue). Best bet for an engine swap is doing some reprogramming/Tuning/immo delete of the DME/DDE.
I've worked on some projects where people did modify the DME to get it to work in another car. But I only was involved in the data transmission of the CAN bus to make the gages and similar work so can't advise how it was done. More information likely can be found on BMW tuning forums.
Thaniel
In this particular case, the DDE in question has had EWS disabled, so it will start as soon as the engine turns over (and the START wire is pulled high). I'm not trying to build a standalone EWS bypass device, that's more headache than I care for. 8)
I reached out to the Bimmergeeks folks since it was their tool that was sending 0x6f1, and they cleared up my misconception - that ID is actually a query to the CAS, as they want to read the VIN and VO in order to identify the vehicle. I pulled the CAS & key reader from my donor vehicle and added it to the stack, removed my 0x130 generator, and whilst INPA is not entirely happy I can now scan the DDE and (so far as I can tell) talk to things "normally". I'm sidetracked reversing the flash protocol for another CAN device right now, but I will start documenting what I can see now that I have the CAS in the picture shortly, since ideally I'd like to be able to talk to the DDE without the CAS or JBE present.
'02 M Coupe
So back at my "emulate the CAS enough to be able to diagnose / maintain the DDE standalone" project. I think I have a handle on most of what's going on as ProTool is scanning the car, and faking it should be pretty straightforward.
While digging through this, I noticed that the VO returned by C_FA_LESEN is encoded in some fashion. I see mention of a FA_STREAM2STRUCT job that is supposed to do the decoding here, but searching turns up almost nothing. I don't actually need to know the VO, since I just need to cough it up when asked, but I assume *someone* must know how the encoding works...
Since I managed not to find a description of how the tools talk to individual ECUs anywhere (and the loopybunny site's page on the subject isn't linked), here's what I've been able to work out so far.
BMW assign specific CAN message IDs to ECUs for the purpose of addressing specific devices. There's a partial list on the loopybunny page, but I'll reproduce it here for the sake of searchability (and adjust it a bit)
0x00 JBBF, Junction Box Module
0x01 MRS, Airbag
0x40 CAS. CAS ELV. car access sytem
0x41 DWA, AntiTheft Alarm System.
0x50 SINE, Siren And Tilt Sensor.
0x56 FZD, functional roof sensor
0x60 KOMBI, Intrument Cluster,
0x64 PDC, Rear Parking Sensors
0x72 FRM, Footwell module
0x78 KLIMA, Climate control.
0xef broadcast / all-call
0xf1 D-CAN adapter
Whenever a module is talking as part of one of these conversations, it uses the CAN ID that is 0x600 + the module ID. Conversations always start with a message from the D-CAN adapter (the test system), of the form:
0x6f1: XX YY Z1 Z2 Z3 Z4 Z5 Z6
XX = ID of the module being addressed
YY = length in bytes of the command
Z1-6 = command bytes
These command bytes line up with the KWP2000 commands / subcommands listed in Tool32 jobs, which is awfully convenient.
The response from the addressed module looks like:
0x6XX: 0xf1 0x10 LL DD DD DD DD DD
XX = ID of the module responding
LL = total length of the response in bytes
DD = first 5 bytes of the response, where the first YY bytes are the same as the command, except that the first byte has bit 0x40 set. Padded with 0xff if there are less than 5 bytes in the reply.
If the response is 5 bytes or less, this is the end of the exchange. However if it's longer, the D-CAN probe will respond with:
0x6f1: XX 0x30 0x00 0x01 0x00 0x00 0x00 0x00
XX = ID of the module being asked to complete its response
The addressed module will then deliver the remainder of its response, with a sequence of messages of the form:
0x6XX: 0xf1 SS DD DD DD DD DD DD
SS = sequence number, starts with 0x21 and counts up.
DD = data bytes, padded with 0xff
As an example, here is the probe reading the VIN from CAS:
41 0:02.489.646 6f1 8 40 03 22 10 10 00 00 00 VIN read
42 0:02.513.397 640 8 F1 10 14 62 10 10 57 42 “WB”
43 0:02.514.073 6f1 8 40 30 00 01 00 00 00 00
44 0:02.514.345 640 8 F1 21 41 50 4E 37 33 35 “APN735”
45 0:02.516.107 640 8 F1 22 58 39 41 32 36 36 “X9A266”
46 0:02.518.709 640 8 F1 23 33 38 36 FF FF FF “386”
Last edited by DrZiplok; 01-18-2021 at 04:25 AM.
'02 M Coupe
Bookmarks