Good afternoon,
Do we have any updates on this? I really need to get this equipment working.
Notes:
- First testing, the FPM-T would not enter tilt mode with and RTK Fix (no beeps, no dot stop moving). I was testing on d3.4 with IM19 v6.4 (not sure of the minor version, but it was old)
- Connecting over BLE and SPP simultaneously was giving me issues. The BLE channel wasn’t reporting NMEA to SW Maps so NTRIP didn’t start. I changed to using a hot spot on my cell phone with an NTRIP Client enabled on the FPM-T. This allowed the unit to enter RTK Fix, and then I could connect over SPP and view serial debugging output.
- Once debugging was enabled, device entered tilt without challenge.
- Factory resetting the device, device entered tilt without challenge.
- So now I can’t explain why the device failed to enter tilt in the first place.
- Upgraded the IM19 to v11.4.1 to try to more closely replicate your setup. (I know you have v11.4 but the patch version shouldn’t make a difference)
- Factory reset. This removes debug output as part of the equation.
- Getting corrections over WiFi, connecting SW Maps over BLE, device entered tilt without challenge.
- Factory reset.
- Connecting SW Maps over Bluetooth, providing corrections over SW Maps (no more WiFi, no more debugging), device enters tilt without challenge.
So I don’t have a good recommendation at the moment. I’ll keep testing. Here’s what I recommend trying.
- Factory reset. Allow the device to boot and auto-detect GNSS and tilt. Once started, power down the device. Take it outside.
- Turn on the device. Allow it to get a 3D fix.
- Connect over Bluetooth SPP.
- Open SW Maps, provide corrections. Get RTK Fix.
- Rock the device back and forth. At this point, I immediately start to get audible feedback.
This is the output from a factory reset just so you can see version numbers in case we’re missing anything.
============================
SparkPNT FP d3.4-Jun 25 2026
============================
Profile 'Profile1' loaded
Beginning GNSS autodetection
Could not communicate with mosaic-X5 at selected baud rate. Attempting a soft reset...
Auto-detected GNSS receiver: Mosaic-X5
Starting communication with mosaic-X5
GNSS mosaic-X5 online
mosaic-X5 firmware: 4.15.0
Beginning tilt autodetection
Tilt sensor detected
Fuel gauge configuration complete
No GNSS date/time available for system RTC.
Authentication coprocessor online
Bluetooth SPP and BLE broadcasting as: SparkPNT FPMT-A2FE06
STATE_ROVER_NOT_STARTED --> STATE_ROVER_CONFIG_WAIT
Batt (100%): Voltage: 8.20V Discharging: 1.77%/hr
mosaic-X5 configuration updated
Mode: Rover
LoRa firmware: 3.0.1
Rover Accuracy (m): 0.000, SIV: 0 GNSS State: No Fix
Rover configured
STATE_ROVER_CONFIG_WAIT --> STATE_ROVER_NO_FIX
Batt (100%): Voltage: 8.20V Discharging: 1.56%/hr
IM19 firmware: 1141
Tilt sensor configuration complete
Rover Accuracy (m): 0.000, SIV: 0 GNSS State: No Fix
This is the output from a power on:
============================
SparkPNT FP d3.4-Jun 25 2026
============================
Profile 'Profile1' loaded
Starting communication with mosaic-X5
Could not communicate with mosaic-X5 at selected baud rate. Attempting a soft reset...
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-A2FE06
STATE_ROVER_NOT_STARTED --> STATE_ROVER_CONFIG_WAIT
Batt (100%): Voltage: 8.20V Discharging: 2.06%/hr
Mode: Rover
NTRIP Client start
LoRa firmware: 3.0.1
Rover Accuracy (m): 0.000, SIV: 0 GNSS State: No Fix
IM19 firmware: 1141
Tilt sensor configuration complete
Rover Accuracy (m): 0.000, SIV: 0 GNSS State: No Fix
Rover configured
STATE_ROVER_CONFIG_WAIT --> STATE_ROVER_NO_FIX
Batt (100%): Voltage: 8.20V Discharging: 1.83%/hr
Rover Accuracy (m): 0.000, SIV: 0 GNSS State: No Fix
Here is the output via Bluetooth SPP. Indoors, Print Tilt/IMU Debugging: Enabled. Note, no tilt debug prints are seen because indoors I do not have RTK Fix:
Next, outdoors. I’m getting corrections over WiFi/built-in NTRIP Client:
Above, we see tilt started, RTK Fix, and initialization proceeds as we tilt.
Above, Tilt is correcting after initialization is complete.
It’s hard for me to say why the very first attempt at entering tilt failed. I may blame it on the state of my unit. We, developers, do very mean things to our units and my unit may have been in a bad state. After that first factory reset, I cannot get tilt to fail to work. Please let me know if you see anything different on your unit.
Good afternoon,
I am still struggling with the tilt compensation and want to provide a clearer summary of my setup and testing.
I have tested with:
- Wi-Fi Internet;
- my phone’s hotspot, with SW Maps running on my tablet; and
- SW Maps installed directly on my phone, using both Wi-Fi and cellular data.
I also tested X-Survey. It reports more satellites and reaches RTK Fix quickly, but I still do not hear any tilt beep or see the pole-tip behavior change in either application.
I have repeated the tilt test well over 30 times. I am in a very quiet area, so I would be able to hear the beep. I have tried slow and fast forward/back movements, left/right movements, circles, and different directions. I have never heard the initialization sound.
I can receive normal NMEA data over both the Windows USB serial connection and Bluetooth Serial Terminal, but I have not captured any useful tilt initialization or compensation output.
Following your last recommendation, I did the following:
- Factory-reset the FPM-T.
- Allowed it to boot and auto-detect GNSS and tilt.
- Powered it down and took it outside.
- Powered it on and waited for a normal 3D GNSS position.
- Connected SW Maps, supplied Onocoy NTRIP corrections, and obtained RTK Fix.
- Rocked the pole forward and backward several times.
The result was still the same: no audible tilt feedback and no apparent tilt compensation.
My correction source is Onocoy NTRIP. My own validated Onocoy base antenna is on my roof, very close to my test location.
My devices should be capable:
- Google Pixel 10 Pro, Android 17
- Ulefone RugKing 2 Pro, Android 16
The FPM-T is running firmware d3.4 (Jun 25 2026), and the IM19 reports firmware 1140 / version 11.4.
Could this be a hardware issue? Would you recommend returning the unit for inspection? Also, for the test you described, should the Bluetooth SPP connection remain connected at the same time as SW Maps over BLE, or should I perform the test with SW Maps only?
I am happy to record a video showing the complete procedure from startup through the rocking test, or perform any other test you recommend. I really need tilt compensation working to perform my work.
Thank you again for your help.
One additional question: your successful test used IM19 firmware 11.4.1, while my FPM‑T reports IM19 firmware 1140 / version 11.4. I understand you said the patch difference should not matter, but since tilt still will not initialize after the factory-reset test, would it be possible to provide the official procedure and firmware file to update my IM19 to the same 11.4.1 revision you tested?
I understand this may not be a normal user-update path. I will not attempt any unofficial flashing method; I only want to try it if you can provide or confirm the exact supported FPM‑T procedure.
Additional Bluetooth and correction test results:
- On my Google Pixel phone, SW Maps connects to the FPM‑T only using Bluetooth Classic, not Bluetooth LE. Because SW Maps occupies the Classic/SPP connection, I cannot simultaneously connect Serial Bluetooth Terminal; the two apps disconnect each other.
- On my Ulefone tablet, SW Maps can connect through Bluetooth LE while Serial Bluetooth Terminal connects through Bluetooth Classic/SPP at the same time. This matches the dual BLE + SPP setup you described.
- I tested the tablet with SW Maps connected by both Bluetooth LE and Bluetooth Classic. In both cases, with RTK Fix active, rocking/balancing the pole forward and backward produced no tilt beep and no apparent tilt behavior.
- On the phone, using Wi‑Fi and cellular Internet, enabling “Apply Base Antenna PCO” in SW Maps makes a major difference to correction performance: RTK Fix is obtained much faster and more reliably.
Therefore, the tablet can reproduce the intended simultaneous BLE + SPP connection setup, but tilt still does not initialize or provide audible feedback in either Bluetooth mode.