I’ve been casually reading along and I am not an expert.
Is it ok to have these tests with a (dual band) F9P base station? Would the UM982 have better performance if using a triple band base station?
From the data posted it looks like the UM982 roll and heading information is all over the place when compared to the F9P? Am I interpreting the data correctly?
Like I said, casually reading along and I’m not an expert. I greatly appreciate the work that you are doing, and that you are sharing the results.
I see something a little different. The UM982 stays within the same heading degree while the F9P goes a little bit into the next heading degree. The height of bars for the UM982 heading are taller and there a fewer of them. This seems to indicate more readings of the same value.
On the roll front, the UM982 has a total variation of 1.68 degrees while the F9P has 2.51 degrees. Like heading, the roll bars are higher and there are fewer of them which seems to indicate more readings of the same value.
The F9P has proven itself quite sufficient for AOG use even with the Ublox antennas. The UM982 looks like it would work just as well.
Slave antenna of um982 is dual band only, as roll and heading are derived from slave antenna position, it is sufficient for this type of test. But for master antenna or real world use, um982 would benefit from 3 band rtk base. As real roll is influenced by master antenna height accuracy as well.
So for F9P its @chri5k data but with ± that value as master antenna and slave antenna of F9P can have error of ±2.5cm respectively, verticaly. But um982 data should be better as master antenna vertical position accuracy is ±1.5cm.
A quick analysis of the data presented suggests that
The UM982 with Ali antennas has better roll and heading performance than F9P’s with ANN-MB’s
The UM982 has better heading performance than the F9P.
The F9P has better roll performance than the UM982, but you have to use Ali antenas to achieve it.
The Ali antenna surpasses the ANN-MB’s performance.
I question whether the setup has something to do with the data trends. I think that the fairest test would be never to disturb the antennas/ground planes, but to move the receivers around between antenna setups. Is that what you did, or did you move the antennas between ground planes?
Seeing the standard deviation on future excel graphs would be very helpful.
The antennas stayed on the roof in the same position the whole time. Only switched the cables over between boards. I did not test the UM982 with the ANN-MB’s.
I am not sure STDEV tells the whole story on which might be better. Something can stay within the STDEV but change between values rapidly within the STDEV. That is what I interpret when I see a graph with many smaller bars.
Rapid changes to the value of a heading or roll display that can show up as a twitchiness. If a downstream algorithm is using the data, that can make its’ output twitchy as well.
I am not planing any future tests since I have broken down the test bed. I am moving on to practical usage of the UM982. I have two new assembled boards arriving from JLPCB in a few days so I need some of the equipment.
IMHO, my point on STDEV is more academic than practical. I think either setup will work fine for AOG. In any case, I would go with the Aliexpress antennas over the ANN-MBs.
I looked in the manual and the standard configuration for signal groups is main antenna signal group 4 and slave antenna signal group 5. Signal group 5 does contain B3I for the Beidou constellation. If a location has B3I satellites in view it seems like that would improve the performance further.
Thing is um982 see third band with ann mb / bt560 (dual band antennas) as well.
Tested no name patch antenna (with ground plate) and HA901A (both are 3band). Top4 sats for patch average 48~, HA901A 50~. But HA901A see more sats in general then patch.
Has anyone tried Galileo HAS on F9P or UM982? I recently tested it on a GNSS board from a third-party brand, and the accuracy appears promising. However, I’m uncertain about its applicability for use on a tractor. I would appreciate any insights or assistance on this matter. Btw, I was pleasantly surprised to discover that one notable advantage of this service is that it doesn’t require RTK correction data, and it also operates without the need for a radio or internet connection. Here is my testing result on RTKlib.
Please try software - RTKLIb. It is an open-source software which is very friendly to use. In RTKPLOT, you could easily import NMEA-0183 GPGGA data into it. Then you’ll get this graph.
I never could get RTKLIB to use the output from a UM982 reliably. I think the extra digits after the decimal may have been the issue. If anyone gets RTKLIB working with the UM982, pease post your settings.
Regarding HAS & the UM982, the UM982 does receive E6 satellites but I don’t see anything in the manual around processing the HAS (PPP) data.
I met similar issue before. But not UM982’s data. I changed a version to solved this issue. Maybe you could try RTKLIB_2.4.3_b33. I can’t promise if this method can solve your issue. But hope is will be helpful. (The problem I encountered is that when I import NMEA-0183 data to RTKLIB, the data will not be converted into point data and appear on the interface.)
Regarding to UM982’s PPP, I think unicorecomm has special firmware to control it.
Thanks. I did try that one. I have tried older versions and versions folks have modified or updated. Always the same result. Sometimes it will work and an hour later it won’t. Sometimes not at all. I just didn’t feel like delving into the source to fix it.
Ublox U-center reads the data just fine. It had tools that I used to analyze the data. I did try exporting the data from U-center in UBX format but RTKlib still did not like the data. Very strange.
Is there any chance we could have the firmware as well? Mine is still the old version you shared previously. Polite request for firmware sharing. Your help is greatly appreciated.
I’m coming back to the base compatibility issue, or did I miss some comments.
What did you conclude on the fact that the F9P base is a dual frequency device and as such is not capable to provide RTK correction data for the UM982 L5 frequency. Doesn’t this mean that UM982 does not reach its full performance. Or was it intentional to use a dual band base as the UM982 second receiver for heading anyway only supports two frequencies? Wouldn’t it be interesting to see UM982 single antenna performance compared with F9P base versus a tri-band base?
Another slightly related question is about the codes each base uses in their RTK correction data. I actually have not seen MSM messages decoded but messages like RTCM 1004 include information related to e.g. L1C or L1P etc. Now F9P I believe only supports L2C codes while other receivers support L2P too. Why is there any discussion about the rover compatibility with each base in this respect. Why is the code mentioned if the reported pseudorange is code irrelevant (I would assume so)?
For the actual (carrier) phase range the code should not matter but phase range is needed for each frequency, otherwise it is not possible to make use of that frequency for RTK calculations. Also isn’t the code range only (mainly?) needed for first fix (or to recover fix after lost RTK) to reduce load on phase ambiguity resolution, not any more for RTK position updates?
The background for these questions is that I was wondering if modern commercial GNSS receivers from Trimble, Novatel, JD etc. would gain from a similar base instead of an F9P that does not support all the codes those commercial products do (UM982 seems to belong to the “commercial GNSS receivers” group in this respect).
I’ll try to unpack all the questions.
I used the F9P base as that is what I happened to have running at the time. Setting up a UM982 base would require another 3-band antenna which I don’t have nor plan to purchase at the moment. I really don’t know what effect a 3-band base will have on the UM982.
Interesting question on the the slave antenna being dual band. The standard configuration for the UM982 includes all 3 bands of the BDS constellation for the slave antenna.
I would be interested to see what the UM982 does with a 3-band base in either single or dual mode. It is just not something I have time for at the moment. I know @Radmuffins is doing some more work on UM982 heading and roll performance. It seems he has some very exacting precision requirements in his farming operations.
The questions around correction codes and what receivers uses which and why is way beyond my knowledge of GNNS inner workings.
I don’t own any of the other brand of GNSS systems so I really can’t comment or test. The UM982 and a 3-band antenna are not super expensive so perhaps an owner of the these other systems might want to test to see if they can get more precision out of their investment.
IMHO, the performance of the UM982 with a dual band base seems to be more than sufficient for AOG purposes. @NorthernFarmer comments and questions could indicate the UM982 may be capable of even better performance than I have found. The new v4.4 standard board due out soon corrects the UM982/Bynav slot issue. The new board design enhances the use of the UM982 in terms of mounting and cable clearance as well. The designers have also worked to use more standard components to lower the cost of the board. Together with the UM982, this will help make precision agriculture more affordable for farmers.
I acknowledge that UM982_R4.10Build9984 is present in my module from your release. However, it appears that e6-has is not supported with this version. Regrettably, my attempts to contact Unicore Communications have been unsuccessful, as they declined to provide the new firmware. Their refusal is based on the fact that I did not acquire the module through what they consider official channels (Alibaba is not deemed official).
I appreciate your swift response and send my best wishes.
