Technical details of Current Cost RF protocol
The RF modules used in the Current Cost devices appear to be the HopeRF RFM01 receiver and RFM02 transmitter. In turn, these are based on the RF Monolithics RXC101 and TXC101 devices. The RF side uses FSK modulation, with a nominal centre frequency of 433.90MHz, but this varies due to tolerances. The modules use a data rate of 3918bps and are configured with a baseband bandwidth of 67kHz.
Each packet that is transmitted is prefixed by a preamble byte and a sync word. This is to help to receiver to lock onto the signal and to identify a valid transmission. Failure to include them means the receiver won't see your packet! The preamble pattern is an alternating bit pattern of either 0x55 or 0xAA. The sync word is fixed at 0x2DD4.
The remaining data is transmitted with standard manchester encoding. Thus a total of 19 bytes (3 preamble/header, 16 manchester encoded data) are transmitted. It is unknown why manchester encoding is used, as the RF modules deal with clock recovery themselves. The fact that the data is manchester encoded can be used as a check on the data's integrity. If the data is correct then the data must be made up of bit pairs 01 or 10. e.g. 01101010 is OK but 11101010 is not (because the first bit pair is 11 which is illegal).
Prior to manchester encoding, the data packet consists of 8 bytes of data. There appear to be two forms of construction, one for electricity consumption data, and one for electricity, gas, oil and water counter data. The firmware on the EnviR only displays electricity consumption. Pairing a counter sensor results in the EnviR lighting the appropriate indicator and showing the counts per unit transmitted, but otherwise the channel will only show "data" on the display when in use. Data turns up in the XML stream.
The packet consists of a nibble of flag information, and 12 bits of address information, followed by three sets of sensor words.
| Byte | Bit | Description |
| 0 | 7 | Pairing request - set when unit is in pairing mode |
| 0 | 6 | Data sensor indicator, set to zero |
| 0 | 6-4 | Unknown |
| 0 | 3-0 | Address bits 11 to 8 |
| 1 | 7-0 | Address bits 7 to 0 |
| 2 | 7 | Data valid indicator - indicates sensor 1 contains valid data |
| 2 | 6-0 | Data bits 15-8 of sensor 1 |
| 3 | 7-0 | Data bits 7-0 of sensor 1 |
| 4 | 7 | Data valid indicator - indicates sensor 2 contains valid data |
| 4 | 6-0 | Data bits 15-8 of sensor 2 |
| 5 | 7-0 | Data bits 7-0 of sensor 2 |
| 6 | 7 | Data valid indicator - indicates sensor 3 contains valid data |
| 6 | 6-0 | Data bits 15-8 of sensor 3 |
| 7 | 7-0 | Data bits 7-0 of sensor 3 |
The packet consists of a nibble of flag information, and 12 bits of address information, followed by an unused byte, a sensor type byte, and a 32bit counter value. When attempting pairing, the 32bit counter value sets the number of impulses per unit (IPU). When in normal data update mode, the 32bit counter value represents the current count. This way missed packets do not put out the total count.
| Byte | Bit | Description |
| 0 | 7 | Pairing request - set when unit is in pairing mode |
| 0 | 6 | Data sensor indicator - set to 1 |
| 0 | 5-4 | Unknown |
| 0 | 3-0 | Address bits 11 to 8 |
| 1 | 7-0 | Address bits 7 to 0 |
| 2 | 7-0 | Apparently unused |
| 3 | 7-0 | Sensor type. Valid values are: 2-Electric, 3-Gas, 4-Water |
| 4 | 7-0 | Impulse counter bits 31-24 |
| 5 | 7-0 | Impulse counter bits 23-16 |
| 6 | 7-0 | Impulse counter bits 15-8 |
| 7 | 7-0 | Impulse counter bits 7-0 |
[ UID ] [ Payload ] [ '0000' ]
55 69 5A 9A 95 56 95 69 55 55 55 55
Payload bytes: 95 56 95 69
1] Convert to binary: 1001 0101 0101 0110 1001 0101 0110 1001
2] Decode: (Manchester encoding -> Take pairs of binary digits and interpret as follows: 10 == 1, 01 == 0.)
10 00 00 01 10 00 01 10
3] Strip off MSB: 0 00 00 01 10 00 01 10
(MSB=1 if data valid, else 0. Power reading is 15-bit unsigned value in watts)
4] Convert to decimal: [000 0001 1000 0110] = 390, which is our reading in watts.
An alternative packet (base unit reading 9.34kW):
[ UID ] [ Payload ] [ '0000' ]
55 69 5A 9A 99 65 6A A5 55 55 55 55
Payload bytes: 99 65 6A A5
In binary: 1001 1001 0110 0101 0110 1010 1010 0101
Decode, ignore MSB: x 0 1 0 0 1 0 0 0 1 1 1 1 1 0 0
Convert: 10 0100 0111 1100 = 9340W or 9.34kW
The unit generates a 12bit random UID, and transmits a packet with this UID and the pairing bit set. Different devices transmit the pairing packet differently. The digital dev boards retransmit this packet continuously for around 40 seconds, whereas the whole house transmitter retransmits about every 2 seconds. Generally, pairing is trigged by pressing and holding the red button for about 10 seconds and then releasing.
A data device includes additional information in the packet (see above), including the number of impulses per unit. This information is shown on the display while pairing is occurring.
A single TX can appear to be more than one device. The OptiSmart product appears as two devices - one electricity consumption device and one electricity counter device. The UID is different across the two device types of the OptiSmart. Counter data style TX devices cannot switch the type (gas/oil/water/electricity) without regenerating the UID. The EnviR seems to associate this information with the UID, and doesn't updated it if you try to pair multiple times with the same UID. Counter data style TX devices have a 32bit "counter" that can be packed with whatever information you want. The EnviR doesn't appear to do any validation of this information, and simply passes it on in the XML stream. If you wish to have 4 x 8 bit thermometer values in there, nothing is stopping you, other than the fact that you'll need to keep track of what the counter data actually means!
The sensor ID in the XML is a decimal representation of the sensor UID.
Overview:
- Battery powered mains clamp meter, PIC16F698 based unit with detachable clamp
- Transmitter sends every ~6s, accompanied by flash of its LED
- As the meter can't read the voltage across the cable it must calculate power drawn with V as a constant (240?). Could test with known V and I to calculate this constant.
If I remember correctly, my Current Cost "sensable" transmitter just clicked apart: I don't remember having to undo any screws: I think I just forced a flat-head screwdriver into the gap between the top and bottom halves and teased it apart. But I was probably quite heavy-handed with mine ;).
Interestingly, the plastic external aerial is a dummy (it's just a bit of plastic):
- IAM v3 tear down (with photos)
- Old IAM tear down by netcompsys (photos)
- EnviR tear down (with photos)
- Sniffing SPI data from an EnviR (with photos)
- Adding a aerial socket to an EnviR (photos)
- more photos of the inside of an EnviR by netcompsys
- The majority of the info on this page is down to the hard work and generosity of Graham M. Many thanks!