Tag: rf

  • Blueline / Black & Decker Power Monitor RF Packets

    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]
      Inside a Black & Decker Power Meter
    • The transmitter unit was designed by Intectus in Ottawa for Blueline. It uses a TI MSP430 µcontroller. [Transmitter board picture]
      Black & Decker Power Monitor: Meter Transmitter board
    • 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.
      Arduino-based domestic power meter simulator
    • 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 data packet bundle
    • 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.
      powermeter-203453vs203525
    • 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 …