Do you have insights about the antenna model (PCO/PCV) handling ? The RTCMV3 messages listed in the Interface document includes 1033 or 1006/1007 messages as input, do you know if the receiver includes some kind of antenna database to apply PCO and PCV ?
As a feedback to U-Blox, it would be nice to also allow setting the antenna model for the base station and select one of 1006/1007 or 1033 message as output… (especially when the only antenna related message available is 1005 and allows outputting ARP coordinates only without an associated antenna type)
We are not aware of the possibility of entering PCO/PCV values in the u-blox firmware as of today. We will ask u-blox and update.
For the rest of the audience, it might be useful to know that in a simplertk2b base/rover setup this should not be critical as both base and rover have the same values (same antennas) and would get eliminated in the calculation of relative position.
Thanks for forwarding the question to u-blox.
I’ll be able to do some testing at end of week in order to check if the broadcasted antenna models (in VRS/ntrip modes with correction coming from a third party receiver) is taken into account or not by the rover.
I’ll post my findings here.
some new information from testings… I run one of the french network CORS station (http://rgp.ign.fr/STATIONS/#MAGC) driven by a Trimble BD970 receiver, with a roof mounted Zephyr 2 Geodetic antenna.
The antenna is equipped with a GNSS signal splitter, so I’ve been able to do some 0 baseline testing RTK solution with F9P being the rover, and BD970 being the base, in “NTRIP” mode.
The station (MAGC) published geodetic marker ellipsoid height is 861.775 m (cf link above)
The antenna is mounted above the geodetic marker with a small extender (antenna height above ARP) of 13.87 cm
The antenna PCO ) is about 6.7 cm
Result of the test :
And the result of ublox RTK computations is around 861.97 m which at first glance looks very close to the position of the L1PC (L1 phase center) : 861.775 + 0.1387 + 0.0667 = 861.98
instead of computing the position of the geodetic marker (as a regular surveying grade receiver should), by removing :
– the antenna height (13.9 cm, information sent in the RTCM 1006 message that integration manual of F9P report as handled
– the ARP to L1PC (PCO from a database that the receiver should hold internally if it wants to handle 1007 message correctly)
In summary :
the input 1006 message is NOT handled correctly by F9P as the receiver forget to remove the antenna height. In many stations, this is 0 but not all, and the 0 value is not mandatory
the input 1007 message is NOT handled correctly by F9P which is not taking published database PCO into account.
I hope you’ll be able to push those findings to u-blox. Meanwhile,all “geodetic / surveying” use of F9P must behandled with care regarding those points.
Small edit to previous message, my BD970 station is sending message 1008 instead of message 1007 (1008 include extra antenna serial number). ublox do not handle 1008, so maybe 1007 is handled correctly…
Not handling 1008 is still a bad point for third party interroperability
Some further details after additionnal testings :
– the Trimble station broacast 1008 (not handled by F9P) instead of 1007 and also 1033 which contains the antenna model. Still, having a more complete set of handled message by F9P would be good (e.g. 1008)
– the Trimble BD970 RTCM stream can be configured in 2 fashions : “raw” measurements and native antenna model broadcasted, and “raw” measurement corrected from PCO/PCV + antenna model broacasted as “ADVNULLANTENNA”
In anycase, the antenna height from 1006 (in my case the 0.1387 m) is not handled by the F9P.
The ADVNULLANTENNA is not handled (this was the configuration of my initial testing), BUT the other mode broadcasting the actual antenna name is handling the PCO correctly !
So this is narrowing down the unperfect F9P behaviour to :
– handling NULLADVANTENNA
– handling the antenna height in the 1006 message when it is non 0
so we got some information from u-blox, and it seems it’s currently not supported but it’s being considered. I quote:
“We are planning to have a messages that allows the antenna phase center offset to be entered. This would be for the ZED-F9P Rover or base antenna. This will be in a future firmware release.
We don’t have any antennas models lookup table on our modules.
Official ref. receiver NTRIP sources will have done their offset compensation already. It is only if you have your own base receiver as RTCM3 source that you will need to compensate for PCO to zero calibrate the base position.
Typically ITRF ref frame offsets are usually more of an issue as they cause 50 cm or more offsets if compared to a separate ref receiver used in the same location as the Rover. Again this need to be compensated for. This is covered in the ZED-F9P Integration Manual appendix section.”
Thank for forwarding u-blox info. So they confirm not using antenna at all, in base and rover.
Meanwhile, I also got better understanding of what is happenning in my setup :
in “ADVNULLANTENNA” mode, my Trimble station 1006 message decodes to :
TM Rtcm3.1 2109.9 Sat Jan 05 08:34:52.134 2019
MT1006 Stat 0 Status 1 Sec 2110 Seq 1000 Frame 216
MT1006 ITRFRealYear 0 GpsInd 1 GloInd 1 GalInd 0 RefStatInd 0 SingRecOscInd 0 ARP_X 4449946.1365 ARP_Y 224257.7729 ARP_Z 4549706.4301 AntH 0.2241
so the broadcasted coordinates are the actual L1PC position, and the antenna height is adjusted by the receiver to include le ARP-L1PC offset
in “TRM57971.00 NONE” the 1006 message decodes to :
TM Rtcm3.1 -1.0 Fri Jan 04 19:50:40.221 2019
MT1006 Stat 0 Status 1 Sec -1 Seq 1000 Frame 216
MT1006 ITRFRealYear 0 GpsInd 1 GloInd 1 GalInd 0 RefStatInd 0 SingRecOscInd 0 ARP_X 4449946.0770 ARP_Y 224257.7699 ARP_Z 4549706.3689 AntH 0.1387
and this time, the coordinates decode to the actual antenna ARP and antenna height.
In the end, it then seems that the main issue is really the rover NOT handling the antenna height in the 1006 message.
As for u-blox remark about comparing datum shifts and antenna height issue, those are totally different problems, and I guess both should be adressed when it comes to cm level receiver. As for the order of magnitude, The antenna height can be large :
e.g. in this station : http://rgp.ign.fr/STATIONS/#MAYG the antenna height above the published marker is >3 m so a 3 m error would arise doing RTK from it !
Talking about datum shifts, I regret hey did not implemented a time dependent datum shift method that would allow using official ITRF tranformations (which are published with linear time dependencies)