Stefal
Main service settings - Antenna info - formatted incorrectly in RINEX observation file
Describe the bug The antenna descriptor in the RINEX header must be formatted a very specific way. The way in which the "Antenna info" field captures this information, and it is passed to rtkconv, is incorrect. For example, if my antenna is an HXCGPS500 with no special radome, with the serial number C16110003828, the correct way for this to be formatted in a RINEX observation file is as follows:
[...]
2a499aa399 ZED-F9P HPG1.51 REC # / TYPE / VERS
C16110003828 HXCGPS500 NONE ANT # / TYPE
[...]
The "Antenna info" field of the Main service options group requests the information in the form of model,serial number, yet if I enter HXCGPS500 NONE,C16110003828 the validator fails the input, because of the spaces. It is important to realize that the proper IGS antenna type designation includes two pieces of information in a single field: the model number of the antenna, and the radome type. In the RINEX observation file, the type must start on the 21st column, and the radome must start on the 37th. If these are not formatted correctly, post processing services like OPUS, Trimble RTX, and CSRS PPP will not pick up the antenna information correctly.
If I enter the model,serial number as prompted, without spaces (e.g. HXCGPS500,C16110003828) and then export a log file as RINEX observations, the resulting data is still formatted incorrectly:
[...]
0000 U-blox_ZED-F9P 1.51 REC # / TYPE / VERS
0000 HXCGPS500,C161100038 ANT # / TYPE
[...]
The serial number should be put in place of the 0000 on the ANT line, as well.
(Also, as a sidenote: for u-blox receivers the serial number of the receiver is available though software, it could be captured in the same way that the firmware version number is captured.)
My recommendation for the Antenna info field would be to request that users enter it in the form of serial,model and to look at the antex file for their antenna to see exactly how the model type is formatted. Then that information can be passed to convbin verbatim as convbin [...] -ha "C16110003828/HXCGPS500 NONE".
It would be great if RINEX observation files weren't so strict about their formatting, but the fact of the matter is that the number of spaces between the antenna model and radome type are critical, and hand-modifying those files before sending them off for post-processing is a real drag.
To Reproduce
1: Open the settings tab of the rtkbase web application
2: Open the Main service options group
3: Enter correctly formatted antenna serial number and type into the Antenna info text field (e.g. C16110003828,HXCGPS500 NONE
4: The field validator will fail the input and prevent the user from saving the input
Expected behavior Users should be able to input properly formatted antenna descriptors into the Antenna info field and have that get passed to the RINEX observation file as expected.
Software/Hardware (please complete the following information):
- RTKBase release number 2.6.3
- OS: Debian 12
- SBC n/a
- GNSS Device: Ublox F9P
- Connection type: usb
Additional context For some more context, see this issue for RTKLIB: https://github.com/rtklibexplorer/RTKLIB/issues/568
Appendix A1 of the RINEX2.11 spec: https://files.igs.org/pub/data/format/rinex211.txt
The ANT #/TYPE header is described as having format 2A20, meaning two alphanumeric fields of no more than 20 characters each. This is what the field validator should be based on.
Thank you for reporting this issue. I have to check how it works with the RTKLib 2.5, and if the behaviour is the same for str2str and convbin. I'll probably don't have time to do that for the next release. I hope I could do it for the next one.
@Stefal - no worries, happy to help. I have done some testing and already confirmed that RTKLib 2.5 does encode the antenna information correctly if it is passed correctly (double quotes are recommended to preserve the spaces).
As far as the RTCM3 message from str2str - this doesn't seem to be very strict. I have connected to a few CORS NTRIP streams with an RTCM3 decoder and have found that most of them just pass ADVNULLANTENNA anyway. This page has a lot of useful context: https://www.use-snip.com/kb/knowledge-base/what-is-advnullantenna/
Ultimately, I would recommend that either the model number be stripped from the HXCGPS500 NONE descriptor for use in 1008, or you give users the ability to manually configure it.