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 â€¦