Config issue with Feynman IM19 not accepting GNSS

Other
1

Hi everyone,

I’m hoping someone from SparkFun or anyone who has successfully integrated the Feynman IM19 with the Septentrio Mosaic-G5 P3 can help, as I’ve reached the point where I believe this is a configuration issue rather than a hardware problem.

Hardware

SparkFun GNSS Flex pHAT

SparkPNT GNSS Flex Module – Mosaic-G5 P3 Tilt

Raspberry Pi 5

IM19 Firmware: ParaVision 4.20

The board is completely unmodified. No solder jumpers have been changed and all routing remains at the factory defaults.

What I’ve verified

The Mosaic receiver is obtaining a valid 3D GNSS fix and is transmitting NMEA correctly.

I’ve verified this by:

Viewing a valid GNSS fix in PyGPSClient.

Monitoring /dev/ttyAMA0.

Using a multimeter to verify that the Mosaic TXD1 line is electrically active, with voltage transitions between approximately 3.0V and 3.3V.

Running hexdump on /dev/ttyAMA0.

The UART output is pure ASCII NMEA with no binary/SBF messages mixed into the stream.

The only messages being transmitted are:

GPGGA, GPGST, GPRMC at 115200 baud rate…

As the SparkFun GNSS Flex pHAT is still in its factory configuration, the Mosaic GNSS output should already be internally routed to the IM19 GNSS input.

I have made no hardware modifications to the board.

The Mosaic TXD1 line is electrically active and the signal is present both on the connector and the corresponding test point on the PCB.

IM19 configuration

Current IM19 settings are:

GNSS Card: OEM

GNSS Port: PHYSICAL_UART3

UART3 Config: NASC

Work Mode: 0x019A

Fix Mode: True

Tilt Mode: True

ParaVision Version: 4.20

The IM19 is definitely alive and communicating.

I can configure it using AT commands through PyGPSClient and it outputs GPFMI/NASC data continuously.

Mosaic output configuration

The UART feeding the IM19 is configured as follows:

Baud Rate: 115200

Output Format: ASCII NMEA only

Enabled messages:

GPGGA, GPGST, GPRMC

No SBF or other binary messages are enabled on this UART.

PyGPSClient configuration

Mosaic receiver

Serial Port: /dev/ttyAMA0

Baud Rate: 115200

Protocol: NMEA

Output is parsed correctly and displays a valid 3D GNSS fix with latitude and longitude.

IM19

Serial Port: /dev/ttyAMA4

Baud Rate: 115200

Protocol: NMEA

IM19 status page displays:

NO FIX

Latitude = 0.00000000

Longitude = 0.00000000

Continuous GPFMI messages are received from the IM19 output.

The issue

Despite all of the above, the IM19 never appears to accept the incoming GNSS solution.

Even after leaving the system running outdoors for over three hours:

Mosaic

Valid 3D GNSS Fix

Correct latitude and longitude

NMEA output present and verified

IM19

NO FIX

Latitude = 0.00000000

Longitude = 0.00000000

The IM19 continues outputting GPFMI messages but never populates its position.

Additional observations

Running:

AT+CHECK_SYNC

returns continuously:

2 0

2 0

2 0

I have been unable to find documentation explaining what these two values represent

2

Hi @MasterChief ,

Welcome!

With the jumpers in the default state, mosaic-X5 COM4 TX is connected directly to IM19 UART2 RX. You need to ensure the mosaic is outputting GGA, GST and RMC on COM4 at 5Hz at 115200 baud.

Using Flex UART numbers:
Flex UART1 : RPi GPIO14 and 15 : is connected to mosaic COM1
Flex UART2 : RPi GPIO8 and 9 : is connected to mosaic COM2
Flex UART3 : RPi GPIO4 and 5 : is connected to IM19 UART1
Flex UART4 TX : connected to RPi GPIO12 : is connected to IM19 UART2 TX

Outputting GGA, GST and RMC on mosaic COM1 is fine. But you also need to make sure they are output on COM4.

The IM19 GNSS Port is PHYSICAL_UART2, not PHYSICAL_UART3. IM19 UART3 is not connected on that Flex module.

Please let us know if / when you need more help.

Best wishes,
Paul

3

Hi @PaulZC I’m trying to use a MOSAIC G5 P3 (SEPT), not a X5…

