The software interface language can be modified from the triangular drop down on the top right near the window controls. However, some options continue to remain in Chinese even after the language is set to English. However, the software is intuitive enough for that to not be too much of a concern. The device firmware, as well as the application itself, can be updated from within the program. The ‘PD Analyzer’ view shows a real-time view of the various voltages and currents, along with a tabular view of the PD handshake process. Various other options such as saving graphs, recording data to a CSV or SQLite DB on the PC, etc. are available, as shown in the gallery above.

Open APIs

The Windows application is closed-source, but ChargerLAB provides some documentation in their HID Demo archive. The document is in Chinese, but I used Google Translate to get an inkling of the contents. From previous reviews, I have found that links often go stale. In order to avoid that with the KM003C API description, a screenshot of the translated version is provided below.

Click for a higher-resolution version of the API document

It is possible that ChargerLAB might update the APIs in the future. In that case, the latest version can be obtained from the FAQ section on their support page. ChargerLAB states there are three interfaces available – as a WinUSB (vendor specific interface) device, a HID device, or a virtual serial port (CDC). The next couple of sections take a look at how these interfaces can be taken advantage of in different operating systems.

Our current USBC-TKEY-based setup for measurement of power consumption uses a Ubuntu 20.04 machine for tracking the parameters on the V_BUS line. Since the USBC-TKEY has a command line interface accessed over the serial port, we had developed a Python script to record a CSV file with the required data. In order to experiment with the APIs provided by ChargerLAB for the KM003C, a SanDisk Professional PRO G40 Thunderbolt 3 portable SSD was connected to a Thunderbolt 3 port of a Quartz Canyon NUC with the KM003C acting as a man-in-the-middle (additional details in a later section discussing the KM003C in action). The HID port of the KM003C was connected to the Ubuntu machine using a Type-C to Type-A cable.

The API document makes a note of the KM003C presenting itself with three bidirectional interfaces. As only Windows support is claimed, it is no surprise that only the HID endpoints get exposed via the usbhid driver. The WinUSB endpoints belong to a vendor specific class, and the virtual serial port appears as a CDC data interface.

In exploring the KM003C as an alternative to the USBC-TKEY, we wanted to retain the Python script infrastructure (because it tied in well with the other components of our direct-attached storage evaluation infrastructure). It turned out that Python’s libusb module could act as a WinUSB alternative with its ability to access the endpoints under the Vendor Specific Class. This module requires the end user to be aware of the raw data that needs to be sent across the interface, and the format in which data is returned on the other endpoint.

The relevant modules to import in Python3 for libusb support are usb.core, usb.util, and usb.control. Since the vendor and product ID of the KM003C are known from the output of the usbdevices command, they are used directly to open the device for access through the script. Reliable scripting needs to ensure that the device is successfully found. For demonstration purposes, the variable contents are displayed, as shown above.

While the libusb module aims to be cross-platform, we did find that the steps below to detach the kernel driver did not work on Windows. libusb needs exclusive access to all the interfaces over which communication is expected to take place. For demonstration purposes, the code extract above cycles through a hard-coded number of interfaces (4), but it is possible to obtain that number from other functions in the module. The extract checks if an interface has a kernel driver attached to it, and detaches it in that case. It then proceeds to claim the interface for access through the script’s session.

In order to retrieve the power consumption data from the device, a command needs to be transferred via the EP 1 OUT endpoint (with endpoint address 0x01). As ChargerLAB mentions, we can also use the EP 5 OUT and EP 3 OUT ones at addresses 0x5 and 0x3, but the response needs to be monitored at the corresponding EP IN endpoint. The command itself is in the form of a 32-bit word, and its encoding is detailed in the API document. In the script extract below, the 32-bit word is 0x0C000200. It corresponds to a GET_DATA command for the ADC data with a command ID of 0x0. I found during the course of experimentation that the ID in [23:16] could be varied from 0x0 to 0xFF without any loss in functionality. Since the command remains the same throughout the reading loop (we attempt to read out the power data 20 times with a gap of 100ms between each read), the command word is initialized outside the loop.

The first step in the loop is to obtain a timestamp for the command written out to endpoint address 0x1. This write is followed by the read to endpoint address 0x81 (the EP IN corresponding to the EP OUT used in the write). The read is blocking, i.e, it waits for the data to be sent back by the device and there is a default timeout associated with this command. The received data is then parsed out into appropriate components (instantaneous V_BUS voltage and current, and the averaged V_BUS voltage and current) based on the struct specified in the API document.

