Shipment Update:

Good news: so far, the main processor is still on track for the manufacturing of the next batch of CANFDuinos, which should arrive this month. All other components are in-hand (with a slight chip package redesign for RS-232 interface) and therefore, we are still on track for shipping products to customers in October.

Field Update:

CAN/OBD2 data over Bluetooth

For this field update, we are going to show you how the CANFDuino can be easily customized for your application by using the PCB prototyping area. Particularly, we received a variety of inquiries about adding wireless communications to the CANFDuino including WiFi, cellular, and Bluetooth. Let’s look at how you can easily add Bluetooth hardware to your PCB area with just a handful of connections.

Adding hardware

There are a few main things to consider when selecting hardware to add to your CANFDuino, these include: operating voltage for the hardware, operating current for the hardware, communications method to the processor, and the communication voltage levels for the processor.

Digital integrated circuits operate at two voltages, 3.3 V or 5 V. This is why you will see both options available on the CANDFduino prototyping space, highlighted by the white silkscreen areas where the small rectangle on the left is the 5 V area, and the long strip at the top of the "breadboard" area is 3.3 V. When connecting to these areas, it is important to understand the current draw of the device versus the amount of current that is available.

Operating Voltage & Current

For the 5 V area, the CANFDuino takes current supply directly from the 5 V power rail provided by the USB input, which means the limitations are set by the USB "source" side as well as the trace sizes on the PCB and connectors. For practical purposes, unless you are adding a high-power device such as a battery charger or high-current transistors, lets ignore the current limitations set by the copper traces and connectors themselves and assume you are connected to a PC. The current limits on a PC "host side" connection are 500 mA for USB, this is is typically plenty of current for lower-power digital devices, so in most cases any prototyping area additions to the 5 V area that are not power electronic circuits are not likely to be current limited. For the 3.3 V area, the limitation is a bit different due to the fact that our processor and a few of the other semiconductors on CANFDuino are 3.3 V devices. The 3.3 V output is supplied by an on-board regulator that takes the 5 V power from the USB connection and converts it to the 3.3 V the processor needs. The catch is, this device has a current limit that is also a function of temperature. If we again make some practical assumptions that we are operating at room temperature under a constant load, the regulators on the CANFDuino should have about 150 mA of extra current available to the prototyping area for use. So checking both the operating voltage (note: this is different than communication voltage levels) and current draw for your devices as you add them to the CANFDuino is critical to your modification. If you are uneasy about the current limits or perhaps you are wanting to power the CANFDuino from a higher voltage (12 V, 28 V) you can actually add a whole new regulator to the board with a 5 V output to supplant the USB power and then add multiple levels of voltage/current independently on the prototyping area (we’ll cover this in a future update).

Communications voltage levels or "IO" voltages

Although not obvious, chips and modules can actually have a different operating voltage vs their communication voltages sometimes referred to as "IO voltage levels". Communication voltages are important, as they are not independent of your larger circuit; that is, if you want to talk to another processor or IC, you need to be talking at the same voltage levels. Level mismatching will at best cause your circuit not to operate, and at worst will destroy one of the devices. There are also chips and modules that allow the flexibility of operating at both levels, the key to interfacing with these is finding the correct pin or connection in order to "set" the voltage level for that device. Often times, this is a pin labeled as "VIO", and feeding it 5 V or 3.3 V sets the IO levels for the rest of the pins on that device. AKA - connecting 3.3 V to a VIO pin will make the device a "3.3 V" device. CANFDuino has an ATASAMC21 main processor that is operating at 3.3 V, and therefore it is "expecting" any device it connects with to also be 3.3 V device.

Communication types

There are a multitude of embedded serial and parallel communication protocols out there, but for the prototyping area on CANFduino we are only dealing with three (ignoring CAN for a moment): SPI (serial peripheral interface), 2 wire (essentially I2C inter-integrated circuit communications) , and UART (universal asynchronous receive and transmission). The processor on the CANFDuino supports a number of all of them as defined in our hookup guide and the sample code for each can be found in our github repo. There are countless sources on these communications methods, so we won’t go into them, just know that the device(s) you choose to interface needs one and can actually share them with other peripherals.

