This is a quick tutorial to demonstrate the process of talking to NCD Energy Monitoring controllers. This tutorial will help you understand all communications protocols, which will greatly simplify implementation. NCD.io current monitoring controllers require 3 protocols to be wrapped together for proper implementation. This is not nearly as difficult as it sounds, as this tutorial will do most of the work for you.
NCD current monitoring controllers use a custom dedicated CPU to measure energy usage. This CPU uses I²C communications to talk to a NCD Fusion class communications processor. There are essential 3 command sets you will be working with:
- The I²C Command Set for the Current Monitoring CPU. If you wish to learn more about the I²C commands for NCD Energy Monitoring Controllers please click here.
- The Fusion CPU has a serial command set for converting serial bytes into I²C communication packets. The Fusion communications CPU can be used to talk to just about any I²C device ever created, to learn how to communicate with all I²C devices, please click here.
- The Fusion CPU requires all commands to be wrapped into a packet with a header and a checksum. To learn how to wrap commands into API format, please click here.
As you might expect, there is a lot of information to process at the above links, so here, we will boil it all down to raw examples so all of this information may be easily digested.
It’s worth noting that we expect you to already understand the basics of serial communications. We will be using a USB to serial adapter in this guide, and all data will be sent to a virtual COM port at 115.2K Baud.
Before we get started, there are a few basics you need to be aware of:
- Fusion class processors have multiple I²C ports, usually Port 0 is dedicated to on-board devices (such as energy monitoring), but off-board expansions may be used as well. Port 1 is available for controlling just about any other I²C device.
- NCD Energy monitoring I²C processors are capable of chaining 16 devices per I²C port. So Port 0 already has one I²C processor, and 15 expansions may be added externally. Port 1 is unused, and 16 expansions may be added externally.
- Neither NCD Fusion or I²C processors require any form of initialization, they are ready to read energy values immediately on power-up. No initialization is ever required for any of our devices.
- We make many different current monitoring controllers with many different options. Each Energy Monitoring I²C chip contains specific data that identifies the number of channels and the amperage of the sensors. We STRONGLY advise you read this information from the CPU so your software will provide the correct readings, but this step may be skipped if you are learning.
- All byte values below will be shown in decimal format, if you prefer to work in hex, these values may be easily converted.
- Often you will see 2 checksums in our communication examples. Fusion API communication frames always need a checksum. I²C communications always use a checksum. A checksum is a way of validating the data packet as accurate. Checksums are calculated as 8-bit values. Many programming languages use the Bitwise AND function to convert a 16-bit value into a 8-bit value.
Reading Device Information from the Controller
The first thing your software should always do is read the type of sensors and controller calibration information.
Send these bytes of data to read device calibration data:
| Byte | Byte | Byte |
|---|---|---|
| Number | Value | Description |
| 1 | 170 | Fusion Processor API Header Byte |
| 2 | 14 | This Command will Contain 14 Bytes |
| 3 | 188 | Fusion Processor I²C Header Byte |
| 4 | 50 | Fusion Processor I²C Port 0 (51 = Port 1, etc.) |
| 5 | 10 | Write 10 Bytes of Data to the I²C Port |
| 6 | 84 | I²C Start Address (42×2)+0 for Write Operation |
| 7 | 146 | I²C Processor Header Byte 1 |
| 8 | 106 | I²C Processor Header Byte 2 |
| 9 | 2 | I²C Command for Reading Device Identification Data |
| 10 | 0 | I²C Command for Reading Device Identification Data |
| 11 | 0 | I²C Command for Reading Device Identification Data |
| 12 | 0 | I²C Command for Reading Device Identification Data |
| 13 | 0 | I²C Command for Reading Device Identification Data |
| 14 | 254 | Checksum for I²C Frame = 8-Bit Sum of Bytes 7 through 13 |
| 15 | 85 | I²C Start Address (42×2)+1 for Read Operation |
| 16 | 7 | Read 7 Bytes of Data from the I²C Port |
| 17 | 92 | Checksum = Sum Bytes 1 through 16 Truncated to the Lower 8 Bits |
The controller will respond with 7 bytes of data that identify the number of channels and sensor calibration data:
| 170 | Fusion API Header Frame |
| 7 | Fusion API Indicates 7 Bytes of Data in the Payload |
| 5 | Sensor Type (See Sensor Types Below) |
| 50 | Max Current |
| 6 | Number of Channels Supported by the Controller |
| 1 | Firmware Version for Energy Monitoring CPU |
| 0 | Reserved |
| 0 | Reserved |
| 62 | Checksum of I²C Communications |
| 45 | Checksum for Fusion API Frame |
Sensor Types:
Our example controller is using Type 5 above, here is a list of all currently supported sensors:
1 = “DLCT03C20”
2 = “DLCT27C10”
3 = “DLCT03CL20”
4 = “OPCT16AL”
5 = “SCT013”
6 = “OPCT38AL”
Note 1:
If the controller is using sensor 6 (OPCT38AL), the Max Current value should be multiplied by 10
Reading Measured Current from the Controller
This section will demonstrate how to read energy values from the controller. The commands shown below will change depending on how many channels are available on your controller. The controller we are using has 6 on-board channels (See Byte 11 Below), so please keep this in mind when reviewing this sample:
| Byte | Byte | Byte |
|---|---|---|
| Number | Value | Description |
| 1 | 170 | Fusion API Header Frame |
| 2 | 14 | This Command will Contain 14 Bytes |
| 3 | 188 | Fusion Processor I²C Header Byte |
| 4 | 50 | Fusion Processor I²C Port 0 (51 = Port 1, etc.) |
| 5 | 10 | Write 10 Bytes of Data to the I²C Port |
| 6 | 84 | I²C Start Address (42×2)+0 for Write Operation |
| 7 | 146 | I²C Processor Header Byte 1 |
| 8 | 106 | I²C Processor Header Byte 2 |
| 9 | 1 | I²C Command for Reading Current Value Data |
| 10 | 1 | I²C Command for Reading Start Channel 1 |
| 11 | 6 | I²C Command for Reading End Channel 6 |
| 12 | 0 | I²C Command Byte Reserved for Future Use |
| 13 | 0 | I²C Command Byte Reserved for Future Use |
| 14 | 4 | Checksum for I²C Frame = 8-Bit Sum of Bytes 7 through 13 |
| 15 | 85 | I²C Start Address (42×2)+1 for Read Operation |
| 16 | 19 | Read 19 Bytes of Data from the I²C Port (3 Bytes per Channel + Checksum) |
| 17 | 116 | Fusion API Checksum = Sum Bytes 1 through 16 Truncated to the Lower 8 Bits |
Since our sample controller has 6 channels, and our request was for current readings of all 6 channels (Byte 11 above), we are expecting 19 bytes back from the controller (Byte 16 above). Three bytes are allocated for each channel + 1 checksum byte for all 6 channels (6×3)+1 = 19 Total Bytes. Here is an example of what will be returned:
| 1 | 170 | Fusion API Frame Header |
| 2 | 19 | Fusion API Indicates 19 Bytes in this Packet |
| 3 | 0 | Channel 1 Most Significant Byte |
| 4 | 0 | Channel 1 Mid Significant Byte |
| 5 | 0 | Channel 1 Low Significant Byte |
| 6 | 0 | Channel 2 Most Significant Byte |
| 7 | 0 | Channel 2 Mid Significant Byte |
| 8 | 0 | Channel 2 Low Significant Byte |
| 9 | 0 | Channel 3 Most Significant Byte |
| 10 | 0 | Channel 3 Mid Significant Byte |
| 11 | 0 | Channel 3 Low Significant Byte |
| 12 | 0 | Channel 4 Most Significant Byte |
| 13 | 0 | Channel 4 Mid Significant Byte |
| 14 | 0 | Channel 4 Low Significant Byte |
| 15 | 0 | Channel 5 Most Significant Byte |
| 16 | 0 | Channel 5 Mid Significant Byte |
| 17 | 0 | Channel 5 Low Significant Byte |
| 18 | 0 | Channel 6 Most Significant Byte |
| 19 | 0 | Channel 6 Mid Significant Byte |
| 20 | 0 | Channel 6 Low Significant Byte |
| 21 | 0 | 8-Bit I²C Checksum of Bytes 3 through 20 |
| 22 | 189 | Fusion API Checksum (8-Bit Sum of Bytes 3-21) |
Here is how we convert each channel data into usable real-world amperage readings. Remember, 3 bytes per channel:
Dim CalcACCurrent1 As Integer = ((CurrentReadings(0) * 65536) + (CurrentReadings(1) * 256) + CurrentReadings(2))
Amps = (CalcACCurrent1 / 1000)
Watts = ((CalcACCurrent1 / 1000) * SystemVolts