The HID demonstration code (supplied as a Visual Studio 2019 project) tagged along with the API document read out the averaged voltage and current. The documentation did not specify the averaging duration or the sampling rate. In the initial trials, the code did not read out the instantaneous values, and I was left frustrated as to why the averaged value was changing only once every second instead of getting updated for every read out. I spent quite a bit of time trying out the same code with different endpoints, and even different OSes. I even went to the extent of using Wireshark along with usbpcap in an attempt to trace the commands sent and data received by ChargeLAB’s closed-source Windows software. It was only after careful analysis of the packet capture did I realize that the average V_BUS voltage and currents were changing only once ever second even in the traffic triggered by the software. The instantaneous data of interest actually turned out to be the first two words in the returned ADC data struct. The time taken for the read process and display of the CSV data is computed and the code segment is left idle before starting the next loop iteration 100ms later. Each line in the output data stream shows the timestamp, instantaneous voltage, instantaneous current, and instantaneous computed power, followed by the averaged versions of all three. Given the details of the averaging process, it is possible that the computed averaged power consumption can also be interpreted as the energy consumed by the sink (device, in this case) since the last change in that parameter.

As a final step in the script, a cleanup is performed so that all open accesses to the device via libusb are flushed out, and the device is made accessible to other programs. The script can then be terminated safely.

Custom user programs and scripts to access the data from the KM003C are comparatively easier to create on Windows compared to Linux. One of the primary reasons is that ChargerLAB supplies a HID demo program (ZIP) on its technical support page. It includes a VisualStudio 2019 project with C++ source code to access the data from the device. The KM003C also presents itself as an USB device as well as a serial device to the OS. In the ideal case, we should have seen the latter interface even in Linux as /dev/ttyACM0, but that was not the case in our Ubuntu install.

Powershell is my preferred scripting language on Windows machines, and accessing the KM003C as a serial device is as simple as opening the appropriate COM device output in the above command. As mentioned in the API document, the baud rate and other parameters do not matter.

The command to be sent over the serial port for getting the ADC data (the 32-bit word, 0x0C000200) is prepared. Similar to libusb, the device write function expects a UTF-8 string. Unlike libusb, the read function is not blocking. In order to avoid polling for the data, or waiting for a pre-defined amount of time (by which there is no guarantee that the read might have returned the data from the device or not), a Powershell event is set up to trigger whenever data is received on the opened port.

The read out process is isolated out into a script block, and the logic to compute the instantaneous and averaged power consumption is similar to what was done using Python on Linux. The main difference is that we wait for the event triggered by the data receipt before the call to the read from the port.

The script block is called in a loop every 100ms and generates output that is similar to the one created by the Python script in the previous section – CSV strings with a timestamp, followed by instantaneous voltage, current, and power, and the averaged versions of the same.

The clean-up process involves closing the port and deregistering / removing the event set up to track the data receipt from the port.

Prior to the adoption of the KM003C as a replacement for the tried and tested Plugable USBC-TKEY (Google Twinkie), we wanted to perform a few checks. Any inline power meter has the possibility of introducing signal interference that can adversely affect bandwidth (by introducing retransmissions). That is one of the primary reasons for almost all low-cost PD analyzers in the market to completely disable data transmission while monitoring the PD traffic.

The test setup for the KM003C involves one of the Thunderbolt 3 ports on the Quartz Canyon NUC – our direct-attached storage testbed. The SanDisk Professional PRO-G40 was chosen as the target device. A CrystalDiskMark run with a 32GB data span (five passes, and 12 distinct workloads, with each workload separated by 5 second intervals) was processed in three different setups:

• Direct connection to the Thunderbolt 3 host port without inline power metering
• Connection to the Thunderbolt 3 host port with a Plugable USBC-TKEY (Google Twinkie) acting as a man-in-the-middle (MITM)
• Connection to the Thunderbolt 3 host port with a ChargerLAB KM003C as a MITM

The three screenshots below show the CrystalDiskMark benchmark numbers obtained in each of the above three scenarios.

Though the vanilla configuration with no MITM comes out on top in all the workloads except for the high queue depth random writes, all the numbers are bunched close together within the realm of run-to-run variations. As such, the impact on the performance numbers with the KM003C is no different from the impact resulting from having the USBC-TKEY as an interposer.

Moving on to the recorded power consumption data, we first take a look at the numbers polled from the USBC-TKEY at 1 second intervals.

A peak of 7.16W was observed via the USBC-TKEY. From the Google Twinkie / USBC-TKEY documentation, it is not clear whether the ‘twinkie vbus’ command reports instantaneous numbers or averaged ones – but, looking at the smoothening, it does appear to be an averaged one.

In the first pass with the KM003C, we attempted to retain the 1 second polling interval used with the USBC-TKEY. Recording the averaged power consumption made more sense in that case.

A peak of 6.63W is observed for the 1s polling interval, and the graph is quite smooth. This needs to be compared with the high-resolution graph (where the data is polled every 100ms, and the instantaneous values are recorded) having a 7.55W peak.

