GNSS BRIDGE mode working only in one direction (GNSS -> USB -> PC)

31 views
Skip to first unread message

Andreas Hotovy

unread,
Jan 9, 2026, 2:13:17 PM (2 days ago) Jan 9
to SoftRF_community

Hello Group,


Long-time reader, first post. I have a question regarding GNSS BRIDGE mode on a T-Beam.


Background:

Andreas (“Andy”) Hotovy, IT professional, licensed radio amateur. Flight licenses: GPL, Ultralight, PPL(A). Home base: EDMV Vilshofen, 80 mi east of Munich, Bavaria, Germany. Often seen flying powered in the German and Austrian alps with lots of powered and unpowered traffic. Using Moshes SoftRF since MB123 on T-Echo, switching to T-Beam with the availabilty of ADS-B.


Equipment used:

- T-Beam V1.2 with Moshe’s SoftRF (latest MB171)

- GNSS: u-blox M8N

- Protocols: FLARM, ADS-B

- BMP280

- SD card for logging

- ADS-B receiver: GNS5892R

- SkyDemon on iPadOS via BLE

Issue:

The u-blox M8N shows poor GNSS performance:

- Long TTFF (~2 minutes cold start)

- Low satellite count (8–10 with 3 GNSS constellations enabled)

- Poor horizontal and vertical stability, even after hours of operation

Multiple active ceramic patch antennae (various sizes and price ranges) were tested without satisfactory result. In contrast, a Heltec tracker almost immediately reports 25+ satellites with significantly better position and altitude stability.

Objective:

I would like to analyze the M8N using u-blox u-center with the T-Beam V1.2 in GNSS BRIDGE mode.

Problem:

Data forwarding from GNSS -> USB -> PC works, but PC -> USB -> GNSS does not. As a result, u-center cannot communicate with the receiver. Immediately after reset, I can observe the SoftRF GNSS initialization sequence on the RX pin 21 using an oscilloscope. However, when attempting to send data from the PC to the GNSS module, there is no activity.

Questions:

- Are additional settings required beyond enabling BRIDGE mode?

- Are there any further debug options or diagnostics available?

Any assistance is much appreciated.

Thank you,

Andy

Moshe Braner

unread,
Jan 9, 2026, 5:06:05 PM (2 days ago) Jan 9
to SoftRF_community
Welcome Andy!

I'm surprised your Neo8 doesn't work well.  The older Neo6 which is in most T-Beams, some of them work OK and some are poor.  A better antenna usually makes them work well enough, but you've already tried that.  My suggestion (if you can't make the Neo8 work better) is to graft on a "VK2828U7" module, those are a uBlox 7 chip integrated with a 25x25mm antenna, and are available online.  I've used several of those and they work well.  And they cost less than EUR10.

Meanwhile, to try and make your Neo8 work, have you tried the "reset GNSS" button in the status web page of SoftRF?  That does a cold start.

Connecting to uBlox U-Center should work, I did that with one unit here just a few weeks ago, so I am not sure why it did not work for you.  Perhaps you have a baud rate issue, although since it works in one direction that seems unlikely.  Note that the Neo8 default baud rate is (probably) 9600 baud.  In normal use my SoftRF tries that, and if that fails, tries several baud rates from 115000 down.  But in "GNSS Bridge" mode the baud rate used to connect to the module is the same as is used for the external USB-Serial connection.  So set that (in the SoftRF settings) to 9600 baud as the first guess.  And tell U-Center to use that.  But you probably already did that.

When you are NOT in GNSS Bridge mode, does the USB-serial output during booting show that it is communicating in 2 directions with the Neo8?  It would say things like "U8 detected", which means it sent a UBX command to the module and got a reply, thus it proves 2-way communications.

- Moshe

Andreas Hotovy

unread,
Jan 10, 2026, 7:07:03 AM (2 days ago) Jan 10
to SoftRF_community
Thank you Moshe!

