Trouble Activating Tilt Compensation on Facet FPM-T

Positioning and Navigation
1

I recently purchased two Facet FPM-T receivers. They appear to be working fine in general, but I’ve been unable to activate tilt compensation on either of them. One receiver is running RTK Everywhere Firmware v.3.2, and the other is running v3.3 (that’s how they were shipped). Both are running mosaic-X5 Firmware 4.15.0.

The various web pages, manuals, and videos from SparkFun, SparkPNT, and Feyman (manufacturer of the IM19 IMU) have differing descriptions of how to activate tilt compensation. Some say you first need to do an up-and-down movement of the receiver, followed by planting the rod tip on the ground and rocking the rod and receiver side-to-side in one vertical plane, and then rock them side-to-side in the vertical plane perpendicular to the first. Some omit the initial up-and-down movement. Some simply show side-to-side rocking in only one vertical plane. And one video also includes moving the planted rod and receiver in an upside-down conical motion.

I’ve tried all these variations multiple times with both of my receivers, with varying degrees and speeds of rocking, and I’ve seen no sign of tilt compensation activating. I haven’t heard the beeps indicating that it’s been activated, even though I’ve been in quiet conditions in which I can plainly hear the power-on and power-off beeps. Also, as I tilt the rod and receiver, I can plainly see the current coordinates displayed in QField changing much more than they would if tilt compensation were active.

I checked the tilt compensation settings in the Wi-Fi / web configuration’s Instrument Configuration menu on both receivers. The Enable Tilt Compensation setting was already checked, as expected. The Antenna Phase Center setting was already set to the expected 58.3 mm, and I set the Antenna Height (a.k.a. Pole Length) to the correct value for the rod I was using — not that either of those last two settings should affect mere activation of tilt compensation.

I was getting solid RTK Fix status, using my state’s RTN via my iPhone 17 Pro, QField, and Bluetooth, with quite good sky view. The horizontal accuracy values shown on the receiver display were usually 0.007 or 0.008 meters, occasionally going down to 0.006 meters.

I’ve now found a topic (linked below) on the SparkFun GPS/GNSS forum about tilt compensation with the GNSS Flex pHAT ZED-X20P & IM19 that mentioned the IM19’s tilt mode setting. My reading of the IM19’s Product Integration Guide is that this setting can allow tilt initialization simply by walking — but only after first doing a shaking initialization, and that walking initialization is a subsequent alternative to shaking initialization, not a necessary requirement in addition to shaking. However, a comment in that forum topic claims that the Product Integration Guide is incorrect, and that walking is indeed an additional, necessary requirement — at least for certain values of the tilt mode setting. Could this be relevant to the Facet FPM-T? Would the walking be needed before or after the shaking or the rocking? I can try experimenting with this tomorrow, in the daylight.

Can anyone share successful experience with getting the FPM-T to activate tilt compensation?

Thanks!

--Bill

2

I’ve done some further investigation.

I’ve looked at the RTK_Everywhere / Tilt.ino source code, and I see that the ESP32 firmware is setting the IM19’s “work mode” to Tilt mode 2, meaning “initialize by shaking the RTK pole back and forth or by simply walking. Shaking initialization (same as mode 1) is required when the RTK tilt survey is used for the first time (as an calibration)”, according to the IM19 Product Integration Guide. But according to that older topic linked in my original post, the walking is actually required.

In any case, I tried more attempts today to get tilt compensation to activate, while in RTK Fix: walking, rocking the rod and receiver in two different planes, more walking, more rocking — and nothing worked.

I then looked at the startup messages on both receivers’ serial consoles. Instead of power-cycling the receivers — which drops the USB serial connection and then you miss the startup messages by the time you can reconnect — I used the serial console to switch back and forth between two user profiles. Changing profile causes a reboot, without dropping the USB connection.

One time, with one of the receivers, I saw “Beginning tilt autodetection” and “Tilt sensor detected” messages. But most of the times, with both receivers, I either saw no messages about the tilt sensor, or I saw a “Tilt sensor failed to configure after multiple attempts” message (without a “Beginning tilt autodetection” message).

Does anyone from SparkPNT have ideas about what’s going on?

Thanks!

3

Welcome wjc! Thanks for posting. The device will autodetect the GNSS receiver and the tilt sensor only once after a factory reset. After that, you should not see any messages regarding detection.

You’ve got RTK fix, and I presume you are using default settings, so that should be all you need. A small tilt back and forth is all that is required. We’ll do some testing this morning and try to replicate your issue.

4

We’re able to get an FPM-T into tilt compensation mode doing the following steps:

  1. Turn the device on
  2. Extend the pole to 1.8 meters (default, but can be changed via the Antenna Height)
  3. Enable NTRIP or other and obtain an RTK Fix (required)
  4. Rock the FPM-T back and forth 2 or 3 times
  5. Spin the FPM-T 90°
  6. Rock the FPM-T back and forth 2 or 3 times
  7. Once a beep is heard, the device is actively tilt compensating and work can begin
  8. The device will emit a beep every few seconds indicating it remains in tilt compensation mode

