Testing USB-C to USB-A/Micro-USB Cables for Conformance

Many new mobile devices now feature an USB-C connector. In order to connect these devices to USB devices or chargers with a USB-A or Micro-USB connector, you need an adapter or cable with USB-C plug on the one side and USB-A/Micro-USB connector on the other.

As first discovered by Google engineer Benson Leung, many of these USB-C to USB-A/Micro-USB cables or adapters do not conform with the USB standard allowing USB-C devices to draw excessive power, which might damage the host or charger permanently.

Recently, I bought a Nexus 5x featuring a USB-C connector and now faced the problem of figuring out whether my USB-C to USB-A cable is conforming with the standard. So I bought a USB-C connector (actually, not so easy to get as I thought) and tested my cable with a multimeter. Of course, this works fine, and fortunately, my cable was OK. Then I thought: Why not build a little device to quickly check cables without multimeter? Just plug in the cable and see whether it is OK or not.

That’s exactly what I present here: an Arduino-based device to check USB-C to USB-A/Micro-USB cables and adapters for standard conformity. Two images of the board are shown below. It’s not very complex at all as you will see, and I don’t claim this to be rocket science. It’s just a little practical tool. Everything is completely open source, the code as well as the hardware design (printed circuit board), and you can download both from my Github repository.

USB-C Adapter Tester

USB-C Adapter Tester

USB-C Adapter Tester

USB-C Adapter Tester

Background

I don’t want to repeat everything that has already been said elsewhere. However, to keep this page self-contained, I quickly describe the problem in plain words so you can easily understand the solution.

USB-C allows the USB host or charger (called downstream-facing port, DFP) to signal to the powered USB-C device (called upstream-facing port, UFP) how much current it can provide. This is implemented by a defined current flowing from DFP to UFP over the CC (Channel Configuration) line of the USB-C connector. 80 µA +- 20 % signal “Default USB power” (900 mA for “Super Speed” devices), whereas 180 µA +-8 % signal 1.5 A, and 330 µA signal 3.0 A.

So far, so good. A USB-C host or charger will know how much power it can provide and signal the correct value by sending the corresponding current over the CC line. The problem starts with “legacy” devices with USB-A or Micro-USB connector. These connectors don’t have a CC pin, thus, the host or charger cannot signal to the USB-C device how much current they can provide. In this case, the current on the CC line is “generated” by the cable or adapter using a simple resistor RP connecting the 5 V line to the CC line of the UFP. You might remember: R = V/I. So by selecting the right resistor in the cable/adapter, a certain current ICC is flowing through the CC line. Actually, the UFP connects CC through another 5.1k resistor (RD) to ground, so you have to consider the series resistance of RP and RD when calculating ICC. RP = 56k corresponds to about 80 µA (corresponding to “Default USB-Power”), RP = 22k to 180 µA (corresponding to 1.5 A), and RP = 10k to 300 µA (corresponding to 3.0 A).

Note that now the adapter cable rather than the upstream USB host or USB charger is defining the maximum current the downstream USB-C device can pull! However, the cable cannot know to which host or charger it will be connected and how much current this host or charger can actually provide. So the only safe choice for RP is a value resulting in 80 µA on the CC line corresponding to “Default USB Power”, i.e., a 56k resistor. Unfortunately, some cable and adapter manufacturers don’t use 56k resistors but lower values like 10k resistors. If your host can just provide the required “Default USB Power”, it might get grilled.

USB-C-Adapter-Tester

Now that we know what to check, we can build our USB-C-Adapter-Tester shown on the images above. This tester consists of a microcontroller (Atmega 328p; same chip as used by the Arduino UNO) featuring an Analog-to-Digital Converter (ADC). The ADC measures the voltage drop along a 5.1k resistor (actually, two separate 5.1k resistors on different channels of the ADC since USB-C features two CC so you can plug-in the USB-C cable either way). Knowing the resistance and the voltage drop measured by the ADC, the microcontroller calculates ICC. If ICC is within the specified range (80 µA +- 20 %), an LED signaling a “good” cable is turned on from an GPIO pin. If it is outside the range, another LED signaling a “bad” cable is turned on.