As far as I know, the Sparkfun is there to collect lat/long and NMEA GGA GST and RMC, and PPS from the Mosaic board, on RXTD1 to the Uart2 RX on the Feynman IM19. High Speed (on the IMU) keeps moaning that it isn’t supported for NMEA output sadly, so Am just keeping it to 1Hz. It has the engine for IMU calculations which outputs on the Uart2 TX to the TX4 port (pin 33) on the Raspberry Pi. I can see the basic NMEA text being output from the IMU. Just it refuses to process the NMEA data on the input.

When I took a scrceenshot earlier, i had opened up the config on /dev/ttyAMA2 (Uart1 for the IMU) and it got a GNSS time fix at the time. So I know it is collecting some data, but not always which I can’t quite figure out. Its 98% of the way there. Just don’t know whats missing!

4

Hi @MasterChief ,

Ah! Sorry… I didn’t read your post well enough…

OK. For the G5 P3 with IM19, yes, the IM19 UART2 RX is fed by mosaic UART1 TX. So, yes, it should be ~happy with what you’re seeing from UART1.

Things to check:
You need to feed the IM19 GGA, GST and RMC at 5Hz (message interval 200ms) at 115200 baud. Please double check the message interval.
The mosaic COM1 is feeding IM19 PHYSICAL_UART2 (not PHYSICAL_UART3)
The GNSS needs RTK Fix (not just a 3D fix). How are you providing the mosaic with RTCM corrections? Are they being delivered to mosaic COM2? Are they coming from an NTRIP Server through PyGPSClient?

If you connect the pHAT USB port back to the Pi, or two another computer, you will get another two ‘virtual’ COM port connections to the mosaic. They can be very useful for diagnostics. If you connect a terminal emulator at 115200 baud and hit Enter a few times, you should see a USB1> or USB2> prompt. If you do, then try typing “lstConfigFile,Current” (without the quotes) and hit enter. You should see a text report which tells you how the mosaic is configured. It will tell you which messages are enabled on which streams on which ports. If you see that, please copy and paste it here so we can take a look.

Forgive me for asking, but your GNSS antenna is outdoors, with a clear view of the sky?

Best wishes,
Paul

5

PXL_20260709_115217255.RAW-01.COVER
PXL_20260709_115217255.RAW-01.COVER1920×1080 561 KB

Notes for context. Top left - /dev/ttyAMA0 - Serial port 1 for GNSS output from Mosaic G5-P3 Sept including 3D fix

Right side - /dev/ttyAMA2 - Serial port 2 for IM19 IMU config (Command AT+READ_PARA=ALL) with GNSS time lock at the time I opened up the connection

Bottom Left - /dev/ttyAMA4 - RX4 on the Pi5 - Received IMU logs from the IM19 but with NO FIX and no lat/long coordinates. Tilt compensated data not outputted correctly as not initialised due to no GNSS fix.

6

Hi Paul,

Whenever I’ve tried using PHYSICAL_UART2, i’ve then lost all output from the IMU. Whenever I’ve used Physical_UART3, I can see output from the IMU, but without GNSS compensated input…

I’m currently inside an aircraft hangar, so there isn’t great unobstructed view of the sky. But in the next bay along (away from my workbench) theres a GNSS Repeater with strong signal, and its antenna ontop of the building with a clear view of the sky. It’s where I took the other photo.

I’ve currently got a ZED-X20P module connected to the sparkfun, so you might have to bear with me whilst I switch over the boards :slight_smile:
I’ve been configuring the Mosaic through RXControl, so If theres a way to send the config out from saved configs I’ll try that :wink:

7

I can’t say with absolute certainty, but I don’t think a RTK Fixed solution will be possible with a typical gnss rooftop repeater due to hardware delays and phase shifts… and Paul says this needs a RTK Fix solution to work.

8

Hi @MasterChief ,

I have not tried using the IM19 UART2 for GNSS data input and Feyman NMEA or Binary output at the same time. I’m really not sure if that is supported…

My advice is to concentrate on using IM19 UART1 for configuration and Feyman message output, and leave IM19 UART2 dedicated for the GNSS NMEA data input.

IM19 UART3 is not connected on that module. Selecting AT+GNSS_PORT=PHYSICAL_UART3 is not the right choice.

