USB compatibility in EMS devices
About this page
This page was written by the New Horizons engineering team, which operated until December 2025. First-person references ("we", "our") are the original authors'. A number of those authors are now working with Phoenix GH, which maintains this material and stands behind it. Questions and comments are welcome — please get in touch.
Last update: August 28, 2024
Overview
Following the publication of the WHO PQS EMS specifications, New Horizons developed an EMS level-1 logger as a demonstration product and an opportunity to learn. During the development of this device, we encountered a series of technical challenges that impacted device reliability and performance, many of which were related to the USB implementation. In addition, New Horizons has evaluated pre-release samples of CCE monitoring systems from some third-party suppliers, all of which exhibited one or more USB-related compatibility challenges.
To support the broader community of developers working in this field, New Horizons is sharing this document to highlight the challenges we observed and identify potential solutions to these issues. This document is intended to highlight common pitfalls in the development of EMS loggers, with special focus on ensuring compliance with USB specifications, maximizing compatibility with a variety of USB host devices, and improving overall device robustness. By addressing these challenges, we hope to assist manufacturers in developing more reliable and efficient EMS loggers, ultimately contributing to the effectiveness of cold chain equipment.
Issues observed in USB implementation
CC1 & CC2 pins must not share a single 5.1K resistor
Issue overview
In some USB-C implementations, we observed host devices failing to detect the connected device when using a USB-C to USB-C cable. Upon investigation, it was determined that the CC1 and CC2 lines were shorted together and pulled down by a single 5.1K resistor, which is not compliant with the USB-C specification. This configuration can cause the host to misidentify the device, especially when using E-Marked USB-C cables that support power delivery.
Detecting this issue
Measure the resistance between the CC1 and CC2 lines when the device is unplugged. If the resistance is zero, this indicates that the lines are shorted. The expected resistance should be approximately 10K.
Also note that Windows hosts may report an "Unsupported Audio Accessory" error when connecting to a device with CC1 and CC2 pins sharing a single 5.1K resistor. To test this, connect the non-compliant device to a Windows host using an E-Marked USB-C to USB-C cable. In our experience, other operating systems may not report this issue as clearly or reliably as Windows.
Recommendations
To comply with USB-C specifications and to avoid device misidentification, ensure that the CC1 and CC2 lines are each pulled down by their own 5.1K resistor.
Additional details
In 2019, the Raspberry Pi 4 used an incorrect USB circuit with shorted CC1 and CC2 lines. This issue prevented hosts from delivering power using E-Marked USB-C cables and caused significant problems for Raspberry Pi users. Further details on the Raspberry Pi issue can be found here.
Impedance in signal path when using ferrites to control EMI
Issue Overview
One of our USB-C implementations used individual ferrite beads in each data signal line to minimize electromagnetic emissions. However, we observed that some hosts were failing to connect to our device or were experiencing data transfer problems over the USB connection.
Our troubleshooting revealed that our device exhibited slow signal-rise times, which were outside the accepted limits of the USB specification. The slower rise times correlated with data transmission errors and seemed to prevent reliable host/device communication. Some USB hosts were more sensitive to poor signal-rise times, while others appeared to be unaffected.
Issue Detection
Use an oscilloscope to monitor the D+ and D- signals. The USB specification for Full-Speed 10-90% rise/fall time is 4-20 nsec. When put in terms of slew rate, it is 130-660 V/usec. See USB-IF Compliance Updates, which also shows the limits for USB Low-Speed and High-Speed implementations. If the measured slew rate is less than 130 V/usec, it is reasonable to expect that some hosts will have problems with USB Full speed communication.
Recommendations
Some amount of filtering may be needed to maintain EMC compliance. For Low-Speed and Full-Speed USB, this might be accomplished with individual impedances in each data signal line, as long as signal rise times are confirmed within specification.
Because the data lines are differential signals and tend to cancel each other, it is more important to filter the common-mode signals likely to be a cause of EMC problems. We would recommend using common-mode chokes in the data signals for Full-Speed or High-Speed implementations.
Connection reliability of voltage clamps vs. 5.1K resistors
Issue Overview
One of our USB-C implementations used a 1.1-volt clamp on the CC lines instead of the more common 5.1K pull-down resistors. While this approach is compliant with the USB specification, it differs significantly from using pull-down resistors in that it only pulls the CC line down to 1.1 volts, compared to approximately 0.4 volts with the resistors.
This difference in voltage levels created reliability issues, which we initially noticed with certain Samsung phones. These host devices appear to compare the CC line voltage at 1.1 volts, which is right at the edge of the voltage provided by the clamp. As a result, the connection would fail intermittently. This issue could be exacerbated by using USB cables of different lengths and physical characteristics. When we replaced the voltage clamp with 5.1K resistors, these connection issues were resolved, and the Samsung phones connected reliably.
Recommendations
For enhanced reliability and broader compatibility with various host devices, we recommend using 5.1K pull-down resistors instead of a voltage clamp on the CC lines. Using 5.1K resistors pulls the CC line down to approximately 0.4 volts, which provides a clear and distinct signal that is well below the detection threshold used by most devices. This reduces the likelihood of connection failures and improves overall compatibility with a wider range of hosts.
If you implement a voltage clamp instead of 5.1K resistors, you should test your device with a wide variety of hosts, some of which may be more sensitive to voltage clamp implementations. If you observe intermittent connection issues to devices that use voltage clamps on the CC lines, this may indicate that the voltage clamp is too close to the host’s detection threshold.
Proper Control of D+ Line Voltage in Absence of VBUS
Issue Overview
In a prototype USB device, we observed that the device was holding the USB D+ line at 3.3 volts, even when VBUS power was absent. This behavior is inconsistent with the USB 2.0 specification, specifically section 1.7.1.5, which states:
"The voltage source on the pull-up resistor must be derived from or controlled by the power supplied on the USB cable such that when VBUS is removed, the pull-up resistor does not supply current on the data line to which it is attached."
This issue was identified while troubleshooting connection failures between the logger device and various host devices, including external EMDs that can maintain physical USB connections to a logger over long periods of time. A USB protocol analyzer revealed that the host would send a USB reset to the logger, followed by additional packets, but not receive any response from the logger. These packet transmissions were occurring before the USB CC handshake process and before the application of VBUS, suggesting that the host believed the logger was already connected (based on the status of the D+ line) and was attempting to reset the connection. However, the logger remained unresponsive, failing even to send a simple NAK signal.
Detecting this issue
Measure the voltage on the D+ line when VBUS is not active (i.e., no voltage applied to VBUS). If the D+ line holds a voltage around 3.3 volts (between 3.0 and 3.6 volts), the device is exhibiting this issue. In a compliant design, the D+ line should float at a much lower voltage when VBUS is not present. This may require a USB breakout board and an external host that supports explicit control of VBUS.
Recommendations
To ensure proper USB operation and compliance with the USB 2.0 specification, the pull-up current on the D+ line should only be applied after the host indicates readiness by applying voltage to VBUS.
Controlled D+ Pull-Up: The device should be designed such that the pull-up resistor on the D+ line is only activated when VBUS is present and the device is ready to communicate. This prevents the host from incorrectly assuming that the device is ready to respond to USB packets before the device's USB driver is active.
Practical Implementation: This issue may not surface in normal scenarios where the USB cable is connected to a powered and active host, such as a laptop, which will automatically enable VBUS. However, with custom hosts that maintain a long-term physical connection with a logger – and may manipulate VBUS to establish or break the USB connection (e.g., external EMDs) – this issue may be surfaced and can lead to failures. Ensuring that D+ pull-up current is controlled based on VBUS presence will prevent such connection failures.
Implementation guidance
Optimizing the speed of logger report-file generation
Overview
For EMS loggers, minimizing the delay between establishing a physical connection and making the logger’s file system accessible to the host is crucial. The speed of PDF report generation is the most significant contributor to this delay, particularly when generating reports that encompass a full 60 days of data, as required by PQS specifications. This process is especially time-consuming on embedded platforms when generating reports directly from raw JSON data. To optimize this, as much data preparation as possible should be done prior to the host connection, ensuring that minimal work is needed once the USB connection is established.
The challenge in generating the 60-day PDF summary file lies in the need to read, parse, and aggregate raw JSON data to create the final report. On embedded platforms, this end-to-end process can take a considerable amount of time, even before factoring in the time required to write the final PDF, which is often over 100 kilobytes in size. The simplest approach—processing the JSON data at the time of USB connection—demands handling a large volume of data, typically over a megabyte, which inevitably leads to significant delays.
Two approaches to minimize report-generation time are described below.
Approach 1: Optimizing with binary files
One effective way to significantly reduce PDF report creation time is to store the data in both JSON and binary formats. While this duplication may seem inefficient, the binary data requires much less space than JSON and, crucially, does not need to be parsed before summarizing. In our experience, processing binary data is roughly ten times faster than processing equivalent data in JSON format.
Although the PQS specification requires EMS loggers to maintain at least a year’s worth of data in the DATA_HISTORY directory, the binary data is only used for the 60-day PDF summary, so it only needs to contain 60 days of data. The binary file can also store specialized or proprietary information to further speed up PDF creation, including data not required in the JSON format.
Create a dedicated subdirectory to store these binary files, which will help prevent clutter in the base directory—a requirement of the PQS specification.
Approach 2: Optimizing with preprocessing
NOTE: This approach includes Approach 1, but with additional optimization.
The PDF 60-day summary report includes a line of information for each of the past 60 days, starting with day 1 ("today") and working backward. The PQS specification allows for two definitions of "today." The first option treats "today" as a full 24-hour period, ending when the logger connects to an EMD or another host. Adhering to this definition limits the options for preprocessing because the exact time of each data point isn't known until the USB connection is made.
The second option defines "today" as a day in progress, potentially shorter than 24 hours. This method allows for preprocessing by using the logger’s relative time (RELT) to determine when each day starts and ends. Many current PQS prequalified 30DTR loggers use this method. The day starts when the RELT time rolls over (e.g., when "T0H0M0S" appears). This enables daily data summarization in real-time, storing each completed day’s summary in a binary file and holding the current day’s data in RAM.
When the logger is connected, the preprocessed data allows for rapid PDF generation, with day 1 ("today") retrieved from RAM and previous days from the binary file. This approach significantly speeds up the creation of the 60-day summary report. However, if data is stored solely in RAM, a watchdog event could result in the loss of up to 60 days of information. Writing data to flash daily mitigates this risk, ensuring only one day's data is at risk in such events.
Low-level USB behavior after connecting host to logger
Overview
The prior section describes methods to improve the speed of report generation. This section discusses a separate but related topic: the low-level USB behavior of EMS loggers during the period when the logger is preparing the report files and has not (yet) presented the storage device to the host. The USB interactions during this period are crucial and can impact the logger’s compatibility with various host devices.
Option 1: Single-Stage Initialization
In the simplest implementation, the logger enables the D+ signal line only after it has finished generating the necessary files and is fully ready to present its storage device to the host. This is straightforward to implement and is, in our experience, fairly reliable when implemented in conjunction with the speed optimizations described in the previous section.
It is worth noting that the USB specification does not provide guidance on how long a host should wait for a connected device to enable the D+ line after the host supplies VBUS. We expect that different hosts will implement different timeout thresholds. If the delay between supplying VBUS and enabling the D+ line exceeds the host’s timeout threshold, the host might consider the logger unresponsive and ignore it. This could lead to inconsistent behavior across different host devices, although we have not encountered this issue in our own (limited) testing.
Option 2: Two-Stage Initialization
A two-stage initialization is intended to ensure that the logger can quickly respond to the host under all conditions, even when is not yet ready to present the storage device. With this approach, the logger initially presents itself as a simpler USB device, such as a HID or vendor-specific device, signaling to the host that it is present but providing minimal functionality (e.g., signaling a "busy" status to the host). When the file generation process is complete, the device would perform a soft reboot, which forces a disconnection and reconnection to the host, triggering a fresh enumeration process as a full MSC device.
By initially presenting a simpler device, the logger can quickly respond to the host’s connection attempts, reducing the risk of being ignored due to delayed D+ line activation. It's possible (though untested) that a two-stage approach might offer greater compatibility across a wider range of hosts, ensuring quicker initial recognition.
We have not implemented nor tested a two-stage initialization. It is more complex to implement and it might introduce unforeseen compatibility problems with some hosts, particularly if they react unexpectedly to the transition from the initial simple device to the full MSC device. Given that we haven’t detected host incompatibility with a single-stage initialization, we have not been motivated to implement a two-stage approach.
Choosing the Best Approach
Our testing of a single-phase initialization has been reliable but it should not be interpreted as conclusive evidence that this approach will be universally compatible with all hosts. We encourage suppliers to test their devices with a wide variety of host devices and, if practical, engage a USB-IF test laboratory to assess compliance of their devices against the formal USB specifications.
Contact
Contact: Bob Lockhart
For more information, contact us about USB implementation guidance.