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.
I done static tests on 3band base, for 1h and then 4.5h to have more data samples.
1h test:
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.
Hello,
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 (gnss.store) 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: https://www.aliexpress.us/item/1005006480973490.html 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.
https://www.printables.com/model/775428-enclosure-for-agopengps-pcbv4xstd-v4
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.
Has anyone connected Um982 to Stefal RTK base? what settings did you use? Reciever type and format
how you get centimeter accuracy with 7 decimals with um9xx series ? with this 7 decimals, its like you are in a circle of 6/7 cm. not so accurate than f9p. without this 8st decimal, UM series cant replace f9p efficiently
You got ksxt message with 8 decimals, eventsln with 11 decimals. 7 dec deg is 1.11cm and its aog precision limitation not on receiver side.
What position message from the UM982 only has 7 digits after the decimal point? GGA has 8 digits after the decimal point. KSXT has 8. AGRIC has 11. BESTNAV has 11. The UM982 is perfectly capable of replacing the F9P at about half the cost for a dual setup.
GGa in aog got 7 digits from my um982, same from um960… ksxt not supported by agio no ? why want use it ?
Gga from f9p has more? 7 dec deg is AOG precision, it doesnt support more. No matter how many receiver message outputs.
Ksxt is supported by AgIO.
The AgIO main screen only shows 7 digits after the decimal point for any receiver. The display field is limiting what is shown. Click the “$PNGGA” icon next to the LAT/LON display and the system data form will open. This box will show the raw data coming into AgIO. This will show the full message from the UM982 and the 8 digits after the decimal point.
thanks will try and see
You can also hook a serial terminal to one of the com ports. Send the GPGGA command to the UM982 and it will show you the message with 8 digits.
um982 BESTNAVA can adapt to PANDA
BESTNAVA has 11-digit decimal
Hello everyone,
I thought it might be helpful to share my recent experiences testing the UM980 (a sibling of the UM982, which uses a single antenna) in the context of whether it’s a “F9P killer” for AgOpenGPS. In my tests, I’ve found that the overall RTK-fix rate on rovers is higher with the UM980 compared to the ZED-F9P. I’ve discussed this in this issue on Stefal’s rtkbase repo.
To give a better idea of my setup, here is my base configuration command file:
MASK 0
UNLOG com1
UNLOG com2
MODE BASE TIME 10
CONFIG COM2 115200 8 n 1
CONFIG SIGNALGROUP 2
RTCM1019 COM1 1
RTCM1020 COM1 1
RTCM1042 COM1 1
RTCM1046 COM1 1
RTCM1077 COM1 1
RTCM1087 COM1 1
RTCM1097 COM1 1
RTCM1127 COM1 1
GPRMC COM1 1
RANGEB COM2 1
GPSEPHB COM2 60
BD3EPHB COM2 60
BDSEPHB COM2 60
GLOEPHB COM2 60
GALEPHB COM2 60
SAVECONFIG
I send this configuration via str2str
through the COM1 (UART of the Raspberry).
For the rover, I typically configure the receiver using COM3, which for the WIT MOTION board I use as a rover, is accessed through a USB-C port. My rover configuration file looks like this:
MASK 0
UNLOG COM1
UNLOG COM2
UNLOG COM3
MODE ROVER AUTOMOTIVE
CONFIG SIGNALGROUP 2
CONFIG COM1 115200
GPGGA COM3 1
GPGSA COM3 1
GNGSV COM3 1
GPGST COM3 1
GPRMC COM3 1
RANGEB COM3 0.2
GPSEPHB COM3 60
BD3EPHB COM3 60
BDSEPHB COM3 60
GLOEPHB COM3 60
GALEPHB COM3 60
CONFIG COM3 460800
SAVECONFIG
In the various posts within the GitHub issue, I’ve also showcased the capabilities of the UM980, both as a base (for which I use the unicore branch of my rtkbase fork, as mentioned in my previous message within this thread) and as a rover (using the headless_unicore branch of my BashRTKStation repo). Another user in the GitHub issue, Jef239, suggests that the superior performance of the UM980 over the ZED-F9P could be due to the Unicore’s lower quartz oscillator noise and reduced code and phase noise.
For what it’s worth, I’ve also included photos of both the base and rover setups in the typical enclosures I use for my receivers.
Base receiver:
Rover receiver:
In conclusion, I maintain my view that the UM98* series presents a highly promising alternative to the ZED-F9P. The findings, in my opinion, are not only relevant but also potentially impactful for a wide range of users.