We Built a Speed Radar. The Police Should Open Source Theirs.

There is a road in front of my house where cars go too fast. So I decided to measure it.

I obtained an OmniPreSense OPS243-C radar module, a 24 GHz Doppler and FMCW sensor designed exactly for this purpose. I wired up a Raspberry Pi Zero 2, wrote the software with AI assistance, and set it up at the curb. The hardware cost around $200. The time cost was the better part of a full day.

Getting a radar to accurately measure vehicle speed is not simple. You can’t just point the radar at the road.

There is the cosine correction problem. Radar measures radial velocity: the component of speed directly toward or away from the sensor. If the road runs at an angle to the radar beam, which it almost always does, the sensor underreports speed. The correction factor is 1 divided by the cosine of the offset angle. My radar is pointed at a compass bearing of 142 degrees. The road runs at 109 degrees. The offset is 33 degrees. That correction factor should have been 1.19, and it has to be applied to every reading. Except applying 33 degrees produced readings of 35.2, 45.1, and 33.3 mph for the same car doing the same 30 mph. The variance was too high. We tested 20 degrees as a compromise and got more consistent results, but the right number is still an open question requiring more calibration passes at known speed.

Then there is the mounting problem. Set the sensor at curb level and it sees the curb. For most of the day, every recorded range measurement came back as 0.7 meters, not 5 to 17 meters where the passing cars actually were. The sensor was locked onto near-field clutter. It could still detect vehicle speeds through the Doppler channel, but the range data was useless. We tried software range gates, minimum distance filters, and API configuration changes. None of it fixed the physical problem. The sensor needs to be raised off the ground and aimed so nothing close is in the beam. We are mounting it on a tripod tomorrow.

Then there is the firmware API. The OPS243-C has a serial interface with dozens of configuration commands covering speed units, output modes, magnitude thresholds, direction filters, peak detection algorithms, and range gating. Each setting interacts with the others. We spent time applying what looked like a sensible vehicle-optimized profile: timestamps enabled, magnitude output enabled, speed filtering, peak detection. The sensor stopped reporting any vehicle events at all. After diagnosis, it turned out that two of the output mode commands we sent were replacing the speed output mode rather than augmenting it. The sensor was still running. It was just no longer reporting speeds. The fix was removing those two lines.

Then there is the USB enumeration problem. After a full system reboot, the radar did not appear as a serial device. The service started, looked for the device, found nothing, and crashed. The sensor was physically connected. The operating system simply had not yet registered it. You need a systemd service dependency that waits for the specific USB device path before starting the software. And you only know the exact path to specify if you have read the right documentation at the right time.

Then there is the direction problem. The sensor reports speed as positive or negative depending on whether a target is moving toward or away from it. Which direction is positive depends on how the sensor is oriented. We spent time flipping the software direction flag back and forth, verifying which way the sensor was physically pointed, trying to determine whether the inbound readings should be the positive or negative values. We got it wrong twice before getting it right.

I had AI assistance throughout all of this. The AI wrote code, suggested configurations, diagnosed errors, read the API documentation, and caught problems I missed. And it still took most of a day, multiple failed approaches, a full reboot, a physical USB reconnect, several test drives at known speeds, and the realization that the final calibration requires someone to actually drive past the sensor at a verified GPS speed and compare the readings.

Which brings me to the part that I care about.

Police departments use radar speed enforcement systems that are treated as authoritative. A reading from a radar gun can result in a fine, points on a license, increased insurance premiums, and in some cases a suspension. The systems that generate these readings are largely proprietary. The algorithms, firmware, calibration procedures, and accuracy validations are not publicly available. You cannot inspect them. You cannot replicate them. You can challenge a ticket in court, but you cannot review the code or the calibration logs that produced the measurement used against you.

I am not saying these systems are inaccurate. I am saying there is no independent way to verify that they are accurate in the specific conditions under which your reading was taken.

Physics don’t change. Doppler radar measures radial velocity. Cosine error affects every measurement taken at any angle offset from the direction of travel. Near-field clutter can corrupt range data. Firmware settings interact in non-obvious ways. Mounting geometry matters enormously. These are not edge cases. These are fundamental properties of the technology that affect a $200 consumer module and a $3,000 professional enforcement unit equally.

If law enforcement agencies and the companies that build their equipment have solved these problems in ways that produce materially better accuracy and reliability than what a careful engineer can build with publicly available tools and a day of work, that is genuinely important. It means the readings that carry legal consequences are more trustworthy than my experience leads me to fear they might be.

But we should be able to verify that. And right now, we cannot.

If your system is better, show the work. Open source the algorithm. Publish the calibration methodology. Let independent engineers review what you built. Not because we assume it is wrong. Because when a number generated by a machine can cost someone money and affect their record, they deserve to know how that number was produced.

Show your work.

Andrew Perkins is the authorof After the Grind: Rethinking Your Business Career in the Age of Artificial Intelligence and Robotics and Chair of the Department of Marketing and International Business at Washington State University’s Carson College of Business.