I'm not sure how useful this information is because it's more typical to use a GNSS chip that can do NTRIP but in case anyone is interested ...

I built a GNSS receiver using an LC29HAA board (which can output RTCM3 and NMEA but does not do NTRIP). The receiver has an active antenna with a ground plane. It uses an ESP32 microcontroller to configure the LC29HAA and send the RTCM3 and GGA out over bluetooth. On my phone I run rtkgps+ (the eltorio github version which I ported to Android Studio using the AI agent to do 99.9% of it) which connects to an NTRIP caster and does the NTRIP corrections, and acts as a mock location app (so the other apps on my phone can access the NTRIP corrected location data).

When I was testing the device and the horizontal error went below 5 cm, my android apps, that only display horizontal error in tenths of a meter (10cm or greater), rounded down to 0. That was my criterion for success, 0 error. ;)

Here's what I had to buy:

• ESP32-WROOM-32E DevKitC $5.34 AliExpress
• Quectel LC29HAA development board $17.70 AliExpress
• UFL to SMA cable ( 8 pack) $0.99 AliExpress
• Amazon Basics 8-Pack AA NiMH Batteries 10.03 amazon.com
• KLAYERS Q25 GNSS L1+L2+L5 Multi Constellation | Multiband Quadrifilar Helix Active High-Precision Positioning Antenna $23.99 amazon.com

QGNSS testing software from Quectel free

LC29HAA firmware upgrade free

Total $58.05

And many hours of fun and frustration that I can't put a price tag on.

I already had a cellphone, and an AA battery powered usb power supply, and a breadboard and jumpers to wire it together, a tupperware type container to use as an enclosure, and a Windows computer to program the ESP32 using Arduino IDE and run Android Studio. My computer is somewhat underpowered for Android Studio but with AI help I adjusted the memory settings in the Studio and it works well enough. The biggest problem is that I've had 4, 5, and 8 hour timeouts for using too many AI tokens in Android Studio.

The battery pack plugs into the ESP32 via a usb cable, and the LC29HAA gets it's power from the ESP32.

I've ordered a voltage regulator and a power monitor to add to the device. When using the device in NMEA only mode, I have an app on my phone I wrote that I use to interact with the device, to monitor the voltage, change $PAIR settings, view the bluetooth signal strength in Bluetooth LE mode.

I am planning to eventually put the device on perfboard with "2.54mm Double Row Straight Female Header Socket Connectors" those supplies are also very inexpensive on aliexpress.

I don't have a lot of experience with GNSS. I got started on this when I dropped my cell phone and broke the glass and the replacement phone I bought had very poor gps reception. I was browsing on the internet for a better gps deivce when I saw a gnss board. I asked the google search AI what it was and the project snowballed from there. The device was pretty much conceived and designed and coded by Gemini (the AI in Google search AI mode and Android Studio). I had to pester it several times before it figured out how I could do NTRIP corrections on my phone. So the following comments are from someone who doesn't have a lot of gnss experience and doesn't know all the settings etc that can be used with NTRIP. But my experience is that for the average person NTRIP is a lot of fun to try and amazing to get cm level accuracy, but for a walking app, a receiver or phone that uses the L5 bands is more than good enough. To get centimeter level accuracy with my device it has to be stationary for several minutes and when I come to a stop after walking the location drifts until it settles down to the higher accuracy level. So for every day walks I might test the NTRIP corrections but will probably really just use the device with NMEA not RTCM3 and NTRIP corrections. I'd be interested if my characterization of what it's like using the NTRIP corrections are correct, there's a lot I don't understand about all the settings on rtkgps+.

