i have put some data into a spreadsheet to compare functions such as LOCK-UNLOCK, VOLUMEUP-VOLUMEDOWN.
you can see it here <a href="">bit.ly/canbus1</a>

This is LOCK data:
Message ID Data
581 1 0 FF FF FF FF FF FF i am assuming that to try this , that i would have to change it to
0581 01 00 FF FF FF FF FF FF and then

Command Bus Id Message ID Data Length
02 01 0581 0100FFFFFFFFFFFF 8

You seem to be progressing fast Alan. Curious how you analyzed so fast these are the mentioned command. Mind sharing that?

As for sending commands, you have to include for which module the command is intended so it knows it has to do something.

XAG
the vehicle was idle and producing no data. The data that you see on the excel sheet is from one press of one button. When it has stopped, I save it and then clear it and try the next button press. One button press produces 1941 lines of data for LOCK and 1975 for UNLOCK.
The buttons that i tried are buttons that produce data without the key being turned to the on position, the vehicle is in a timed shutdown mode. I can get a response from a button press and export it as text file from coolterm and then import to excel. I'm trying to compare data that is likely on the same module, such as vol up-down, lock-unlock, mirror adjustments. Windows up and down does not produce any data, interesting as they do operate, maybe they are not controlled by a module. There is too much data right now for me to analyze if the ignition is turned to the on position. Im trying to send a successful command before i move on. I really need to figure out what each modules message ID is.
in this piece of data, "581 1 0 FF FF FF FF FF FF " my message id or module is 0581 i assume.

Vehicle Type: 2013 Ford F150

Thanks Alan! The problem is that my car doesn't use the CANbus for these kind of things so I need to find what is being send over the line.

after reading the approach that amesatfish took, <a href="http://forum.canb.us/discussion/91/identifying-steering-wheel-button-packets-an-example#latest">forum.canb.us/discussion/91/identifying-steering-wheel-button-packets-an-example#latest</a> i think that i am missing the packet length in my data. I need to change how i format my data to include the length of the data stream so that i have the correct format when i want to inject packets, (Command -Bus Id-Message ID - Data - Length). Hopefully will get a chance to explore this tomorrow.

It might help if you ignored the upper few bits so that "A" could be used instead of 0x01, "B" for 0x02, etc.

Derek, would it be possible to get a link to the list of bus codes like status and errors? IE:

{"e":"busdgb", "name":"Bus 2", "canctrl":"7", "status":"14", "error":"B", "nextTxBuffer":"2"}
{"e":"busdgb", "name":"Bus 3", "canctrl":"7", "status":"0", "error":"B", "nextTxBuffer":"0"}

I'm connecting bus 2 and 3 to separated CAN-B & C networks and getting some strange errors on other network devices. I know the "B" is for baud error, tried both 500 and 125 but same issues.

I believe the latest version of the software has auto baud detection. Also, error "B" is actually the hex value for one of the MCP2515 registries (buffer maybe - I forget off the top of my head). I think the latest code on GitHub has both auto baud detection and some more descriptive error definition so updating might solve some of your errors.

Ok thanks I'll go DL the latest copy. I haven't had much luck previously with auto baud detection, and was setting it manually.

Figured out my current baud conflicts. On the Mercedes W211 CAN-B "interior" is 83kb while CAN-C "powertrain" is 500kb. CAN-D "DLC-16 plug" is 500kb also, but it only passes formatted diagnostic commands to/from the others through a gateway. So I jacked into the B & C hubs directly. But setup the CBT baud wrong, and it freaks out other connected modules. Scary...

Will start a new topic with some useful Benz hacking notes I've collected.

I pushed an update to the github repo with improved baud rate setup and auto rate detection! I still need to update the docs.

<b>New baud rate config code</b>
It allows you to use any baud rate on the can bus. If you tell it to use 381 that's what it will try to do. Before it had fixed settings you could run 10,20,50,125,250,500,1000.

Serial api command: 0x0109NNXXXX (NN is bus id, XXXX 16bit integer representing speed, up to 1000)

Example: Set bus 1 to 500kbps.
Decimal 500 = Hex 0x1F4

So send: 0x01090101F4

Also, changes are written to eeprom so they are persisted through a reboot or power loss.

<b>Auto Baud</b>
Also, if your CBT is connected to a CAN bus you can send a command to auto detect baud rate.
Serial api command: 0x0108X (X being the bus, 01 - 03)

