Our friend Kerry from The Smarter Home Club pokes a pin in the balloon of our most basic technological concept while sharing his troubleshooting process with RFLink and its problems relating to a grouchy anemometer….
Everyone using modern technology has experienced issues with wireless reception of one sort or another. It’s frustrating to have a cellphone that works one moment and drops out the next. In most situations the technology includes safeguards like a cellphone automatically picking back up the signal and continuing with the call, or WiFi automatically re-sending data so fast you don’t even know anything was lost. This is possible because these technologies are two-way communications and the two “ends” of the connection acknowledge what’s been received.
One particular wireless technology I’ve been using as part of my home automation system, 433MHz RF, isn’t quite so sophisticated. It’s led to some interesting experiments, some frustrations and some realizations. The same conclusions would hold for 315MHz, 433MHz and 868MHz systems. All of these frequencies are used in various countries for many remote control and low speed data communications applications. If you have a wireless weather station, a wireless alarm system or inexpensive remote controlled plugs, they are likely using this type of technology.
My fascination with 433MHz originated when I discovered a project called RFLink that is a gateway between RF protocols and home automation. When I set up my first RFLink device, it immediately found and started recording temperature and humidity readings from some sensors that previously were only displayed on a small clock that sits on a side table. Now I can graph the difference between indoor and outdoor temperatures (as well as my attic and garage) and know how well the air conditioning is keeping up as the seasons change.
I recently found an anemometer (wind speed device) that was cheap and sold separate from the weather station it must’ve been built for. The brand was one I recognized as working with RFLink, so I bought it. Having recently spent time tweaking the antenna on my RFLink device in order to better receive all of the temperature and other devices in and around my house, I wasn’t too shocked by the fact I didn’t immediately pick up the transmissions from the anemometer. I’m used to needing to re-position the transmitters or the receiver’s antenna to get things to work well. But I quickly found that this particular unit only worked literally a few inches away from the receiver. That’s not going to work very well for a device meant to measure the wind speed. Outdoors, of course.
The seemingly weak reception of the signal from the anemometer was the impetus for another series of investigations. I’ll take something apart at the drop of a hat! What I immediately learned about this particular model is it has a separate module that does the 433MHz communications. It’s the little “daughter card” in the picture below, with the shiny metal spring antenna attached to it. This is good news, I thought, because worst-case, if the original transmitter is weak because it’s not working properly, I have a replacement module that should work.
But first I’d need to determine if this is indeed the problem. I have some basic test equipment including multi-meters, and a low-frequency oscilloscope, but nothing like a signal-strength meter or spectrum analyzer, tools that someone with more radio frequency experience might use to thoroughly investigate this situation. Still, I could use the distance from the receiver as a measure of signal strength, I thought.
So I tested all of the usual suspects. Were the batteries good? Making a good connection? I determined that power was getting all the way to that transmitter module. It appears it runs off 2.1 volts, as there is a tiny voltage regulator and that’s the only component aside from a diode in the circuit I traced all the way back to the batteries. If it’s indeed intended to run off 2.1 volts, then I had to conclude that the assumed signal weakness was either in the module itself or related to the antenna on the transmitter. (For a short while I entertained the idea, suggested by a fellow electronics hobbyist, that the power supplied to the transmitter was “noisy” and might lead to degraded reception. While I didn’t rule that out as a contributing factor, I’ve measured it in my final configuration and decided it’s not significant.)
With the transmitter module being a tiny device with circuit mount components and nothing I could really try to diagnose without a schematic, I eventually moved forward with the idea of replacing the module. I first needed to make sure that the module I had, which only has three pins, could work well in place of the 4-pin unit that would come out. The pins are clearly labeled on both. They share the common connections: power, ground and data. The fourth pin on the old module is an “enable” line. That would be used to keep the transmitter from drawing any significant power during times that transmissions aren’t being sent. This is to increase battery life. Fortunately, measuring the current drawn by the new device when it is idle showed there wouldn’t be an issue. It basically puts itself in a low power mode when there’s nothing received on the data input, I think.
But here’s the kicker, and where this story turns into an interesting learning experience: The new module, which is now being powered directly from the batteries, at 3.2V (because it can accept a higher range of input voltage) is also apparently very hard to receive. It is perhaps a small improvement, but doubtful it would make it from the roof to inside the house. So this is where the story takes an interesting twist requiring a new way of thinking about the problem.
Let’s assume that this was never a matter of the signal strength or even the signal quality of the transmitter. Where could the real problem reside? Perhaps my RFLink receiver, known to work with so many other devices, is failing me in a less-than-obvious way. Clearly the receiver is on the correct frequency, 433MHz, as so many of the other devices it receives around the house confirm this. And the antenna must be a good fit and placed in a reasonable place, given all of the rest of my experimentation with trying to get many other devices all working together.
Yet this anemometer defies all of that logic, seemingly.
What about the RFLink software itself? Can we question that? If the anemometer works up close, then surely it “understands” the protocol, right? Think of “protocol” as a language or a code. In fact, for devices like the 433MHz weather sensors we are discussing, it’s rather like Morse Code—a series of short and long pulses signifying zeros and ones instead of letters. It’s “digital”.
We usually think of digital systems as simply “working” or “not working.” We don’t think of the kinds of problems that exist in the analog world like being a little off frequency or not powerful enough. Software is either right or wrong, working or buggy, right? If the RFLink understands the protocol, then what could the distance between the transmitter and receiver possibly affect?
Well, here’s a shocker for you: there is no “DIGITAL”. It’s something that’s made up to make us think things are easier and simpler than they really are. What’s the most “digital” thing you can think of? What I came up with is the storage of data on various “digital” media, like DVDs, USB drives and disk drives. They span three realms: light, electricity and magnetism. As nice as it is to think about the “1”s and “0”s as existing in some concrete fashion in those three worlds, every one of them has an analog element: The size of the laser-cut hole in a DVD, the amount of charge representing a “bit” on a USB drive, and the amount of magnetic flux density on a disk drive know nothing of “1” or “0”. They are all analog phenomena.
So back to our 433MHz protocol, with the dashes and dots similar to Morse Code, representing ones and zeros… How long does a pulse need to be before a dot becomes a dash? It’s a matter of timing.
In all of these “digital” representations, there must be a threshold.
The size, amplitude, strength, or duration of whatever stores or represents “0”s and “1”s must exceed a certain measurement to flip from a “0” to a “1” in each of these cases. For RFLink to interpret a 433MHz protocol that’s representing digital data, it must be measuring pulses of the transmitter’s signal being on or off and using the time, compared against a threshold, to determine what’s a one or a zero.
Now, how does this relate back to my distance problem? Let’s talk about another problem the RFLink software has to solve. When it receives a series of on/off pulses, it needs to decide is this a temperature reading from a Lacrosse device, or wind speed from an Acurite? It needs to discriminate between many, many different protocols. To do this, it needs to recognize patterns. If one brand uses a pulse that should be measurements like 40-20-40-40 and a different brand is 30-10-30-10, it should be easy to tell them apart. So undoubtedly in the software, there are thresholds in time durations that help it determine which specific protocol it needs to decode.
And, if a pulse with is somewhere in-between, like maybe 35? It probably throws it out as bad data.
Now here’s the crux of my new theory as to why the anemometer only works up close to the RFLink antenna: The thresholds for deciding what’s a “good” signal were determined empirically. And to easily manipulate the readings, it was probably very close to the receiver. With a good, strong signal, close by, thresholds were set to discriminate on what is a “good” series of pulses from the anemometer.
Now, what happens when it’s moved off at a distance? There is no “digital”. The pulse widths aren’t exact, and the laws of physics in the material world translate to unforeseen changes. A little distance between the transmitter and receiver means the timing of what’s considered a long or short pulse might change a bit, due to the analog nature of transmissions. A weaker signal might read as a slightly shorter pulse, for example. What we might have is a case of over-fitting. The ideal situation of a close-by transmitter and receiver made the empirical data consistent and precise, but not a representation of the real-world situation where distance introduces variations.
Well, there’s a moral to this story. Instead of using the RFLink software in its normal mode where it only reports signals it is able to decode, I should have turned on the debug mode long ago. When I was trying to figure out what was going on as I moved the anemometer further away than a few inches and it dropped of entirely, I should have looked at the debug output from RFLink, which shows even signals that it doesn’t recognize. This would remove the thresholds from the equation.
I plan to capture some of the debug output, with the anemometer closer and farther away in different tests, and send it to the RFLink programmers, to hopefully improve their interpretation of the protocol, and make it work at a greater distance.
SmarterHome.club is the website for our Facebook community, The Smarter Home Club – which is an umbrella for all kinds of smart home technologies – home automation, security, custom electronics, weather stations, alternative energy, you name it. DIY focused.
If you’re interested in joining the Smarter Home Club’s Facebook group, please follow this link: