My first build: CAN-Bus and GPS through Bluetooth LE

13»

Comments

  • Oh BTW, the ItsyBitsy is awesome!
    This is how small my whole build is now: https://i.imgur.com/1BNYfff.jpg (5x5 mm cells in the background for scale).

    All the wiring is done on the mini breadboard by just a few jumper wires from this kit: https://www.sparkfun.com/products/124
    and is hidden under the ItsyBitsy and the MCP breakout.
  • Figured out a few more things, and here's my first version on GitHub!
    https://github.com/timurrrr/RaceChronoDiyBleDevice

    As you may notice, instead of respecting the "update interval" requested by Arduino, I instead send every Nth message (where N is different for different PIDs). I've observed more stable refresh rates this way, and it makes more sense to me. You might consider changing the RaceChrono DIY BLE protocol to do something like that too.
  • I guess the "update interval" can just be ignored, no protocol changes needed for this. I will refine and fix the device example once I get around to it again, using your experiences and advice posted here!
  • After spending a significant amount of time playing with parameters, writing stress tests, and talking to my more experienced Arduino DIYers, I'm pretty certain that we should power the MCP via regulated 3.3V, not via unregulated USB. Since the voltage on the "USB" pin is not regulated, when nRF is sending data and needs a lot of power, it can cause so much crap on the USB (and thus on VCC of the MCP) that the MCP sends/receives jibberish over SPI or can stop responding altogether.
    On my stress test MCP receives garbage and goes unconscious in just a matter of seconds if VCC is connected to USB; and it works with no issues when VCC is connected to a 3(.3)V pin.

    You might consider updating the wiki in your Github project accordingly.
  • aolaol
    edited September 4
    I'm powering the whole thing through the USB-pin, not only the MCP board, but also the Adafruit nRF board. So I'm not using the USB-pin as power output, but as an input.

    My build has a separate 12=>5 V regulator/step-down. The regulator built-in to the nRF board is not used for anything.

    As long as the voltage regulator/step-down is good enough I don't think the voltage is going to dip? I'm nowhere near expert on this, but this what I've figured out... My MCP board refuses to work at 3.3V and the input is clearly marked as 5V.
  • Yeah if you're using another regulator when stepping down from 12V to 5V you're probably fine (I'm no expert either) but if someone's getting 5V directly from USB (as your wiki suggests as an option), looks like they should use a regulator.

    I just noticed your wiki says "The 3.3 V outputs are not sufficient, as the board requires 5 V." which contradicts my experience. What's the source for this sentence? The MCP2515 datasheet says it can take as low as 2.7 V.

  • Yeah regulated power is probably a good idea for digital communications circuits. It also depends on max current/power the regulator can support. Generally power supplies should have bypass capacitors to support current spikes due to digital signaling if they don’t exist somewhere on the circuit board. I haven’t taken too close a look at the circuit.
  • edited September 14
    I’m a little confused by the tutorial. Does racechrono on iOS support the DIY device link over BLE? What’s the bandwidth limit on BLE?

    What’s the pairing process like with the DIY BLE on iOS? Is there any danger that someone can highjack the link or is safe because the DIY interface is transmit only? (I’m concerned with the security of off the shelf BLE OBD interfaces because there doesn’t seem to be any kind of pairing process so I’m considering the DIY route. I’m also concerned that nearby cars in grid can interfere with the connection process making it unreliable.)

    Can the DIY device replace the OBDII interface, reading standard OBD PIDs off the CAN?

    The CAN signals are on the ODB connector right? So I can just tap them off to run into the MCP2515?

    OBD is a polling scheme (request/response) whereas CAN is essentially broadcast it seems? Is it typical that ECUs are just continuously writing their data at some fixed rate to CAN?

    How do you go about reverse engineering the CAN messages? Do you need a logger than can read all the messages at full rate or is the DIY hardware sufficient? If the source is too fast for the link, just pick some random PID at a time and rate limit?
  • > Can the DIY device replace the OBDII interface, reading standard OBD PIDs off the CAN?

    I believe you can make OBD requests via the CAN bus on most modern vehicles.

    > The CAN signals are on the ODB connector right?
    > So I can just tap them off to run into the MCP2515?

    I guess that depends on the vehicle, but for most modern ones yes.
    On some vehicles you might find other ways to get the CAN signals, e.g. on BRZ/86s there's a hidden connector with the CAN pins available:
    https://github.com/timurrrr/RaceChronoDiyBleDevice/blob/master/can_db/ft86.md#connections

    > OBD is a polling scheme (request/response) whereas CAN is essentially broadcast it seems?

    Yup. I believe you can still poll data on the CAN bus (RTR messages?), but I believe it's generally not efficient.

    > Is it typical that ECUs are just continuously writing their data at some fixed rate to CAN?

    I believe so. Might not be true for one-off kinds of messages, e.g. when enabling turn signals.

    > How do you go about reverse engineering the CAN messages?
    > Do you need a logger than can read all the messages at full rate or is the DIY hardware sufficient?
    > If the source is too fast for the link, just pick some random PID at a time and rate limit?

    Those are some good options. You might be able to find some existing info on the internet.

    Other things I've done is creating artificial "Analog 1", "Analog 2", etc. channels in RaceChrono for individual bytes of various PIDs I was interested in (e.g. the most frequent ones*), capturing some of my everyday drives, then cross-referencing the data with the map, and trying to remember what I was doing.
    You'll soon develop a good sense of which bytes provide analog/continuous values and which are bitsets/flags; how to detect signed vs unsigned encoding, and cases when you need to decode a multibyte value instead of separate byte-sized values.

    * — you might find this Arduino sketch useful:
    https://github.com/timurrrr/arduino-CAN/blob/master/examples/PidHistogram/PidHistogram.ino
  • aolaol
    edited September 14
    Q: Does racechrono on iOS support the DIY device link over BLE?
    Yes.

    Q: What’s the bandwidth limit on BLE?
    It's quite low, but you'll achieve something like 60 messages per second with this setup.

    Q: What’s the pairing process like with the DIY BLE on iOS? Is there any danger that someone can highjack the link or is safe because the DIY interface is transmit only? (I’m concerned with the security of off the shelf BLE OBD interfaces because there doesn’t seem to be any kind of pairing process so I’m considering the DIY route. I’m also concerned that nearby cars in grid can interfere with the connection process making it unreliable.)
    There's no pairing in iOS, and the devices are connected by matching them by name. For OBD-II it may be a security vulnerability of some level, but this DIY device is a "read-only" device, so there's no threat (unless the device can somehow be hacked to do something beyond the API functionality). So only threat is that someone reads your coolant temperature...

    Q: Can the DIY device replace the OBDII interface, reading standard OBD PIDs off the CAN?
    It easily could if you did some more programming. With my code it doesn't.

    Q: The CAN signals are on the ODB connector right? So I can just tap them off to run into the MCP2515?
    OBD-II protocol "runs over" the CAN-Bus.

    Q: OBD is a polling scheme (request/response) whereas CAN is essentially broadcast it seems? Is it typical that ECUs are just continuously writing their data at some fixed rate to CAN?
    As said before, OBD-II protocol "runs over" the CAN-Bus. So CAN-Bus can do all the request/response pairs if needed as well. But usually you're interested in the messages that the ECUs are "broadcasting" with fixed rate.

    Q: How do you go about reverse engineering the CAN messages? Do you need a logger than can read all the messages at full rate or is the DIY hardware sufficient? If the source is too fast for the link, just pick some random PID at a time and rate limit?
    You can start from something as easy as accelerator pedal position. Just manipulate the pedal between fully depressed and not depressed at all. See which byte changes accordingly on each position change. It gets much more complicated for values that cannot be easily manipulated, but you get the idea.


  • > Q: What’s the bandwidth limit on BLE?
    > It's quite low, but you'll achieve something like 60 messages per second with this setup.

    Are you talking about iOS specifically, or BLE in general?
  • aolaol
    edited September 15
    @timurrrr talking specifically about this DIY build. It achieves pretty much same update rate on both OS. I know you can reach substantial bandwidths with proper hardware and software.
  • edited September 16
    I see. In my real-world testing I'm consistently getting ~100 messages per second with my build
    https://github.com/timurrrr/RaceChronoDiyBleDevice
Sign In or Register to comment.