Friend mentioned that he received a device from the local electric utility that lets him monitor his home energy use in near real time. After I ordered the same (free) device, I thought about using my rtl-sdr to do the same thing.
There are programs existing for the purpose and I figured it would be trivial to use them.
What I found:
First, it's not trivial. I should have known that.
I wish I had followed this order:
1. Calibrate the rtl-sdr. I roughly followed the steps on this website: http://rtl-sdr.sceners.org/?tag=calibrate-rtl2832u
The calibration is sensitive to temperature. So, run a program like sdr# for a while to get the device warmed up.
Get the kalibrate program.
run it:
kal -g 42 -e 22 -s 850
The output:
Seed it with a ppm (e.g., 41) and pic the strongest channel from above step (250 in my case)
kal -e 41 -c 250 -v
...and finally
Now you have the 36 ppm as the offset you need.
Saturday, April 2, 2016
Tuesday, February 2, 2016
Reverse engineer smart meter data packets (Part I)
I received an Energy Bridge from my electric utility, DTE. DTE
has a great smartphone app but I wanted a way to intercept the data
from the Energy Bridge to monitor the real-time data without the
smartphone.
I had previously opened up the Energy Bridge and found an XBee SMT board. I assumed the XBee was communicating to the smart meter and gating the data to the ethernet connection.
As a first step to intercept smart meter data, I put a shared internet connection between the Energy Bridge and the Internet and recorded TCP packets using Wireshark. The ethernet route I used did not allow the Energy Bridge to connect to the Internet. Although I could see packets to/from relaypilot.vectorform.com 208.81.180.78, I could not be sure the packets were reporting good data from the smart meter. I have some ideas how to improve this but they will wait for Part II.
Since the TCP packet sniffing turned out to be slower than I had hoped, I opened up the Energy Bridge again to poke around to see if I could tap in to the serial data between the XBee board and the microprocessor that was talking to the Internet. First, I found the schematic of the XBee board online and looked for the DOUT and DIN pins, that are pins 3 and 4.
Those pins are right next to the tricolor LED and they have traces running from them. So, it looks like they are connected to something.
So, I added a couple of wire taps to pins 3, 4, and 13 for ground.
I measured the signals with an oscilloscope and confirmed that it looks like serial data should look.
I looked at the shortest pulse duration at a given state to determine the baud rate. The shortest pulse was ~8.75us wide. I calculated 1 bit / (8.75E-6 sec) = 114285. That is close enough to 115200 bit/s or 115200 baud.
Once I knew the baud rate, I hooked up the wire leads to an Arduino and wrote a little script to read the data from the XBee Pro and transmit them to the PC. I could see 8 bits in between the start bits and then assumed no parity and 1 stop bit.
The first few bytes of the data packet in hex format looked like
The 7E, 0, 7, and 8B were constant.
The 18 is a counter running from 00 to FF incrementing by 1 in each packet.
The five 0s were constant.
The 5E looks like a counter running from FF to 00. It goes down by one in each packet.
I also manually decoded a few bytes from the oscilloscope traces to make sure the bitbang serial in the Arduino was working correctly.
The full packet is about 43 bytes long.
I was not entirely successful in intercepting and decoding the smart meter data yet but I can see the consumption data in the 43 bytes. It moves in a similar way as the real-time data in the smartphone app.
In Part II I will make a data logger to look at the packets over time and hopefully correlate the serial data with the TCP packets.
Stay tuned!
Subscribe to:
Posts (Atom)