Final state of our prototype
Our radar UI running on the Raspberry Pi
Soldering of the hlk-ld2450 sensor
UI demonstrating bpm and range sensors

Inspiration

Pulse began with an idea from Rainbow Six Siege, where the character Pulse uses a device to sense people through barriers. We wanted to explore whether a real version of that idea could serve a more practical purpose.

We built a prototype around the idea of helping responders locate people during an emergency, such as after a natural disaster. Our goal was to combine location tracking with close range vital sign sensing in a handheld device.

What it does

Pulse combines two radar sensors to give responders a clearer picture of who may be nearby. The 24 GHz HLK-LD2450 tracks up to three moving targets and plots their positions relative to the device as dots on a radar screen. When someone is within the 60 GHz DFRobot C1001’s sensing range, it can provide breathing and heart rate readings. An operator can tap a dot to view available readings and on-screen guidance for aiming the sensor toward that person. Together, the location and vital sign information can help responders save lives in emergency situations.

How we built it

We built Pulse from the hardware up in 36 hours, including its sensor drivers, fusion engine, and radar interface.

Hardware: A Raspberry Pi 4 with 2 GB of memory runs the system and connects to a 7 inch Hosyond DSI capacitive touchscreen with an 800 × 480 resolution. The HLK LD2450 tracks targets using 24 GHz radar. The DFRobot C1001 uses 60 GHz radar for close range breathing and heart rate readings. Both sensors connect directly to separate hardware UARTs on the Pi. The LD2450 uses UART0 at 256000 baud, and the C1001 uses UART3 at 115200 baud. A USB power bank makes the unit portable.

Software: A Python and FastAPI backend streams radar data to a JavaScript canvas interface over WebSocket at 10 Hz. We wrote Python parsers for both sensors using their documentation and DFRobot’s Arduino library as references. The parsers handle split frames, resynchronization, protocol checks, and reconnection.

The fusion engine uses an alpha beta tracking filter, one to one target association, and range hysteresis to reduce flicker and help maintain target IDs when people cross paths. Since the C1001 does not report a target’s location, the interface pairs its readings with a dot only when the operator aims at a nearby target and the reading is in range.

The touchscreen interface runs full screen in kiosk mode. It includes a radar sweep, touch range controls, a contact history drawer, and a tap activated card with available vital readings and direction guidance. We also built a simulator that runs scripted scenarios through the same fusion code, along with 187 automated tests. Setup scripts, SSH deployment tools, a system service, and serial debugging tools helped us develop and test the system on the Pi.

Challenges we ran into

We changed our idea late in the process, which left us searching for parts that could arrive in time. Overnight shipping helped us get started, but our limited options meant making compromises in the hardware we could use.

The LD2450’s small, closely spaced pins did not match the jumper wires available to us. We had to cut, strip, and solder wires directly to the sensor. Keeping the joints separate was difficult, and we had to be careful to avoid shorting neighboring pins.

Neither sensor came with a ready to use Raspberry Pi driver for our setup. We built Python parsers from the sensor documentation and the available DFRobot Arduino library, then worked through serial communication issues on the Pi.

Our first readings also made the displayed dots jump around instead of following people smoothly. We traced this to sensor noise and adjusted the movement threshold so the interface responded to more significant movement. That made the display steadier, while also making it less responsive to small movements.

Accomplishments that we’re proud of

• Built a handheld prototype with a Raspberry Pi, touchscreen, and two radar sensors in 36 hours.

• Connected the Hosyond display to the Pi, configured it to launch Pulse full screen, and used SSH to make changes during development.

• Displayed up to three HLK LD2450 targets as dots, using the sensor’s X and Y position readings.

• Built a touch interface for selecting targets and viewing available readings.

• Wrote sensor parsers and a fusion engine, then developed a simulator and ran 187 automated tests through the fusion code.

• Soldered connections to the LD2450 despite its small, closely spaced pins.

What we learned

Radar fusion takes more than combining data. The LD2450 gives us target positions, while the C1001 provides close range vital readings without a target location. Each sensor has different strengths and limits, so the software has to be careful about when it associates a reading with a dot.

Serial communication needs careful setup. Getting two sensors working on separate UARTs meant configuring the Pi’s hardware serial ports and writing parsers that could recover when data arrived in partial frames or contained invalid values.

Soldering small connections takes patience. We learned to prepare and position wires carefully, control how much solder we use, and inspect close pins for accidental bridges before powering the hardware.

Clear displays matter more than effects. We chose a high contrast interface that could be read at a glance on the 800 × 480 screen. The amber and green states are prototype cues, not medical assessments.

Radar has physical limits. Signals may pass through some materials, but performance changes with the material and environment. Solid concrete and water soaked debris can block or weaken them. We learned to be precise about what our prototype has demonstrated and what still needs testing.

A shared data contract helps teams work in parallel. Defining the information exchanged by the Python backend and JavaScript interface let us develop both sides alongside a deterministic simulator and test suite.

What’s next for Pulse

Our first prototype was built with the sensors we could obtain in time. Next, we want to evaluate higher quality radar options that could improve positional accuracy, extend useful range, and track more than three people. We also want to test how different walls and debris affect detection, improve calibration and target association, and make the hardware more durable and portable.

With stronger sensing and extensive testing, Pulse could grow into a more capable tool for search and rescue teams. Our long term goal is to help responders find useful information about people who may be difficult to see.