With almost 8 billion souls to feed and a changing climate to deal with, there’s never been a better time to field a meaningful “Internet of Agriculture.” But the expansive fields that make industrial-scale agriculture feasible work against the deployment of sensors and actuators because of a lack of infrastructure to power and connect everything. So a low-power radio network for soil moisture sensors is certainly a welcome development.
We can think of a lot of ways that sensors could be powered in the field. Solar comes to mind, since good exposure to the sun is usually a prerequisite for any cropland. But in practice, solar has issues, the prime one being that the plants need the sun more, and will quickly shade out low-profile soil-based sensors.
That’s why [Spyros Daskalakis] eschewed PV for his capacitive soil moisture sensors in favor of a backscatter technique very similar to that used in both the Great Seal Bug and mundane RFID tags alike. The soil sensor switches half of an etched PCB bowtie antenna in and out of a circuit at a frequency proportional to soil moisture. A carrier signal from a separate transmitter is reflected off the alternately loaded and unloaded antenna, picking up subcarriers with a frequency proportional to soil moisture. [Spyros] explains more about the sensor design and his technique for handling multiple sensors in his paper.
We really like the principles [Spyros] leveraged here, and the simplicity of the system. We can’t help but wonder what sort of synergies there are between this project and the 2015 Hackaday Prize-winning Vinduino project.
Continue reading “Using Backscatter Radio for a Soil Sensor Network”
Recently ZDNet and Gizmodo published articles outlining a critical flaw in a large array of personal printers. While the number of printers with this flaw is staggering, the ramifications are even more impressive. Ultimately, any of these printers could have documents sent to them stolen even if the document was only intended to be printed as a hard copy.
Luckily the people responsible for this discovery are white-hat in nature, and the release of this information has been made public so the responsible parties can fix the security flaws. Whether or not the “responsible party” is the manufacturer of the printer, though, is still somewhat unclear because part of the exploit takes advantage of a standard that is part of almost all consumer-grade printers. The standard itself may need to be patched.
Right now, however, it doesn’t seem clear exactly how deep the rabbit hole goes. We all remember the DDoS attack that was caused by Internet of Things devices that were poorly secured, and it seems feasible that networked printers could take some part in a similar botnet if a dedicated user really needed them. At the very least, however, your printed documents might not be secure at all, and you may be seeing a patch for your printer’s firmware in the near future.
We all know feature creep can be a problem in almost any project. A simple idea can often become unusable if a project’s scope isn’t clearly defined in the beginning. However, the opposite problem sometimes presents itself: forgetting to include a key feature. [Zach] had this problem when he built a Raspberry Pi magic mirror and forgot to build a physical reset/shutoff switch. Luckily he had a spare Amazon Dash button and re-purposed it for use with his Pi.
The Raspberry Pi doesn’t include its own on/off switch. Without installing one yourself, the only way to turn off the device (without access to the terminal) is to unplug it, which can easily corrupt data on the SD card. Since [Zach]’s mirror was already complete, he didn’t want to take the entire thing apart just to install a button. There’s already a whole host of applications for the Dash button, so with a little Node.js work on the Raspberry Pi he was able to configure a remote-reset button for his mirror.
This is a similar problem for most Raspberry Pi owners, so if you want to follow [Zach]’s work he has done a great job detailing his process on his project site. If you’re looking for other uses for these convenient network-enabled buttons, he also links to a Github site with lots of other projects. This pizza button is probably our favorite, though.
NASA has been tracking bright meteoroids (“fireballs”) using a distributed network of video cameras pointed upwards. And while we usually think of NASA in the context of multi-bazillion dollar rocket ships, but this operation is clearly shoe-string. This is a hack worthy of Hackaday.
The basic idea is that with many wide-angle video cameras capturing the night sky, and a little bit of image processing, identifying meteoroids in the night sky should be fairly easy. When enough cameras capture the same meteoroid, one can use triangulation to back out the path of the meteoroid in 3D, estimate its mass, and more. It’s surprising how many there are to see on any given night.
You can watch the videos of a meteoroid event from any camera, watch the cameras live, and even download the meteoroid’s orbital parameters. We’re bookmarking this website for the next big meteor shower.
The work is apparently based on [Rob Weryk]’s ASGARD system, for which the code is unfortunately unavailable. But it shouldn’t be all that hard to hack something together with a single-board computer, camera, and OpenCV. NASA’s project is limited to the US so far, but we wonder how much more data could be collected with a network of cameras all over the globe. So which ones of you are going to take up our challenge? Build your own version and let us know about it!
Between this project and the Radio Meteor Zoo, we’re surprised at how much public information there is out there about the rocky balls of fire that rain down on us every night, and will eventually be responsible for our extinction. At least we can be sure we’ll get it on film.
So you’ve built out your complete home automation setup, with little network-connected “things” scattered all around your home. You’ve got net-connected TVs, weather stations, security cameras, and whatever else. More devices means more chances for failure. How do you know that they’re all online and doing what they should?
[WTH]’s solution is pretty simple: take a Raspberry Pi Zero, ping all the things, log, and display the status on an RGB LED strip. (And if that one-sentence summary was too many words for you, there’s a video embedded below the break.)
Continue reading “Colorful Display Keeps Track of Your Network”
[danman] has been playing around with various HDMI video streaming options, and he’s hit on a great low-cost solution. A $40 “HDMI extender” turns out to actually be an HDMI-to-RTP converter under the hood.
He’d done work previously on a similar extender that turned out to use a quirky method to send the video, which he naturally reversed and made to do his bidding. But non-standard formats are a pain. So when he was given a newer version of the same device, and started peeking into the packets with Wireshark, he was pleasantly surprised to find that the output was just MPEG-encoded video over RTP. No hacking necessary.
Until now, streaming video over an IP network from an arbitrary HDMI output has been tricky, [danman] has been more than a little obsessed with getting it working on the cheap. In addition to the previous version of this extender, he also managed to get a stream out of a rooted Android set-top box. That costs a bit more, but can also record at the same time, should you need to.
None of this solves the HDMI HDCP encryption problem, though. You’re on your own for that one.
(Those of you Wireshark wizards out there will note that we just swiped the headline image from the previous version of the project. There were no good images for this one. Sorry about that.)
[Ronald] has been improving his audio set-up for a while now, his latest revision culminating in this WiFi enabled center channel speaker. It all started with feature creep as you can see in this direct quote, “Being an engineer, I couldn’t stop here, not now that I had a way of adding more features…”
He had purchased a new amplifier for his system, but was irritated that the loudness setting would re-enable itself every time he switched inputs. First he thought he might just have a little board that intercepted the signals from his remote and tacked on the loudness off signal. It occurred to him that it would be even cooler if he could control it from his computer or phone. So he opened the case on his new amp and discovered an i2c break-out. We can guess how it went after that.
In version 2.0 he kept most of his work from 1.0, but wanted to simplify the set-up and build it all into a center speaker unit since an amplifier and two speaker cabinets takes up too much room. He fit a similar set-up as before in the center speaker casing, but added a touch screen and a few other improvements. Though, strangely, he ran into some problems upgrading to the Raspberry Pi 2.0 and had to revert.
The final result is very nice, though obviously not done. As the engineer’s mantra goes, “If it ain’t broke, it doesn’t have enough features yet.”