“When all else fails, there’s ham radio.” With Hurricane Harvey just wrapping up, and Irma queued up to clobber Florida this weekend, hams are gearing up to pitch in with disaster communications for areas that won’t have any communications infrastructure left. And the perfect thing for the ham on the go is this ham shack in a box.
Go-boxes, as they are known, have been a staple of amateur radio field operations for as long as there have been hams. The go-box that [Fuzz (KC3JGB)] came up with is absolutely packed with goodies that would make it a perfect EmComm platform. The video tour below is all we have to go on, but we can see a tri-band transceiver, an RTL-SDR dongle and a Raspberry Pi with a TFT screen for tracking satellites. The Pi and SDR might also be part of a NOAA satellite receiver like the one [Fuzz] describes in a separate video; such a setup would be very valuable in natural disaster responses. Everything is powered by a 12-volt battery which can be charged from a small solar panel.
At first glance, the ColibriNANO SDR looks like another cheap SDR dongle. But after watching [Mile Kokotov’s] review (see video below), you can see that it was built specifically for software defined radio service. When [Mile] takes the case off, you notice the heavy metal body which you don’t see on the typical cheap dongle. Of course, a low-end RTL-SDR is around $20. The ColibriNANO costs about $300–so you’d hope you get what you pay for.
The frequency range is nominally 10 kHz to 55 MHz, although if you use external filters and preamps you can get to 500 MHz. In addition to a 14-bit 122.88 megasample per second A/D converter, the device sports an Altera MAX10 FPGA.
We all do it — park our cars, thumb the lock button on the key fob, and trust that our ride will be there when we get back. But there could be evildoers lurking in that parking lot, preventing you from locking up by using a powerful RF jammer. If you want to be sure your car is safe, you might want to scan the lot with a Raspberry Pi and SDR jammer range finder.
Inspired by a recent post featuring a simple jammer detector, [mikeh69] decide to build something that would provide more directional information. His jammer locator consists of an SDR dongle and a Raspberry Pi. The SDR is set to listen to the band used by key fobs for the continuous, strong emissions you’d expect from a jammer, and the Pi generates a tone that varies relative to signal strength. In theory you could walk through a parking lot until you get the strongest signal and locate the bad guys. We can’t say we’d recommend confronting anyone based on this information, but at least you’d know your car is at risk.
We’d venture a guess that a directional antenna would make the search much easier than the whip shown. In that case, brushing up on Yagi-Uda antenna basics might be a good idea.
There was a time when a pair of rabbit ears accompanied every new TV. Those days are gone, but [Thomas Cholakov (N1SPY)] managed to find one of the old TV dipoles in his garage, complete with 300-ohm twinlead and spade connectors. He put it to work listening to a NOAA weather satellite on 137 MHz by configuring it in a horizontal V-dipole arrangement. The antenna legs are spread about 120° apart and adjusted to about 20.5 inches (52 cm) length each. The length makes the antenna resonant at the right frequency, the vee shape makes the radiation pattern nearly circular, and the horizontal polarization excludes signals from the nearby FM broadcast band and directs the pattern skyward. [Thomas] doesn’t mention how he matched the antenna’s impedance to the SDR, but there appears to be some sort of balun in the video below. The satellite signal is decoded and displayed in real time with surprisingly good results.
Itching to listen to satellites but don’t have any rabbit ears? No problem — just go find a cooking pot and get to it.
When [ik1xpv] sets out to build a software-defined radio (SDR), he doesn’t fool around. His Breadboard RF103 sports USB 3.0, and 16-bit A/D converter that can sample up to 105 Msps, and can receive from 0 to 1800 MHz. Not bad. Thanks to the USB 3.0 port, all the signal processing occurs in the PC without the limitations of feeding data through a common sound port. You can see the device in action in the video below.
The Cypress FX3 USB device is an ARM processor, but it is only streaming data, not processing it. You can find the slightly modified firmware, a driver for using PC software, and schematics and board layouts on GitHub.
In 1985, [Wim van Eck] published several technical reports on obtaining information the electromagnetic emissions of computer systems. In one analysis, [van Eck] reliably obtained data from a computer system over hundreds of meters using just a handful of components and a TV set. There were obvious security implications, and now computer systems handling highly classified data are TEMPEST shielded – an NSA specification for protection from this van Eck phreaking.
Methods of van Eck phreaking are as numerous as they are awesome. [Craig Ramsay] at Fox It has demonstrated a new method of this interesting side-channel analysis using readily available hardware (PDF warning) that includes the ubiquitous RTL-SDR USB dongle.
The experimental setup for this research involved implementing AES encryption on two FPGA boards, a SmartFusion 2 SOC and a Xilinx Pynq board. After signaling the board to run its encryption routine, analog measurement was performed on various SDRs, recorded, processed, and each byte of the key recovered.
The results from different tests show the AES key can be extracted reliably in any environment, provided the antenna is in direct contact with the device under test. Using an improvised Faraday cage constructed out of mylar space blankets, the key can be reliably extracted at a distance of 30 centimeters. In an anechoic chamber, the key can be extracted over a distance of one meter. While this is a proof of concept, if this attack requires direct, physical access to the device, the attacker is an idiot for using this method; physical access is root access.
However, this is a novel use of software defined radio. As far as the experiment itself is concerned, the same result could be obtained much more quickly with a more relevant side-channel analysis device. The ChipWhisperer, for example, can extract AES keys using power signal analysis. The ChipWhisperer does require a direct, physical access to a device, but if the alternative doesn’t work beyond one meter that shouldn’t be a problem.
It’s not hard to detect meteors: go outside on a clear night in a dark place and you’re bound to see one eventually. But visible light detection is limiting, and knowing that meteors leave a trail of ions means radio detection is possible. That’s what’s behind this attempt to map meteor trails using broadcast signals, which so far hasn’t yielded great results.
The fact that meteor trails reflect radio signals is well-known; hams use “meteor bounce” to make long-distance contacts all the time. And using commercial FM broadcast signals to map meteor activity isn’t new, either — we’ve covered the “forward scattering” technique before. The technique requires tuning into a frequency used by a distant station but not a local one and waiting for a passing meteor to bounce the distant signal back to your SDR dongle. Capturing the waterfall display for later analysis should show characteristic patterns and give you an idea of where and when the meteor passed.
[Dave Venne] is an amateur astronomer who turns his eyes and ears to the heavens just to see what he can find. [Dave]’s problem is that the commercial FM band in the Minneapolis area that he calls home is crowded, to say the least. He hit upon the idea of using the National Weather Service weather radio broadcasts at around 160 MHz as a substitute. Sadly, all he managed to capture were passing airplanes with their characteristic Doppler shift; pretty cool in its own right, but not the desired result.
The comments in the RTL-SDR.com post on [Dave]’s attempt had a few ideas on where this went wrong and how to improve it, including the intriguing idea of using 60-meter ham band propagation beacons. Now it’s Hackaday’s turn: any ideas on how to fix [Dave]’s problem? Sound off in the comments below.