The cable to be checked is also powering the microcontroller from the USB host or charger. The good old Atmega 328p can be powered from 5V, which is the voltage of USB-A and Micro-USB.

Since the internal voltage reference of the Atmega might not be very precise, I used an external 2.5 V voltage reference diode to provide a reference voltage to the ADC. If you trust the internal 1.1 V voltage reference of the Atmega, you can save this part.

As said, the USB-C connector was a little hard to get, but I finally found one at an E-Bay shop.

For the implementation of the code, I used the Arduino platform. The device is programmed through a standard 6 pin in-system programmer port.

As soon as you plug in the cable under test, the microcontroller starts measuring the voltage drop, translates it to current, compares it to the specified range, and switches on the corresponding LED signaling a good or bad cable.

If you want to etch the PCB yourself, I provide the Eagle files in the Git repository. Of course, you can also simply use a standard Arduino UNO instead of the shown PCB.

Several cables and adapters were tested with this device. The Micro-USB/USB-C adapter that came with the Nexus 5x phone was OK as well as my axxbiz USB-A/USB-C cable. Some Micro-USB/USB-C adapters were not OK (using 10k resistor instead of 51k resistors). Benson Leung tested many more cables if you are interested in what to buy.

I hope your USB cable is OK :)

BLE-V-Monitor: How car batteries join the Internet of Things

The Internet of Things (IoT) envisions a world where virtually everything is connected and able to communicate. Today, I want to present one such IoT application, namely, the BLE-V-Monitor: a battery voltage monitor for vehicels (cars, motorbikes).

BLE-V-Monitor consists of an Arduino-based monitoring device and an Android app. The BLE-V-Monitor device is connected to the car battery to monitor the battery voltage and record voltage histories. The app queries the current voltage and voltage history via Bluetooth Low Energy (BLE) and displays them to the user. Below you can see an image of the circuit board of the BLE-V-Monitor device and two sceenshots of the app showing the current voltage, charge status, and voltage history.

BLE-V-Monitor Board

BLE-V-Monitor board.

 

BLE-V-Monitor app: voltage and charge status

BLE-V-Monitor app: voltage and charge status

BLE-V-Monitor app: minutely history

BLE-V-Monitor app: minutely voltage history

The main features of BLE-V-Monitor are:

  • Voltage and battery charge status monitoring
  • Recording of minutely, hourly, and daily voltage histories
  • Bluetooth Low Energy (BLE) to transmit voltage samples to smartphones, tablets, Internet gateways, etc.
  • Very low energy consumption
  • Android app for displaying current voltage and voltage histories
  • Open source hardware (CERN Open Hardware Licence v1.2) and software (Apache License 2.0)

Motivation

According to a recent study of ADAC (the largest automobile club in Europe), 46 % of car breakdowns are due to electrical problems, mostly empty or broken batteries. Personally, I know several incidents, where a broken or empty battery was the reason for breakdowns of cars or motorbikes. So no question: there is a real problem to be solved.

The major problem with an empty battery is that you might not realize it until you turn the key, or for those of you with a more modern car, push the engine start button. And then it is already too late! So wouldn’t it be nice if the battery could tell you in advance, when it needs to be recharged and let you know its status (weakly charge, fully charged, discharged, etc.)?

That’s where the Internet of Things comes into play: the “thing” is your car battery, which is able to communicate its voltage and charge status using wireless communication technologies.

Let me present you some technical details of BLE-V-Monitor, to show you how to implement this specific IoT use case. More details including Android and Arduino source code and hardware design (PCB layout) can be found on Github:

https://github.com/duerrfk/BLE-V-Monitor