For the GNSS Repeater, I’ve used those in high-bay labs a couple of times. But only for standard 3D positioning, never for RTK. The Repeater signal will be good enough to let the mosaic get a 3D solution. But when it comes to calibrating the IM19, I suspect it will cause all kinds of difficulties. When you tilt and rotate the IM19, the motion of the IMU and the GNSS solution won’t match (assuming that the GNSS solution moves at all…). To get your system calibrated, you’re going to have to have the antenna and IM19 mounted on the same hardware, outdoors, with RTK Fix.

I hope this helps,
Paul

9

PS. RxControl has a handy “Show Receiver Configurations” option under “File”. Click the little arrow next to “Current” to view the current configuration. Behind the scenes, it is using lstConfigFile to create that view.

10

MosaicG5P3SEPT_IM19IMU.txt (216 Bytes)
That’s the log file :slight_smile:

11

@MasterChief :

Thank you.

You have COM1 and COM2 set to NMEA Output (and Auto Input).
You have created Stream1 to output NMEA GGA+GST+RMC on COM1 at an interval of 200msec.

You have a Daisy Chain 1 and 2 (DC1 and DC2) set to ASCII mode. But you’re not actually using DC1 or DC2. So that’s OK.

That all looks OK. COM1 and COM2 will be using the default baud rate of 115200. That’s what the IM19 is expecting.

The IM19 should be happy with that.

I suggest looking again at the AT+GNSS_PORT and making sure that is set to PHYSICAL_UART2. It won’t work any other way. Use IM19 UART1 for your configuration and Feyman message output.

If you send AT+READ_PARA=ALL (plus Carriage Return and Line Feed) to the IM19 on UART1, it will respond with all its settings. If you post those here, we will check them for you.

Best wishes,
Paul

12

Just in case it helps, here is the configuration we use in our RTK Everywhere Firmware:

AT+LOAD_DEFAULT
AT+GNSS_PORT=PHYSICAL_UART2
AT+NAVI_OUTPUT=UART1,ON
AT+INSTALL_ANGLE=0,180,0
AT+LEVER_ARM2=0.03391,0.00272,0.0237
AT+CLUB_VECTOR=0,0,1.916
AT+GNSS_CARD=OEM
AT+WORK_MODE=408
AT+HIGH_RATE=DISABLE
AT+MEMS_OUTPUT=UART1,OFF
AT+CORRECT_HOLDER=ENABLE
AT+SET_PPS_EDGE=RISING
AT+AHRS=ENABLE
AT+MAG_AUTO_SAVE=ENABLE

Note: ‘CORRECT_HOLDER’ command is not supported on app versions 11.1 and later.

Note: INSTALL_ANGLE must be sent before LEVER_ARM2

13

The problem I have is this a hardware fault or a software fault? When i set the Physical GNSS Port to UART2, i can’t tell whether the IM19 is accepting the data since I get no output, but when I set the GNSS to UART3 (which shouldn’t exist but appears to be mapped to some port…) I get IMU output on the correct pin (TXD4)… Is this a configuration issue or a hardware fault with the sparkfun board.

I’ll be leaving soon for evening events, but I can try getting the GNSS/IMU setup this evening when I return, or possibly on the weekend.

14

@MasterChief :

I believe it’s purely a configuration issue.

Like I said earlier, I am not sure if the IM19 can use UART2 for GNSS data input and Feyman NMEA or Binary output at the same time.

I suggest you forget about trying to enable the GPFMI (NAVI ASCII) message on UART2 TX (TXD4). Enable it on UART1 TX (TXD3) instead using AT+NAVI_OUTPUT=UART1,ON. Leave UART2 dedicated for GNSS input only, no output.

AT+LOAD_DEFAULT
AT+GNSS_PORT=PHYSICAL_UART2
AT+NAVI_OUTPUT=UART1,ON
AT+INSTALL_ANGLE=0,180,0
AT+LEVER_ARM2=0.03391,0.00272,0.0237
AT+CLUB_VECTOR=0,0,1.916
AT+GNSS_CARD=OEM
AT+WORK_MODE=408
AT+HIGH_RATE=DISABLE
AT+MEMS_OUTPUT=UART1,OFF
AT+CORRECT_HOLDER=ENABLE
AT+SET_PPS_EDGE=RISING
AT+AHRS=ENABLE
AT+MAG_AUTO_SAVE=ENABLE

You may need to delete the AT+CORRECT_HOLDER=ENABLE if your IM19 firmware does not support it.