Autobaud not always returning correct speed
  • 0
  • I was trying out autobaud today, and the first time I ran it (LS can), it returned 125 baud rate (which is correct). After trying to send a frame (and probably messing something up while sending a frame) I got some errors. I tried autobaud again, and it set the speed to 1000. I'm not sure what other info to include, but I thought I'd raise the issue in case other people run into the same thing.

    I'd be happy if someone can point out that it is user error. ;)

  • 0
  • I've notices that depending on the vehicle year/model, the BUS speed may change up or down (typically down) based on transceiver error rate. I use 0109NN "bus ID" to verify CBT baud rate at any instance. If I run autobaud command, 0108NN multiple times, it often lowers the rate from the last. This mismatch can also then cause errors, and once you see the REC>=128 message below, you typically have to disconnect CBT an start over again. At least this is my experience.

    {"e":"busdgb", "name":"Bus 2", "canctrl":"7", "status":"0", "error":"1001011"
    "Receive Error Warning - TEC or REC >= 96",
    "Receive Error Warning - REC >= 96",
    "Receive Error Warning - REC >= 128",
    "Receive Buffer 0 Overflow", "nextTxBuffer":"0"}
    {'e':'baud', 'bus':2, 'rate':500}

    Is there a command to reset or reload the BUS transceiver chips? Would avoid power cycling the CBT.

  • 0
  • administrators

    You can send a reset command 0x0116 but this will reset into the bootloader, then start the main code after 8 sec and reset/setup each can controller again.

  • 0
  • Thanks Derek I will give that a try.

    Further testing on this particular bus, along with some outside reading has me thinking its possibly a clocking crystal manufacture mismatch causing slight baud differences, or a possible issue related to Extended Frame packets. What I have read on other forums points to this, or ACK messages being sent from the CBT and the CAN-B command unit saying "hey what are you doing on my network?" Mercedes documents state this bus speed should be running at 83k, however I've see the CBT briefly receive data while setting at 125.

    When this Rec Error Warning happens, the whole bus sometimes freaks out and sets hard trouble codes I can read with a scan tool. Some nodes have even shut down completely until the CBT is removed from the network and the bus goes to sleep and wakes up again.
    <i>
    Is it hard to modify the existing code so a transceiver operates in "Listen Only" mode?

    How well does the CBT code handled Extended Frame packets?</i>

    Those may be my best approach to sort this out . There is 3 separate canbus networks on this car, the other two I have no issues working with.

    Tks

  • 0
  • Hi Derek quick question regarding the CBT and <b>Baud Rate 83kbps</b>. I am seeing specific problems on an 83k bus and feel this may be the answer.
    I see where someone posted this message below to you on github about the correct settings for 83.3kbps.

    <i>i use this in my jeep. works perfectly. made a pull to seeduino code.
    +#define MCP_16MHz_83k3BPS_CFG1 (0x03)
    +#define MCP_16MHz_83k3BPS_CFG2 (0xBE)
    +#define MCP_16MHz_83k3BPS_CFG3 (0x07)</i>

    When I look at their rep, they've updated it under CAN_BUS_SHIELD files<b> mcp_can_dfs.h</b>

    While I didn't see that exact file included with the CBT Master set, I did find this <b>Case83</b> setting and comment in the CANbus.cpp file.

    <i>case 83:
    // TODO
    config0 = 0x00;
    config1 = 0x00;
    config2 = 0x00;
    break;
    </i>

    Along with that, there is no reference to Baud 83 in the included CANbus.h file. So just wondering if I am missing something that is in another location?? I know very little JAVA, so please point me in the right direction..

    Looks like he also found the correct settings to identify extended flags, which I believe you were working towards.

    TKS

  • 0
  • Believe I isolated my issue tonight to a bad solder connection on the CBT leads to the CAN-B 83kbps network. Using an oscilloscope I was able to see overlapping pulse signals. Compared to a good 500kbps bus connection signal it was obvious.
    What's funny is that because I used twisted pairs on my CBT leads, both CH on the oscilloscope actually showed a partial pulse signal.. Reason I could record some short data bursts. But a simple ohm test between CAN high and low leads [<i>with key off</i>] showed an open circuit. Duh...
    I'll fix the connection and verify the 83.3kbps settings this week.

  • 0
  • administrators

    Awesome, glad you narrowed it down.

    The new baud rate code actually calculates the settings on the fly so you won't see 83.3 listed anywhere. The problem is i'm not sure the code will work with a float. I'll have to figure that out.

  • 7
    Posts
  • 1584
    Views
  • Log in to reply