Project ideas from Hacker News discussions.

Cheap GPS jammers are filling the world with navigation dead zones

📝 Discussion Summary (Click to expand)

Theme 1 – GPS is inherently vulnerable to jamming/spoofing, creating a need for resilient navigation
- “GPS signals are just incredibly weak so it takes next to nothing to drown them out.” – jacquesm
- “If you have GPS, LORAN, VORs, NDBs, astronavigation, etc. you have many more options at your disposal and present a much more complex attack target.” – teeray

Theme 2 – Ground‑based systems (LORAN/eLoran, VOR) are proposed as backups, with noted strengths and drawbacks
- “LORAN, from my quick googling, looks to be about 6‑7 orders of magnitude higher received power.” – azernik
- “Even a 160 m guy‑wire tower is cheap… but such an antenna will be extremely conspicuous and easy to triangulate.” – lstodd / cyberax
- “VOR is extremely short range and requires an extraordinary number of transmitters… LORAN … only required one master station and a few remote stations to provide continent‑scale coverage.” – buildsjets

Theme 3 – Technical hardening of GNSS (multi‑constellation, L5, adaptive antennas, inertial/star navigation) is seen as a way to mitigate jamming
- “L5‑band signals are 30× harder to jam and interfere with compared to L1…” – toomuchtodo
- “Single element antennas, adaptive antennas, beam steering antennas… basically attempting to pull good RF while avoiding bad RF.” – toomuchtodo
- “Astro‑inertial guidance … is used on submarine‑launched ballistic missiles.” – leonidasrup


🚀 Project Ideas

GPShield Community Jammer Map

Summary

  • Detects GPS signal loss/spoofing using inexpensive SDR dongles or smartphone sensors and uploads anonymized events to a live map.
  • Core value: near‑real‑time, crowdsourced visibility of jamming/spoofing hotspots for pilots, drivers, and maritime users.

Details

Key Value
Target Audience Aviation enthusiasts, drone operators, delivery drivers, maritime hikers
Core Feature Real‑time detection of GNSS anomalies (loss of lock, sudden jumps) and aggregation onto a public heatmap
Tech Stack RTL‑SDR/HackRF + Python (pyrtlsdr) for detection, React/Mapbox GL JS frontend, Node.js backend, PostGIS for storage
Difficulty Medium
Monetization Revenue-ready: freemium API (free tier for hobbyists, paid tier for commercial access with higher‑resolution alerts)

Notes

  • HN commenters repeatedly asked for a “crowd sourced map of jammers” (Gigachad: “If you wanted to exactly pinpoint it with a single device…”) and wished for low‑battery detection apps (eternityforest: “Is there a reliable app to detect these without using excessive amounts of battery?”). This project directly satisfies those asks and could spark discussion on open‑source detection algorithms.
  • Practical utility: enables rapid response to jamming incidents, helps regulators locate illegal jammers, and gives users situational awareness when GNSS is degraded.

OpenSource Adaptive GNSS Receiver Firmware

Summary

  • Firmware for inexpensive SDR platforms (e.g., RTL‑SDR, ADALM‑Pluto) that implements multi‑constellation (GPS L1/L5, Galileo E1/E5b, BeiDou B1/B2) reception, adaptive beamforming/nulling, and spoofing/jamming detection.
  • Core value: provides a jam‑resistant GNSS solution that can be flashed onto existing hobby hardware, lowering the barrier for resilient navigation.

Details

Key Value
Target Audience DIY avionics builders, UAV developers, radio hobbyists, research labs
Core Feature Adaptive antenna array processing + integrity monitoring to output a reliable position even under jamming/spoofing
Tech Stack GNU Radio flowgraphs, C++/Rust for DSP, optional FPGA (IceStorm) for beamforming, u‑blox‑style NMEA output
Difficulty High
Monetization Hobby

Notes

  • Comments highlighted the lack of affordable anti‑jam options (leonidasrup: “It uses 2MHz band… you need an antenna of at least around 40m size…”, thenthenthen: “Better use a software defined radio like hackrf … with some machine learning?”). An open‑source firmware would give the community a tangible way to experiment with adaptive nulling and multi‑frequency diversity.
  • Potential for discussion: invites collaboration on DSP algorithms, could be integrated into drone flight controllers, and serves as a testbed for evaluating new L5‑only receivers.

Broadcast Positioning Service (BPS) API

Summary

  • Leverages existing high‑power FM/TV broadcast towers to disseminate precise time and position corrections (similar to the Broadcast Positioning System experiments mentioned by geerlingguy). Provides a simple HTTPS API that returns correction data for a given location, enabling receivers to augment GNSS or operate standalone.
  • Core value: offers a low‑cost, infrastructure‑based PNT layer that is extremely hard to jam due to high ERP and low frequency, acting as a backup or augmentation to GNSS.

Details

Key Value
Target Audience Embedded device manufacturers, aviation OEMs, maritime operators, IoT firms
Core Feature Delivers pseudorange corrections and time offsets derived from monitored broadcast signals, usable by any GNSS receiver via standard RTCM‑like messages
Tech Stack Signal processing server (Python + SDR) monitoring FM/RDS, APIs built with FastAPI, hosted on Kubernetes, data stored in TimescaleDB
Difficulty Medium
Monetization Revenue-ready: subscription per device (e.g., $0.001 per correction request) with free tier for low‑volume developers

Notes

  • HN users noted experiments with BPS using high‑power TV transmitters (geerlingguy: “experiments with BPS … using high power TV transmitters to distribute time and position in urban areas”) and the desire for a system that’s hard to overpower (Jacquesm: “LORAN … uses low frequency, extremely high power signals… makes it vastly more robust”). This idea turns that concept into a usable service.
  • Practical utility: enables devices in jam‑prone environments (urban canyons, near airports) to maintain navigation without relying solely on satellite signals, and creates a data feed that regulators could monitor for interference.

Inertial‑Stellar Backup Navigator App

Summary

  • Mobile application that fuses phone IMU, barometer, magnetometer, and optional star‑camera tracking (using the phone’s camera and known star catalog) to provide a dead‑reckoning position when GNSS is unavailable or suspect.
  • Core value: gives pilots, hikers, and drone operators a self‑contained backup navigation source that works offline, consumes minimal power, and alerts the user when GNSS confidence drops.

Details

Key Value
Target Audience General aviation pilots, outdoor adventurers, UAV operators, maritime sailors
Core Feature Sensor fusion (EKF) delivering position, velocity, attitude; star‑camera update corrects drift; GNSS health monitor triggers backup mode
Tech Stack Swift/Kotlin for native sensor access, OpenCV for star detection, C++ Eigen for EKF, optional offline star catalog (Hipparcos)
Difficulty Medium
Monetization Hobby

Notes

  • Multiple commenters advocated for celestial/stellar navigation aided by modern tech (leonidasrup: “In the 21st century you don't do astronavigation by hand, you use cameras, computers and software.”; mschuster91: “Astro‑inertial guidance … is used on submarine‑launched ballistic missiles.”). This app brings that concept to the consumer device level.
  • Potential for discussion: could be extended to integrate with aircraft EFBs, serve as a teaching tool for VOR/NDB backup, and spark interest in low‑power, jam‑resistant navigation techniques.

Read Later