Skip to content

reardar – show me the data!

Welcome back. As you may recall, we’ve been digging into how we might use an inexpensive Doppler radar module to help cyclists detect cars approaching from behind. Last time, Josh explained the project’s origin, the radar module itself, and the circuitry necessary to get “microcontroller-ready” data out of the module.

In this post, I’ll give a quick run-down on what we think we can glean from that data, what the data looks like (before and after all of the digital signal processing we had to use to make it useful), and the testing we’ve done thus far.

data, data, everywhere

Some of our first thoughts were “what can we do with the data?” We aren’t radar-experts, per say, but enough of us stayed awake through a physics lesson or two :) to answer some of the questions that came up, such as:

  • Can we detect how far away the car is? (no, not directly)
  • Can we figure out if it is coming at us or going the opposite direction? (not directly with this module, but maybe indirectly?)
  • What’s the range? (it varies…so let’s test)
  • Can we tell if the car will hit us, or pass by safely one lane away? (not directly, but maybe indirectly?)

We did a quick refresh on the theory of Doppler radar (there are some nice explanatory pieces HERE and HERE) and then set-out to try and quickly answer a few of these questions.

The question that intrigued me (and encapsulates the rest, in a way) was if you could determine if the car would hit you or pass by safely one lane away. If there is a lane between my bike and the car, then I’m not as concerned if it’s coming up quickly; if it’s moving fast AND will pass within a foot of my handlebar, I am concerned. A few key points about Doppler radar will help answer this:

  • Only a speed is obtained, not velocity. Velocity is a vector (magnitude and direction) while speed is a scalar (just magnitude). That means that you don’t know whether that object is coming towards you, going away from you, or something in-between. Some radar modules have a quadrature encoder-style output from which you can determine relative direction, but this inexpensive model does not.
  • The speed that the radar reports is a relative speed; in other words, the speed of the target (car) minus the speed of the source (cyclist). The radar doesn’t care if the cyclist is moving or standing still; it will report the difference in speed (otherwise known as relative speed) either way.
  • The speed reported is dependent on the angle between the paths of the radar source and target. In other words, if a car is approaching the cyclist directly at a constant velocity, the radar-reported speed won’t change as the car gets closer to the cyclist. But, if the car approaches the cyclist offset some distance, the speed will appear to drop off as the angle between two increases (by a factor of the cosine of that angle). The simulation below demonstrates this.

With those points in mind, it seemed that by looking at the radar-reported speed over time, the microcontroller might be able to predict the distance between the car and bike as the car passed using the rate of change of the radar-reported speed. In the simulation, note how the red curve for the second car (which passes very close to the cyclist) doesn’t drop off as gradually as the green curve (a safe distance away) does.

enough theory, let’s test!

Looking at those relatively smooth, easy-to-discern lines on the plot above reminds me of a favorite quote: “In theory, theory and practice are the same. In practice, they are not.” Knowing that real data would be “messier” than that predicted with theory, we set out to generate some test data from which we could validate the passing distance idea discussed above, test smoothing algorithms, and judge the relative performance and range of the module.

We picked some of our fastest employees :) to best simulate an approaching car and used a cookie sheet to give us a nice radar-reflective surface. Using the FreqMeasure library for the Teensy, we were quickly able to see frequency data from the module, but there were a few issues.

  • The data had intermittent, very high-amplitude noise spikes, even during no-movement-in-the-vicinity times. This was most likely due to the quickly-breadboarded amplifier/comparator circuitry and/or the non-shielded wires running from the radar module to the amplifier.
  • During times with movement in the vicinity, there was a generous amount of lower-amplitude, relatively high-frequency noise in the signal. This was probably due in part to the reasons above, but it was also apparent that a human running with a cookie sheet does not make for a constant-speed output.

The most robust solution to these problems is fairly straightforward; reduce potential Electromagnetic Interference (EMI) by using a PCB instead of a bread-boarded circuitry and adding shielding to the signal wires. Additionally, a low-pass filter on the unamplified signal would reduce amplified noise making it’s way into the data. We designed a tunable band-pass filter and sent the PCB out, but, we wanted to see if we could use digital filtering (software) to get a “close-enough” answer.