I was turning on GNSS debug mode (#define DO_GNSS_DEBUG in GNSS.cpp) and recompiling MB171 with that. All communication to and from the module seem to be ok. 

For ex, writing to the GNSS during initalization:
 * Reading ACK response: prepared:B5,62,5,1,2,0,6,3E,4C,75,
B5,62,5,1,2,0,6,3E,4C,75, (SUCCESS!)

I did the software reset and also a hardware reset, forcing pin 1 of the neo to GND during power up, with no obvious success.

But - while checking the T-Beam schematics I stumbled across one thing that could explain the poor GNSS performance for all u-blox modules on the T-Beams (spoiler: not in my case):

The Bias-T in the RF path of the GNSS module, that cares for DC supply of the LNA of the patch antenna, has strange values for the inductor and the resistor (and one missing capacitor):

Resistor: is 100 Ohms, should be 10 Ohms. Should act as a current limiter for short circuit protection only, not as a current limiter in series with a LED for ex. In this case, 100 Ohms are way to much. I've seen voltage drops of as much as 2.0V over the R+L, diving 1.2 V for the LNA on one of my tested antennas, which is out of spec for most LNAs. So you never know if its actually amplifying something or attenuating the precious RF. Changed that R to 10 Ohms, have now 3.0 V @ 18 mA on my trusted antenna, which is OK.

Inductor: is 27 uH (micro!), should be 27 nH. The resonant frequency of that inductor should be way higher than the highest used frequency in the RF path, here 1.5 - 1.6 GHz. Resonant freq of a 0805 SMD inductor with 27 uH is - depending on the manufacturer - between 14 MHz and 30 MHz. So its unpredictable how this inductor acts at 1.5 GHz. Most likely the parasitic capacitive component outweighs the inductive component and worst case the whole thing acts as an attenuator... Replaced it by 27 nH 0805 inductor with self resonant frequency of >2.6 GHz.

Normally, there should also be a capacitor of 10 nF from the common L-R node to GND, filtering out residing EMI from power supply or shorting residing RF after the inductor. Added a small 0603 ceramic cap to GND.

All recommended values according to u-blox' HW integration manual https://content.u-blox.com/sites/default/files/NEO-8Q-NEO-M8-FW3_HIM_UBX-15029985.pdf, page 15.

As mentioned before, this did not help in my case, but in aviation, we should leave nothing to chance. And maybe this explains the reported varying GNSS performance on some 6M modules...

So, at the moment I am a bit stuck and don't know how to go on, knowing the u-blox could do better. Adding external GNSS module is my last ressort. I am planning to add an additional SoftRF module - maybe the Nano - for FANET reception (Nano FANET -> GDL90 out -> T-Beam GDL90 in on RX/TX (USB not powered). Works with Heltek Tracker and FLARM with a second T-Echo sending FLARM in my lab, so every T-Beam pin counts...).

Andy

VirusPilot

unread,
Jan 10, 2026, 7:14:34 AM (2 days ago) Jan 10
to SoftRF_community
Hi Andy and best Regards from EDFW!

Before you abandon the onboard M8N, please let me also do some tests - I spent a significant amount of time with u-blox chipsets, e.g. did some of the GNSS enhancements in Stratux, MB's SoftRF and GXAirCom. Meanwhile I also can report a strange situation: just received a new T-Beam v1.2 with M8N which seems to have a default baud rate of 115200 so I wanted to investigate further on this anyway ...

Best,

Stefan

Moshe Braner

unread,
Jan 10, 2026, 9:28:39 AM (2 days ago) Jan 10
to SoftRF_community
Due to the GNSS module on some T-Beams reported defaulting to 115200 baud, some months ago I added the autobaud feature, where SoftRF tries several baud rates if the module is not detected at 9600 baud.

Moshe Braner

unread,
Jan 10, 2026, 1:19:43 PM (2 days ago) Jan 10
to SoftRF_community
I now tried using a T-Beam with an M8N GNSS that I had sitting here but never used before.  It got a fix very quickly, and that is with the original little rectangular GNSS antenna.

On the other hand for experiments I am running today I was also using an old T-Beam to which I attached an alternative 25x25mm GNSS antenna a while ago, since the internal antenna worked poorly.  It worked fine at first, but at one point it lost the fix and would not regain it, even outside the house.  After some frustration, I rotated somewhat the tiny connector at the end of the antenna cable, that plugs into the jack on the T-Beam board.  It immediately got a fix again.  I.e., that connector was having an intermittent connection.

Which reminds me to warn everybody: that tiny U/FL connector is terrible.  If you unplug it and re-plug it there is a large probability that it will break.  Doing that more than a couple of time is likely to break it.  Maybe that is the problem in your case, Andy?  An advantage of using the VK2828 module is that then you do not use that U/FL connector any more.  The connection to the antenna is internal to the VK2828 module.  The connection to the T-Beam is then 5 plain wires, for power, ground, serial data in both directions, and PPS.

That would not explain why u-center cannot communicate with the receiver though.


Reply all
Reply to author
Forward
0 new messages