Back to our Bluetooth device

So, lets look specially at our Bluetooth module and evaluate if it’s going to work:

Model: RN-42 Bluetooth module Supplier: Microchip via Mouser Operating Voltage: 3.3 V Operating Current: ~30 mA Interface Levels: 3.3 V Communications Interface: UART

Looks like it’s going to work, so lets get to modifying. Step 1: Land it on the prototyping space where you’ve got some room Step 2: Run power pad 11 to the 3.3 V rail on the prototyping space Step 3: Run gnd pad 1 to the ground rail on the prototyping space Step 4: With a quick look at the CANFDuino hookup guide for a spare UART, we can see that pins D10 and D11 are labeled as Rx2 and Tx2 which are "free" for prototyping as UART2. The #1 thing that people will screw up when adding UART devices: RX on our Bluetooth module must go to the TX on CANFDuino and TX on our Bluetooth module must go to the RX on our CANFDuino (opposite of a CAN bus). The notation is specific to each end of the device e.g. RX means = "i want data transmitted to me", you don’t hook up "like pins" for a UART you hook up "opposite pins". So in this case, we are wiring D10 to pad 13 and D11 to pad 14.

See the picture below showing mounting and wiring of the RN-42 to the CANFDuino (we flipped it over and used a bit of glue to keep it in place).

Worth Noting: UART and RS-232 are two terms that can be easily conflated. This is due to the fact that RS-232 communication is a type of UART, but UART does not necessarily mean it is RS-232. This is because RS-232 requires transceivers for boosting the VIO levels for communications "outside of the box off circuit board" over long distances, where UART communications between embedded chips and modules "on circuit board" can occur at very low levels (3.3 V, 5 V).

So, that wasn’t really too hard: only four connections! So let’s get on to making it do something.

Software: OBD2 over Bluetooth

Our module is on UART2, in software for the Arduino libraries this is equivalent to "Serial 2" so all we need to do is use that port in code and we’ll be transmitting our OBD2 data over Bluetooth. Luckily, we have a handy set of example code in our github repository "CANFDuino_OBD2Logger" that we can quickly modify to transmit over Bluetooth "CANFDuino_OBD2LoggerBlue.ino". You can see where we have changed the code to include a macro #BLUETOOTH that switches our previous "Serial.print" statements to "Serial2.print" to use our Bluetooth module connected on UART2. We added this code and then did a find and replace so all previous calls to Serial are now calls to our SERIAL macro which allows us to switch between Bluetooth and USB.

//
//Quick macro hack allows Bluetooth module wired to Serial2 by declaring #define BLUETOOTH (see www.togglebit.net CANFDuino hookup guide). 
//
#define BLUETOOTH

#ifdef BLUETOOTH
    #define SERIAL Serial2
    #define BAUDRATE 115200
#else
    #define SERIAL Serial
    #define BAUDRATE 2000000
#endif

Lets see if we can get this OBD2 data to a phone over Bluetooth. Since our code was originally written for a terminal program you’d find on Windows or Linux such as PuTTY, all we need to do is find an equivalent for a phone. Luckily we found an app called "Serial Bluetooth Terminal" developed for Android written by Kai Morich.

Ready to test

With our CANFDuino modified, an OBD2 interface cable connected to CAN0, our phone paired to the RN-42, and connected in the terminal app….all we need to do is to go for a drive:

You can see the in the screenshot the OBD2 channels during our drive were transmitted over Bluetooth to the phone Speed, Engine Speed, Throttle, Coolant, Load, Mass Air Flow and Intake Air Temperature.

Good to go

There you go! We hope this update provides good guidance for adding mods to your CANFDuino, and for adding wireless communications to your next project.

Thanks!
Dan