Improving RTL-SDR Decoding of the Efergy Wireless Energy Monitor

In all of my excitement after discovering that Efergy Wireless Energy Monitors could be decoded using the data from an RTL-SDR dongle and a program written by Nathaniel Elijah, there were still several investigations I needed to conduct to determine why I found decoding with the R820T more difficult.

I suppose the biggest thing to come out of my experiment is this:

I retract my finding that the E4000 is better at pulling signals from the air for decoding Efergy Wireless Energy Monitors. In fact, the R820T can perform similarly well, although taking into note what I will say in the following sections.

This is good news for everyone!

 

So you ain’t got no decode?

I started off just by plugging the dongle and executing the given instructions, almost blindly, hoping for a result. When I got one from the E4000 reliably, and none from the R820T despite playing with the gain, I came to the wrong conclusion that the R820T was worse.

The reason why this is the case becomes apparent when I fire SDR# on both dongles.

Efergy-E4000-42dB

The above is the E4000, note the bursts at 6 second intervals on the waterfall coming out reasonably over the background noise. The demodulation bandwidth has been adjusted to WFM mode, 200khz, centred near 433.55Mhz as the setting would have been for rtl_fm, also with the frequency correction at 0ppm (as the rtl_fm does not apply any correction to my knowledge).

Efergy-R820T-49.6dB

This is the output from the R820T. Do I see a problem? Hell yeah I see a problem! See how the FSK is at the band edge – in fact, it’s almost out of the edge entirely? It’s outside the demodulation bandwidth due to crystal tolerances!

It was at this point I went “D’oh. My bad!”

The solution to this is obvious. When issuing the rtl_fm part of the command, replace 433550000 with say 433510000 for this particular dongle. In fact, visualize your signal before you try to decode it – you will find values from 433500000 to 433600000 might be necessary for frequency, noting the aim to keep the demodulation frequency at the centre of the bursts to allow for some drift as the temperature changes and to ease the burden on the demodulation algorithm.

The second thing to notice is that the peaks are only just visible despite the tuner gains being maxed out. Yikes. Measuring the antenna gave us the answer – it’s tuned horribly for use at 433Mhz.

The quarter wavelength of 433Mhz is about 17.5cm. I cut a piece of solid core wire to 18cm, stripped about 0.5-1cm off the end and (unlovingly) jammed it into the centre pin of the MMCX connector, leaving it standing vertically proud of the tuner. For comparison, the stock antenna is shown to the side. I would suggest you avoid doing this, as you may permanently flail the centre pin of your tuner and leave it unable to contact MMCX connectors properly in the future. If you damage your tuner this way, that’s your problem – I take no responsibility for what you do here.

Efergy-Antenna

Having the right antenna is key to making sure you get a good signal. Unfortunately, a configuration like this leaves the antenna right next to the tuner and computer and that leaves it vulnerable to picking up hash noise which raises the noise floor. But I figured, as long as it improves the reception of the desired signal without introducing too much hash noise, it’s definitely worth it as it improves the “golden metric” – the signal to noise ratio.

Efergy-R820T-Wireant-3.7dB

Notice now, I’ve got the gain turned down to just 3.7dB and the signals actually are quite clean off the background noise? It’s an excellent outcome, and you really should at least take the effort to do something *this* simple to improve your reception.

Testing it all out

Seeing that my Chromebook was otherwise occupied, I grabbed my old Dell Inspiron 640m running Lubuntu 13.10 to do the experiments.

Grabbing the latest rtl_sdr and building it was no hassle, as was building the source code by instruction. One thing you will have to do is sudo rmmod dvb_usb_rtl28xxu at the prompt on tuner insertion, because there is a driver which will take over the USB tuner and prevent rtl_sdr from being able to use it at all.

Even stupidly leaving the gain maxed out at 49.6dB, it decoded reliably every six seconds despite picking up a whole lot of noise from the digital circuitry on the tuner itself. I’m sure the decoding reliability would have only improved with the gain going down as it would have improved the signal to noise ratio. The frequency was changed to 433.51Mhz to account for the crystal differences.