I think you’re doing all of this, but I will note you have to spin the device 90 degrees and do a few more tilts. Or if you don’t spin, just be sure to get some tilts back and forth that are orthogonal to each other.

The issue that we hit, and presume you are as well is that the internal buzzer is very loud, but the FP housing is nearly hermetically sealed, disallowing any of that volume to exit the device. We often can’t hear the beep indicating that tilt is active. We are going to add an additional icon change to the display so that it is visibly discernable but this may take a few days. Additionally, the way we detect if tilt is active is by viewing the position dot during tilt activation. You’ll see it moving (during init) and then stop moving once tilt is active. Please try using the dot - if it stops moving while you’re rocking, then tilt is active.

5

Hi, @Sparky.

Thank you for your prompt Monday-morning replies!

We’re able to get an FPM-T into tilt compensation mode doing the following steps:

What was the RTK_Everywhere firmware version in that unit? Was it a production unit or a preproduction / engineering unit?

I think you’re doing all of this, but I will note you have to spin the device 90 degrees and do a few more tilts. Or if you don’t spin, just be sure to get some tilts back and forth that are orthogonal to each other.

I have tried that both ways, either rocking in one plane, rotating 90º, and rocking some more in that same plane, or rocking in one plane and then rocking in a plane 90º to the first. I’ve had no luck in either case.

I’ve watched SparkFun’s “Tilt Compensation with SparkFun RTK Torch” video from 2 years ago on YouTube, and I’ve tried emulating that movements shown in that video — along with other variations. Is the IM19 activation very picky about the amounts or speeds of movements?

The issue that we hit, and presume you are as well is that the internal buzzer is very loud, but the FP housing is nearly hermetically sealed, disallowing any of that volume to exit the device. We often can’t hear the beep indicating that tilt is active.

As I mentioned in my initial post, I’ve been able to plainly hear the startup and shutdown beeps, but I’ve never heard any other beeps. Are the tilt-activation and tilt-active beeps less loud than the startup and shutdown beeps?

Additionally, the way we detect if tilt is active is by viewing the position dot during tilt activation. You’ll see it moving (during init) and then stop moving once tilt is active.

I was watching for this, keeping an eye on the blue dot in QField. It always kept moving back-and-forth and left-and-right when I rocked the receivers and rods.

This afternoon with one of the FPM-T receivers (FW v3.3), I did five successive selections of two different user profiles, using the serial console, to cause reboots, while logging the console output to a file. In all five cases, there was a:

Tilt sensor failed to configure after multiple attempts.

message. In my previous reply, I wrote that sometimes I saw no messages about the tilt sensor. I now suspect that I was incorrect, and sometimes missed seeing messages that were there in the console output, when I wasn’t logging the output. I realized that the timing of the “Tilt sensor failed to configure…” message, relative to other messages, is variable. I suspect that this message is present on every reboot of both of my FPM-T receivers. Logging to a file let me catch them every time this afternoon.

In a very quick look at the source code, it appears that the message results from Tilt.ino:beginTilt() not setting tiltState to TILT_STARTED, but there are many ways that that function can end up not setting that state. I noticed in that function that there’s a facility for generating debugging output, and another quick look at the code pointed me to the serial config menus’ Configure System / Debug hardware / Print Tilt/IMU Debugging and Print Tilt/IMU Compensation Debugging.

After enabling both of those, I caused a reboot to the appropriate user profile, and logged the serial console output. I’m including the log below; It looks like the ESP32 is having trouble communicating with the IM19.

Perhaps tomorrow I’ll have a chance to log the debugging output from my other FPM-T receiver.

I was planning to be using the tilt compensation feature in a project at the end of this week; I would love to figure out what’s going wrong, whether it’s user error or something else.

Thanks!

--Bill

IMU debugging output from FPM-T A382:

Menu: User Profiles
1) Select Profile1
2) Select (Empty)
3) Select MAHOME <- Current
4) Select (Empty)
5) Select (Empty)
6) Select (Empty)
7) Select (Empty)
8) Select (Empty)
9) Edit profile name: MAHOME
10) Set profile 'MAHOME' to factory defaults
11) Delete profile 'MAHOME'
12) Print profile
x) Exit
x
Rebooting to apply new profile settings. Goodbye!
ets Jul 29 2019 12:21:46

rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 153911750, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:4832
load:0x40078000,len:16460
load:0x40080400,len:4
load:0x40080404,len:3504
entry 0x400805cc
E (1219) esp_cor??fVW
                     }???͡? No core dump partition found!
E (1219) esp_core_dump_flash: No core dump partition found!


28:56:2F:AC:A3:80 - wifiMACAddress
28:56:2F:AC:A3:82 - btMACAddress
28:56:2F:AC:A3:83 - ethernetMACAddress
=======================
Board ADC ID (mV): 2236
=======================
LittleFS Started
Using profile #2
PSRAM Size (bytes): 2097152
I2C Devices:
  0x0B - BQ40Z50 Battery Pack Manager / Fuel gauge
  0x10 - Authentication Coprocessor
  0x21 - PCA9554 GPIO Expander with Interrupt (Facet FP)
  0x3C - SSD1306 OLED Driver (Facet FP)
