Tundra Mud
Hi Guys a couple videos of the modules doing their thing.
Z4 EV being driven using a Geartooth sensor to the Arduino.
Audi Tach being driven using Can Gateway (Curtis Controller Can messages -> Through the gateway -> Audi)
Also installed one (pic attached) into a LS1 -> E46 M3 saturday. No time to write more.
Thaniel
Last edited by Thaniel; 10-27-2014 at 08:08 PM.
Tundra Mud
Yah apparently this bit is one of the first bits on the Length byte (See MCP2515 spec docs for details). If the bit is set to 1 then the message is considered a "remote frame". If I undestood correctly. And the remote frame contains no data bytes. I interpret that to mean the ARBID didn't come from the device that normally sends that ARBID? dunno. Either way a device looking for that remote frame will reply to that ARBID but set the RTR bit to zero in its reply and give some date. To simulate we just put a 0x610 on the can bus with the RTR set to 1 (no data bytes) and sure enough the IKE responded with a ARBID 0x610 message that contains the vin. And it did it as often as we sent the 0x610 remote frame. Did some checking of the vins on other can captures and yah it all matches up. From the in car testing we did with the ABS disconnected it appears that the ABS was sending the 0x610 "remote frame" or 0x610 with no data bytes and RTR bit set. I hope this helpsOriginally Posted by mdrobnak
Interesting. So the ECU repeats the button presses over the Can bus. Are these sent even if the car is not in motion engine is off?
Not sure if I follow you on bits 1,8 etc. 1,8 of which byte? The TPS byte is 0x329 byte 5. No don't have the correlation of volts to the hex values. But it ends up being a % of throttle. zero being zero% and FE being 100% (expect FF is an error state)
My son just rewrote the can library last night. Made one with dual can ability and muti buffer recieve and send ability. And made the remote frame call easier. But to change the RTR bit it was simply a bit change of the length variable. Sorry I don't remember which one. i'll post the new can library on my google drive when I get it to my computer.
Agreed.
We write all our code in Arduino 1.0.4. Using our code on other versions could have some unusual results.
If the CAN Diy sheild from watterott uses the same MCP chips then you should be able to use our new can library on your set up as well. We just bout 2 sets of chips on on our card to make things simpler. And throw on a Kbus chip for good measure :-)
Thaniel
Member
Ok, so if I'm not removing ABS, I'm in good shape. Gotcha.
Yes, those bytes are sent if the car is stationary. Not sure if engine off, but I assume so.
What I meant was bit _values_ 0x01,0x08,0x10 of byte 3, the same one with the button presses in it.
As far as TPS being byte 5 --- sort of. I do have TPS wired up, and byte 5 is a made-up composite value based on IAC and TPS. It is not a 1:1 correlation between actual TPS position.
-Matt
Member
A follow-up:
0x329 byte 5 is NOT TPS. It is _pedal_ position. There is a 1:1 correlation between my pedal position sensor values and byte 5, and aside from my scaling being a little off, it's almost exact.
When the DME encounters a Throttle or IAC control issue, it sets byte 5 to be whatever correlates to 30.4% or something close (I have to review logs). I know this as I'm working on getting throttle and IAC working on the Motec M1 currently. This also makes the DSC freak out, so no traction control or "fake" differential via braking.
I'm working on trying to get a better handle on the remaining unknown bytes, and the additional 10 arbitration IDs that the GS30 transmission controller spits out on its bus.
-Matt
Member
0x316 byte 0, value 0x40 (decimal 64) is AC Clutch Engaged.
Tundra Mud
Good stuff. Yah TPS was probably the wrong term to use. Drivers wish signal is probably more descriptive.
lately I've started adding to my bench test setup. Added a ihka and have a abs module I've not yet connected.
I've also started programming transponder keys. Not sure that's helpful for engine swaps but it's interesting.
thaniel
Member
I thought some time, 329 B5 would pedal sensor. However, there was some reason to change the opinion
1. lack of accuracy in comparison with diagnostic software
2. during driving with cruise control, the byte is still set, although in diagnostic software for DME will not be displayed
I think 329 B5 is throttle open (in percent) - drivers wish. Multiply the value by 0.39
I also found place in diagnostic software for DSC control unit, where this value is shown and this is always identical to CAN
Last edited by drukhadze; 11-14-2014 at 02:05 AM.
Member
Oooh, that's interesting stuff there, Dmitry.
Maybe I will have to start playing with ToolSet 32 more.
For that I-Bus monitor, is that your program?
I have had similar thoughts about the current vs target throttle opening.
I know the GS30 TCU calls byte 5 Virtual CAN Accelerator.
I think the best way to describe it is throttle aim - and whatever the source, that's the outputted aim. So for my screenshot, you'll see byte 5 follows byte 4 when CC is enabled...I also didn't see any pedal position on the ASC ARBID.
-Matt
Member
yes, that is a program from me. Actually has nothing in common with IBus.
It should have been called "CAN-bus monitor", but until now I have not done the most difficult in the program - to change title
It communicates with Can-bus via Arduino. In attachment few screenshots
Member
Clearly you've been holding out on us.
Looks awesome. I have a few questions I will PM you with.
-Matt
Member
After looking over drukhadze's posts, and PMs, and in reviewing more of my logs, the following is my theory on currently unknown bytes:
0x153:
Byte 0
- 16 (dec) = Brake on
- 0 = Normal
- 1 = Braking intervention?
- 4 = 4 + 32 when no IAC.
- 8 = DME intervention?
- 32 = 32 + 4 when no IAC.
- 228 = Uncalibrated / Other problem?
Byte 3 & Byte 6 change during tq red. Desired % of total tq available?
Byte 6 is what causes the change from Byte 0 being 1 and then it being 9.
0x316:
Byte 0 - State comprised of adding which sub-states are active (ie "5" is normal running value)
- 1 Key On?
- 4 DME Ready?
- 16 (dec) Overrun
- 24 (dec) 24 + 32 when IAC was disconnected
- 32 (dec) 32 + 24 when IAC was disconnected
- 64 (dec) AC Clutch Engaged
Byte 1 - Current Throttle Opening (Includes IAC at low requests)
Byte 4 - Desired Throttle Opening (Includes IAC at low requests)
Byte 5
- Mixture Aim / Lambda? I think Mixture Aim. Scaling / offset unknown.
Byte 6 - State of ___
- 128 on egagement of next gear
- 8 ?
- 0 all other times
Byte 7 - Throttle opening without shift tq reduction taken into acct (Includes IAC at low requests)
0x329:
Byte 0 - Rolling byte. No idea why, 4 values. 17,64,141,217. Later log 132 instead of 141.
As my main tuning laptop is with my vehicle in NJ, I realized most of my newer logs are on that laptop. So some of this is theory, some of it has enough information to 'fake it' well enough I think to get DSC to be happy again and drive the speedometer and fuel consumption gauges on the IKE. I will find out when I come back from vacation.
-Matt
Tundra Mud
Hi Matt, Great stuff. I'll post my theorys too. I'm working on adding to my bench setup a DME & DSC modules to help isolate some of these values. I've just recently added a IHKA, EWS (including transponder ring) and I have an ECU and DSC and LCM I need to hook up. I've already figured out how to reprogram keys and EWS's so I should be able to get the DME to think it's actaully ok to turn on. But I think you may have this figured out before I getting it all connected and working :-)
Oh. And as much as I enjoy decoding the can bus. I might mention that you do NOT have to have these messages decoded for the speedometer and fuel consumption to work. I have several cars out there now running my modules and the speedometer works on ALL of them. Now the DSC when scanned does have a code set for torque reduction not possible. Which indeed is true. And barring some real creative coding will be hard to make the DSC think it all is working when if it tries the car will not slow down. But that's not saying we shouldn't try to at least get the DSC to think it could if it wanted to :-)
OK - Here's my guesses:
0x153 This is from the ASC. We don't need to send this out but we might want to know what it says to send the right torque reduction response. I've got nothing new on this one. Perhaps if I get my bench setup working I can simulate wheel slip and get some more info
0x316
I think in this message the torque variables for the torque reduction are. based on some reading (Sorry I don't have a link at the moment) there should be
Standard Torque output (Nm)
Torque consumed by friction (%)
Indicated Engine torque during Intervention (%)
Indicated Engine torque without intervention (%)
My guesses are:
B1 - Indicated Engine torque without intervention (%)
B4 - Standard Torque output (Nm)
B5 - Torque consumed by friction (%)
B7 - Indicated Engine torque during Intervention (%)
But honestly I'm guessing quite a bit at which is which. B1,4 and 7 on the data I have are all quite similar. I but B5 as torque consumed by friction as it was smaller and less variable. B6 on my data is always zero. But it could be an indication of something that only happens when there is wheel slip. Anyone want to spin the tires and take can data :-)
0x329
Yah I noticed what you mentioned about the 329 B0 being a rolling value. Maybe it's to let the other modules know it's still away? No idea.
Thaniel
Member
Right - from 0x153 we just need to know when it's saying 'you should do something' and how much, if it says that...at least that's useful for possible translation into other vehicle's DSC equivalents. In my case it'd be useful to know when there should be a torque reduction request...even though currently there's nothing in the GPR package to act upon it. I'd have to write something.
As for 0x316 - if you look at Dimitri's INPA / Tool32 output - you can see it translates to something like 'driver filling request' which does sound like the throttle body. B5 changes even when the car is not in motion, and I think it may have to do with torque used by AC clutch, as I've seen that value in INPA. Or idle adder because of AC clutch? Not sure.
B0 - 0x10 (16 decimal) looks more to be 'injectors inactive' rather then engine overrun. I say that as B0 briefly goes to 0x10 right before engine speed is non-zero. Only sometimes though. Oh DME, why you so mysterious? LOL
On my 11 hour flight to Hawaii (which was a very nice change of pace for a week) I did some rough categorizing of other 'unknown' signals...when I pull that off my laptop tomorrow (after I get closer to normal time again), I'll post more thoughts.
Oh, and, yes, clearly this is the advanced level stuff at this point - driving the speedo is very simple in comparison.Sorry if I was implying that you had not got that working already - clearly your vids show it working pretty well hehe.
-Matt
Tundra Mud
Appology not necessary. Just wanting to make sure you weren't holding up part of your project to get all the bits figured out.
Maybe over the break I'll get my ABS module wired up to my bench test setup. Might be able to learn some more from it. Being able to pull wires on and off at will and not having to worry about damaging a car, has it's advantages.
Thaniel
Tundra Mud
Learned a few more things about the M3 cluster.
The IKE can not be recoded with the PA soft tool. Must use inpa or DIS or something.
The 545 byte3 holds the RPM lights. Here is a list of what binary value maps to what lights. For the RPM lights it appears only one of the bits should be set and it lights all the higher lights. The yellow 7.5K and the 2 Red 8 and 8.5 K lights appear to always stay on as long as the car is on.
Bin Hex 0 0 Nothing 1 1 Nothing 10 2 Oil level 100 4 Nothing 1000 8 Over heat 10000 10 7K and up RPM 100000 20 6.5K and up RPM 1000000 40 5.5K and up RPM 10000000 80 Nothing
Thaniel
Member
I would be interested in CAN converter. For example I want to run N55 engine in E46 and I want to use E46 DSC and Cluster. It does not work because N55 uses different CAN, so these modules are not competable. For example E46 MK60 DSC uses D-CAN low and high, and E90 N55 uses PT-CAN high and low, I guess higher resolution stuff.
Tundra Mud
Yah the newer model BMW's use different messages. But the concept for integrating the motor should work the same as doing the LS or EV swaps.
Do you know if the N55 motor Can messages are similar to these http://www.loopybunny.co.uk/CarPC/k_can.html ?
Thaniel
Member
That's not entirely accurate anyway - MK60 is definitely attached to the Powertrain CAN Bus..
Member
N55 engine or E90 chassis, have the same messaging so 2007-2011 3 series for sure, Other BMWs should have the same communications for those years.
Tundra Mud
Then using the data from that website you would have a foot hold. Though there are only a few of the PT bus messages on there. The hard part, in my opinion, would be getting traction control to be happy. In the LS swapped car torque reduction is not maintained. I'm sure between the 2 BMW buses it would be possible but trying to decode the torque reduction messages has not been done. Far as I know, other than torque reduction, the rest of the DSC works fine without the DME data.
Member
Thaniel, DSC is not important to me. What is important is for the N55 engine to communicate to E46 cluster, RPM, temperature and the rest. What would I need to accomplish that?
Tundra Mud
Sent you a PM. I expect the solution described here: http://www.bimmerforums.com/forum/sh...-signals/page2 and used on a couple LS3 E46's would work for this as well.
Tundra Mud
Our "car in the house" or our test bench, has been expanding. Awhile ago we added a DME, EWS, Transponder reader, IHKA and Radio. Recently we added a LCM and ABS/DSC. Yesterday we addeed.....
Did you see it? A GM PCM :-) Here is a better look.
It's not an LS1 PCM but for what we want it to do it should work. We've been having good luck with the Can to can interface. We thought we'd try to develop a Can to VPW interface (without using the ELM). We needed some hardware to test the interface on. It think it from a '01 cadilac seville. The Class 2 serial data does stream from it so it should work just fine.
A couple things that struck me funny. The GM PCM is HUGE compared to the BMW DME. Yah it controls 2 more cyl but that doesn't explain the expanded size and mass. The other thing that was odd was NONE of the GM's wires were large. And a few of the BMW's are quite large. The BIGGER one has smaller wires while the smaller one has bigger wires. I'm sure I could figure out why but it doesn't matter. I just though it was funny.
Thaniel
Member
The LS2's E40 PCM is quite a bit smaller than the LS1 computers.
Tipsy
Member
The GM PCM controls the transmission as well, so it's like BMW's DME and EGS in one box.
GM spreads high current loads out over several smaller wires. The PCM may have 3 or 4 +12V and GND wires that just get spliced together somewhere in the harness.
Posting Permissions
Reply With Quote
Bookmarks