Yes - one could imagine that the Mercedes OEM code did 20 ms and Jaguar had to live with it, but given how much in line the ZF and Mercedes implementations are in other respects, it's an outlier. On the others for the XKR I have ECM 0x7d0 at 200ms, INST 0x7d2 at 200ms, and ABS 0x7d3 strangely at about 194ms average with a fair amount of jitter....

 

@crbass
thanks,
I was reading your thread...
Way out of my League...
Impressive work though.
Not sure I can manage to get up te speed far enough.
Will see. (or at least look)

 

Does any of you know if the 3000rpm limiter is based on gearbox speed sensors that result through TCM in limit signal to ECU, or by the lineair switch position to (other network I guess) eventually ECU imposing the 3000rpm limit based on crankshaft speed sensor?
(I think crank speed sensor, but would be great if it came from gearbox speed sensors)

 

Do not know, but expect the limit comes from the ECM not getting the information it needs/wants.

 

I thought 3000rpm is a programmed limit to protect engine when in P or N?
I was wondering whether it uses crank speed for this, just like the 6500 limit, or gearbox sensor, because gearbox is part of the equasion in this case.

 

Don't know this for sure but my guess would be that the ECM is listening for the CAN messages that indicate what gear to be in and adjusting its behavior accordingly by way of the crank sensor.

 

Dale, in another thread (I think it was your decoding thread) you talk about the TCM heartbeat and refer to it using an ID of 7e9. Is 7d1 for the early cars? (pre2003)? I made a classic blunder of yanking the transmission out before doing any sniffing on my own canbus and now I'm trying to figure out the correct IDs to use. Any help would be appreciated.

 

Caveat, I've had a later model (2003-2006) with the sniffer for a few minutes. For 2001-2002, I have hundreds of hours of data. So, yes hex 7D1 is the token ID for 2001-2002, probably same for earlier. One byte message, should be reported as hex 14 (binary 10100). Message IDs with data are C8 and 3E8.

From the limited data on the later models (2003-2006), it appears there are no tokens, the TCM message IDs appear to be C9 and 3E9. I have not fully decoded these messages, but assume they have some similarity to the 2001-2002 data.

 

Oh boy, no token? That'll make things fun and difficult... Although it would explain some things. I tried a few variations of of replicating that heartbeat last night with no effect. (short program transmitted from an arduino)

I wonder if I can hook up just the TCM sans transmission and still get any usable results.

 

Easier in one respect, the system doesn't care if it's transmitted. Seems like the tricky thing is making the TCM IDs spit out data that, first, allows or defeats TCM/ECM synchronization, depending on what you want to do at the time and not run out or limit RPMs depending on things no longer happening in the transmission. Then provide whatever the ECM needs to think the TCM is happy.

Good luck with it.

 

Yeah, I was foolishly hoping that the heartbeat was the big thing causing the transmission fault/restricted performance and the other missing data wasn't required, just missing. I guess I need to find another functioning STR to do some sniffing. Thank you.

 

Static (i.e at the start) may be straightforward. Try sending two messages every 10 ms using your sniffer

ID: 3E9 8 Bytes: 0000610200000063
ID: C9 8 Bytes: 01FFB00000000000

Unfortunately, if you ask me what each byte means, I have little idea, but it is key on before start.

Note: there are 5 of 20 IDs I have not located to a module in the 2003-2006, one or more of these may come from the TCM, so these two messages may be incomplete. But, you could always send those 5 as well and sequentially delete until some warning happens.

 

Thinking about this further, since you don't have the TCM in, if you just make the bus whole by bridging the TCM connection, you can see if any of the following IDs show up

1B0, 1C2, 41A, 70, 80

If all show up, the two I mentioned earlier are the TCM IDs. Whatever doesn't show up, must be from the TCM, and I can provide engine off and start data for those.

 

I haven't sniffed any more but I did throw a quick program to shoot the previous two strings out every 10ms. (the 3e9 and c9 set of bytes) and after a few key cycles the restricted performance is gone! The check engine is still on but the training wheels are off the car. Throttle response was back to being snappy. I'm going to run it around the block and see how she drives. It's absolutely amazing what a little bit of coding can do. Thank you. We'll see if this lasts under some driving conditions.

Since the TCM was just a node on the network I didn't jumper any wires other than the P/N switch when I pulled it. I DID have to bridge the network at the Jgate connector when I removed that since it goes through the module itself. That's actually how I'm accessing the canbus. I paired off those wires.

 

That's great. It wasn't clear how the nodes worked in your model since they go through all the modules in earlier versions.

So, you currently have a manual transmission in it, or have you just removed the TCM connector?

 

The manual box is in the car already. I did things backwards and did all the mechanical stuff first and then attacked the electrical.

So I cleared the codes and the check engine light didn't come back on. It does complain that cruise control is unavailable but I assume the cruise module is looking for some info from the auto box.

Shouldn't be too hard to set up a park/neutral switch trigged off the arduino either. I guess then it's just a matter of choosing how it's triggered. Maybe off of rpm reading? When r's drop under a certain threshold it triggers park so the ebrake works and such? Hrm..

 

I guess, ideally, someone would decode the messages. Do you have some feedback from the manual to tell you it's in park/neutral? The only issue I see with rpm is that it's not a particularly specific metric of 'park' for example, and 'neutral' certainly. Of course, it's not clear to me what the consequences would be of always being in 'park/neutral' anyway.

 

Nothing concrete from the manual. Only the reverse light switch for reverse.

I supposed a few caveats could be written. Under a certain RPM, wheel speed at zero and I don't know what else?

Again, thank you for you help.

 

I had another thought. Currently I have the Arduino powered off of the cigarette lighter which is basically ignition hot. If it were powered off the BCM or another module that stays alive for a minute after engine shutdown I could use any ignition/run hot source as another trigger for the parking brake module.
RPM zero, wheel speed zero, brake pedal switch on, ignition voltage disappears = engages parking brake
RPM above 500ish, brake pedal switch off, ignition voltage present = parking brake disengages

 

Please pardon my ignorance of the later models, but this is an electronic brake different from the hand brake? Am only familiar with the earlier model handbrake option which is 'pull up when you feel like it'.

If so, logic seems fine to me. Prevents the system engaging if you are rolling and stall.