Serial Commands
  • 0
  • Has anyone had luck sending Serial Commands? What exactly are you typing into the serial monitor?
    According to http://docs.canb.us/firmware/api.html the command and sub command for print debug are 0x01 0x01. But what do I have to type to send that command?

  • 0
  • With a little help from Derek I realised you need to be sending the commands as hex values, not ASCII strings. The Arduino Serial Monitor doesn't provide that functionality.

    Depending on what platform you're running you need to download a suitable Serial Terminal client - I'm on OS X and am using CoolTerm to send the HEX strings.

  • 0
  • ahhhhhh. Ok. Makes sense. Thanks.

  • 0
  • administrators

    Yep, you want to send actual bytes in hex. Ascii will be converted, so if you sent it in ascii you're really sending 0x30313031 and that's not a valid command.

    I know it's pretty low level but that's the fastest way to move the data over BT LE and it's easy for the MCU to process. Last night I updated the getting started page with more info:
    <a href="https://canb.us/getting-started">https://canb.us/getting-started</a>

    By default the CBT will not dump packets, you have to tell it which bus, and an optional filter. So to dump all packets on Bus 1 you would send:
    0x03030300000000

    A breakdown of that command
    03 is bus logging command prefix
    01 is bus 1
    01 is enable (00 to disable)
    and the remaining two 16 byte flags are to filter for a specific message id, leave them at 0 to dump everything.
    0x03 0x01 0x01 0x0000 0x0000

    The app has all these commands built in so you can just see a log of all the packets in chronological or combined formats. I'm working on finishing that up asap! :)

  • 0
  • administrators

    I might add the firmware on the device out of the box is locked at 125kbps unless you load up ardunio and change it, then write the new code to the CBT.

    I'm working on auto baud rate detection so that you will be able to send a command and it will find the baud rate, then save the baud rate in EEPROM so it persists. Should have this done soon.

  • 0
  • Awesome Derek thanks. Just wanted to point out a small typo...
    On the getting started page it says:

    Connect to your CBT Serial port and you're ready to send commands.

    Send 0x0101 to get general device information.
    Send 0x011001 to get CAN Bus 1 information.
    Send 0x011001 to get CAN Bus 2 information.
    Send 0x011001 to get CAN Bus 3 information

    When it should say:

    Send 0x011001 to get CAN Bus 1 information.
    Send 0x011002 to get CAN Bus 2 information.
    Send 0x011003 to get CAN Bus 3 information

  • 0
  • administrators

    I had 0x011001 in each entry, missed changing the bus id in the command

  • 0
  • I'm getting problems if getting out of sync. I have started with a little Tcl script to control CANbus Triple.
    It works so far, e.g. I can ask for the version sending two bytes \x01\x01 . But when I get out of this sequence, e.g. sending a byte not understood by CBT, I'm lost. The CBT is silent. I don't know how to start again the "Print System Info". Is there any protocol used or not. I mean something common in serial communication like:
    "STX command data ETX"
    with special coding for STX -Start Of Text and End Of Text.

  • 0
  • administrators

    It reads the entire buffer in one shot, and some more advanced commands wait for additional input. This could probably be improved upon.

  • 0
  • I can send commands as described above using Coolterm on a Mac with the expected result. When I connect the Canbus triple to the ODBII port in my car (Volvo XC70, 2005) I don't see any logging data after sending the command to log data, I tried Bus 1, 2 and 3. Any hints? Is this perhaps the baud rate problem which will be fixed by autodetection?

  • 0
  • Try issuing the bus debug command - 0x01 0x10 0x01 (for bus 1).

    Trial and error suggests that Status = B is the error state for incorrect baud rate. Status = 0 seems to imply no electrical connection (ie no activity on the bus if it's connected correctly), and Status = 1 is for connected.

  • 0
  • Now that I am using cool term I have no problem sending commands. Occasionally the CBT will get pissed off but I have been able to narrow it down and I'm pretty sure it was caused by the bus power cycling even though it has power from the usb.

    If you are looking for an easy way to dump decoded id's and messages you can add this code snippet to each of the IF statements that checks for a full RX buffer in the readBus() function.

    <code>
    Serial.print("busId: ");
    Serial.print(msg.busId);
    Serial.print(" BusStat: ");
    Serial.print(msg.busStatus);
    Serial.print(" FrameId: ");
    Serial.print(msg.frame_id, HEX);
    Serial.print(" msgLen: ");
    Serial.print(msg.length);
    Serial.print(" Msg: ");
    for(int i=0;i<msg.length;i++){
    Serial.print(msg.frame_data[i], HEX);
    Serial.print(".");
    }
    Serial.println();
    </code>

    This is not the best way to go about this but it is quick and dirty. Its just a bunch of print statements. You can paste it in right after the line readQueue.push(msg);

    I don't know how this will function if you are using bluetooth but for quick and dirty dumping of formatted id's and messages it works.

    after pasting it in, your readBus function will look something like this:

    <code>
    void readBus( CANBus bus ){
    // Abort if readQueue is full
    if( readQueue.isFull() ) return;

    rx_status = bus.readStatus();

    // Check buffer RX0
    if( (rx_status & 0x1) == 0x1 ){
    Message msg;
    msg.busStatus = rx_status;
    msg.busId = bus.busId;
    bus.readDATA_ff_0( &msg.length, msg.frame_data, &msg.frame_id );
    readQueue.push(msg);
    Serial.print("busId: ");
    Serial.print(msg.busId);
    Serial.print(" BusStat: ");
    Serial.print(msg.busStatus);
    Serial.print(" FrameId: ");
    Serial.print(msg.frame_id, HEX);
    Serial.print(" msgLen: ");
    Serial.print(msg.length);
    Serial.print(" Msg: ");
    for(int i=0;i<msg.length;i++){
    Serial.print(msg.frame_data[i], HEX);
    Serial.print(".");
    }
    Serial.println();
    }

    // Abort if readQueue is full
    if( readQueue.isFull() ) return;

    // Check buffer RX1
    if( (rx_status & 0x2) == 0x2 ) {
    Message msg;
    msg.busStatus = rx_status;
    msg.busId = bus.busId;
    bus.readDATA_ff_1( &msg.length, msg.frame_data, &msg.frame_id );
    readQueue.push(msg);
    Serial.print("busId: ");
    Serial.print(msg.busId);
    Serial.print(" BusStat: ");
    Serial.print(msg.busStatus);
    Serial.print(" FrameId: ");
    Serial.print(msg.frame_id, HEX);
    Serial.print(" msgLen: ");
    Serial.print(msg.length);
    Serial.print(" Msg: ");
    for(int i=0;i<msg.length;i++){
    Serial.print(msg.frame_data[i]);
    Serial.print(".");
    }
    Serial.println();
    }

    }</code>

  • 0
  • I still have problems understanding the serial command syntax
    http://docs.canb.us/firmware/api.html says

    Send CAN Packet

    Send a CAN Packet over the specified Bus. Bus Id should be 1 through 3
    Command Bus Id Message ID Data Length
    0x02 01 290 00 00 00 00 00 00 00 00 8

    • are all the values hex values? the command in the example is given as 0x02
    • what about the "Message Id" ?, how many byte do I have to send for it? the base frame is 11 bit, that means in hex Its up to 0x7ff - 3 bytes. Do I have to send always three bytes, ebven if Message Id is zero or 1? What about extended frame id with 29bit, which is common in cars.
    • next is data, always eight bytes?
    • last but not least, what is "Length"? Has it to follow the data? As value in hex?

    <b>Summary</b>- Sending a CAN frame (as of now) is a sequence of always 14 bytes, is it?

  • 0
  • Derek
    <i>and the remaining two 16 byte flags are to filter for a specific message id, leave them at 0 to dump everything.
    0x03 0x01 0x01 0x0000 0x0000</i>

    I think you mean <b>the remaining two 16 bit flags</b>, do you? and the command is seven bytes

  • 0
  • administrators

    Hey Heinz,

    You're correct, thanks. I have to write a lot of this stuff late at night when I'm tired after work. And I'm moving as fast as I can now and make mistakes so thank you for pointing that out!

    And yes to your previous post, sending a frame is always 14 bytes.

  • 0
  • administrators

    Also, as of right now the firmware does not support 29 bit message ids. But the hardware does, it's just a matter of implementing that in the code eventually.

  • 0
  • I know that the mcp2515 supports 29bit. It was not clear von the docs if 29bit frame id is implemented or not or not documented.

    Derek, what is your opinion about setting up a wiki where we all can contribute and help.

  • 0
  • @henk_kuipers‌ I read that Volvo is a bit special in the CANBUS and needs a signal from the K-line to keep awake if you try to access the CANBUS over OBDII. I tried on my V70 and had the samen problem, no data at all. There seems to be the option of connecting to CANBUS direct elsewhere but I don't know enough about Volvo to know where.

    Hope to have an other make car this weekend to test the CBT on that one.

  • 0
  • <a href="http://forum.canb.us/profile/254/Xag">@Xag </a> Thanks, that is very useful information. I am already using a proprietary Canbus Function Extender so I should be able to figure out the direct connection to the Canbus. Will post an update when I make some progress.

  • 61
    Posts
  • 20915
    Views
  • Log in to reply