Requirements

The technical design of BLE-V-Monitor was driven by two key requirements:

  1. Keep it as simple as possible: Simple and commonly available hardware; through-hole PCB design to allow for simple etching and soldering.
  2. Very low energy consumption. What is the use of a battery monitor consuming substantial energy? Just to give you an idea that this is not trivial even considering the fact that a car battery stores a lot of energy (usually more than 40 Ah even for smaller cars): Consider the current of one standard LED, which is about 15 mA connected through a resistor to your 12 V car battery. After two hours, this LED and the resistor consumed 2 h * 15 mA * 12 V = 30 mAh * 12 V energy. Now, assume starting your motor with a starter motor drawing 50 A on average over a 2 s starting period. In this scenario, starting your motor once consumes 2 s * 50 A * 12 V = 28 mAh * 12 V. Thus, in less than two hours, the LED and its resistor consumed about the same energy as starting your car once. I know, this scenario is highly simplified, but it might serve to show that even a small consumer (in our case the BLE-Monitor device) is significant if it is running for a long time. Consequently, as a goal we want to bring down the average energy consumption of the monitoring device far below 1 mA.

Implementation

Technically, BLE-V-Monitor consists of the BLE-V-Monitor device already shown above and a smartphone app for Android.

The BLE-V-Monitor device periodically samples the voltage of the battery, and the app uses Bluetooth Low Energy (BLE) to query the battery voltage when the smartphone is close to the car. Instead of using a smartphone, you could also install some dedicated (fixed) hardware (e.g., a Raspberry Pi with a Bluetooth USB stick in your garage), but since I walk by my car every day and the range of BLE was sufficient to receive the signal even one floor above the garage, I did not consider this option so far.

In order not to lose data while the smartphone is not within BLE range, the BLE-V-Monitor device records minutely, daily, and hourly histories in RAM, which can then be queried by the smartphone.

This approach based on BLE has several advantages: It is cheap. It is energy efficient. Clients can be implemented with many existing devices since BLE is commonly available in most consumer devices, in particular, mobile devices and cheap single-board computers like the Raspberry Pi (using a Bluetooth USB stick).

BLE-V-Monitor Device

The BLE-V-Monitor device is based on the Arduino platform. It uses an ATmega 328P microcontroller and the BLE module MOD-nRF8001 from Olimex with the Nordic Semiconductors BLE chip nRF8001. The ATmega is programmed via an in-system programmer (ISP) and interfaces with the BLE module through SPI. Overall, if you build this device yourself, the hardware might cost you less than 20$.  And since we rely on a simple and energy efficient microcontroller and BLE together with small duty cycles, the current consumption can be below 100 microampere (including everything like the 3.3 V voltage regulator to power the microcontroller and BLE module from the car battery).

To measure voltage, we use the 10 bit analog/digital converter (ADC) of the ATmega (no extra ADC component required). The voltage range that can be measured ranges from 0 to 18 V, thus, the resolution is 18 V / 1024 = 17.6 mV, which is fine-grained enough to derive the charge status of the battery (see voltage thresholds below). Note that while the car is running, the car’s alternator provides more than 12 V to charge the battery (about 15 V for my car as can be seen from the voltage history screenshot). A voltage divider with large resistor values (to save energy) is used to divide the battery voltage. Since we use a 2.5 V reference voltage, 18 V is mapped to 2.5 V by the voltage divider. The 2.5 V reference voltage is provided by the very precise micropower voltage reference diode LM285-2.5, which is only powered on demand through a GPIO pin of the ATmega during sampling to minimize energy consumption as much as possible. Since the resistors of the voltage divider have large values to save energy, a 100 nF capacitor in parallel to the second resistor of the voltage divider provides a low impedance source to the ADC (this 100 nF capacitor is much larger than the 14 pF sampling capacitor of the ATmega).

