elevation mask pattern support #552
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a useful function for parsing the formatted files, so move this from rinex.c into rktcmd.c and export it.
Improve the ANTEX support. * Support PCV with azimuth. Was just NOAZI. Use linear interpolation between azimuth points, as well as the zenith. Satellite PCV still only supports NOAZI as that is most common, but all the support is there to extend this to vary with azimuth * Support ZEN1, ZEN2, DZEN, and DAZI. The PHV size is also now variable so the smallest size array is allocated. There was a fixed azimuth length of 19. It now correctly handles variations of these parameters. Require some more memory management, to free these. * Support the full range of frequencies, across systems. Was just GPS and NFREQ. The usage of the antmodel() etc functions needed to change. There were returning a NFREQ array with the offsets, but that did not work with multiple systems with different frequencies mapped to the frequency same indices - these functions are now single frequency functions. * Support PCO and PCV interpolation between frequency entries, with heuristics to avoid extrapolation of noisy data, and avoid interpolation across frequency bands (which may well be implemented with separate antenna elements e.g. stacked elements). * Add support for ANTEX 2 which avoids much redundancy. This required the PRN to SVN mapping in the SINEX satellite meta data. * Add minimal SINEX satellite meta data support, just for the PRN to SVN mappings. Adding the file-satmetafile option. * Support for the console apps. * Support for the qt apps, adding the satellite meta data file to the GUI. * Some windows app support, untested, and not yet the satellite meta data file for ANTEX 2 which needs adding to the GUI. * Adding a new function antpcv(). Implement antmodel() using the existing antpco() and the this new function to avoid code duplication, with some repetition of code execution. This is intended to allow the caller to apply the receiver PCO first and then separately the PCV, for greater accuracy, just as these are currently separated for satellites.
Implement the automated antenna type selection along with the antenna
delta from the input stream, from an RTCM or raw stream, the config
options ant{1,2}-anttype="*".
Have the config options ant{1,2}-postype RTCM and raw automatically
set the position, and independently of the antenna type, and now
including for the rover when in fixed mode.
Previously only an antenna delta would be picked up as an offset to a
base position, including a RTCM height, and only when the position was
also being automatically set and only for the base and not the rover.
Also there was no separate 'raw' antenna automated position mode, this
is included under the 'rtcm' option.
Pass in the receiver index, as a 'base' argument, which is 0 for the rover and 1 for the base, to allow the respective options to be selected rather than just using the rover options even for the base. Start making use of this: in rescode() this is now used to select the respective SNR and SNR mask. For postpos.c where a one based receiver number and zero base index were both be used, fix an instance in antpos() of indexing into option anttype[] with an one base index which would be OOB for a value of 2. Try to clean up this code in this regard.
This allows setpcv() to automatically set the antenna delta, rather than having to hack that delta into the position in antpos(), and that hack can now be removed.
Have tropmodel use the precise mapping function, rather than 1/cos(z). Update the exponent in the pressure vs temperature function, from 5.2568 to 5.255877 which is found in references on the matter. Update the rtkpos RTK code to also account for the wet component when not estimating it, and to also allow use of the SBAS model when that is selected.
Apply the antenna delta from the marker to ARP, and the per-frequency PCO, before some of the other calculations such as the geometric distance and line of sight vectors. The antenna PCV is later applied. The line of sight vectors and now from the antenna phase center, rather than from the marker position. This makes the calculations much more robust to large antenna offsets. It was a trivial matter to also use per-frequency line-of-sight vectors, so do that. The azimuth and elevation are now also from the phase center rather than the marker position, but still only per satellite.
There was some support in the rtkplot code for elevation mask patterns. Extended this support to the rtk and post processing code. Move the code for the loading and saving of these patterns into the main library and extend this to include a station name key so that a single file can include the elevation mask patterns for the rover and base, and add the file-elmaskfile option for this file. For post processing, the station name can come from the RINEX files, from the marker name. For rtkrcv, add new options sta1-name and sta2-name to supply the rover and base station names respectively. These station names are also need for the loading of DCB file, and would also be useful for loading ocean tide loading parameters. There was a '-sta' option to rtkrcv for reading the DCB file, but with support for just the one station name this was not adequate for reading the DCB for multiple receivers. The station name can nos be specified in the config file using sta1-name and sta2-name so just remove this option.
Predicted erp data can be used for RTK, so support this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A proposed extension of the rtkplot elevation mask pattern support to the solution code paths.
Should work with post processed solutions, getting the station names from the RINEX files, from the marker names, and looking up the elevation mask patterns in the new file-elmaskfile, For rtk both base and rover masks can be used. The file format is nothing special, just a minimal extension of the extension of the current rtkplot mask pattern file format, adding the station name key.
Also works for rtkrcv which has been extended adding config options sta1-name and sta2-name to supply the rover and base station names for the lookup of the respective elevation mask patterns.
rtknavi still lacks this extra support for the station names, and for loading the patterns. Perhaps these could just be added to the 'misc' options tab?
Also rolled in a patch to rtkrcv to load the erp and blq data, as tide displacement can work for rtk too, there are erp estimates available, and this uses the new station name options so would need to be based on this patch anyway. Tide displacement seems to add little for RTK, but still a couple of mm is still something, but it seems useful for PPP solutions.
This PR is based this on other queued PRs as there are a few conflicts but it could be split out.
Not sure how much use this is. There still seems to be some interest, see https://s-taka.org/en/quantifying-skyview-with-spherical-cameras/ and MALIB has some patches in this direction. For a poor base site it might help, and this might be typical for low end base installations. Even if the patterns are flat, so just a plain elevation mask, it might still be useful to have them in a file keyed by their station name so that this is applied automatically in post processing. Could it be useful to mask out a tree or post etc.