Specific set up for limeSDR XTRX for location data across X5

Projects LimeSDR
1

Hi,

We are trying to understand and use the onboard GNSS path of a LimeSDR XTRX, specifically through the X5 GNSS antenna connector, and I’d like to confirm what is actually expected to work and what should not.

Our goal is to see whether we can get any useful GNSS-related status or timing from the board when an active GPS/BD antenna is connected to X5.

Our setup is

Jetson AGX Orin
Abysm Gaming Cable De Extensión Riser Pcie 4.0 X16 Flexible Blanco (P/N: AB461701W | Cod. Artículo: 10864575)
LimeFEA mPCIe Full
LimeSDR XTRX v1.2

Host device appears: /dev/limepcie0

I have an active GPS/BD antenna connected to X5.
I measured about 3.05 V open-circuit on the X5 antenna supply line.

What we are trying to do

We are trying to determine whether:

  1. the onboard GNSS receiver connected to X5 is actually working,
  2. the board can obtain GNSS lock,
  3. there is any supported way to get GNSS-related data/status beyond basic lock state.

We are not trying to use X5 as an LMS7002M RX RF input. I understand X5 is associated with the onboard GNSS subsystem, not the normal RXA/RXB RF paths.

Results

1. limeDevice -f

This is what we currently get:

Found 1 device(s) :
0: LimeSDR XTRX, media=PCIe, addr=/dev/limepcie0, serial=whatever
    Expansion name          : UNSUPPORTED
    Firmware version        : 4
    Gateware version        : 1
    Gateware revision       : 22
    Gateware target board   : LimeSDR XTRX
    Hardware version        : 2
    Protocol version        : 1
    Serial number           : whatever
    SPI slave devices       :
                              FPGA
                              LMS7002M
    Memory devices          :
                              EEPROM
                              FPGA/FLASH
                              FPGA/gold-image
                              FPGA/user-image
    GPS Lock:
            GPS - Undefined
            Glonass - Undefined
            Galileo - Undefined
            Beidou - Undefined
    Sensors:
            Temperature(LMS7002) : 60.768°C
            VCTCXO DAC (volatile) : 46870
            Board Temperature : 60.8C

So the board reports all constellations as Undefined.

2. limeOEM --test

With gateware revision 22, we now get:

=== LimeSDR-XTRX OEM Test ===
  === PCIe Reference clock ===
    results: 20417; 21981; 23545
  === PCIe Reference clock - PASSED ===
  === VCTCXO ===
    Count : 2605898 (min); 2605926 (max)
  === VCTCXO - PASSED ===
  === GNSS ===
  === GNSS - PASSED ===
 ...
=== LimeSDR-XTRX OEM Test - FAILED ===
OEM TEST FAILED

Our questions

  1. What exactly does GNSS - PASSED in limeOEM --test verify on XTRX?
  2. Why would limeDevice -f still show all constellations as Undefined if GNSS passes OEM test?
  3. Are there any additional commands, logs, FPGA registers, or diagnostic steps that should be used specifically for XTRX GNSS?
  4. Is the X5 GNSS path expected to work with a standard active GPS/BD antenna powered from the board, or are there antenna requirements that are easy to miss?
  5. Is there any public example with a specific antenna, limeSDR XTRX version, PCIE connector and limeFEA version of successfully using the onboard GNSS on XTRX for lock?

We bought an 1.8 - 3.3V 4 constellation, antenna and we will try as soon as it arrives.

Thanks.

2

Hello jcebriansa,

To answer your questions:

What exactly does GNSS - PASSED in limeOEM --test verify on XTRX?

limeOEM GNSS test only verifies if the GNSS chip is alive (responding to NMEA messages in an expected manner).

Why would limeDevice -f still show all constellations as Undefined if GNSS passes OEM test?
limeDevice checks a register at the address of 0x114 to retrieve lock status. On the XTRX it looks like that register is not implemented, hence the undefined value.

Are there any additional commands, logs, FPGA registers, or diagnostic steps that should be used specifically for XTRX GNSS?
Newer gateware revisions expose the GNSS UART interface to the host machine at /dev/ttyLimeUART0 (baud rate 9600). This allows directly monitoring all NMEA messages emitted by the chip, as well as configuration, if needed. Your current gateware revision (1.22) does not support this.
Instructions on how to upgrade can be found at (you should upgrade the user image):

