JP Marhefka
Skip to case study

01

OmniPreSense Internship

I built and deployed an OPS243 coverage calculator, then continued the OmniPreSense work through a ready curved-road mapping version, a Google Maps 3D prototype, OpenFlight capture, and advanced OPSLaunch development.

Role
Engineering intern
Year
2026
Discipline
Embedded sensing, radar, web engineering
OmniPreSense Internship project poster
Scroll to case study

01 · OmniPreSense internship

From summer internship to school-year work

I started at OmniPreSense as a summer engineering intern and was invited back to continue during the school year.

The timeline

I moved from MATLAB-derived OPS243 geometry into a public field-of-view calculator, then continued into real-road mapping, perspective visualization, OpenFlight capture, and OPSLaunch firmware and app integration work.

That progression produced one deployed calculator, a curved-road mapping package ready for use, a Google Maps 3D prototype, a merged OpenFlight implementation, and advanced OPSLaunch source work with device validation still ahead.

Blender studio render of the OPS243 radar evaluation board in a three-quarter view
Assembled OPS243 board render with its radar module, antenna traces, and evaluation hardware.

02 · Engineering themes

From straight-road math to real-road context

The work grew from one coverage calculation into a set of tools and integrations around radar placement and capture.

What connected the work

I kept the flat-road lane math as the authoritative numeric foundation while exploring real geographic road context and approximate perspective context.

I also worked across the boundary between radar firmware, rolling I/Q capture, embedded processing, BLE metrics, and a numerical iPhone display.

03 · Building across systems

From geometry to device integration

I carried implementation details from geometry and map data through device protocols and test boundaries.

How I worked

I kept the calculator work grounded in geometry functions and visual overlays, connected the curved-road mapping package through WordPress REST and roadway data, and separated OpenFlight into trigger, capture, parser, and re-arm stages before it merged upstream.

For OPSLaunch, I kept host-tested firmware and app source separate from physical flashing, live radar input, and calibrated device validation.

04 · Current boundaries

Deployed, merged, and still in progress

I have a publicly deployed calculator, a curved-road mapping version ready for use, a Google Maps 3D prototype, an OpenFlight implementation merged upstream as PR #221, and advanced OPSLaunch work with device validation still ahead.

What I can show today

I can point to the public calculator and merged OpenFlight PR. The curved-road mapping version is ready for use, the 3D visualization remains a Google Maps prototype, and I am still validating OPSLaunch on hardware.