Update 2014-10-02: I’ve forked Bryan’s Arduino code and added some instructions: scruss/Powermon433 (though use Bryan’s, srsly)
Update 2014-08-19: Bryan Mayland has decoded the data on Arduino! More details here: CapnBry/Powermon433
Given that I first started thinking about reverse-engineering the Blueline Powercost Monitor‘s data stream in September 2010, I hardly win any awards for rapid development. Here’s what I know so far about the device and its transmissions:
- The Blueline unit and the (now discontinued) Black & Decker Power Monitor (EM100B) appear to be functionally identical. Both transmit data using simple ASK/OOK at 433.92 MHz in the ISM band.
- It is, however, completely different from the Norgo NGE101 meter, dammit.
- The display unit is made by Hideki Electronic Limited, who make many small weather stations and wireless displays. [Pictures of the display circuit boards]
- The transmitter unit was designed by Intectus in Ottawa for Blueline. It uses a TI MSP430 µcontroller. [Transmitter board picture]
- The transmitter can be triggered by simulating a power meter if you flash a 940 nm IR Emitter LED for 50 ms into its sensor. 1× 50 ms flash represents 1 Wh of power consumed. A pulse frequency of 1 Hz represents 3.6 kW consumption.
- The transmitter sends a bundle of three (seemingly) identical packets every 31.8 seconds. These appear to contain consumption data, as the display updates approximately every 32 seconds.
- A series of contiguous packets, recorded as audio using a simple circuit described by the Protocol Analyzer project: audio201311182215-silenced (FLAC; please note that interstitial silences have been blanked to reduce file size).
- Temperature packets may be sent separately from power, as the display updates temperature much more slowly than power use.
- Power packets only appear to contain use data (along with a transmitter ID). If the sensor receives an absolutely constant input, the packets transmitted 32 s apart can be identical.
- The packets appear to be Manchester-encoded.
Some rough notes on mark/space timing (all times in µs):
Mark : Mean 529.4 Min 499.0 Max 590.0 StdDev: 15.03 Space: Mean 694.5 Min 385.0 Max 1474.0 StdDev: 281.57
Mark/space times, by frequency (all times in µs):
MARK
====
µS
Rank Value Count
-------- ------- -----
1 522 498
2 544 206
3 567 32
4 499 32
5 590 8
SPACE
=====
µS
Rank Value Count
-------- ------- -----
1 476 279
2 975 223
3 454 99
4 952 65
5 431 26
6 1474 22
7 408 21
8 499 17
9 998 12
10 199000 8
11 385 2
12 1451 2
More later, including raw packet data.
Thanks to Randy Simons and Bryan Mayland for the recent help. Thanks too to Brett “Wiring” Hagman for asking just why I was trying to do this …