Unfortunately, the data from the FreqMeasure library isn’t output at a constant rate; it uses a buffer to collect clock-time between interrupts on the input line, and when enough have been captured, it averages them and reports out the average frequency. Digital filters generally require a constant sample rate, so a work-around was constructed. When it’s time for a sample to be acquired, the latest frequency value is used, if one is available. If not, an exponentially-decaying value based on the previous value is reported. This ensures that the output speed returns to zero after a few samples are requested but no new data is available, and prevents the very high-amplitude noise measurements from being reported out. A moving average filter is applied to each reading to smooth the final signal with a minimal temporal shift.

Indoor test setup: humans running with cookie sheets
Indoor testing: running parallel to the radar, about 12 feet offset
Indoor testing: running at the radar

We could see rather clearly the difference in speeds between our two test subjects, and could also discern a fairly clean signal of the test subject entering and being within the radar’s field-of-view (FOV). We could also discern the difference between running directly at the radar and running parallel to the radar, offset about 12 feet away (simulating a car coming up one lane away from the cyclist).

time to hit the streets

We decided to take the next step and acquire some nearly-real-world data by heading out the door to the street corner. I held the radar module stationary in my hand pointed at oncoming traffic, as my colleague Tim videoed the traffic and my laptop for post-test analyses.

Outcomes were about what we’d predicted. In general, there was a lot more noise in the signal out on the street than in our office.  The median data value was about 560 Hz (7.8 mph) vs. about 5 Hz (~0 mph) in our office, or 100x more noise. You can see in the plots above that during testing in our office, the radar signal was essentially zero except when the test subject was running at it. In the plot below of test data obtained on the street, you’ll see the value rarely dips below 100 Hz, or 1.4 mph. This is due to:

  • Traffic. Four lanes of downtown Seattle traffic in the afternoon means many radar-reflectors (cars) are in near-constant motion in and out of the radar’s FOV.
  • People. One block away from Pike’s Place Market in July is a fairly people-dense environment, so there’s always a human-moving within a 30-foot radius.

Looking at the data side-by-side with the video, the following conclusions were drawn:

  • Finding the time when a car enters the radar’s FOV just by looking at the data seems possible (with a small degree of uncertainty), with some time spent tuning parameters. Filtering the signal, both in analog and digital, would help the signal stand out from the noise. Additionally, finding a narrow-beam antenna would reduce the radar’s FOV, thereby increasing the signal-to-noise ratio (as it wouldn’t be bouncing microwaves off of so many moving targets all at once).


  • Discerning when a car is in the lane immediately next to the radar module and when it is one lane away is not as clear-cut as in our human-testing experiments. To be fair, that was more of a stretch-goal. Having reardar tell the cyclist, “Watch out, I think that you’re about to get hit!” would mean that the cyclist might start to put too much trust into the device’s warnings and let their guard down, which could be deadly in the case of a false-negative (reardar failing to recognize a car about to hit the cyclist).
  • The range of these cheap Doppler radar modules in an application like this out in the real-world is lower than we’d hoped.
Fast car
Fastest car observed: 35.4 mph

The fastest car captured was travelling at 35.4 mph, according to the radar. Zooming in on that slice of data, you can see that if the device considered any signal above the median value (the red dashed line) as worthy of being reported to the cyclist, then the cyclist would have had about 1.0 second to react before the car passed immediately beside them. This isn’t horrible, but considering that best-case human reaction times are roughly 0.15 seconds to 0.25 seconds (depending on the what you are reacting to), that doesn’t leave a lot of time to process the data, make a decision, and re-position your bike, before the car passes too close to you.

Fast car zoomed
Fast car zoomed

If you want a feel for how fast you can react, see this website for a visual stimuli test. This isn’t vibratory haptic stimuli like we’re planning for reardar, but it should still give you a rough feeling for how much advanced notice you’d want for a car rapidly-approaching your bicycle from behind you.

what’s next?

The general consensus is that a bit more time between reardar sensing that something is coming up behind you and that thing passing you is necessary to make it be valuable. To that end, we are researching other inexpensive, low-profile radar antennas with a higher-gain and/or narrower beam to increase the range of the device. With a narrower beam, it may be even more important to keep the source as close to stationary as is possible, so alternative methods to attach the module to the bike are being looked at. Finally, and perhaps most importantly, we’re starting to investigate the Human Machine Interaction of reardar. We hope to prototype a few different alert algorithms (vibratory and auditory) and test them to determine how to best convey speed data in a way that it becomes a sort of “sixth-sense” for cyclists riding in traffic.

Thanks for reading. Keep your eyes out for the next reardar installment soon!