I'm not an expert in CAN car communication but more in the industrial area.
But what I know is that fault tolerant CAN is more or less out of use in modern designs.
That is what can be read here. http://articles.sae.org/13090/
Anyway, using a standard crystal of 16 MHz for the MCP2515 it should be possible to get 83.333 Kbit/s.
You can tools like http://www.bittiming.can-wiki.info/ to see what bit timings are possible.
Got my CanBusTriple, now I need to figure out how to get it to talk at this speed and reading these messages... I know you're busy Derek but if you can help me just with the baud rate stuff, I can probably get started on my own. I will see about finding time to work on this in the next few weeks.
Autobaud is working (in firmware 0.4.3) but only checks for specified values. 10,20,50,100,125,250,500,800,1000.
But you can send a 16 bit number to the CBT and it will figure out the config for you. 01 09 01 XX XX , xx xx being 16 bits representing the speed you want. It's relatively new but so far it's been working well for me and others as well.
Ok Derek I hit the bone yard today and cut a couple CAN C and CAN B bus bar/hubs and leads out of a late model E Class for testing with. Resolved my flaky connection issues, but it didn't resolve the baud rate issues as I hoped.
I had actually loaded a custom sketch and custom CANbus.h hacked together with some pieces i found here.
I also set all the CAN transceivers to (LISTEN) only rather than Normal. On first connection it stated capturing data, but would stop after about a minute. Couldn't use the Nodejs features either, but did log some with the USBPcap. Thinking having a good connection fixed it, I loaded the CBT autobaud sketch to use the Nodejs features. Nope bad move, it set me back to square one. And then I realized I didn't save my previous test config....
So starting over from scratch, here is what I found today. Maybe it will help us nail down the 83.3k network issue.
When the MB CAN B bus is in sleep mode, testing between CAN high and low registers 11.7 volts. Soon as you trigger a wake up event, that switches to 3.5v.
When running the the autobaud sketch, or any sketch with transceivers set in (Normal) mode, the CAN B bus will not wake up. If you wake the bus, and then connect the CBT, it crashes every node and causes all sorts of funky actions in the car. Headlamps come on, command unit malfunctions, and red "Visit Workshop" message in DIC. Like a voltage short issue. Same thing happens if you bring it out of sleep mode by turning the key on. Doesn't happen when CBT is in listen mode.
Should also be noted that the CBT is locking up under same events even in listen mode. If bus in sleep, CBT acts normal, no errors. Soon as the bus wakes up, CBT will capture a single wakeup message, then locks up and has to be power cycled. Some times the Red LED will come on depending on baud settings.
All these tests were done with only USB powering the CBT. No other connections besides the CAN B network. I'll try to rebuild the working sketch tomorrow.
Hope this helps, I am dying to get ahead of this.
Received an update earlier today on a related topic I posted over on a MBworld forum, which confirms what I had noticed about this CAN B network design. Seems that because CAN B is low speed "83.3kbps", it doesn't require termination. So it doesn't have the two 120ohm resistors in series which creates the 60ohms across the CAN H & L wires.
I'm not certain, but this may be causing some of errors I'm seeing when the CBT is connected. Need someone with more expertise on the 2515 transceivers to weigh in on this one. I do know something is causing the CBT to lock up frequently, requiring a power cycle to regain serial access.
I spent about 4 hours working on this today and here's what I have to report.
I had another device on the CAN BUS that worked fine before I started, and when I was done, the other device was broken and seems to fuck up the rest of my CANBUS.
In the middle of it all I was able to capture about 10,000 packets at 83kbps from my CAN BUS, I'm assuming they're not corrupted. I wasn't able to determine if they are anything useful, but I did press a bunch of buttons on my steering wheel and can confirm that none of the packets are 1A8, which is what is supposed to be the steering wheel buttons from a 2007 CLK350. Maybe they've changed.
Later on, I was unable to capture anything anymore and after tearing my hair out a few more times I disconnected it all and was happy my car still worked.
Sigh. I was extremely frustrated by this and it has sapped all of my desire to do it again. :( Losing the other module ($500 module) for reasons unknown also REALLY sucks.
I took a break to work on another project, but feel your pain. You captured more than I have so far.
1st issue I had is the 83k network is not terminated. Unsure reasoning, but could be a problem.
2nd issue I could only get the CBT to work part of the time in listen only mode. When in normal mode, it just freaked out everything else on the bus. Light flash, door locks won't work, visit workshop message in dash. As you found, once CBT is removed the MB bus clears and recovers.
I'd love to work on collecting data further, but first need to get someone with more skills to write specific config for the CBT that's tested to work in the MB bus....
I just got myself a second hand CANBus Triple for use in a 2003 CL55. After reading this thread, seems like I've made a mistake. Did either of you make any further progress? The thought of all the electrics going mad warns me to just leave it alone...
I haven't had much time on it just yet, will splice into some CAN networks tomorrow!
I replied to your question about the 29bit firmware in the other topic. I've been focused on another GM model and not messed with the Benz in a few weeks. I think it's a voltage issue on that bus, it's not normal. Also I think some of the VW users may be able to help further since some models may share that bus configuration with MB...