Working with AIs was a learning experience. They are amazingly capable tools but they also make mistakes and occasionally contradict themselves (maybe in some cases because I didn't fully understand what they were saying). It was pretty bad when Gemini was giving me incorrect check sum values for $PAIR commands because you'd never suspect an AI would make that mistake. QGNSS can calculate the check sums so that saved me.

I've ordered a gnss board that should do the NTRIP but since I haven't tried it out I can't say how well it works but I think it is probably a better way to do this. I never heard of RTK when I started. The project got more and more complicated over time as I asked questions of the AI. It wasn't like an AI conceived the whole thing from the beginning, it evolved in response to my questions. So even though the AI is incredibly useful you have to work with it and understand it can screw up in unexpected way and give you wrong or misleading information. Also the AI doesn't remember previoous chats and becomes unstable as chats get longer and longer, so you have to explain yourself over and over every time you want to ask a question. I've found chatting to be a good practice because the AI offered suggestions I didn't think of asking about when I was just chatting. For exaple it helped me figuire the right settings to connect to an NTRIP caster when that info should have rightly come from the NTRIP provider.

I have been building sidereon, an open-source (MIT-licensed) GNSS and astrodynamics library that covers ground you would normally assemble from several specialized libraries: one for positioning, another for orbital mechanics, others for geodesy, quality control, and format handling. Here it is one engine with one validated core, and it has reached the point where it is useful to people other than me, so: announcing it here first.

The core is rust for speed and safety, exposed through idiomatic interfaces in five languages (python, C, WASM/JS, elixir in addition to rust).

The basics:

• SPP/RTK/PPP/DGNSS positioning with RAIM integrity and covariance-derived error bounds
• RINEX 3/4, RTCM 3.x, NTRIP, ANTEX, SPK
• Troposphere and ionosphere models
• Frames and time: TEME/GCRS/ITRS, IAU time scales, IERS EOP including polar motion
• SGP4 (batched across whole constellations) and numerical propagation with a composable force stack through tides, drag, SRP, and albedo
• Orbit determination, conjunction screening, and reliability-first pass prediction (event sampling scaled to orbital rate)
• GNSS/INS fusion with robust updates and smoothing

And some things that are hard to find in fully open code, or that address pain points in existing OSS libraries:

• Multi-constellation ARAIM (MHSS) protection levels
• Galileo HAS and SSR state-space corrections: orbit, clock, code and phase biases
• Station displacement corrections: solid Earth tide, pole tide, and ocean loading from BLQ coefficients
• teqc-style observation quality control: completeness, cycle slips, multipath metrics
• Sidereal filtering: repeating-geometry multipath removal for static receivers
• A no-IMU track filter for cleaning kinematic tracks straight from solver covariances

There's a heavy emphasis on validation: positioning is pinned bit-for-bit against RTKLIB solves as a committed test, SGP4 against the Vallado and CelesTrak verification vectors, frames against Skyfield, geodesics against Karney's test set, ARAIM against the WG-C reference implementation, and a daily job publishes orbit-fit residuals against IGS products so any regression is visible in public.

Links:

• Core (rust): https://github.com/neilberkman/sidereon
• Live demo, the engine compiled to WASM running client-side in your browser: https://sidereon.dev
• A worked example, cleaning a smartphone GNSS track from public GSDC data against SPAN ground truth: https://sidereon.dev/track-cleanup
• pip install sidereon · cargo add sidereon · npm i u/neilberkman/sidereon · {:sidereon, "~> 0.19"}

The code is heavily AI-written, with the architecture and the validation strategy human-steered. The test suite pinned to public references is the contract, and additional hardening has come through use in real-world applications.

I would value critique from this group, on the scope, the validation approach, or anything that looks off. Thanks!

This is FlySight - device used by skydivers to record flights performance based on GPS data. Skydiving involves airplanes which are a gigantic metal can that dampens the signal, unless the device is held close to the window.

There are similar devices on the market and they have better GPS signal in the very same environment - as manufacturer explained those devices have newer u-blox module and fine-tuned antenna.

Question: does anybody have positive experience with connecting external antennas to N9M and thus improving signal quality? I happen to have few of them from Neo 7M modules

If it does, the follow-up question: from technical specs one of those lower right pins is Antenna pin, but I don't know if I should solder directly to that pin or there should be placed some circuitry in-between.

Hi everyone,

I’m currently working with a GNSS module and trying to figure out how to access some basic device information.

Could someone tell me how I can check the serial number and firmware version of the module?

I’ve looked through the documentation but I’m still not 100% sure where this information is usually accessed — is it done through a specific command, software tool, or interface?

Any guidance or examples would be really appreciated.

Thanks in advance!

I usually visualize this kind of test data with Google Earth and a few in-house tools. They work, but the workflow is fiddly and difficult to reuse or share.

As an experiment, I gave Claude Code two time-aligned KML tracks—reference and test—and built a Python pipeline to calculate horizontal error, visualize positioning status, and render everything as an animated video.

It came together much faster than expected. The script still needs cleanup, but I may turn it into a reusable skill and share it if others find this useful.

Curious how people here visualize reference-versus-test GNSS tracks, especially when RTK status or dead reckoning changes during a run.

The topics for this year's IEEE NAVICON Tutorials have come out. For fellow enthusiasts, here they are:

Featured tutorial topics include:
• 5G Positioning: From Standards to Practice
• Ambiguity Resolution Methods in GNSS Mixed-Integer Models
• Civil GNSS Authentication
• Robust Estimation for Navigation Systems
• Inertial Navigation from First Principles
• LEO PNT: Fundamentals, Advancements, and Open Problems

https://ieee-nav.org/2026/tutorials

Extremely interesting.

Hey, is anyone going to IEEE NaviCon? I'm likely unable to go and would love for anyone who's going to inform me

Let me know thanks

Does anyone here have a specialty in 3DMA GNSS? I've dived deep into ones from HK PolyU (ION), but I wanna know if anyone here has done their own field test using 3DMA. I'd love to see to learn more

I recorded a smartphone GPX track on a Sony Xperia 10 V during China Eastern MU771 from Shanghai Pudong (PVG) to Amsterdam (AMS) on 2026-05-26.

I know smartphone GNSS reception inside an aircraft cabin is poor, so I expected reception gaps, bad fixes, altitude errors, and straight-line artifacts where the app simply connects sparse points. The track has all of that.

However, the more interesting part is that the GPX contains two blocks where the GNSS timestamps jump to clearly wrong dates:

• 62 consecutive trackpoints with timestamps on 2026-05-20
• 37 consecutive trackpoints with timestamps on 2045-12-13

These are not single isolated corrupt points. They are consecutive sequences with plausible-looking seconds, positions, satellite counts, and app "last fix" values.

Approximate locations:

• 2026-05-20 block: around 59.51-59.65N, 33.90-34.17E, NW Russia / south of Lake Onega / east of St. Petersburg
• 2045-12-13 block: around 54.88-55.09N, 19.73-20.04E, Baltic Sea / Kaliningrad region

Some screenshots from the phone also show the phone system time as normal local time, while the "GPS Status" app overlay shows an inconsistent GNSS "last fix" time. The phone screenshots use CEST / UTC+2 local time, while the GPX timestamps are UTC, so a normal 2-hour offset is expected. But the jumps to 2026-05-20 and 2045-12-13 are not explainable by a timezone offset.

Examples:

• Screenshot at phone time 15:24 CEST shows position 59°38.7630'N, 33°54.1630'E, altitude 1237.5 m, 9/48 sats/fix, and "last fix" 2:03:08. This corresponds to the GPX block with timestamps around 2026-05-20T00:03:08Z.
• Screenshot at phone time 16:52 CEST shows position 55°5.0030'N, 19°43.7460'E, altitude 2977.3 m, 8/19 sats/fix, and a large reported error near the Baltic / Kaliningrad region.

Some example points / segments from the GPX:

My question:

The data is clearly not the real aircraft trajectory. What I am trying to understand is the likely failure mode:

• Does this look more like spoofing, jamming followed by bad reacquisition, receiver/app fallback behavior, or something else?
• In particular, can GNSS interference produce a sequence where position, altitude, speed, and GNSS time are all wrong but internally consistent for dozens of fixes?
• Are the dates 2026-05-20 and 2045-12-13 meaningful in any known GNSS failure mode, or are they likely receiver/app artifacts after losing a trustworthy solution?

I put the GPX, map views, screenshots, and a short summary here:

https://github.com/voomdoon/gnss-observations/tree/main/cases/2026-05-26_MU771_PVG-AMS

Image notes:

• In the Google Earth screenshots, red lines are time-continuous GPX segments. Orange lines connect segment endpoints across time gaps or timestamp discontinuities; they are not continuous recorded movement.
• The black GNSS overlay in the phone screenshots is from the Android app "GPS Status" (com.eclipsim.gpsstatus2).
• Map backgrounds visible in phone screenshots are from MAPS.ME / OpenStreetMap.
• Red pins visible on phone map screenshots, such as Warsaw or Moscow, were added manually as orientation markers and are not recorded GNSS points.

Attached images:

1. Google Earth overview of the anomalous area.
2. Close-up of loop-like fixes near Yaroslavl / Rybinsk.
3. Phone screenshot showing GPS Status around the 2026-05-20 timestamp anomaly.
4. Phone screenshot near the Baltic / Kaliningrad area.

I've published a short technical eBook on GNSS navigation — eight chapters covering how satellite navigation actually works, from signal propagation through the constellations (GPS, GLONASS, Galileo, BeiDou) to receivers, error sources, differential corrections (SBAS, RTK, PPP), coordinate systems and datums, and practical waypoint/route planning.

Written for the technically curious reader rather than the specialist. No jargon where plain language works. About 20-25 minutes to read through.

Free to read, no signup required: https://jeffswalk.com/msebnew/rnrminisummary.php?id=1452

I'm a retired engineer with a long interest in positioning systems. Built with AI assistance — happy to discuss any of the technical content or correct anything that's wrong.

The data stream from GPS satellites includes a 176bit field which repeats every 12.5minutes and carries encrypted data. Analysis of 19 years of GPS satellite broadcasts indicates that it is used by the US military to distribute encryption keys.

Hi,

I'm looking for a portable GNSS receiver that supports Galileo HAS and NMEA 0183 over Bluetooth.

I'm a blind person and I would use the device to accurately position myself in urban and natural environments. I've used more imprecise receivers until now, but I'm unhappy with their precision. It is difficult to find a path crossing in a forest, if the accuracy is only something like 5 m.

I found SparkFun Sparkpnt tx2, but I found no EU dealers. Its price is almost too much for me even without VAT.

Are you aware of any other receivers that would support Galileo HAS, NMEA over bluetooth, have a good antenna and an internal battery?

I'm often off-grid so NTRIP corrections are not an option. Also SBAS does not work well here in north.

Thanks in advance!

Hello everyone,

I am a GNSS professional and researcher. For my research, I am studying the precise positioning applications. I am looking for volunteers in Southern Norway (Arendal, Egersund, Kristiansand, Mandal and surrounding areas) who could offer me a place to install and test RTK stations. If you don't have place, can you please refer to anyone one who could possibly help. The ideal place should be as simple as open space in your garden or rooftop of a house, hotel, workshop, restaurant etc.

As a reward, you will get a 100 krone cash or gift card. The rewards increase for each place where you refer.

DM for more questions.

Thank you in advance.

Dear All,
I was experimenting with 2 U-blox devices ZED-F9P and ZED-X20P. The goal was a setup with a base station and a rover. It took some effort, therefore I wrote a blog about it. This I want to share with you, maybe someone finds the information useful.

https://blog.mayer.tv/2026/05/03/RTK-base-rover-with-Ublox-GNSS-receivers.html

Kind regards
Hans

--

I’ve been working on a UI overhaul for a GNSS evaluation app lately. I ended up trying out Stitch for the front-end, and honestly, it’s been interesting to work with.

My main thought here is simple: GNSS folks deserve better-looking tools. Now it's 2026.

Hi everyone,

I’m hoping to get some help from people who know this stuff better than I do.

I work with an Indigenous community in Canada, and I’ve been trying to really learn the right way to get a solid RTK Fix and collect good GCP points. We have Emlid Reach RS3 units and a DJI Mavic 3E. I’ve got a basic understanding of the workflow, but I still feel like I’m missing some of the real-world practical knowledge that makes everything click.

I’m mainly trying to understand:

• how people consistently get a good RTK Fix with a base/rover setup
• common reasons a rover stays at FLOAT or “waiting for FIX”
• best practices for collecting clean, reliable GCPs
• common beginner mistakes
• how to tell whether the points you collected are actually good
• how to tie the RS3 workflow together properly with a Mavic 3E mapping workflow

I’m not looking for someone to do it for me. I’m trying to actually learn it properly and build a solid SOP for our team, so we’re doing things the right way and not just guessing.

If anyone here has experience with Reach RS3, Emlid Flow / Flow360, Local NTRIP, and GCP collection, I’d really appreciate any advice. If someone is open to spending a bit of time helping point me in the right direction, I can also offer a small amount of money for the help.

Thanks, I’d really appreciate it.
You can contact me on here

A compact dual-band RTK receiver prototype, paired directly with an Android phone.

Centimeter-level positioning is starting to feel more mobile, more lightweight, and much easier to bring into field workflows.

Curious what the GNSS community thinks about this kind of smaller phone-first RTK setup.

Still early, but I like this direction.

If it is a base station, how dense the RTK network could be?

I have a Linux IoT device running gpsd with a u-blox GNSS module, and I wanted to grab its UBX/NMEA output with remote tools like u-center. There are third-party packages available that can translate gpsd's messages to NMEA, but I like simpler solutions. Since the u-blox module can output both UBX and NMEA, we just need a means of pushing it out the door.

I use the socat utility to listen for incoming connections on a given TCP port (I picked 12345) and run the gpspipe utility whenever a connection was initiated. Here's the shell script, /usr/local/bin/gps-nmea-server, that handles that bit:

#/bin/bash
#
# gps-nmea-server = pump gpsd's UBX/NMEA feed to a tcp/ip service
#
PORTNUM=12345   # the TCP port on which we'll listen for connections
UBXOPTS="-P 18.00 --device=/dev/ttyACM0"  # yes, my u-blox is OLD...

# Make sure the u-blox device is providing NMEA
/usr/bin/python -u /usr/local/bin/ubxtool -e NMEA -w .5 $UBXOPTS 2>&1 >/dev/null

# Establish a TCP listener that runs gpspipe in "super-raw" binary 
# mode when connections are made. (Note that this supports multiple 
# concurrent connections.)
/usr/bin/nohup /usr/bin/socat tcp-listen:$PORTNUM,fork,reuseaddr EXEC:"/usr/local/bin/gpspipe -R" 2>/dev/null &

exit 0

To launch this service on boot, I created this service file and installed it with systemctl:

[Unit]
Description=Push gpsd UBX/NMEA output to TCP server
After=gpsd.service

[Service]
Type=forking
ExecStart=/bin/sh -c "/usr/local/bin/gps-nmea-server"
TimeoutStartSec=60

[Install]
WantedBy=multi-user.target

Now, I can examine/visualize the data with tools like u-center (Windows), GNSS Master (Android), and PyGPSClient (cross-platform)...

This is a read-only service - users cannot push configurations/commands to the GNSS device - but it's a quick-and-easy way to make the receiver's output available to a wide variety of remote systems, apps, etc.

I’ve been digging into GNSS behavior lately, and something that keeps coming up is how different “expected” accuracy can be from what actually happens in the field.

On paper, things can look solid:

- good satellite geometry

- low GDOP

- plenty of satellites

But in practice, results can still degrade quite a bit.

From what I’ve seen, a big part of it comes down to factors that aren’t captured by geometry alone:

- terrain blocking or attenuating signals

- multipath (especially near water or structures)

- different signal quality across satellites

So even if the geometry looks good, the actual conditions are not uniform.

Curious how people here deal with that in real workflows — do you mostly trust DOP values, or rely more on field validation?