Bernese.gif Bernese GNSS Software
AIUB ¦ CODE ¦ IGS

[ Introduction ] [ General ] [ Installation ] [ Messages ] [ BPE ] [ Examples ] [ AIUB's FTP site ] [ Programs ]



Introduction


With version 5.2 we will publish answers to questions from users to the Bernese user support on this web page if we have the feeling that the question is of a wider interest (of course fully anonymous with respect to the person who has sent the question).

We hope that we can establish in this way a collection of frequently asked questions (FAQ) providing brief answers to many common questions with respect to using the Bernese GNSS Software (e.g., error messages during processing, warnings, etc.).

Please, check this FAQ for answers before sending your question by e-mail to the support.



General questions


Questions concerning the installation/update procedure


Questions concerning messages issued by the software


Questions concerning BPE


Questions concerning distributed processing examples


Questions concerning file on the AIUB's ftp site


Questions concerning processing programs




Is there a trial version of the Bernese GNSS Software available?


No. Even if we try to keep the software as user friendly as possible, the Bernese GNSS Software remains a high-end product. We believe that it is not possible to obtain optimal results simply in a "trial and error" mode (apart from the option that you spend a lot of time in studying the complete documentation).
We recommend to all potential customers who are not sure whether the software fits their needs to attend the introductory course. Here you will learn how to use the software and get some theoretical background information. You have the opportunity to use the software for standard applications with the personal support of our experts.
If you decide to buy the software after participating in a course the price for the package will of course be reduced by the course fee.



What should we consider if we setup a new computer to use the Bernese GNSS Software?


A computer with a big disk to host your GNSS data is important. At least for the location of the processing campaigns a quick access to the disk is essential for the performance.
If you do not have access to a cluster of computers you should consider a multi-core machine because the number of cores gives the number of jobs you can run in parallel in the BPE. Of course, if you are in a Unix/Linux cluster environment you can increase the number by including other computing nodes. Here a quick network connection to the location of the data is beneficial.
In general a 64-bit architecture is preferable compared to a 32-bit architecture if a proper compiler is available. For Windows systems we distribute both sets of executables.



Are there any differences between the Windows and Unix/Linux version of the Bernese GNSS Software? What system do you recommend?


The source code, the provided scripts and the examples are identical for Windows and Unix/Linux.
For Windows platforms, a set of executables for the programs as well as the GUI is provided, whereas for Unix/Linux (or Mac) these must be compiled by the user. Note that you will get the full source code regardless of which system you have chosen.
Concerning the BPE (which e.g. allows execution of individual jobs on remote CPUs) the Bernese GNSS Software is currently better prepared to use this feature under linux, than under Windows.
Strictly technically spoken, this is, however, also possible on Windows platforms. Out of the box, the BPE under windows executes all jobs locally.



Windows: If I click on the "Bernese 5.2" icon on my desktop the menu is not launched.


Check first whether all setup wizards have been installed. You should find, apart from the "Bernese 5.2" icon/shorcut, also the "GPSUSER52", "CAMPAIGN52", "DATAPOOL", and "SAVEDISK" ones. If not, this is an indication that you did not run all the setup wizards.
If all icons are available, you should check the "User Variables" for your account to control that the Bernese-specific variables are defined. You have to remember that the setup wizard establishes these variables only for the currently active user. If the wizards have been executed by the "administrator" (instead of the user that shall use the Bernese GNSS Software), the variables are not listed in your "User Variables" area. Please inspect the README_INSTALL.TXT file (either in the BERN52\GPS\DOC directory or on your installation CD-ROM) for instructions on how to proceed: either reinstall the software for your account or establish a multi-user environment.



UNIX: Unrecognized command line option "-fbacktrace".


The compiler message above indicates that the used "-fbacktrace" option is not supported by the GNU compiler from RedHat. This option is only used for debugging purposes, but is not mandatory. Therefore if this message appears just remove this option in the file ${X}/EXE/Makefile.template. Thanks to Peter Franke from BKG Frankfurt for his helpful test feedback to solve this problem.



After compilation, I find two directories with executables (e.g. EXE_G95 and EXE_G95c) with different sizes of the executables. What is the purpose, and which of them should I use?


The The Makefile.template in $(X)/EXE is prepared to run two compilations: a speed-optimized (creating the executables in the directory EXE_${F_VERS} and a debugging version (in the directory EXE_${F_VERS}c ). If the environment variable ${F_DEBUG} is blank or set to YES, both versions are created. If you set ${F_DEBUG} to NO, only the speed optimzed versions are created. The debug executables run slower, but contain more debug output, which might be helpful in case of problems. Pay attention that the variable ${XG} is set to the directory containing the executables you actually want to use.



I get the message "### Executable CRX2RNX is missing" even though the compilation went without problems. What can I do?


The CRX2RNX and the RNX2CRX programs are external programs to Hatanaka decompress/compress RINEX files. Please see the README_INSTALL file to find out where to obtain the source and the executables of these programs. The executables must be placed in a directory which is listet in your PATH environment variable, so they can be called from anywhere without having to specify the path.



UNIX:The menu is not created and I find the message "/usr/bin/ld: .obj/release/menutils.o: undefined reference to symbol uncompress " in the MENUCOMP.log file. How can I solve this?


You can edit the file ${C}/MENU/menu.pro and activate the line 45 by removing the two # at the beginning, so that it reads
QMAKE_LIBS += -lz
Then you can recompile the menu. If the error persists, please contact us for support, providing the MENUCOMP.log file.





Cannot open INP file ${P}/EXAMPLE/STA/SESSIONS.SES


The message indicates that the session table is not available. Potential reasons are:

  1. The campaign directory tree has not been created yet. Use "Menu >Campaign >Create new campaign" to establish the campaign directory tree (which will contain a default session table).
  2. The campaign was not selected. Select the active campaign with your session table using "Menu >Campaign >Select active campaign".
  3. The session table in the actual campaign has a different name than in your previous one. Use dialogue "Menu >Configure >Set session/compute date" to define the name of the session table.


SEARCH_OFF: No offset values found for satellite system "R"


The software assumes that the antenna phase center file contains corrections for all antennas and all GNSS that may be supported by at least one receiver connected to this antenna.

According to the convention of the IGS, in case of missing calibrations of a specific system the GPS values are used instead. Copying the GPS-related calibration value for other GNSS is exclusively done by the ATX2PCV program (menu >Conversion >ANTEX to Bernese format).

At each time when you update the station information file by entering a new combination of receiver and antenna we recommend to run the ATX2PCV program introducing the station information and the receiver information files to update the list of phase center correction file.

This update step is supported by the example BPEs (see BPE server variable V_MYATX).

This procedure has been introduced to protect users for an unintended use of antenna phase center corrections for different GNSS.



GPHECC: ANTENNA(/RECEIVER) TYPE NOT FOUND


The entry for the used antenna type/radome is missing in your "Phase Center Variations file" likely for one of the following reasons:

  1. The antenna type is misspelled in the Bernese observation file. Use the correct spelling in the station information file when you import the measurements from RINEX into the Bernese format.
  2. The expected antenna type/radome combination is missing. The Bernese processing programs expect that for each antenna type/radome combination the corrections are listed in the "Phase Center Variation file". With the program ATX2PCV ("Menu >Conversion >ANTEX to Bernese format") you may either add your own antenna calibration values or follow the convention of the IGS to use the calibration of the antenna type without radome also for those antenna type/radome combinations that are not calibrated (yet).
  3. In general it is recommended to consider radome-specific calibration values when available. Please check whether the radome type is specified in the "Phase Center Variation file" and in the Bernese observation file (the characters 16 to 20 of the antenna type). During the data import you have to choose the option "Consider radome code of the antennas" in panel "RXOBV3 4: Input Options 2" accordingly.
  4. The corrections for a specific GNSS are missing. The processing programs assume to have the antenna phase center corrections for all GNSS involved in the processing or supported by the receiver in the "Phase Center Variations file". Use the program ATX2PCV ("Menu >Conversion >ANTEX to Bernese format") to extend the list of corrections using available calibration values or by copying the calibrations for GPS for the other systems (proposed practise of the IGS).
  5. Another reason may be the unauthorized use of tabulators in the "Phase center variation" or "Station information" files.

The mentioned files are located in the $X/GEN (resp. %X%\GEN for Windows) directory.



SATELLITE NOT FOUND


Very likely the used satellite file is not up-to-date. Download the current satellite information file (SATELLIT.xxx) and the satellite problem file (SAT_xxxx.CRX) from our ftp site.



ROCKMD: SATELLITE NOT FOUND IN SATELLITE INFO FILE


The reasons for this message can be that the satellite information file (SATELLIT.xxx) in $X/GEN is not up-to-date. Download the latest file from our ftp site.



NEQCKDIM: DIMENSION TOO SMALL


The expected dimension of the input or resulting combined normal equation as specified in the input option "Maximum number of parameters in combined NEQ" in panel "ADDNEQ2 3.1: Options 1" is too small. The number must be adjusted to the size of the normal equations.



GETPOL: NO SUITABLE EPOCHS IN POLE FILE


The reason of this error message is probably that a wrong pole file was selected or that the selected pole file does not fully cover the interval of the standard orbit in the processing. Note that the epochs in the pole files are interpolated while the requested epochs may also be outside the interval of the processed data. If a proper pole file is selected it should work as usual.
It can also happen that you have specified an unintended time interval for your processing or for the orbit generation, so please check also this aspect.



OPNERR: OPEN FAILED (${X}/GPS/GEN/DE405.EPH)


The reason is a missing DE405.EPH ephemeris file in your ${X}/GEN (%X%\GEN on Windows) directory. The DE405-ephemerides are needed to run the examples of Bernese GNSS Software Version 5.2. README_JPL_EPH.TXT in ${X}/DOC (%X%\DOC on Windows) gives detailed instructions on how to generate a new ephemeris file.



JEPEPH: Error return from call to JESTAT "Epoch out of range"


This error message indicates that the ephemeris file DE405.EPH in ${X}/GEN does not contain data for the requested epoch. README_JPL_EPH.TXT in ${X}/DOC (%X%\DOC on Windows) gives detailed instructions on how to generate a new ephemeris file. In order to expand the validity of the ephemeris file, you will have to get the appropriate ascii-data file from JPL, covering the period of the requested epoch.



L12VAL: WL-FACTOR COMBINATION NOT ALLOWED
WL-FACTOR L1: 2
WL-FACTOR L2: 1


Probably the RINEX header contains invalid information applied as such. Check the zero difference files. There you will possibly find the reason for the problem. Another possible reason could be a useless RECEIVER. file.



READSIN: SOLUTION/STATISTICS Block incomplete for SINEX file


The VARIANCE FACTOR value in your SINEX file is too big. It is expected that the value is within the range of 0.1 and 10. It indicates that something is going wrong in the solution creation.



RDCBFL: MORE THAN 500 RECEIVER-SPECIFIC CODE BIASES FOUND


The reason for this message is that the number of DCB receivers is limited to 500 in the source code. If there are more than 500 stations in your DCB file, we suggest that you reduce the DCB file to only contain stations that you really want to process.
Alternatively you may increase the value for MAXREC in the ${I}/M_MAXDIM.f90 (or %I%\M_MAXDIM.f90) and recompile the affected parts of the software using "CBERN ALL" (or "perl %X%\EXE\cbern.pl ALL" on Windows).



CKOPTL: A character string is expected for keyword "AGENCY"


An empty string is not allowed for input option "Agency running program" in a RINEX utility. Enter the name of the agency/institution creating the RINEX files for this option. This information then will be included in the header of each RINEX file.



HELMTR: TOO MANY PARAMETERS TO ESTIMATE
NUMBER OF PARAMETERS: 3
NUMBER OF STATIONS: 0


For standard regional GNSS network analysis at least one reference station (with known ITRF coordinates) is needed. Either add further observation files of such stations to your analysis or adjust your FIX/CRD file accordingly.
The output can also result from the "outlier rejection" procedure implemented in the HELMR1 program: if one of the stations has an exceptionally wrong coordinate, the residuals for all stations may exceed the thresholds specified in panel "HELMR1 3: Outlier Rejection". Typically this station can easily be identified by inspecting the program output. Exclude the station from the datum definition and rerun the program on the remaining sites.



CHKMAX: Dimension for parameter "MAXzzz" exceeded
CHKMAX: Unusual big number of parameter "MAXzzz" detected


The dimensions of the main arrays are adjusted from the input files and input options. This way, the memory used by the program during the run-time is reduced to a minimum.
The size of most of the arrays is critical in terms of amount of memory needed by the program for execution. Therefore, the adjusted values are limited by built-in default settings (file ${I}/P_GPSEST.f90 or ${I}/M_MAXDIM.f90) to avoid unintentional program runs (e.g., with a huge number of epoch parameters if those were not pre-eliminated epoch-wise).
If these limits are exceeded, a message is issued. Up to a value of two times of the built-in limit the corresponding program run is executed (the message shall indicate that it is an extreme run which will need an exceptional amount of resources regarding memory and/or computing time). If the value exceeds the hard limit of two times of the built-in default setting the program will stop, assuming that the program run is not useful anymore. You should review your program settings carefully and, if necessary, you may split the network into clusters.



GETSTAF: COORDINATES NOT FOUND


The reason for this message is very likely that the renaming of the stations in the station information file (.STA) was missed by RXOBV3 or the RINEX header does not fit in the search pattern of the STA file. Because as the corresponding station is used in your observation file, it needs also be added to the .CRD, .KIN and .STA files.



ARSTR3: RECEIVER TYPE COULD NOT BE ASSIGNED TO A RECEIVER GROUP


The reason for this error message is the fact that teh receiver type is not known to the ambiguity resolution subroutine ARSTR3. Depending on the receiver architecture, ambiguity resolution may be done differently. The predefined receiver types are given in the suboutine 

$LG/ARSTR3.f
Here, you find some definitions: 
C GENERAL DEFINITION OF VARIOUS RECEIVER GROUPS:
                  IF (RECSTR(I)(1:3).EQ.'ASH') RECSTR(I)='@TRI'
                  IF (RECSTR(I)(1:3).EQ.'CHC') RECSTR(I)='@CHC'
                  IF (RECSTR(I)(1:3).EQ.'JAV') RECSTR(I)='@JNS'
                  IF (RECSTR(I)(1:3).EQ.'JPS') RECSTR(I)='@JNS'
                  IF (RECSTR(I)(1:3).EQ.'LEI') RECSTR(I)='@LEI'
                  ...
Because your receiver type is not listed here, you get the error message.
You have the possibility to either change the receiver name in the original RINEX file (and/or the station information file) to a name which at least correspond to the first three characters of an already defined receiver type in the group table. Then, restart the processing from the beginning. If that is not an option, you may add your receiver type to the subroutine. Please add a new line.
If you know that your receiver uses the receiver technology similiar to a Leica receiver, then please assign it to '@LEI'.
If you know that your receiver uses the receiver technology similiar to a Trimble receiver, then please assign it to '@TRI'.
If you are not sure, you can assign it to a new receiver group (with identical three characters after the '@' (as e.g. 'CHC').
A wrong assignment may result in a degraded or wrong ambiguity fixing. To activate your changes you have to recompile the software: 'CBERN GPSEST' ('perl %EXE%\cbern.pl GPSEST' on Windows).





UNIX: we cannot launch BPE scripts in our queuing system because it does not accept Perl scripts. It requires sh-scripts.


To run a BPE from the menu you only need to replace RUNBPE.pm by RUNBPE.sh as the Client script in the first panel of menu >BPE >Start BPE processing. The RUNBPE.sh is also located in the ${BPE}-directory and simply starts RUNBPE.pm as a Perl script with all arguments.
If you want to run BPEs within scripts using the ${BPE}/startBPE.pm module, you need to replace 

$$self{BPE_CLIENT} = '${BPE}/RUNBPE.pm';

by 

$$self{BPE_CLIENT} = '${BPE}/RUNBPE.sh';

in the startBPE::_init method.



Parallel running programs crash from time to time or produce incomplete program output files. The log-file (BPE/{TASKID}yyssss_{PID}_{SUBPID}.LOG) contains a message like: 

LOGFILE_HEADER
lockFile: file
.../OUT/GPSEST.J cannot be locked
What can I do?


The default name of the program output file follows the structure GPSEST.Lxx, where xx is a counter managed by the file GPSEST.J (in the OUT-directory of the campaign). To allow several program runs in parallel a locking mechanism is needed for the file GPSEST.J, which is realized by a special lock file GPSEST.J_lk
If the lock file cannot be released for any reason all parallel running GPSEST will use the same program output in the file GPSEST.XXX which can cause one or more of the parallel running programs to crash.
To reset the file locking mechanism you can remove all *.J_lk files in the OUT-directory in your campaign. It is furthermore recommended not to use the default filename in parallel running BPE scripts to prevent this situation.



Windows and Unix: The BPE starts, but does not finish the first PID of my PCF. No error message is issued, no PRT or LOG files are in the campaign BPE directory. How can I fix this?


This is usually an indication that perl is not available on your system, or it is not correctly installed. Type perl -v on the console, and you should get a version information of the perl available. If not, then please install perl on your system (windows users: get perl for free from activestate).





How can I use Vienna Mapping Function (VMF1) for the data processing?


In the configuration of the processing examples the Global Mapping Function (GMF) is selected. For technical reasons there is no variable in the PCFiles available to select the troposphere model.

Nevertheless you might be interested to change the troposphere model in the program options. General information on how to use the VMF with the Bernese GNSS Software is given in the ${X}/DOC/README_VMF.TXT file (accessable via menu >Help >Readme: VMF correction from TU Vienna).

To include the VMF corrections to the processing examples you have to:

  1. Download the VMF grid files from the TU Vienna server to your DATAPOOL area.
  2. Modify the copy script of your BPE (PPP_COP, R2S_COP, and/or CLK_COP in ${U}/SCRIPT directory depending in which of the BPEs you want to use the VMF) to copy the grid files from the datapool into your processing campaign.
    You need five files to cover a full day. For an hourly processing scheme you have to select the grid files according to your cmenu >current session and the number of hourly included in the processing (BPE variables V_HOURLY).
  3. Because the access to the grid files needs some computing resources we recommend to run the pre-processing steps still on GMF. You have to modify the GPSEST input files in the BPE option directories of the following BPE scripts using menu >BPE >Edit PCF program input files:
    PPP_BAS.PCF 302 PPPEDT_P PPP_GEN
    PPP_DEMO.PCF302 PPPEDT_P PPP_GEN
    523 TIMEST_P PPP_KIN
    543 TIMEST_P PPP_TRP
    563 TIMEST_P PPP_ION
    571 GPSEST PPP_RIM
    RNX2SNX.PCF 502 GPSCLU_P R2S_FIN
    CLKEST.PCF 502 TIMEST_P CLK_RES
    In the corresponding program input panels for GPSEST you have to
    • add the file name of the "Gridded VMF1 coefficients" in panel GPSEST 1.1
    • select DRY_VMF for the "ZPD model and mapping function" in panel GPSEST 3.2
    • select WET_VMF for the "Mapping function" in panel GPSEST 6.1.1
  4. If you introduce a solution troposphere file via BPE variable V_FIXTRP to the clock estimation example (CLKDET.PCF) that was generated using VMF troposphere corrections you have to include the "Gridded VMF1 coefficients" in panel GPSEST 1 to all GPSEST runs where this file is introduced:
    CLKEST.PCF 412 TIMEST_P CLK_ED0
    452 TIMEST_P CLK_EDT
    502 TIMEST_P CLK_RES

Important remark for operational processing:
The use of the VMF requires external gridded information from TU Vienna. In general these files are available in time. In case of an outage of this external data source or if your download of the gridded information fails for any reason your processing will stop with an error.



Why satellites with accuracy code 0 are excluded in PRETAB?


The accuracy code 0 used in the SP3 files indicate satellites with less than three contributing analysis centers. Due to several changes it may happen that uncertain orbits from unhealthy satellites obtained from one-day arcs may by included (in particular marginally observed unhealthy satellites benefit from multi-day arcs).

To get complete orbits for all active GNSS satellites, you should, e.g., use the CODE orbit products.



The example BPE stops with an error message like: 

 *** SR OPNERR: OPEN FAILED
                FILE NAME : ${P}/LONGCAMPAIGN/OUT/COD15941.C
                ...


Unfortunately the internal length of filenames (including the path) is still limited on 32 characters. To run through the examples with the filenaming as it is used in the distributed BPEs, the campaign name should not be longer than 7 characters.





There is no entry for a specific antenna/radome combination in the phase center correction file PCV_COD.I08 in the BSWUSER52/GEN directory of our ftp site.


The IGS08.ATX in its latest version contains only antennas that are used within the IGS network. For our processing in the frame of the IGS and EPN we at CODE extract those antennas that we are using for our processing according to our network configuration. This extraction results in the file PCV_COD.I08 that is posted to out ftp site.
This file is only intended as a basis for your processing and must be extended using the program ATX2PCV of the software by further antenna phase center corrections from IGS08.ATX or from other sources. The basis for the included antenna/radome combinations and GNSS-related corrections is the station information file you are specifiying in ATX2PCV.





What is the meaning of *MARK* in program SATMRK?


"Marking" of observations means that a flag is added to the observation file. The processing programs do not use these flagged measurements. With a pre-processing program (like MAUPRP) such flags can also be removed again and the observation may become valid again. In contrast, the "ELIMINATE" option removes the data from the observation files and cannot be recovered.


 

















 


















Quick Links

Current version
 
 
 

Page maintained by Pierre Fridez - Last update: 21-Feb-2024 12:13:05 CET