A 100ms polling interval seems to yield a better record of power consumption spikes. A better idea of the energy efficiency of a bus-powered device can probably be obtained by looking at the sum of the averaged power numbers throughout the duration of the test. For devices like portable SSDs, this will also take into account any deep-sleep idle timeout features and garbage collection activities. Overall, the KM003C appears to expose more interesting data compared to the USBC-TKEY for evaluation of the power and energy efficiency of bus-powered USB devices.

Our evaluation of the ChargerLAB KM003C for the purpose of USB-C power metering returned very good results, making it a credible alternative to the Plugable USBC-TKEY / Google Twinkie for our use-case. The hardware build quality is top notch, with the aluminum enclosure miles ahead of the flaky transparent polycarbonate shell enclosing the Twinkie PCB in the USBC-TKEY. The KM003C also comes with an aluminum box to store the device safely when it is not in use.

Most mainstream consumers opting to purchase the KM003C do it to ensure that their USB-C chargers are operating as expected and delivering the appropriate amount of power to the sink. Despite the emergence of USB-PD, many custom fast-charging protocols with varying voltage and current levels are also present in the market. The KM003C has the ability to recognize a large number of these custom protocols and give feedback to the user on the power at which a device is getting charged.

A search on Amazon reveals a large number of USB power meters, and a few of them like Plugable’s simple-to-use USBC-VAMETER3 are from reputed brands. However, most of the low-cost ones (including the Plugable model) just present the collected data on a screen built into the device. Only a few models allow for monitoring and processing the collected data externally, and very few actually provide APIs for this purpose. ChargerLAB’s KM003C belongs to that rare category, and provides API details as well as a demo program using those APIs. Additionally, very few allow high-speed data pass-through, and the KM003C and the Plugable USBC-TKEY / Google Twinkie are the rare exceptions that can support pass-through up to 40 Gbps.

One of the unique aspects of the KM003C is that its manufacturer (ChargerLAB) has been releasing frequent firmware updates to address bugs and add new features. They also maintain a technical blog detailing the features of the product. The posts serve as an introduction to some of the advanced features of the KM003C. On this front, ChargerLAB seems to be comprised of hardware enthusiasts who understand the needs of power users. ChargerLAB’s support team is also quite responsive. I had mailed them once prior to purchase (wanting to check whether the KM003C could be used as an alternative to the Google Twinkie / Plugable USBC-TKEY), and they helpfully pointed me to their transmission test blog post and the FAQ section in their technical support page. I also communicated with them about the sampling rate issue, but after a few days they could not come back to me with an appropriate answer (that I was looking up the wrong bits from the returned data structure). That said, the e-mail exchange was definitely on a much higher technical level than any of my previous tech support conversations with other vendors.

The KM003C is also relatively future-proof, and claims support for 240W PD measurement when adapters supporting that wattage are not even available in retail yet. The digital power monitoring chip is one of the primary components restricting the usage of certain USB power meters with higher wattage power supplies. Even though the USB-PD 3.1 protocol only goes up to 48V, the INA228 metering chip can withstand up to 85V (the KM003C is rated for 0-50V).

In terms of scope for improvement, the KM003C does have an outstanding issue with passing USB 2.0 traffic. While the product does come with an online English manual, the API description document is only in Chinese. A more detailed multi-lingual version would be nice to have. Allowing replication of functionality such as altering the settings and tracking charge / energy via APIs should also be included. The software accompanying the device has many features, but is not particularly stable (with the application terminating unexpectedly under some circumstances).

A replica of the on-device screen in the software would be nice to have for easier remote operation. A ‘Virtual Display’ tab in addition to the ‘Data Recorder’ and ‘PD Analyzer’ that replicates the on-screen contents along with virtual buttons to allow cycling through different options (just like physically operating the buttons on the device would) would make the user experience better. Often times, it is difficult to keep track of the behavior of each button in different screens. Being able to handle this from the software would make things much easier.

The features of the KM003C make it appeal to a wide variety of consumers. However, for specific use-cases like ours, features such as the on-device screen and physical buttons are not particularly useful. Allowing everything to be accessed and controlled via the HID port and removing the screen / buttons to reduce the BOM cost (and end-use pricing) in a KM003C-Lite would be a consumer-friendly move from ChargerLAB.

Overall, the ChargerLAB KM003C springs a pleasant surprise by providing capabilities that go above and beyond the claims in their marketing material. The core capabilities have been reviewed with good results by multiple outlets on YouTube. Since they are incidental to our primary use-case, we did not bother with testing those in detail. Our aim was to evaluate whether the KM003C would make a good relatively future-proof alternative to the Google Twinkie for power metering, and we are glad to report that the product passed the test with flying colors. There is some scope for improvement as outlined earlier in this section, and the product could do with some competition to drive down the pricing. The KM003C is available in China for around 400 RMB, which translates to around $55. On Amazon, the product is available for double the price – $110. Even accounting for import costs, the markup is a little hard to digest. Despite this premium pricing, we believe that the KM003C should be part of every USB-C power user / developer’s toolkit.