Lubuntu

This is a solid showing for the code – I haven’t touched it, and it runs on virtually everything. CPU utilization was much healthier running on a beefy thing such as a laptop.

Hmm …

This development has just suddenly lead to a thought. As many people are concerned about the advent of wireless smart meters, and the ability of unauthorized people to access the data (and the ability of authorized people to misuse the data), owning and operating a wireless energy monitor like this is actively broadcasting, without protections of any sort, your energy usage to your immediate surroundings!

In fact, running a decoder system like this requires no interaction with an existing system – it does not need to be paired at all. Thus, a system like this could inadvertently reveal when you are home, when you are not, what you are using at a given time. The paranoid would immediately consider this a giant risk, however, I think the risk is still rather small.

This system has no ability to switch my appliances on or off, burn down the house, etc.

But I suppose one should be aware that with a high gain antenna, it may be possible to receive and decode usage figures from people’s transmitters more than the intended 10-100m range.

Conclusion

It’s best not to just take what you are given and plug it in and hope for the best. I came to the wrong conclusion because I just blindly followed the instructions. Further investigations show that decoding performance can be improved by proper selection of centre demodulation frequency (duh) and improving the antenna itself (double duh). R820T owners rejoice!

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Electronics, Radio and tagged , , . Bookmark the permalink.