So to find the baud of bus 1 send 0x010801 and the CBT will send back JSON data as it tries each speed (speeds are hard coded at the moment)

If a speed is detected it's written to the eeprom settings and persisted through a reboot or power loss.

Make sure you update to the new code (0.4.2) to use this functionality. <a href="https://github.com/CANBus-Triple/CANBus-Triple">https://github.com/CANBus-Triple/CANBus-Triple</a>

I'm working on the mobile / desktop app still which will make logging easier.

I'm sure the example should be:
<blockquote>Example: Set bus 1 to 500kbps.
Decimal 500 = Hex 0x1E4
So send: 0x01090101E4</blockquote>

But, by the way. Not every value can be possible. What happens in case the bit rate, eg. 520Kbit/s, can not be set?

The term "baud rate" is not correct and never used in CAN. Better say "bit"rate" (If you like, check Wikipedia for the term "baud".

I'm getting a similar result as alan had, receiving "ÿ" with 030101. What was the fix there ?

Bit of background info...
01 10 01:
{"e":"busdgb", "name":"Bus 1", "canctrl":"4", "status":"0", "error":"0 - No Errors", "nextTxBuffer":"0"}

Checked wiring, looks good. Using the supplied OBD cable. On a 2013 Jeep Wrangler.

@Derek I installed the new code and tried the baudrate detection, works great on my High Speed Can connection and helps me in my quest to get the data logging on Low Speed Can working!

Yes the new autobaud code does work pretty nicely. Tested successfully on two OBD-II ports. The changes to the bus status outputs are also helpful. But I'm still fighting an error message connecting to the 2005 Mercedes CAN B network. Have even tied manual settings, but same error. Looking at the MCP2515 documents, looks to be taking errors on the transceiver. Any thoughts?

{"e":"busdgb", "name":"Bus 3", "canctrl":"7", "status":"0", "error":"1011"
"Receive Error Warning - TEC or REC >= 96",
"Receive Error Warning - REC >= 96",
"Receive Error Warning - REC >= 128", "nextTxBuffer":"0"}

Hmm, KidTurbo, looks we are facing similar problems, when checking the status of Bus 1 on my 2005 Volvo XC70, I now see:
{"e":"busdgb", "name":"Bus 1", "canctrl":"4", "status":"0", "error":"1011"
"Receive Error Warning - TEC or REC >= 96",
"Receive Error Warning - REC >= 96",
"Receive Error Warning - REC >= 128", "nextTxBuffer":"0"}
What I did:
This time I only connected CBT wire 4 (yellow, CAN1 LOW ) to the CAN low wire of my car (white cable) and CBT wire 3 (orange, CAN1 HIGH)) to CAN high wire of my car (white). I now used connectors, no soldering anymore. The white and green twisted cabling in my car is very clearly the CAN wiring according to the diagram. The CBT is connected to the USB port of the laptop and I used CoolTerm to send commands. I receive no response when I send other commands like the start logging on Bus 1 command or discovering the bitrate. Sending the device info command gives a normal response.
I am wondering if I am still facing wiring problems or if this is something else.....

Hey wow! I tried again: the only difference was that I first connected all the wiring and after that I connected the CBT to the USB of my laptop so it powered up. Now I could finally log data on the low speed CAN bus :D
I probably caused the Canbus errors because I plugged/unplugged a wire while the CBT was already running, I can imagine that it is not a good idea to do that...

I'll give that a try. Was reading on the 2515 transceiver regarding those errors and effect. It seems we may need a way to reset it when that occurs.
If I am reading correctly, when the error limit is reached, it pulls the transceiver off line. If in normal mode, it needs to be told to reset. If in <u>listen only</u> mode, it ignores errors and continues to pass all packets. Is probably why I did see data streaming one time after a usb reset. Hopefully someone experience can clarify how this should be handled.

henk_kuipers , your approach did help with connection issues I was seeing on the Benz CAN B & C bus. I've still been fighting errors, and noticed that the other units on the bus will actually change baud rate, shut down, or switch to single wire mode if the CBT doesn't sync up. But am able to record some data off each and working to isolate the error cause. Also haven't noticed this problem on the OBD-II port, where a interface gateway isolates the other networks.

Hi KidTurbo, good to read it helped you somewhat. Good luck with the rest of the puzzle!