For single antenna rover or base is the um960 as good as the um982?
Both Triple band?
Usable with radio?
UM960, UM980 and UM982 are based on the NebulasIV SOC. They all go rtk positioning accuracy at:
Horizontal: 0.8cm+1ppm
Vertical: 1.5cm+1ppm
And all are triband.
Diffrence is in position update rate:
Um960 20hz
Um980 50hz*
Um982 20hz (but dual)
So they all could be used as base station. As NebulasIV manual is used for all of them, configuring should not differ from um982.
Um982 with esp32 as wifi ntrip master. Without antenna
1 Like
Has roll been figured out on dual antenna UM982? Or do you still need a BNO?
Yes. This was a clever trick used in AOG in the past. By placing the antennas perpendicular to the axis of travel, the pitch value in the UM982 becomes the roll. Only need to put the 90 degree heading correction in either the UM982 or the AOG firmware.
I was able to calculate roll using the the height difference and some trig. This required more data from the UM982 and more calculations in the Teensy. As it sits now I have been playing with the AOG firmware and have 2 methods to use the UM982.
-
Use GGA & HPR messages. The Teensy decodes the messages using the standard NMEAParser. The data is used to create a PAOGI sentence.
-
Use a KSXT sentence. I put an “UM982” passthrough routine in the AOG firmware that sends the KSXT data via UDP. AgIO can decode KSXT messages directly and build a PAOGI sentence. The data can also go over the USB cable to the PC with AgIO. This is already in AgIO to support Bynav. The only issue I see with this approach is KSXT does not contain solution age so it always shows 0.0 in AOG.
In case anyone else is curious exactly which signals and frequencies each of the chips utilize here is the breakdown:
UM960:
GPS: L1C/A, L2P(W), L2C, L5
BDS: B1I, B2I, B3I
GLONASS: L1C/A, L2C/A
Galileo: E1, E5b, E5a
QZSS: L1, L2, L5
UM980* (with CONFIG SIGNALGROUP 2):
BDS: B1I, B2I, B3I, B1C, B2a, B2b
GPS: L1C/A, L1C, L2C, L2P, L5
GLO: G1, G2, G3
GAL: E1, E5a, E5b, E6
QZSS: L1C/A, L1C, L2C, L5
NavIC: L5
UM982* (Main antenna default):
BDS: B1I, B2I, B3I
GPS: L1C/A, L2C/L2P, L5 GLO: G1, G2
GAL: E1, E5a, E5b
QZSS: L1C/A, L2C, L5
* Section 4.23 SIGNALGROUP of Unicore Reference Commands Manual for Nebula IV has tables with a breakdown of signal groups and defaults per model.
1 Like
Dang it. Where were they 2 months ago when I spent some late nights modifying the NMEAParser to parse UM982messages. 
Did they just release their um980 “red” board? Looks more quite a expensive than a 982 from AliExpress
IDT Sparkfun is known for aggressive pricing. Their F9P board is $275. 
Has anyone found a taller 2x14P 2mm header for the um982eb module? Standard height for 2mm seems to be 4.3mm. So far I’ve only found this 6.35mm at lcsc but there’s no stock at jlcpcb.
Something like this. These are low stock (17 available) at Mouser. Lead time is 3 weeks if out of stock.
Thanks. Looks like those are about double height 8.6mm, similar to a 2.54mm’s standard height. I’m trying to keep the immediate area by the RF connectors clear, and at least one or two paths for the coax to route out from under the module. I thought if the headers could be extended that would help.
Or maybe solder male pin headers on the PCB, then solder two 2x14P female sockets back to back to couple it with the module’s pin headers. Should end up a little taller then the Samtec elevated sockets
Samtec makes a connector with a longer lead. The max height for that style lead is 0.800 inches. However, those were not in stock at Mouser or any of the other large suppliers. The lead time for Mouser is 3 weeks.
I was preparing to gather data to compare the UM982 and the F9P. I noticed something interesting between the UM982 and F9P GGA sentences.
The UM982 sentence is on top. Each setup is using its’ own pair of antennas. The antennas are about 25 CM apart longitudinally.
$GNGGA,203534.00,3035.44590340,N,08210.84460370,W,4,38,0.4,60.9400,M,-29.6651,M,1.0,067
$GNGGA,203534.00,3035.44589,N,08210.84443,W,4,12,0.51,61.0,M,-29.7,M,1.0,00006A
It looks like the F9P is either rounding or truncating the decimal portion to 5 places while the UM982 is carrying out to 8 decimal places. The spec sheets for both indicate this is the output decimal places the manufacturer intended.
RTKLIB, U-center and AgIO translate the raw GNSS readings to “cooked” degrees and fractions of a degree. In the case of AgIO, it multiples the last two whole numbers and the decimal (35.44589) portion by 0.01666666666667 to get the decimal degree portion.
I am thinking I may need to either truncate or round the UM982 data to 5 decimal places to make a good comparison. Curious what others might think on this?
You can set the F9P to “High Precision Mode” in Ucenter to get more decimal places.
1 Like
Enable High Precision mode
This will extend the decimals of Lat/Long and setting the Numbering used for SVs will get around a NMEA limit for satellites in view. And High precision NMEA increases the number of decimal places from 5 to 7.
$GNGLL,4005.42027,N,10511.08674,W,180753.00,A,D*63
$GNGLL,4005.4202248,N,10511.0867652,W,180817.00,A,D*60
I saw on the UBLOX forum UBX-NAV-HPPOSLLH reports position, in decimal degrees to 9 decimal places.
Thanks for the feedback. I saw the F9P is capable of outputting more decimal digits. I this thread I am looking to see if the UM982 can be used for AOG in place of the F9P.
AOG currently uses GGA and VTG sentences. The F9P output above was from the F9P configuration files in the AOG repo. It seems five decimal places is more than enough for AOG. This is why I am thinking about rounding the UM982 output down to 5 decimal places to make a more apples to apples comparison.
I have been running AOG with the UM982 and F9P. I have not seen any difference between the 5 an 8 digit output between the two devices. This a purely a subjective observation. I was looking to move to a more objective conclusion by comparing the raw output of both devices in a configuration that is useful for AOG.
I would think the official configs should have high precision enabled. Otherwise, I’m very interested in your findings and thanks for sharing your discoveries.
Precision is a tricky thing, and can fool you.
The precision froma 5-digit minute number is at worst case 2mm (longitude at the equator). Converting minutes to degrees kind of hides the fact that our maximum precision is about 2mm, even though the 7-digit degree number seems to have a precision of 1mm. Either way, the maximum precision of the RTK calculations is about 10 mm, so anything that appears more precise than that is really just noise.
So no need for AOG to officially turn on high precision for the F9P. And in fact the UM982 probably shouldn’t really be using that kind of artificial precision either.
As for rounding, yes that will probably give you the best comparison. Probably best to simply round the final decimal degree number in your spreadsheet with a data format.