A 18 V varistor (not shown on the image; it’s an SMD on the backside of the PCB since I only had an SMD version available) protects from transient voltage spikes above 18 V. Since varistors typically age whenever they shunt excessive voltage, a fuse limits the current to protect against a short circuit of the varistor.

A micropower voltage regulator (LP295x) provides 3.3 V to the ATmega and BLE module. The 100 mA that can be provided by this regulator are more than sufficient to power the ATmega and BLE module while being active, and a very low quiescent current of only 75 microampere ensures efficient operation with small duty cycles.

BLE-V-Monitor App

The BLE-V-Monitor App is implemented for Android (version 4.3 or higher since we need the BLE features of Android). It consists of a tab view with a fragment to display the current voltage, and three more fragments to display minutely, hourly, and daily voltage histories, respectively.

The charge status of a lead–acid car battery can be quite easily derived from its voltage. We use the following voltage levels to estimate the charge status on the client side:

  • 100 % charged (fully charged): about 12.66 V
  • 75 % charged (charged): about 12.35 V
  • 50 % charged (weakly charged): about 12.10 V
  • 25 % charged (discharged): about 11.95 V
  • 0 % charged (over discharged): about 11.7 V

The screenshots above show some examples of the current voltage, charge status, and voltage histories. In the history screenshot you can also identify two periods when the car was running where the charging voltage reached about 15 V.

Final Prototype

The following photos show how the BLE-V-monitor PCB is mounted inside a case and the placement of the monitoring device right in front of the battery of my car (in this photo, the device is already connected to the battery but not yet fixed). Fortunately, older cars have plenty of space and not a lot of useless plastic hiding every part of the motor.

BLE-V-Monitor device

BLE-V-Monitor device with case

 

BLE-V-Monitor device in car

BLE-V-Monitor device mounted in car and connected to car battery

The pull relief (knot) might not look very elegant but it is highly effective.

Obviously, plastic is the better choice for the case since the Bluetooth module is inside. Still, I had some concerns that all the metal of the car would shield Bluetooth signals too much, but it works suprisingly well. Even one floor above the garage with the metal engine hood and a concrete ceiling between device and client I can still receive a weak signal and I can still query the battery status.

Where to go from here?

Obviously, there is some potential to further improve the functionality. Beyond just monitoring the raw voltage and mapping it to a charge status, we could analyse the voltage data to find out whether the battery is still in a healthy condition. For instance, we could look at voltage peaks and analyse the voltage histories to find out how quickly the battery discharges, and how these values change over the lifetime of the battery. To this end, you could send the data to the cloud. Although I think, you could implement such simple “small data” analytics also on the smartphone or even on the microcontroller of the monitoring device.

However, the battery or car vendor might want to collect the status of all of their batteries in the cloud for other reasons, for instance, to improve maintenance and product quality, or to offer advanced services. With the cloud, everything becomes a service, so why not offering “battery as a service”? Instead of buying the battery, you buy the service of always having enough energy to operate your car. When the performance of your battery is degrading over time, the vendor already knows and sends you a new battery well before the old one is completely broken or invites you to visit a garage where they exchange the battery for you (this service would be include in the “battery as a service” fees).

I hope you found this little journey to the IoT interesting. Have a good trip, wherever you go!

Wireless Connection for Carrera Slot Car Track

This post is about a special networked device: a slot car track and how to connect it via Bluetooth to a PC, laptop, or mobile phone.

At Christmas we had a lot of fun playing with my nephew’s brand new slot car track: a Carrera 132 digital — so everything I write here applies to this specific slot car track, although I believe that it’s at least applicable to all other digital models from Carrera. I realized that what used to be analog some (ten) years ago now is digital and has a connection to a so-called “PC Unit”. After searching a little bit, I found out that this is nothing else than a serial connection using TTL-level signals. By connecting a PC with the right software (which you can get for free), you get a lap counter, you can measure lap times, etc.

