## Question

Hello!
I am a postgraduate student in Moscow Aviation Institute. I want to understand some questions.
There are 3 types of angles that are used in GPSTk: elevation angle (range from 0 to 90 degrees), zenith angle (range from 90 to 0 degrees) and nadir angle (range from 0 to 14 degrees).
My question is about using the function antenna.getAntennaPCVariation( Antenna::G01, elev) without azimuth information. This function includes such code fragment:

// The angle should be measured respect to zenith

double angle( 90.0 - elevation );

// Check that angle is within limits

if( ( angle < zen1 ) ||

( angle > zen2 ) )

{

InvalidRequest e("Elevation is out of allowed range.");

GPSTK_THROW(e);

}

1. If i use this function from class

CorrectObservables.cpp - it means that i deal with receiver antenna. In this case zen1=0 degrees and zen2=80 degrees (information from antex file). In this case the function will eliminate satellites with small elevation angle (that is smaller then 10 degrees) or with big zenith angle (that is bigger then 80 degrees). I agree, it's right.

2. If i use this function from class

ComputeSatPCenter.cpp - it means that i deal with satellite antenna. In this case zen1=0 degrees and zen2=14 degrees (information from antex file, it is nadir angle for satellite). In this case the function have to compare nadir angle with zen1=0 degrees and zen2=14 degrees. But in fact the function compare the value of angle=(90.0-elevation) with zen1=0 degrees and zen2=14 degrees. There is no calculation of nadir angle in this function. But values of zen1=0 degrees and zen2=14 degrees correspond to nadir angle.

I find this issue during the PPP mode (based on example9.cpp). With example stations from example9.cpp (onsa, coco, madr) all correct. But now i work with other station for 2010 year and i see error messages "Elevation is out of allowed range."

What is wrong in my arguments?
I will glad any explanations.

--

AndreyPodkorytov - 13 Jan 2011

## Answer

**If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list below the edit box.**
Hello again.
I will attempt to explain the question above. When I use the function from class

ComputeSatPCenter.cpp - it means that i deal with satellite antenna. Really, the variable "elevation" in function antenna.getAntennaPCVariation(Antenna::G01, elev) is not elevation angle. It is exactly nadir angle which is calculated in class

ComputeSatPCenter.cpp in the following source code:

// We will need the elevation, in degrees. It is found using

// dot product and the corresponding unitary angles

double elev( 90.0 - (std::acos( rrho.dot(rk) ) * RAD_TO_DEG) );

There is error in description ("we will need the elevation...") and in variable name ("elev"). It's andir angle. So, source code works correctly but it has comments and variable names that can confuse programmer.

Also i want to suggest a little correction (addition) for function antenna.getAntennaPCVariation( Antenna::G01, elev). It is about the reason of appearance the error message "Elevation is out of allowed range." during the processing rinex files with GLONASS measurements. It is known that orbit height of the GPS satellites is about 20150 km, and orbit height of the GLONASS satellites is about 19100 km. The maximum value 14 degreed for nadir angle - it is correct only for GPS system. But in GLONASS, due to the lower orbit height, maximum value of nadir angle can exceed 14 degrees. I worked with GLONASS measurement (2010 year) and i saw values 14.26 degree. I suggest to add before the check nadir angle in function antenna.getAntennaPCVariation( Antenna::G01, elev) the following code fragment (for example):

if( (angle > 14)&&(angle < 14.35) )
{
angle=13.7;
}

Then we can use information from standard antex file. Probably, maximum value of nadir angle for GLONASS can exceed value 14.35 degrees. It is necessary to research this question.

Is my offer correct?
I will glad any explanations.

--

AndreyPodkorytov - 01 Feb 2011

Dear Andrey,

Thank you very much for your observations regarding variable naming and documentation in antenna.getAntennaPCVariation. We will look into these issues and get back to you. Also, thank you for your suggestion for modifying the same function to accommodate GLONASS processing -- we'll get back to you as soon as possible, pending research of the issues by one of our staff members familiar with this part of the GPSTk.

Thanks again for your interest in using the GPSTk.

--

SusanCummins - 03 Feb 2011

Hi Andrey,

I've been carefully pondering your questions for a while, and I'll try to answer them the best I can.

1) You are right about elevation, zenith and nadir angles. However, the 'Antenna' class offers an unified interface to the user to avoid mistakes. It was decided that this interface ALWAYS asks for ELEVATION (a simple enough approach, easy to understand).

Therefore, all the other classes that query the 'Antenna' class must manipulate the angles to convert them to elevation, independently of they working with receivers or satellites.

2) Please note that, internally, the 'Antenna' class converts the provided elevation angle to the zenith/nadir angle. (i.e., taking the antenna axis (Z) as 0 degrees).

3) Also, take into account that 'Antenna' class DOES NOT filter out satellites according to their elevation. Sometimes this filtering out is done by the classes calling 'Antenna'. Class 'Antenna' limits itself to throw an 'InvalidRequest' when there are no data to compute the requested geometry.

4) Regarding comments and variable names, I'll expand the comments to provide more information. However, keep in mind that it is elevation what is required by 'Antenna' interface, and therefore the comments and variable names reflect that.

5) I understand the problem you posed about GLONASS satellites and I find it very interesting, but I don't agree with your solution. Please note that 'Antenna' class does not set any limits on the satellites, but those limits are imposed by the data provided in the ANTEX file.

'Antenna' follows the ANTEX standard, and if there are no data beyond 14 degrees, then that satellite must not be used. No extrapolations are foreseen in the ANTEX standard, and therefore 'Antenna' will not extrapolate. There are no hard limits coded into 'Antenna', and there should be not such coded limits unless the standard sets them.

6) Returning to your specific problem, I suggest you three possibilities:

a) Get an ANTEX file that provides complete GLONASS data, i.e., covers all the possible geometries of that GNSS constellation. I know this may be difficult for you (if not, please let me know).

b) Modify the ANTEX file so that it covers the possible geometries for GLONASS. According to what you said, this may be done changing the "ZEN1 / ZEN2 / DZEN" lines so they reach up to 15 degrees and adding one additional entry to each GLONASS 'NOAZI' line. The value of that additional entry will be what your application needs: either repeating the 14 degrees value, doing and extrapolation or setting any other criteria you see as appropriate.

c) If the former solutions don't suit you, I suggest you to catch the 'InvalidRequest' exceptions and handle them in a way appropriate for your application.

I will finish thanking you for your questions and suggestions. In the near future we will carry out the work of modifying the GPSTk to process Multi-GNSS data, and details as the ones you brought up are very valuable.

Cheers,

Dago

--

DagobertoSalazar - 01 Mar 2011

No such template def TMPL:DEF{PROMPT:supportquery}