GPIO Expander for switches configuration complete
Display started
================
SparkPNT FP v3.3
================
SD card detected @ 2026-06-22 22:47:19.640
microSD: Online @ 2026-06-22 22:47:19.701
Profile 'MAHOME' loaded
Starting communication with mosaic-X5
GNSS mosaic-X5 online
mosaic-X5 firmware: 4.15.0
Fuel gauge configuration complete
No GNSS date/time available for system RTC.
Authentication coprocessor online
Bluetooth SPP and BLE broadcasting as: SparkPNT FPMT-A38206
STATE_ROVER_NOT_STARTED --> STATE_ROVER_CONFIG_WAIT
Batt (100%): Voltage: 8.30V Discharging: 0.00%/hr
mosaic-X5 configuration updated
Mode: Rover
NTRIP Client start
Rover Accuracy (m): 0.426, SIV: 0 GNSS State: DGPS Fix
Batt (100%): Voltage: 8.30V Discharging: 0.00%/hr
sdCardSemaphore failed to yield, held by SD Size Check, NVM.ino line 319
System time set to: Monday, June 22 2026 22:47:23
sdCardSemaphore failed to yield, held by SD Size Check, NVM.ino line 319
Scanning for WiFi...
SD card size: 29.7 GB / Free space: 29.7 GB
WiFi: Station online (OMICRON-313: 172.16.1.186)
Sending disable Navi command.
OK not found in response (17 bytes): 
Install Rotmat:
Setting club vector to: CLUB_VECTOR=0,0,1.858
OK not found in response (2 bytes): 

OK not found in response (7 bytes): 
Error
Sending disable Navi command.
OK not found in response (17 bytes): 
Install Rotmat:
Setting club vector to: CLUB_VECTOR=0,0,1.858
OK not found in response (2 bytes): 

OK not found in response (7 bytes): 
Error
Sending disable Navi command.
OK not found in response (17 bytes): 
Install Rotmat:
Setting club vector to: CLUB_VECTOR=0,0,1.858
OK not found in response (2 bytes): 

OK not found in response (7 bytes): 
Error
Tilt sensor failed to configure after multiple attempts.
Rover Accuracy (m): 0.467, SIV: 29 GNSS State: DGPS Fix
Rover configured
STATE_ROVER_CONFIG_WAIT --> STATE_ROVER_NO_FIX, 2026-06-22 22:47:38.293
Batt (100%): Voltage: 8.30V Discharging: 0.00%/hr
Log file name: /SFE_FP_260622_224738.txt
Default Network Interface: None --> WiFi Station
STATE_ROVER_NO_FIX --> STATE_ROVER_FIX, 2026-06-22 22:47:38.402
TCP Server online, IP address 172.16.1.186:2948
Rover Accuracy (m): 0.471, SIV: 29 GNSS State: DGPS Fix
NTRIP Client connected to macorsrtk.massdot.state.ma.us:10000 via 172.16.1.186:53155 at 22:47:40
Rover Accuracy (m): 0.474, SIV: 29 GNSS State: DGPS Fix
Batt (100%): Voltage: 8.30V Discharging: 0.00%/hr
Log file size: 6467 - Generation rate: 1.3kB/s
Rover Accuracy (m): 0.478, SIV: 29 GNSS State: DGPS Fix
STATE_ROVER_FIX --> STATE_ROVER_RTK_FIX, 2026-06-22 22:47:45.949
Rover Accuracy (m): 0.031, SIV: 29 GNSS State: RTK Fix
Batt (100%): Voltage: 8.30V Discharging: 0.00%/hr
Log file size: 14265 - Generation rate: 1.6kB/s
Rover Accuracy (m): 0.030, SIV: 29 GNSS State: RTK Fix
Rover Accuracy (m): 0.030, SIV: 29 GNSS State: RTK Fix
Rover Accuracy (m): 0.030, SIV: 29 GNSS State: RTK Fix
Batt (100%): Voltage: 8.30V Discharging: 0.00%/hr
Log file size: 22013 - Generation rate: 1.5kB/s
Rover Accuracy (m): 0.030, SIV: 29 GNSS State: RTK Fix
6

What was the RTK_Everywhere firmware version in that unit? Was it a production unit or a preproduction / engineering unit?

I pulled a FPM-T production unit running v3.3.

I assume both of your units are throwing the “OK not found in response” error?

We can do a unit swap, or a module swap. I will PM you for contact info.

7

Hi, @Sparky.

Thanks again for your quick responses.

Several minutes ago, I turned on hardware debugging in the other unit, and it too is throwing the same messages as does the first unit.

I’ll reply to your PM.

--Bill

8

This turned out to be an issue with the IM19: we got a new batch of modules with new firmware that was causing issues. The current release candidate fixes the problem and will be released into production shortly.