7 Responses to Improving RTL-SDR Decoding of the Efergy Wireless Energy Monitor

  1. Johan Adler says:

    A quick look at the source tells me that rtl_fm does indeed use the ppm correction given on the command line with option -p. My own experience confirms this, as I get bad or no reception/decoding unless I give rtl_fm a decent approximation of the ppm value for the dongle. I am only using R820T dongles and I have not had any problems receiving and decoding anything yet.

    • lui_gough says:

      Hi Johan,

      Indeed, that is right if you provide the -p option, and have already established it using kalibrate-rtl or something similar. You could always derive one of your own with some simple math, and add it to the command line. If you do have a value, then it will be much closer in terms of tuning which will be enough since the frequency shift is fairly big, you don’t need to be quite so accurate.

      That being said, for very narrowband (4khz) signals, I prefer to just determine the uncorrected frequency as indicated by SDR# with 0ppm correction in order to get as close as possible to the centre (although it will drift slightly thanks to temperature dependency). My experience with narrowband signals have indicated the possible need for a more accurate correction factor. I suppose it’s two different approaches, both of which result in the tuner demodulating the range of frequencies we’re interested in. 🙂

      – Gough

      • Johan Adler says:

        (I get error messages when trying to comment, not sure why…)

        I have tried several different methods for finding the proper frequency correction factor, including ‘rtl_test -p’, LTE-Cell-Scanner from https://github.com/Evrytania/LTE-Cell-Scanner, some GSM method, using gqrx and local FM stations, and more.

        When looking at the 433.92 MHz ISM band I think and hope that my most accurate method is to use my Wouxun KG-UV6D to transmit a strong signal at 433.92 MHz and check the deviation in gqrx.

        I do agree about temperature, one problem with the LTE approach is that it will not keep the dongle active for long, meaning you most likely get a correction factor for a cold dongle. Apart from that my impression so far is that the LTE approach potentially gives the most accurate estimate. On the other hand ‘rtl_test -p’ seems to be good enough in most cases.

        Since earlier today I have 8 dongles (all with R820T tuner), and I use rtl_eeprom to put the ppm value in the serial number string for each dongle. That way I can always find the right ppm for the dongle I am currently using. (Initially all my dongles have ‘00000001’ for serial.)

        • lui_gough says:

          Dear Johan,

          Thanks for your replies – yes I am aware of an issue with commenting with the error, but rest assured, your comments are safe. I take it that you’re probably in the USA given your use of LTE – unfortunately in Australia, LTE here isn’t at 700Mhz. Instead, we use the 1800Mhz band which (from what I know) puts it out of reach of the RTL R820T based dongles.

          GREAT idea with the programming of the EEPROM serial number for unique identification/parameter storage. Just this morning, I was wondering whether there was a way to program it. It turns out most of my RTL2832U + R820T’s have 000000001 for serial, however, my RTL2832U + E4000’s have unique serials. I guess it comes down to the OEM whether they bothered to do this – but it could make it handy say in multi-dongle installations hooked up to sectorial/yagi antennas to make easy identification of which tuner to use.

          Of course, kalibrate-rtl works for me wherever I’m in a strong GSM area, but unfortunately, it doesn’t always build on all my machines (I have issues with fftw3 on some of my ARM based “playthings”), but it normally gives me about 31ppm for some of my R820T dongles, and about 16ppm for my “mini” R820T’s. I tend to find the mini ones run hotter, but the crystal seems to hold more stable (surface mount type rather than the HC-49S through hole type).

          Thanks for your persistence in submitting comments – sorry for the error message. If I knew how to fix it, I would, but I suspect my very poor web host won’t help me with the required settings.

          – Gough

          • Johan Adler says:

            I am actually in Stockholm, Sweden, and used Wikipedia and other sources to learn that there are LTE cells in the 800 MHz band here (806.0 MHz being strong where I live). There may also be cells in the 900 MHz band here, I have not bothered searching for them.

            Since I am trying to write some programs of my own for the rtl-sdr dongles I have considered the possibility of having my software read the eeprom and use the ppm value from it, if available. (One reason for making custom software is the bloated GNU Radio, basing my code on the rtl-sdr package I get smaller and more efficient code, I hope. Being new to DSP it might take some time to optimize my work, though.)

            Earlier today I picked up another 5 of the dongles I favour (http://www.ebay.com/itm/221256431317) — the first one I bought has an error of just 7 or 8 ppm. I am currently testing one of the new ones, it seems to have an error of 8 to 9 ppm, and I noticed that LTE-tracker can run as long as I want it to, giving me an estimate of the warm dongle error. I guess it is kalibrate that has the persistance problem.

            By the way, my favourite dongles has surface mounted crystals too (http://www.flickr.com/photos/nyfiken/11009832516/), that combined with the low ppm and the small PCB helped me decide to order more of them.

            Oh, I found your site through http://rtlsdr-dongle.blogspot.se/2013/11/finally-complete-working-prototype-of.html as I am trying to decode the transmissions of an Efergy Elite 2.0R using all three possible clamps. I have not solved that one yet. 🙁

          • lui_gough says:

            Dear Johan,

            Do let me know how you go with it – I suspect that the three clamps contribute just one value (combined three phases) to the ADC in the transmitter which is sent over the air. I’m not entirely sure that this is the case, but if anything, Nathaniel Elijah of http://rtlsdr-dongle.blogspot.com.au/ should know and might be able to help you.

            I have considered buying those dongles, but instead, I’ve used a mixture of these (low error) http://goughlui.com/?p=3821 and these (high error) http://goughlui.com/?p=3866

            Part of the reason was that I didn’t prefer the Belling-Lee PAL type connector, and although MMCX isn’t that durable, I had several MMCX adapters which are easy to work with.

            Good luck with your development work. I’m sure it will find an audience, as I too find gnu-radio a bit big, slow and unwieldy to work with.

            – Gough.

  2. Mark says:

    Hi,

    I have a slightly different efergy device. The efergy E2IR. This uses an IR LED to detect pulse flashes from the utility electricty meter. It then displays the dat on a monitor ver similar to the classic.

    The big difference is that it only sends a data burst every 30 seconds. It hasa nominal frequency of 433.5 MHz, but mine actually transmits on 433.495MHz. I can clearly pic up the data bursts every 30 seconds with my R820T.

    My question is how do you record and analyse the bursts (I have tried audacity with limited success).

Error: Comment is Missing!