The bike isn’t the functional part of this build, as it doesn’t seem to have been intended to move. Rather, it was chosen because it is inconspicuous (read: rusty and not valuable) and simply housed the radar unit and electronics in a rear luggage case. The radar was specially calibrated to have less than 1% error, and ran on a deep cycle lead acid battery for around eight days. Fitting it with an Arduino-compatible shield and running some software (provided on the github page) is enough to get it up and running.
This is an impressive feat of citizen activism to provide the local police with accurate data to change a problem in a neighborhood. Not only was the technology put to good use, but the social engineering involved with hiding expensive electronics in plain sight with a rusty bicycle is a step beyond what we might have thought of as well.
If you’ve ever cast your eyes towards experimenting with microwave frequencies it’s likely that one of your first ports of call was a cheaply-available Doppler radar module. These devices usually operate in the 10 GHz band, and the older ones used a pair of die-cast waveguide cavities while the newer ones use a dielectric resonator and oscillator on a PCB. If you have made your own then you are part of a very select group indeed, as is [Reed Foster] and his two friends who made a Doppler radar module their final project for MIT’s 6.013 Applications of Electromagnetics course.
Their module runs at 2.4 GHz and makes extensive use of the notoriously dark art of PCB striplines, and their write-up offers a fascinating glimpse into the world of this type of design. We see their coupler and mixer prototypes before they combined all parts of the system into a single PCB, and we follow their minor disasters as their original aim of a frequency modulated CW radar is downgraded to a Doppler design. If you’ve never worked with this type of circuitry before than it makes for an interesting read.
We’ve shown you a variety of commercial Doppler modules over the years, of which this teardown is a representative example.
At the turn of the 21st century, it became pretty clear that even our cars wouldn’t escape the Digital Revolution. Years before anyone even uttered the term “smartphone”, it seemed obvious that automobiles would not only become increasingly computer-laden, but they’d need a way to communicate with each other and the world around them. After all, the potential gains would be enormous. Imagine if all the cars on the road could tell what their peers were doing?
Forget about rear-end collisions; a car slamming on the brakes would broadcast its intention to stop and trigger a response in the vehicle behind it before the human occupants even realized what was happening. On the highway, vehicles could synchronize their cruise control systems, creating “flocks” of cars that moved in unison and maintained a safe distance from each other. You’d never need to stop to pay a toll, as your vehicle’s computer would communicate with the toll booth and deduct the money directly from your bank account. All of this, and more, would one day be possible. But only if a special low-latency vehicle to vehicle communication protocol could be developed, and only if it was mandated that all new cars integrate the technology.
Except of course, that never happened. While modern cars are brimming with sensors and computing power just as predicted, they operate in isolation from the other vehicles on the road. Despite this, a well-equipped car rolling off the lot today is capable of all the tricks promised to us by car magazines circa 1998, and some that even the most breathless of publications would have considered too fantastic to publish. Faced with the challenge of building increasingly “smart” vehicles, manufacturers developed their own individual approaches that don’t rely on an omnipresent vehicle to vehicle communication network. The automotive industry has embraced technology like radar, LiDAR, and computer vision, things which back in the 1990s would have been tantamount to saying cars in the future would avoid traffic jams by simply flying over them.
In light of all these advancements, you might be surprised to find that the seemingly antiquated concept of vehicle to vehicle communication originally proposed decades ago hasn’t gone the way of the cassette tape. There’s still a push to implement Dedicated Short-Range Communications (DSRC), a WiFi-derived protocol designed specifically for automotive applications which at this point has been a work in progress for over 20 years. Supporters believe DSRC still holds promise for reducing accidents, but opponents believe it’s a technology which has been superseded by more capable systems. To complicate matters, a valuable section of the radio spectrum reserved for DSRC by the Federal Communications Commission all the way back in 1999 still remains all but unused. So what exactly does DSRC offer, and do we really still need it as we approach the era of “self-driving” cars?
From today’s perspective, vacuum tubes are pretty low tech. But for a while they were the pinnacle of high tech, and heavy research followed the promise shown by early vacuum tubes in transmission and computing. Indeed, as time progressed, tubes became very sophisticated and difficult to manufacture. After all, they were as ubiquitous as ICs are today, so it is hardly surprising that they got a lot of R&D.
Prior to 1938, for example, tubes were built as if they were light bulbs. As the demands on them grew more sophisticated, the traditional light bulb design wasn’t sufficient. For one, the wire leads’ parasitic inductance and capacitance would limit the use of the tube in high-frequency applications. Even the time it took electrons to get from one part of the tube to another was a bottleneck.
There were several attempts to speed tubes up, including RCA’s acorn tubes, lighthouse tubes, and Telefunken’s Stahlröhre designs. These generally tried to keep leads short and tubes small. The Philips company started attacking the problem in 1934 because they were anticipating demand for television receivers that would operate at higher frequencies.
Dr. Hans Jonker was the primary developer of the proposed solution and published his design in an internal technical note describing an all-glass tube that was easier to manufacture than other solutions. Now all they needed was an actual application. While they initially thought the killer app would be television, the E50 would end up helping the Allies win the war.
Radar is a useful tool with familiar uses such as detecting aircraft and observing weather. It also has some less known applications, such as a technology known as ground-penetrating radar (GPR). Despite the difficulty of sending and receiving radio waves through solid objects, with the right equipment it’s possible to build a radar that works underground as well.
The presentation begins by highlighting the basics of GPR, then details the hardware bill of materials for the transmitting circuit, receiving circuit, and the DC power supplies. It also details the theory behind the software needed to get the circuit running properly, and has code as well. The processing is done on a 32-bit Mbed platform, and the rest of the GPR is built with easy-to-source components as well.
The last few days have seen drone stories in the news, as London’s Gatwick airport remained closed for a couple of days amid a spate of drone reports. The police remained baffled, arrested a couple who turned out to be blameless, and finally admitted that there was a possibility the drone could not have existed at all. It emerged that a problem with the investigation lay in there being no means to detect a drone beyond the eyesight of people on the ground, and as we have explored in these pages already, eyewitness reports are not always trustworthy.
Radar Can’t See Them
It seems odd at first sight, that a 21st century airport lacks the ability to spot a drone in the air above it, but a few calls to friends of Hackaday in the business made it clear that drones are extremely difficult to spot using the radar systems on a typical airport. A system designed to track huge metal airliners at significant altitude is not suitable for watching tiny mostly-plastic machines viewed side-on at the low altitudes. We’re told at best an intermittent trace appears, but for the majority of drones there is simply no trace on a radar screen.
We’re sure that some large players in the world of defence radar are queueing up to offer multi-million-dollar systems to airports worldwide, panicked into big spending by the Gatwick story, but idle hackerspace chat on the matter makes us ask the question: Just how difficult would it be to detect a drone in flight over an airport? A quick Google search reveals multiple products purporting to be drone detectors, but wouldn’t airports such as Gatwick already be using them if they were any good? The Hackaday readership never fail to impress us with their ingenuity, so how would you do it?
Can You Hear What You Can’t See?
It’s easy to pose that question as a Hackaday scribe, so to get the ball rolling here’s my first thought on how I’d do it. I always hear a multirotor and look up to see it, so I’d take the approach of listening for the distinctive sound of multirotor propellers. Could the auditory signature of high-RPM brushless motors be detected amidst the roar of sound near airports?
I’m imagining a network of Rasberry Pi boards each with a microphone attached, doing some real-time audio spectrum analysis to spot the likely frequency signature of the drone. Of course it’s easy to just say that as a hardware person with a background in the publishing business, so would a software specialist take that tack too? Or would you go for a radar approach, or perhaps even an infra-red one? Could you sense the heat signature of a multirotor, as their parts become quite hot in flight?
Whatever you think might work as a drone detection system, give it a spin in the comments. We’d suggest that people have the confidence to build something, and maybe even enter it in the Hackaday Prize when the time comes around. Come on, what have you got to lose!
Jeremy Hong knows a secret or two about things you shouldn’t do with radio frequency (RF), but he’s not sharing.
That seems an odd foundation upon which to build one’s 2018 Hackaday Superconference talk, but it’s for good reason. Jeremy knows how to do things like build GPS and radar jammers, which are federal crimes. Even he hasn’t put his knowledge to practical use, having built only devices that never actually emitted any RF.