However, this PC Unit from Carrera has two drawbacks:

  • It costs about 65 EUR — a lot of money for a simple box that just converts TTL-level serial signals to an USB interface.
  • It is wired, i.e., you have to place your PC or laptop close to the track and cannot easily connect wireless devices like smartphones or tablets that do not have an USB port.

Therefore, I decided to connect the slot car track through a cheap Bluetooth-Serial module. With this module, the slot car track will behave as a Bluetooth device implementing a serial profile (“wireless serial port”).

The Circuit

The key component is the HC-06 Bluetooth-Serial module depicted below.

Bluetooth-Serial Module

 

Bluetooth-Serial Module

This module costs about 8 EUR at ebay (including shipping from China). Be sure to get a slave module, so the PC can act as the master establishing the connection to the slave module. This module takes as input 3.3 V to 5 V TTL-level signals, just fine for the PC Unit socket of the slot car track.

The Bluetooth board has a voltage regulator on board that works with 3.6 V to 6 V. Actually, the PC Unit connector (PS/2 socket) has a 5 V output (see figure of socket below). Although I believe it would provide enough power for the Bluetooth module, I did not want to risk to ruin the slot car track of my nephew on Christmas for obvious reasons ;) Therefore, I decided to use a separat 5 V voltage regulator to convert the 14.4 V output of the PC Unit socket to 5 V.

The circuit is very simple as can be seen below.

curcuit

Bluetooth Slot Car Connector

 

Bluetooth Slot Car Connector

 

Bluetooth Slot Car Connector

You have to cross-connect the RX and TX pins of the PC Unit socket and the Bluetooth module. As voltage regulator (IC1) you can use an L7805 or L4940V5, for instance. To stabilize the output, you should add a small capacitor (C1; I used 22 uF, but you can also use higher values without problem).

The PC Unit X1 is a PS/2 connector. Below you see the pins labeled with the numbers from the schematic above. Be sure not to mix up 14.4 V and ground, or RX and TX!

PC Unit Connector

The pins of the Bluetooth-Serial module are nicely labeled as can be seen on the photos above.

Configuring the Bluetooth Module

The serial port of the track uses 19200 baud, 8 bit, no parity bit, and 1 stop bit. By default, the Bluetooth module uses 9200 baud, so we have to change the configuration of the Bluetooth module. To this end, you can use an FTDI breakout board (see below) that converts TTL-level signals of a serial connection to USB. BTW: you can also use this board to connect the slot car track with a cable to the PC or laptop; although this somehow defeats the purpose of this whole post ;)

FTDI

This board is connected to the Bluetooth module, and as long as no wireless device is connected to the Bluetooth module, you can configure it using AT commands. You need a serial terminal software to this end, e.g., putty. Be sure to use the connection settings 9200/8/N/1 initially until you have changed it.

Depending on the Bluetooth module you got, the AT commands might be slightly different. For my module, you can change the baud rate to 19200 baud with

AT+BAUD5

You have to be fast enough when you type in this command. The module does not wait for the final line feed! So better copy&paste this line to your serial terminal. The module should respond with “OK19200″. If you are not sure whether your connection works, you can first simply type in AT. Then the module should respond with “OK”.

You can also change the name of the Bluetooth device using the following command (where “SLOTCAR” is the new name here):

AT+nameSLOTCAR

Of course, you can use any other name than SLOTCAR.

Testing it

To test it, first try to connect your PC or laptop via Bluetooth to the module. The pairing code is 1234 for my module. The module has an LED that flashes while there is no connection, and is permanently on if it is connected to  a remote master device. Be sure to configure the serial port of the Bluetooth device on your PC to 19200/8/N/1.

To further test is — and finally use it :) — I downloaded the X-Lap software from Carrera. When you start this software, it tries to connect to the slot car track using all available serial ports. Your Bluetooth serial port should work automatically.

That’s it. Hope that it works and you have a lot of fun racing :)