Arduino Due

If you want to hook up an Arduino Due to your CAN-bus and use it with CanZE, you need the following things:

  • an Arduino Due or Taijuino (of course!)
  • a CAN tranceiver
  • a Bluetooth tranceiver
  • a SAE J1962 connector

The wiring scheme has to be done like this:DueI personnaly use a SN65HVD230 transceiver and a HC-06 Bluetooth module:

BobDue

 

When starting to sniff the CAN-bus, I used a CanDIV shield hooked up to an Arduino Leonardo, but the chip on this shield as well as the Arduino Leonardo were both not fast enough to handle Zoe’s 1600 frames per second. But, the CanDIY shield had nicely mounted RJ45 connectors … and that’s the reason why I left it there, but disconnected the circuit.

The 10uF capacitor you see on the image make sure the Arduino Due is being reset properly on each power up. As a matter of fact I run into the problem that when power was applied, it did not start as expected. This is an old but still very effective hack to trigger a reset when power is being applied.

The actual firmware is here:

https://github.com/fesch/CanZE.ArduinoDue

Please note, that catching free-frames works fine, but the request-response ISO-TP frame do not get always an answer and thus timeout quite often.

Dependent library:

17 comments on “Arduino Due
  1. Borut says:

    Hello
    Do you have a firmware for arduino due

  2. wiebel says:

    The following may be of interest, also supplying, this “generous amount of storage”.

    https://oshpark.com/shared_projects/VeJFD9qA

  3. igor says:

    Hi there…
    is it possible to use the due to read the vehicle speed pid , and see it through serial monitor?
    if it is possible what changes do i have to make in the sketch for that?(I’m kind of noob in all obd arduino stuff)

    Thank you very much.

    • Bob Fisch says:

      Yes, that is possible.

      Just insert an IF-statement on the PID you need, then do something with it.

      • Igor says:

        Sorry for the noob question…
        But where do I insert it and how
        Thanks

        • Bob Fisch says:

          in the loop() method …

          • Igor says:

            Still can’t get it :/
            I know it’s too much to ask,
            But could you post a printscreen with of the modified sketch, or send it to my email?

            I would really appreciate it..
            Thanks

          • Bob Fisch says:

            Please go to the method “loop()” (there is only one) and add the code in order to intercept a given PID (code: if (your condition goes where) { Serial.println(‘This will be written to the serial line …’); }).

            If you never wrote a line of code, please start with simpler things. This is not a tutorial on how to lean coding …

            Sorry.

          • Igor says:

            Ok, I’ll try that,
            Thank you very much for the help 🙂

  4. ZoeDoktor says:

    It may be helpful: In a factory-new Bluetooth (BT) HC-06 element the Baud Rate has to be reset to the fast one CanZE uses (BT_SPEED ~ 1.3 MegaBAUD). Default is 9.6 Kilobaud fot the HC-06. After setting the new rate, the HC-06 remembers it, even after power off.

    I needed two days of testing to understand why my Samsung Android could not receive any data, despite established BT connection.

    So adding a few primitive lines at the start of the Arduino programme (sketch), immediately at the beginning of the “void setup ( )…. “, structure helped.

    See code. Add it immediately following the “void setup ()” line in the existing “CanZE.ArduinoDue.ino” programm file.
    ——————–

    // establish BT connection first with the HC-06 breakout
    // initialise the BT connection, it is said that the Baudrate must be set very quickly, within 1 sec of powerering up
    #ifdef USE_BT
    // default speed
    Bluetooth.begin(9600); // if the HC-06 is “new” and at default “factory settings”
    // now code for BT highest speed at BT_SPEED
    Bluetooth.print(“AT+BAUDC”);
    delay(1500);
    Bluetooth.begin(BT_SPEED);
    #endif

    ———————-
    Resetting the Arduino DUE once again after power up, during the already established BT connection with the Samsung, also helped.

    Additionally I found that providing 5V power to the HC-06, instead of 3.3V improved the reliability of the it´s signals.
    It is also practical, as the Arduino DUE has one 5V and another 3.3 V power supply pin. 5V power the BT, 3.3V the CAN Transceiver.

  5. Victor Iriciuc says:

    Greetings,

    I’ve been trying to get my head around this and I don’t seem to understand something. Considering an extended CAN frame with maximum number of data bytes( “worst” case scenario) you would get a 128 bits long message. Multiplying that by 1.600( given number of frames as you describe it) you would get a baudrate of 204.800. Of course this is not a real baudrate, so, for purpose of also implying bit stuffing and acknowledge times, let’s say that a baudrate of 500kbps would be MORE than enough.

    I’ve managed to build a CAN shield for a Arduino Uno using a Microchip pair, more precisely MCP2515 and MCP2551, which can handle 500kbps quite well. Maybe I’m missing something over here, but why are you stating that this solution would not be fast enough for the Zoe, and only the Arduino DUE can do it.

    p.s. I am only trying to find the cheapest and also good enough (efficient) solution here.

    Thank you in advance!

    Respectfully,
    V.A.Iriciuc

    • Bob Fisch says:

      The micro processor of a simple Arduino is not fast enough to handle that many frames per second, but the Due is 😉

      • Victor Iriciuc says:

        Can you be more specific? I know that the Due has an ARM and it is obviously more superior to an Atmega, but as long as you obtain the desired baudrate with an Atmega, why wouldn’t it be good enough to process the messages? Maybe your solution didn’t work because you set the CAN controller to work in a normal mode…but there’s also a listening mode, where it doesn’t send reply’s or acknowledges. Any ideas on this approach?
        I would test everything myself, but I do not possess a Zoe, therefore it’s all an imaginative theory based process for me. Also, what oscillator did you use for the controller? As I can see from the image, you also had the Microchip pair, but not sure whether it was 2515 or 2510. I think I can see a quartz over there, but again, not very clear. It can be 4MHz, 8MHz or 16MHz.

        • Bob Fisch says:

          I’ve tested with the CanDIY shield using an Arduino Leonardo and captured about <1200 frames per second. I used the same shield on the Arduino Duo and captured >1600 frames per second. So all this is based on real life testing, not on any calculations. Having the car in the same state and using the same CAN controller & transceiver, different boards gave different result. So I conclude that the power of the processing units does play a role.

          • Victor Iriciuc says:

            Ok, I understand now. Given this information, I suppose it would be possible to just sniff for certain data, given your source code which hopefully targets specific ID’s and decodes accordingly. I believe that one frame is one parameter right? In this case, maybe it wouldn’t even be of interest to sniff all of them. But if a parameter is ultimately constructed by using data provided by two different frames, then this would be a problem.
            Just to make things clear, I am working on a personal project and I’m trying to make use of your work which, btw, is amazing. But I will not make use of the mobile app, so I’m just trying to understand if by simply using your decoding for certain messages, an inferior controller (Atmega) would enable me to sniff exactly those frames.
            Also regarding what you stated, I do have a Uno and also a Due, but then again, no Zoe for testing. I will try to simulate the car’s behavior using the Due( >1600 frames) and tweak with the library on the Uno, and maybe get the desired results.
            Not sure how much this is of interest to you, but I will keep you posted. Thank you!

          • Bob Fisch says:

            Free frames are always composed of a data segment with a given unique PID. Only the request-response based ISO-TP frames are composed of multiple data segments.
            This means that all free frames with the same PID contain the same fields (the data may be different as each field denotes different states, like e.g. a door can be open or closed).

Leave a Reply