Tagged gateware releases can be found at (as far as I can tell, all tagged releases should support the exposed GNSS UART, but I’d recommend at least 3.5):

Is the X5 GNSS path expected to work with a standard active GPS/BD antenna powered from the board, or are there antenna requirements that are easy to miss?
As far as I know, a standard GPS antenna should work.

Is there any public example with a specific antenna, limeSDR XTRX version, PCIE connector and limeFEA version of successfully using the onboard GNSS on XTRX for lock?
Not as far as I know.

Let me know if this helps.

3 
Hi @tomasS,

We upgraded LimeSDR XTRX from gateware 1.22 to 3.7, and we tried 3.5 too. We can confirm that /dev/ttyLimeUART0 is now exposed and I can read NMEA at 9600 baud.

Good news are:
	There is a correct timestamp in sigmf-meta, in core:datetime trying limeTRX -t unix. Last version 1 sent something like -1-11-30T00:00:01. Now is complete ("core:datetime":"1980-01-06T00:08:55.000000203Z")

	We see NMEA sentences such as:

		$GNZDA,005348.101,06,01,1980,,*45
		$GNGGA,005349.101,,,,,0,0,,,M,,M,,*5D
		$GNRMC,005349.101,V,,,,,0.00,0.00,060180,,,N*57
		$GPGSV,1,1,00*79
		$GLGSV,1,1,00*65
	
	Using --syncPPS gives an aligned timestamp 1980-01-06T00:54:06.000000000Z

So the GNSS UART is working, but the receiver has not acquired a valid fix yet: RMC=V, GGA fix=0, GSV=00, and the date remains 06/01/1980.

OEM test report these:
  === GNSS ===
  === GNSS - FAILED (Unexpected gateware version.) ===

Then with GW 3.5 and 3.7, core:datetime is now coherent and has fine timestamp resolution, but it is still anchored to the GNSS epoch/date currently reported by NMEA:

Our current understanding is:

GW 3.5 and 3.7 exposes the GNSS UART correctly.
limeTRX -t unix now produces meaningful timestamp formatting.
The timestamp is still not real UTC because the GNSS receiver has not acquired a valid date/time/fix yet.
limeDevice -f still shows the constellations as Undefined, but I understand this may be due to the 0x114 lock-status register not being useful/implemented for XTRX.
Directly reading 0x114 via limeSPI returns 01140000.

Could you confirm whether this interpretation is correct?

In particular, once the GNSS receiver gets a valid fix/date, should limeTRX -t unix automatically start writing real UTC core:datetime values in the SigMF metadata, or is an additional configuration step needed to propagate GNSS time into the RX stream timestamps?
4

Your current understanding is correct.

The 1980 timestamp you’re seeing without a lock is data taken directly from the ZDA message. Gateware assumes data provided by ZDA messages is always valid (unless checksum fails), so as soon as the GNSS chip achieves lock and starts emitting correct time information, it will be used for timestamps.

5

Hi tomasS,

firstable, thanks a lot for your answers.

You are saying that the gateware is receiving the ZDA information?

We only see GNSS UART that is connected with, we understand, PCIe bus right? No with the FPGA and gateware right? I mean, we think that all data of GNSS, even ZDA, goes to the PCIe directly, by other hand iq samples goes to the bus, and this timestamp of core:datetime is printed across the host thanks time data and iq data of PCIe? Is this correct?

Thanks a lot for your answers again. When we recieve the antenna 1.8 to 3.3V we will write here again for share our results.

6

The GNSS UART is not connected directly to the PCIe bus; it is connected to a UART core inside the FPGA gateware.

Here is how the data flow works:

  • Signal Path: The GNSS chip sends data to the FPGA. Inside the gateware, the GNSS UART RX line is split.

  • Dual Processing: Both the UART core and a dedicated ZDA parser receive this data simultaneously.

  • Timestamping: The ZDA parser updates internal registers to ensure the lowest possible latency for limeTRX -t unix.

  • Host Access: The LimeSuiteNG drivers expose the UART core to the host as a standard tty device.

This architecture ensures that while the host can read the NMEA stream, the hardware itself handles the time-critical synchronization.

More detailed technical implementation info: