Is the UM982 an F9P killer for AOG?

Um982 base work with esp32 as wifi ntrip master as well.

I did some pole tests with UM982 dual and 2 IMUs. Both static and dynamic. IMU BNO08X, both IMUs are used in UART-RVC 100hz mode. UM982 outputs GGA,VTG,HPR sentences at 10hz. For this test master antenna is HA901A (3band), slave antenna is bt560 (dual band) with 150cm baseline between them. RTK base station is 3band. Every 10 points on X axis is 1 second.

Settings for um982 are below:

Freset // reset to factory settings
Unlogall // off all messages
Mode rover automotive //
Headingmode tractor // for agricultural machinery
config heading offset 90 0 // offset of antennas
config heading length 150 0 // baseline
Gpgga com1 0.1
Gpvtg com1 0.1
Gphpr com1 0.1
Config com1 460800 // baud rate
Saveconfig // save config

Hire is static test at 0 deg.

Average of UM982 roll is 0.48deg
Standard deviation 0.25deg

This is static test at expected 10.9deg measured by height and geometry. Test was done also in - direction by rotation of rood 180deg.

Standard deviation 0.14deg
Average roll 11.3deg
Standard deviation 0.32deg
Average roll -10.0deg

Hire we can see IMUs start to diverge as well. They are always close when roll is close to 0 but they can diverge up to 1deg in some cases. This behavior is seen in many tests.

Next are dynamic tests:

These next 3 tests where carried out without pole, so rood/antennas sit on 0 height and rotate around pivot. I first move rood to stoppers slowly and stay there for few seconds. So we have reference for what actual roll output should be. Then fast hit stoppers at ether side.

So in very dynamic environment IMUs seem to overreact. But tractor has less dynamic environment then this.

This is control slow moving test with same conditions.

This is pole (235cm height) test, one IMU is next to antenna other is 100cm from pivot point on center of pole.

And hire is random movement test with movement in Z direction as well. This is to not have “perfect” roll scenario, and should be closer to actual field requirements. All 3 roll sensors seam to output roll very close to each other.

Dual roll from um982 in static and dynamic pole tests seams equally good as IMUs. Some filtering can help when roll is not changing much as dual roll jitters ±0.25 deg.

But real field test is required, even better to gather data in same style so comparison of dual and different heights of IMUs can be achieved.



Yes, the UM982 does work with RTKBase. I installed RTKBase 2.5.0 and configured the UM982 as a self-optimizing base station. Temporarily changed my stream going to from the F9P RTKBase setup to the UM982 RTKBase setup. Verified messages are being received by rtk2go and AgIO.

The following messages need to be enabled on the UM982. The one with (10) are every 10 seconds and the others are every 1 second.

1 Like

You only used RTKBase as an NTRIP server and caster then? In standard operation RTKBase will only receive raw data from the GNSS receiver and process it with RTKlib. (during install it would configure any F9P to enable RAWX and SFRBX and disable SBAS and NMEA) Could UM982 be configured to send raw data?

The UM982 does have messages with the same data as RAWX and SFRBX but they are not the same format as Ublox. What is the advantage of processing the raw data with RTKlib to create RTCMv3.3 messages versus using the onboard processing of either the F9P or UM982 to create RTCMv3.3 messages?

New AIO v4.5 STD board has been released! Greatly improved support for the UM982. Check it out here → AIO v4.5 update released

That is an impressive set of tests and graphics! But I am not sure about your summary. To me it seems that especially in slow and static situations the UM982 shows slow deviations that will certainly cause steering reactions. Based on this data, IMU seems preferable to me. However, the dual UM982 data may be flawed by using completely different antenna’s. (maybe this explains also why 0 degrees is not measured correctly) For ANN antenna’s U-blox advise is even to mount them in the same orientation, (both wires pointing in same direction)

I wouldn’t say it is better, but the standard RTKBase functioning offers more versatility. Like creating multiple different NTRIP streams, gathering RINEX data etc.

IMU is stable in “stable” conditions. Dual roll is always flawed, if we say that dual band vertical accuaracy is ±2.5cm then on 1.5m baseline roll can vary ±0.95deg that is if vertical position is in ±2.5cm range. If its worse then roll will be even more wrong. That is standard trade off of dual vs IMU. Dual produces roll in that tolerance and in short term its ±0.25deg. But from apsolute value that it can be its ± 0.95deg. Or worse if you are further from rtk base or conditions are not good.

F9P is even worse in this aspect as both antennas have ±2.5cm vertical accuaracy. So for F9P dual apsolute roll error can be ±1.89deg vs UM982 ±1.52deg as main UM982 antenna should output ±1.5cm vertical position. This side is not seen on test as roll is calculated from slave antenna position. So in test we see only one side of apsolute roll error.

IMUs have problems on bumps. For more stable conditions they work good. But dual roll should be more stable in rough field work where other forces influence output of IMU roll and heading. Atleast that is theory behind choosing between dual vs IMU system.

