Howdy,
You probably have already figured out that GNSS Solutions is not being maintained anymore. But I know there are a lot of folks using it for processing single and dual frequency Static and Stop&Go occupations.
I wanted to warn everyone that there is a 'known' bug when importing standard RINEX files into 'GNSS Solutions':
If a RINEX file contains an HI, or if you enter an HI for an imported RINEX occupation; and the HI is non-zero; then you need to push the 'Apply to All' button before you 'Process Baselines'.
Here is a picture showing the dialog and the button:
You get to the 'Occupations' tab by selecting the 'Files' tab on the workbook:
Then double-clicking in the left-hand-column of the file:
If you don't do this, then the instrument height that is embedded in the RINEX file (or that you hand enter) may not be recognized and the job is effectively processed with a 0.0 HI. Which will make all derived heights too high.
The latest revision of GNSS Solutions 3.80 is now three years old and it may be time to update. But the update path is not yet totally clear to me. I am working with a product manager on what I think will be a spectacular alternative. I will post a note if I find anything.
Mark
Thanks Mark,
I've seen that bug many times, but never figured out the pattern or solution. It had me basically avoiding using GNSS Solutions.
Very helpful.
If you import B files (older receivers) or G files (newer receivers) it seems to work just fine.
When you import CORS data (RINEX files) the HI is either 0.0 (no issue) or for PBO sites there may be 0.0083 m ARP to BPA offset (not a big issue).
But if you import true RINEX, I don't think it ever automatically applies the HI from the RINEX file:
1.4565 0.0000 0.0000 ANTENNA: DELTA H/E/N
and if you hand enter a height in the import dialog, I think same deal.
So it is best (when not using B or G files) to just always go in and hit the apply button.
I agree that in a perfect world, we would all just switch to an alternative. But GNSS Solutions has an EXCELLENT baseline processor and the workflow with B & G files is excellent. And there is the excellent price (free for L1 only) and an aversion to change.
Again, more on an alternative at a later date.
Mark
Mark Silver, post: 324981, member: 1087 wrote: Howdy,
You probably have already figured out that GNSS Solutions is not being maintained anymore. But I know there are a lot of folks using it for processing single and dual frequency Static and Stop&Go occupations.
I wanted to warn everyone that there is a 'known' bug when importing standard RINEX files into 'GNSS Solutions':
If a RINEX file contains an HI, or if you enter an HI for an imported RINEX occupation; and the HI is non-zero; then you need to push the 'Apply to All' button before you 'Process Baselines'.
Here is a picture showing the dialog and the button:
You get to the 'Occupations' tab by selecting the 'Files' tab on the workbook:
Then double-clicking in the left-hand-column of the file:
If you don't do this, then the instrument height that is embedded in the RINEX file (or that you hand enter) may not be recognized and the job is effectively processed with a 0.0 HI. Which will make all derived heights too high.
The latest revision of GNSS Solutions 3.80 is now three years old and it may be time to update. But the update path is not yet totally clear to me. I am working with a product manager on what I think will be a spectacular alternative. I will post a note if I find anything.
Mark
Hum....... This seems mighty familiar.......:excruciating:
Mark Silver, post: 324981, member: 1087 wrote: Howdy,
You probably have already figured out that GNSS Solutions is not being maintained anymore. But I know there are a lot of folks using it for processing single and dual frequency Static and Stop&Go occupations.
I wanted to warn everyone that there is a 'known' bug when importing standard RINEX files into 'GNSS Solutions':
If a RINEX file contains an HI, or if you enter an HI for an imported RINEX occupation; and the HI is non-zero; then you need to push the 'Apply to All' button before you 'Process Baselines'.
**
If you don't do this, then the instrument height that is embedded in the RINEX file (or that you hand enter) may not be recognized and the job is effectively processed with a 0.0 HI. Which will make all derived heights too high.
Mark
The help file for the Apply to All shows
Antenna pane:
Antenna height: Antenna height for the selected occupation.
Height Type: Type of measurement used to measure the antenna height (slant, vertical, true) for the selected occupation.
Apply to All button: Click this button to apply the two antenna parameters to all the occupations in the observation file. Caution! This cannot be undone.
I import rinex files for X90-OPUS receivers and use Promark3s for rovers. It seems to me that if the X90 receives HI is not the same as each other, and also not the same as the rover HIs, this would cause major problems with their data. Surely there has to be a way to ensure the correct HI is being used besides making them all the same.
Tyler Parsons, post: 325687, member: 139 wrote: The help file for the Apply to All shows
Antenna pane:
Antenna height: Antenna height for the selected occupation.
Height Type: Type of measurement used to measure the antenna height (slant, vertical, true) for the selected occupation.
Apply to All button: Click this button to apply the two antenna parameters to all the occupations in the observation file. Caution! This cannot be undone.I import rinex files for X90-OPUS receivers and use Promark3s for rovers. It seems to me that if the X90 receives HI is not the same as each other, and also not the same as the rover HIs, this would cause major problems with their data. Surely there has to be a way to ensure the correct HI is being used besides making them all the same.
Tyler,
I have experienced this issue multiple times, and Mark helped me with this solution. I was only using it to process a four point static network surrounding my project. I never experienced any problems once I implemented this workaround. As a quick blunder check, you could swap the Promark 3 and an OPUS X90 on two points, and use an OPUS solution as a blunder check.
After I ran into this issue a second time, and for the types of projects I was doing, I opted to sell my promark receivers, and upgrade to two OPUS X90 receivers. There is nothing wrong with the receivers, just the program. I wanted the option to use OPUS as a check.
Thanks Jimmy.
I have 2 X90 receivers which I use for control points and 3 Promark3s which I use as rovers, usually with excellent results. I had a situation yesterday in which I brought into GNSS Solutions the OPUS results for the 2 control points, then a bunch of rover shots and processed them, L1 only. I noticed that I had the wrong HI on the rovers (2.000 ift instead of 2.000m) so I changed them before processing. The baseline data looked good, but then the adjustment went all to xxxx. I tried a new project, same data, and it worked fine. Back to the original several times. Everything worked fine if I fully constrained 1 control point, and made the other 2d. The adjustment has now shaped up with 2 3d control points, why I'm not sure. Perhaps the order of import, or whatever, was messed up.
Please can anyone help ..
I cant download GNSS solutions , it has been removed from the page.
Thanks a lot!