All of the functions in RTKBase worked. Ntrip A & B, Caster, RTCM TCP, RTCM Serial and File. File outputs RTCM files. My F9P based RTKBase outputs UBX with the file service. I did not see an option for RTKBase to convert UBX to Rinex.

1 Like

In the testing I did I used identical antenna pairs. The leads were facing the same direction. The antennas remained mounted. Only the cables inside the building were switched between receivers.

1 Like

I done static tests on 3band base, for 1h and then 4.5h to have more data samples.
1h test:

4.5h roll:

4.5h heading:

With bigger data set roll and heading start to look like normal distributions.

You can use DM’s here. Just click on my username and hit “Message”. That will start a private message thread.


I’ve carefully followed this thread on the UM982 module, recommended by @tomischmid on GitHub in the RTKBase repo issue. Thanks for the invite. I’ve learned a lot from the shared user experiences and hope to contribute my own insights.

I’m José Martínez from the Dominican Republic, experienced with both the u-blox ZED-F9P and Unicore UM980 (similar to UM982 but with a single antenna). I build DIY receivers, both rovers and bases, using Raspberry Pi Zero W (avoiding the 2W for power consumption reasons), adding batteries, charging and protection circuits, and encasing them in electrical enclosures. These devices are used extensively, including for teaching at a public university in the Dominican Republic where I teach geography. One of my ongoing challenges is transitioning from Raspberry Pi to microcontrollers, and ideas from this forum have been incredibly helpful.

My applications are somewhat different from the ones shared in the forum. My main focus is on static occupations for crustal deformation studies in Santo Domingo (geodesy) and occasionally RTK and PPK for drone photogrammetry. I also use GNSS for photogrammetry with historical aerial photographs. For all these applications, I rely on open-source software like the demo5 branch of RTKLib and OpenDroneMap for photogrammetry.

I’ve programmed tools based on RTKLib for operating my rovers in the field using terminal consoles (termux app on Android), and created a branch of RTKBase tailored to my needs for operating both ZED-F9P and UM980 (GitHub - geofis/rtkbase at unicore). My apps are definitely not user friendly, they “work for me”.

Though much has been said about u-blox products here, I’d like to mention that the company offers excellent support, accessible software, and great integration with RTKLib. I’ve used ArduSimple, Sparkfun, and Eltehs ( boards, all performing efficiently over the years (one has been running 24/7 for three years without issues).

Unicore, however, lacks these aspects. Yet, the UM980 outperforms the ZED-F9P in geodesy applications with its full range of frequencies and multiple signals per frequency. Recording raw data every 15 seconds for 24 hours provides remarkable precision for static occupations. Unicore’s raw data to RINEX converter is efficient, handling large files flawlessly, though sometimes it’s inconsistently available on their website.

The UM980’s internal RTK engine (based on Nebulas IV chips) isn’t as robust as u-blox’s, but it seems Unicore is planning improvements. In my tests, achieving a fix with UM980’s internal engine using a ZED-F9P base was slower and less stable compared to using a ZED-F9P as a rover. However, using RTKNAVI (rtkrcv) and transmitting only RTCM (RTKLib doesn’t convert Unicore’s native format), I achieved fixes as efficiently as with u-blox’s internal engine.

On the other hand, testing the UM980 as a base and ZED-F9P as a rover, both in RTK (using u-blox’s internal engine) and PPK (demo5), yielded quick and stable fixed solutions. In all cases, errors were low, though I haven’t conducted a statistical analysis due to time constraints. Sending raw UM980 observations to NRCAN yielded solutions with 2-3 mm Sigma(95%) for 24-hour observations at a 15-second sampling rate.

I haven’t yet tested using both a UM980 base and rover but anticipate more stable and faster fixed solutions, as biases cancel out more easily and apply the same age of differential from the design.

The most astonishing aspect of Unicore modules is their price. I recently paid 85 USD for a UM980: The affordability of these modules, capable of geodetic applications usually valued at thousands of dollars, is remarkable, though it explains the lesser support compared to u-blox.

Looking forward to continued discussions and evaluations of these receivers.


Hire is 3d printable enclosure for new AiO v4.5 STD with support of um982 dev board. Choose faceplate single or dual antennas, with hole for pg7 cable gland if additional cables are needed, like for external IMU. Back plate no holes.


It seems the UM982 boards come in at least two flavors, 20 pin and 28 pin. The 20 pin variety don’t break out the RTK_STAT and ERR_STAT outputs. Why might this matter to some, well the new AIO v4.5 Standard board has greatly improved UM982 support. The RTK_STAT and ERR_STAT outputs go to on-board LED’s and 4 pin header that has GND, PVT_, RTK_STAT and ERR_STAT. This allows remotely mounting LED’s in the case while making it easy to insert or remove the board.

If you have a 20 pi version and want the on-board and remote LED’s, adding the missing pins and some simple rework will turn the 20 pin board into a 28 pin board. I used some 30 ga. Kynar insulated wire-wrap wire for the rework.

It does still have it’s own LEDs on board?

Yes, the on-board leds are there and work. There is just no trace to the pad for the pin.

Logs tab → edit (pencil icon)

A new version uprecise version2.0802
Uprecise software download link