JAVAD GREIS GNSS Receiver External Interface User Guide

How is GREIS Used: It is used to enhance the functionality and accuracy of GNSS systems.
Lists: Refer to the manual for detailed lists of supported features and functionalities.

Objects: Explore different objects that can beutilized with GREIS for specific tasks.

Receiver Input Language

The receiver input language allows users to interact with the device using specific commands and syntax. Here’s a brief overview:

Language Examples: Learn from provided examples to understand how to communicate with the device.
Language Syntax: Familiarize yourself with the syntax rules for sending commands to the receiver.

Commands: Utilize various commands to control and configure the device based on your requirements.

Receiver Messages

Understanding receiver messages is crucial for interpreting data and status information. Here’s what you need to know:

Conventions: Follow specific formats and values for interpreting messages accurately.
Standard Message Stream: Explore the standard message format for consistent data transmission.

FAQs

Q: Can I modify the firmware of the GREIS GNSS Receiver?
A: No, modifying the firmware is not allowed as per the copyright regulations of JAVAD GNSS.

Q: How can I access support for technical issues related to the GREIS GNSS Receiver?
A: For technical support, please contact JAVAD GNSS directly for assistance.

View Fullscreen

Thank you for purchasing your JAVAD GNSS receiver. The materials available in this Reference Guide (the “Guide”) have been prepared by JAVAD GNSS, Inc. for owners of JAVAD GNSS products. It is designed to assist owners with the use of the receiver and its use is subject to these terms and conditions (the “Terms and Conditions”).

Terms and Conditions
PROFESSIONAL USE JAVAD GNSS receivers are designed to be used by a professional. The user is expected to have a good knowledge and understanding of the user and safety instructions before operating, inspecting or adjusting. Always wear the required protectors (safety shoes, helmet, etc.) when operating the receiver.

DISCLAIMER OF WARRANTY EXCEPT FOR ANY WARRANTIES IN THIS GUIDE OR A WARRANTY CARD ACCOMPANYING THE PRODUCT, THIS GUIDE AND THE RECEIVER ARE PROVIDED “AS-IS.” THERE ARE NO OTHER WARRANTIES. JAVAD GNSS DISCLAIMS ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR USE OR PURPOSE. JAVAD GNSS AND ITS DISTRIBUTORS SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN; NOR FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE OR USE OF THIS MATERIAL OR THE RECEIVER. SUCH DISCLAIMED DAMAGES INCLUDE BUT ARE NOT LIMITED TO LOSS OF TIME, LOSS OR DESTRUCTION OF DATA, LOSS OF PROFIT, SAVINGS OR REVENUE, OR LOSS OF THE PRODUCT’S USE. IN ADDITION, JAVAD GNSS IS NOT RESPONSIBLE OR LIABLE FOR DAMAGES OR COSTS INCURRED IN CONNECTION WITH OBTAINING SUBSTITUTE PRODUCTS OR SOFTWARE, CLAIMS BY OTHERS, INCONVENIENCE, OR ANY OTHER COSTS. IN ANY EVENT, JAVAD GNSS SHALL HAVE NO LIABILITY FOR DAMAGES OR OTHERWISE TO YOU OR ANY OTHER PERSON OR ENTITY IN EXCESS OF THE PURCHASE PRICE FOR THE RECEIVER.
LICENSE AGREEMENT Use of any computer programs or software supplied by JAVAD GNSS or downloaded from a JAVAD GNSS website (the “Software”) in connection with the receiver constitutes acceptance of these Terms and Conditions in this Guide and an agreement to abide by these Terms and Conditions. The user is granted a personal, non-exclusive, non-transferable license to use such Software under the terms

PREFACE Terms and Conditions
stated herein and in any case only with a single receiver or single computer. You may not assign or transfer the Software or this license without the express written consent of JAVAD GNSS. This license is effective until terminated. You may terminate the license at any time by destroying the Software and Guide. JAVAD GNSS may terminate the license if you fail to comply with any of the Terms or Conditions. You agree to destroy the Software and Guide upon termination of your use of the receiver. All ownership, copyright and other intellectual property rights in and to the Software belong to JAVAD GNSS. If these license terms are not acceptable, return any unused software and guide.

CONFIDENTIALITY This guide, its contents and the Software (collectively, the “Confidential Information”) are the confidential and proprietary information of JAVAD GNSS. You agree to treat JAVAD GNSS’ Confidential Information with a degree of care no less stringent that the degree of care you would use in safeguarding your own most valuable trade secrets. Nothing in this paragraph shall restrict you from disclosing Confidential Information to your employees as may be necessary or appropriate to operate or care for the receiver. Such employees must also keep the Confidentiality Information confidential. In the event you become legally compelled to disclose any of the Confidential Information, you shall give JAVAD GNSS immediate notice so that it may seek a protective order or other appropriate remedy.
WEBSITE; OTHER STATEMENTS No statement contained at the JAVAD GNSS website (or any other website) or in any other advertisements or JAVAD GNSS literature or made by an employee or independent contractor of JAVAD GNSS modifies these Terms and Conditions (including the Software license, warranty and limitation of liability).
SAFETY Improper use of the receiver can lead to injury to persons or property and/or malfunction of the product. The receiver should only be repaired by authorized JAVAD GNSS warranty service centers.
MISCELLANEOUS The above Terms and Conditions may be amended, modified, superseded, or canceled, at any time by JAVAD GNSS. The above Terms and Conditions will be governed by, and construed in accordance with, the laws of the State of California, without reference to conflict of laws.

What is GREIS
GREIS is an interfacing language enabling user to effectively communicate with GNSS receivers by accessing all of their capabilities and functions.
GREIS represents a generic receiver language structure for the entire range of JAVAD GNSS hardware. This language structure is receiver-independent and open to future modification or expansion. GREIS is based on a unified approach allowing the user to control a JAVAD GNSS receiver using an appropriate set of named objects. Communication with these objects is achieved through predefined commands and messages. There are no specific constraints on the number or type of the receiver objects used.

How is GREIS Used
Any system communicating with the JAVAD GNSS receiver through one of its ports (serial, parallel, USB, Ethernet, etc.) will use GREIS commands and messages to accomplish the required task. A pair of typical applications where GREIS plays a very important role are, first, using hand-held controllers to communicate with the receivers during field operation in survey and RTK projects or, second, when downloading data from the receivers into desktop systems for further post processing. A post processing application itself doesn’t use GREIS commands, but needs to be aware of GREIS messages to extract data from the data files.

One important feature of GREIS is that it can be effectively used both for the automatic and manual control of JAVAD GNSS receivers. For manual control, the user will enter necessary GREIS commands into the receiver through a terminal. This is easily achievable as GREIS is designed to be human-readable text interface. On the other hand, GREIS obeys rather strict rules that makes it easy to use by applications.

Lists
GREIS heavily utilizes a concept of lists. Lists are used both in the receiver input language and in the standard text messages.

INTRODUCTION Objects
Lists in GREIS are represented by a sequence of elements delimited by comma (,, ASCII code 44), and enclosed in braces ({}, ASCII codes 123 and 125):
{element1,element2,element3}
In turn, elements of a list may themselves be lists:
{e1,{ee21,ee22},e3}
Thus the above definition is recursive, so that lists of arbitrary nesting depth are allowed. Elements that are not lists are called leaf elements, or simply leafs. Elements of lists could be empty, in which case we say the element is omitted. For example, in the list below, second element is omitted:
{e1,,e3}
Spaces before and after delimiters are allowed and ignored. If elements of a list all have the same substring (prefix) at the beginning, this substring could be moved out of the braces surrounding the list, e.g.,
elem{1,2,3}
is a shorter form of the
{elem1,elem2,elem3}

Elements could be enclosed into double-quotes (“, ASCII code 34) that are stripped during parsing. Inside quoted element, special symbols (braces, commas, etc.) loose their role and are considered to be regular characters. Another use of quotes is to distinguish between “element is not specified” and “empty element specified” conditions. The former is denoted by simply omitting an element from the list, and the latter is denoted by putting pair of double-quotes between the commas. Quoting is also useful when one needs to have leading or trailing spaces in a string. To put double-quote into element, quote this element and escape the double-quote inside with the backslash character (, ASCII code 92). To put backslash by itself into quoted string, escape it with another backslash, for example:
Example: “String with “quotes”, backslash \, and special characters, {}”
1.4 Objects
In the context of the model that GREIS is based on, a JAVAD GNSS receiver is identified with a set of named objects.

GREIS

www.javad.com

INTRODUCTION Objects
Object Identifiers
Object is defined as a hardware or software entity of the receiver’s that can be addressed, set, or queried. Hardware entities are commonly referred to as devices, whereas firmware objects are normally files and parameters. Receiver ports and memory modules are all good examples of devices. All devices, files and parameters are treated in a uniform way by GREIS. Every object has an associated set of attributes that can be accessed, defined, and/or changed through GREIS.

1.4.1 Object Identifiers
It has been already mentioned that a receiver is considered as a set of objects (devices, files, messages, parameters, etc.) in the context of the GREIS model. For the purposes of addressing the objects in the receiver commands, a unique identifier should be assigned to every object.

Objects in the receiver are logically organized into groups. A group itself is also an object and belongs to another group unless it is the root group. Thus all objects in the receiver are organized into a tree-like hierarchy starting at the single root group. This representation resembles the organization of files into directories (folders) that most computer users are familiar with.
In GREIS, object groups are represented as lists of corresponding object names. The object name is unique inside the list to which the object belongs. Globally unique object identifier is defined as all the object names on the path through the object tree from the root list to the object, delimited by the forward slash (/). The root list itself is identified by the single forward slash.
Examples of object identifiers are:
Example: The root group:
/
Example: Receiver electronic ID:
/par/rcv/id
Example: Serial Port A baud rate:
/par/dev/ser/a/rate
Example: Attributes (size and last modification time) of the file NAME (file attributes are different from object attributes discussed below):
/log/NAME
Example: NMEA GGA sentence:

GREIS

www.javad.com

INTRODUCTION Periodic Output
Object Types
/msg/nmea/GGA
All the objects have one or more attributes associated with them. Object attributes are identified by appending the & character and the attribute name to the object identifier. The primary attribute each object has is value. This attribute is always accessed implicitly by GREIS commands. Some of objects may have additional attributes, for example: Example: Serial port A default baud rate:
/par/dev/ser/a/rate&def
Example: Contents of the file NAME:
/log/NAME&content
1.4.2 Object Types
Every object in the receiver has GREIS type associated with it. The type of an object defines its behavior with respect to GREIS commands. Specifically, the type defines which values the object can take and which particular commands are applicable to the object.
Refer to “Primary Object Types” on page 184 for detailed description of currently supported object types.

GREIS

1.5 Periodic Output

An important role in the receiver operation plays its ability to periodically output some information, such as different kinds of measurements, calculated values, etc., according to specified schedule. GREIS defines a rich set of messages containing different types of information in different formats that are minimal units of output, and provides methods to request periodic output of any combination of the messages in any order to any of the supported media suitable for data output. Any supported medium suitable for data output is called output stream in GREIS.
For every output stream, receiver maintains a list of messages that are currently enabled to be output to the stream, called output list. The order in which messages are output, matches the order of messages in the output list. In addition, every message that is present in an output list has its own set of scheduling parameters associated with it. Scheduling parameters attached to a message in an output list define the schedule of output of this particular message into this particular output stream. GREIS provides three com-

www.javad.com

INTRODUCTION Periodic Output Output Period and Phase
mands, em, out, and dm, to allow for efficient manipulation of output lists and scheduling parameters.
Message scheduling parameters comprise four fields: period, phase, count, and flags, each of which plays different role in the output schedule definition. Below we will describe how exactly their values affect the output, but basically, the period specifies interval between outputs of the message; phase specifies time shift of the moments of output with respect to time moments when current time is multiple of period; the count, when greater than zero, limits the number of times the message will be output; whereas flags filed allows for some fine tuning of the output process.

1.5.1 Output Period and Phase

Note:

The period and phase fields of the message scheduling parameters are floating point values in the range [0…86400) seconds. Their exact meaning is described below.
When the F_CHANGE bit is set in the flags field of the scheduling parameters, the phase field looses its usual role and becomes “forced output period” instead. See description of the F_CHANGE flag below for details.
The receiver has its internal time grid that is defined by the receiver clock and the value of the /par/raw/curmsint parameter that defines the step of receiver internal epochs. Receiver internal epochs occur when receiver time is multiple of the step. In turn, receiver time is defined as the value of receiver clock modulo one day (86400 seconds). Receiver scans the output lists only at internal receiver epochs, so that no output could be generated more frequently than that.
Taking into account the internal time grid, the period and phase variables define the time moments of the output of a message as follows: receiver will output the message only at the receiver times Tout simultaneously satisfying the following two equations:

Toutmod period = phase

(1)

Tout = N step (2)

GREIS

where N is integer number taking the values [0,1,2,…,(86400/step)-1].
The first equation defines the basic rule of messages output, and the second one imposes additional constraints related to the internal receiver epochs. Note that in the most usual case, when both period and phase are multiples of step, the second equation is satisfied automatically whenever the first equation is satisfied. Also note that if
86400 (mod period) 0,

www.javad.com

INTRODUCTION Periodic Output
Output Count

Example:
Example: Example:

the actual interval between the last message sent before the day rollover and the first message after the day rollover will be different from the value of period.
Consider a couple of examples illustrating this mechanism:
Suppose period is 10s, phase is 2.2s, and step is 0.2s. As Tout, according to the second equation, can take only values that are multiple of step, the left part of the first equation will take the following values: 0, 0.2, 0.4, …, 9.8, 0, …, from which only value 2.2 matches phase. These matches will occur, and the message will be output, every time Tout takes one of the following values: 2.2s, 12.2s, 22.2s, etc.
Suppose period is 10s, phase is 2.2s, and step is 0.5s. The receiver will not output the message since the above pair of simultaneous equations is never satisfied.
Suppose phase > period. The receiver won’t output the message at all as the first equation will never be satisfied.

1.5.2 Output Count

Note:

The count field of the message scheduling parameters is an integer value in the range [-256…32767) and serves two different purposes:
1. When the count is 0, unlimited number of messages will be output. When the count is greater than 0, it defines how many times the message will be output. In this case the counter is decremented by 1 every time the message is output, and when it becomes 0, the F_DISABLED bit is set in the flags field. The message scheduler doesn’t output messages with F_DISABLED bit set.
2. When the count is set to a value in the range [-256…-1], the output of the message is not suppressed, and the count field serves entirely different purpose. It enables wrapping of the message into special [>>] message before output (see “[>>] Wrapper” on page 132). The value of count is then used to set the id field in the generated [>>] message so that the id is numerically equal to (-1 – count).
The wrapping feature is useful, for example, for a server application that gets messages from receiver and forwards them to multiple clients. It can request wrapping of arbitrary messages into the [>>] messages with different identifiers, unwrap the received messages, and dispatch the data to particular client(s) based on the received id. Utilizing this feature, such an application doesn’t need to be aware of any other data formats but the format of the [>>] message, and can use single channel of communication with the receiver to get and dispatch messages in different formats.

GREIS

www.javad.com

1.5.3 Output Flags

INTRODUCTION Periodic Output
Output Flags

The flags field of the message scheduling parameters is a 16-bit wide bit-field. Each bit of this bit field is a separate flag and serves different purpose. The following is a list of the message scheduling flags.
Table 1-1. Message Scheduling Flags

Bit#
0 1 2 3 4 5 6 7 8 9 10 11 1215

HEX
0x0001 0x0002 0x0004 0x0008 0x0010 0x0020 0x0040 0x0080 0x0100 0x0200 0x0400 0x0800 0xF000

Name
F_OUT F_CHANGE F_OUT_ON_ADD F_NOTENA F_FIX_PERIOD F_FIX_PHASE F_FIX_COUNT F_FIX_FLAGS reserved reserved reserved F_DISABLED reserved

Note: Field names are introduced here only for the purpose of referring to them in this manual. There is no way to use them in the GREIS commands.

F_OUT If this flag is set, the first messages after invocation of the corresponding command will be output at the internal receiver epoch closest to the command execution time no matter what is specified by the period scheduling parameter.
F_CHANGE If this flag is set, the corresponding message will be output only if the message data have changed since the last output of the message to the given output stream. Receiver checks whether the message data have changed only at the moments defined by the equations (1),(2) where phase variable is set to zero, and period variable is set to the value of period field. The message scheduling parameter phase, which loses its original function in this case, now plays the role of a forced output period. “Forced output” means that the corresponding message will be output whether its contents will have changed or not at the time moments defined by the equations (1),(2) where period variable is set to the value of the phase field, and phase variable is set to zero. If the field phase is zero, then the receiver performs no forced output so that the corresponding message will be output only on condition that its data have changed.

GREIS

www.javad.com

INTRODUCTION Periodic Output
Output Flags
F_OUT_ON_ADD If this flag is set, then the first message will be output immediately after executing the corresponding em or out command. This flag is ignored for majority of messages1.
F_NOTENA If this flag is set for a message in an output list, the F_DISABLED flag for this message won’t be cleared when the message is enabled, and therefore its output will remain suspended. For example, this flag is used in order not to output some of the messages from the default set of messages when the user changes output period on the fly, without first disabling the output.
F_FIX_PERIOD, F_FIX_PHASE, F_FIX_COUNT, F_FIX_PERIOD Being set to 1 in a scheduling parameters, prevent changes to corresponding field(s) of this scheduling parameters through em and out commands.
F_DISABLED Is not explicitly programmable by the user. When one enables a message with a positive count, then, after this message has been output count times, the message scheduler sets this flag to 1. This flag is cleared to 0 when the message is re-enabled, unless F_NOTENA flag is set for this message.

1. Currently only two GREIS messages, [JP] and [MF], honor this flag.

GREIS

www.javad.com

Chapter 2
RECEIVER INPUT LANGUAGE

This chapter describes the syntax and semantics of the receiver input language. We begin with some examples to give the reader a feeling of the language, then turn to detailed syntax definition, and then describe all the defined commands along with their semantics.

2.1 Language Examples

Here are a few examples of real statements receiver understands along with receiver replies. You will find more examples of using particular commands in corresponding subsections. The input to the receiver is marked with the character, while receiver output is marked with the character:

Example: Ask receiver to print its electronic ID. Receiver generates the reply message shown:

Example:

print,/par/rcv/id<CR> RE00C QP01234TR45<CR><LF>
Ask receiver to set the baud rate of its serial port A to 9600. Receiver successfully executes the command and doesn’t generate any reply.

set,/par/dev/ser/a/rate,9600<LF>
Example: Use the same command as in the previous example, but force receiver to generate reply by means of using the statement identifier.

Example:

%set_rate%set,/par/dev/ser/a/rate,9600<LF> RE00A%set_rate%<CR><LF>
Try to set too high baud rate. Receiver replies with the error message even though we used no statement identifier.

set,/par/dev/ser/a/rate,1000000<LF> ER016{4,value out of range}<CR><LF>

Note:

Receiver always puts its normal and error replies into two standard messages, [RE] and [ER], respectively. For more information on the format of GREIS messages, refer to “General Format of Messages” on page 64. The [RE] and [ER] messages themselves are described in “Interactive Messages” on page 129.

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Language Syntax
2.2 Language Syntax
GREIS defines lines of ASCII characters of arbitrary length1, delimited by either carriage-return (<CR>, ASCII decimal code 13), or line-feed (<LF>, ASCII decimal code 10) characters, to be the top-level syntax elements of the language. Empty lines are allowed and ignored in GREIS. As a consequence, a line could be delimited by any combination of <CR> and/or <LF> characters. It allows GREIS to seamlessly support WindowsTM, MacTM, and UNIXTM line ending conventions.
Receiver input language is case-sensitive. It means that, for example, strings GREIS, greis, and gReIs, being different strings, are indeed considered as such by the receiver.
The number sign (#, ASCII code 35) is the comment introduction character. Receiver ignores everything starting from this character up to the end of the line.
After comment (if any) is stripped from the line, receiver removes leading and trailing spaces, and then breaks the line into statements. Statements are delimited with semicolon (;, ASCII code 59), or with two ampersands (&&, ASCII codes 38), or with two vertical bars (||, ASCII codes 124). Statements in a line are then executed in order, from left to right. If statement that ends in && delimiter produces an error, the rest of statements in the line are not executed. If statement that ends in || delimiter executes successfully, the rest of statements in the line are not executed. Statement that ends in semicolon never stops execution of the sequence of statements. Note that the end of line is by itself statement terminator, so you don’t need to put one of explicit statement delimiters at the end of the line.
The format of a statement is as follows:
[%ID%][COMMAND][@CS] where square brackets denote optional fields, and any number of whitespaces is allowed before and after every field. Such whitespaces are ignored, except for the purpose of checksum calculation, see below. The fields are:
%ID% statement identifier, where ID denotes arbitrary string, possibly empty. The identifier, if present, is copied unchanged by the receiver into the response message for the statement. Any statement with an identifier will always generate a response from the receiver. A statement that contains only an identifier is also allowed; in such a case, the receiver will just generate a response message.
COMMAND a (possibly empty) list where the first element is called command name. It denotes the action to be performed. The rest of elements (if any) are command

GREIS

1. Current GREIS implementation in the receivers supports lines of up to 256 characters in length.

www.javad.com

RECEIVER INPUT LANGUAGE Language Syntax
arguments. Braces that surround command list could be omitted. Refer to “Lists” on page 19 for the syntax of lists. @CS checksum, where CS is 8-bit checksum formatted as 2-byte hexadecimal number. Before executing a statement with checksum, the receiver will compare the input checksum CS against that computed by the firmware and will refuse to execute the statement should these checksums mismatch. Checksum is computed starting with the statement’s first non-blank character until and including the @ character. See “Computing Checksums” on page 579 for details.
Statement identifier, %ID%, serves the following purposes:
1. Forces receiver response to the command. 2. Allows to send multiple commands with different identifiers to the receiver
without waiting for response for every command, then receive the responses and tell which response corresponds to which command. 3. Helps to establish synchronization with the receiver by allowing to check that particular receiver response corresponds to particular command, and not to some other command issued before or after.
A list called options could be appended to any element of the COMMAND after the colon (:, ASCII code 58). If options list comprises single element, the surrounding braces could be omitted. Options list appended to a list propagates to every element of the list, though the options explicitly appended to an element of the list take precedence over propagated options. For example,
{e1,{e2:{o1,,o3},e3}}:{o4,o5}
is equivalent to:
{e1:{o4,o5},{e2:{o1,o5,o3},e3:{o4,o5}}}
Note also how missed o2 option allows o5 option to propagate to the list of options for e2 element.
The number and the meaning of arguments and options in the command depends on particular command action and is defined in the description of every receiver command. In addition, if command description specifies some options, but some or all of them are missed in the statement, the default values for the missed options are substituted. The default values for options are also defined in the description of every receiver command.

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Language Syntax

For reference, below is the table comprising all the character sequences that have special meaning in the receiver input language:

Table 2-1. Input Language Special Characters

Characters Decimal ASCII code

Meaning

<LF>

line separator

<CR>

line separator

;

beginning of comment mark statements separator

124

statements and separator statements or separator statement identifier mark

{

123

}

125

checksum mark beginning of list mark end of list mark list elements separator options mark

”

quotation mark

escape

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands
2.3 Commands
In this section we describe all the commands defined in GREIS. Syntax and semantics specifications of every command are accompanied by explanatory examples. For detailed description of objects used as arguments in the examples, please refer to Chapter 4 on page 181.

GREIS

www.javad.com

2.3.1 set

RECEIVER INPUT LANGUAGE Commands set

Name
set set value of an object.
Synopsis
Format: set,object,value Options: none
Arguments
object the target object identifier. If object does not begin with “/”, then “/par/” prefix is automatically inserted before the object prior to executing the command.
value the value to be assigned to the target object. The range of allowed values as well as semantics of the assignment depends on the type of the object and is specified later in this manual for every supported object.
Options
None.
Description
This command assigns value to the object. No response is generated unless there is an error or response is forced by the statement identifier.
Examples
Example: Set baud rate of serial port C to 115200. Either of:
set,/par/dev/ser/c/rate,115200 set,dev/ser/c/rate,115200
Example: Set baud rate of serial port A to 9600 and force reply:
%%set,dev/ser/a/rate,9600 RE002%%

GREIS

www.javad.com

2.3.2 print

RECEIVER INPUT LANGUAGE Commands print

Name
print print value of an object.

Synopsis
Format: print,object Options: {names}

Arguments
object the object identifier of the object to be output. If object does not begin with “/”, then “/par/” prefix is automatically inserted before the object prior to executing the command.

Options

Table 2-2. print options summary

Name Type

Values

names boolean on,off

Default
off

names if off, output only object values. When on, output object names in addition to object values in the format NAME=VALUE.
Description
This command prints value of the object, optionally prefixing the value with the name of corresponding object. The response is always generated, and more than one [RE] message could be generated in response to a single print command.
The value of an object of type list is printed as a list of values for every object in the list. This is applied recursively until leaf objects are reached, so printing an object of nonleaf type effectively outputs entire sub-tree starting from the specified object. In case of printing of lists, multiple [RE] messages could be generated. However, splitting of the output may occur only immediately after list separator characters.

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands print
Examples
Example: Print current period of the internal receiver time grid. Either of:
print,/par/raw/curmsint RE004 100 print,raw/curmsint RE004 100
Example: Print current period of the internal receiver time grid along with the object name. Either of:
print,/par/raw/curmsint:on RE015/par/raw/curmsint=100 print,raw/curmsint:on RE015/par/raw/curmsint=100
Example: Print receiver version information:
print,rcv/ver RE028{“2.5 Sep,13,2006 p2″,0,71,MGGDT_5,none, RE00D {none,none}}
Example: Print receiver version information along with corresponding names:
print,rcv/ver:on RE043/par/rcv/ver={main=”2.5 Sep,13,2006 p2”,boot=0,hw=71,board=MGGDT_5, RE00C modem=none, RE017 pow={fw=none,hw=none}}
Example: Print all the messages enabled for output to serial port B along with their scheduling parameters:
print,out/dev/ser/b:on RE02D/par/out/dev/ser/b={jps/RT={1.00,0.00,0,0×0}, RE01A jps/SI={1.00,0.00,0,0×0}, RE01A jps/rc={1.00,0.00,0,0×0}, RE01A jps/ET={1.00,0.00,0,0×0}, RE01D nmea/GGA={10.00,5.00,0,0×0}}

GREIS

www.javad.com

2.3.3 list

RECEIVER INPUT LANGUAGE Commands list

Name
list list contents of an object.
Synopsis
Format: list[,object] Options: none
Arguments
object the object identifier of the object to be output. If object is omitted, /log is assumed. If object does not begin with “/”, then “/log/” prefix is automatically inserted before the object prior to executing the command.
Options
None.
Description
This command outputs names of every member of the object. The response is always generated, and more than one [RE] message could be generated in response to a single list command. If the object specified is not of type list, empty [RE] message is generated. If the object specified is a list, the list of names of every object in the list is printed. This is applied recursively until leaf objects are reached, so listing an object of non-leaf type effectively outputs entire sub-tree starting from the specified object. In case of printing of lists, multiple [RE] messages could be generated. However, splitting of the output may occur only immediately after list separator characters.
Examples
Example: Empty reply for listing of a non-list object:
list,/par/rcv/ver/main RE000
Example: Error reply for listing of non-existing object:
list,/does_not_exist ER018{2,,wrong 1st parameter}

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands list
Example: Obtain a list of existing log-files. Either of
list,/log list
will produce the same output, e.g.:
RE013{log1127a,log1127b}
Example: List all standard GREIS messages supported by the receiver:
list,/msg/jps RE03D{JP,MF,PM,EV,XA,XB,ZA,ZB,YA,YB,RT,RD,ST,LT,BP,TO,DO,OO,UO,GT, RE040 NT,GO,NO,TT,PT,SI,NN,EL,AZ,SS,FC,RC,rc,PC,pc,CP,cp,DC,CC,cc,EC, RE040 CE,TC,R1,P1,1R,1P,r1,p1,1r,1p,D1,C1,c1,E1,1E,F1,R2,P2,2R,2P,r2, RE040 p2,2r,2p,D2,C2,c2,E2,2E,F2,ID,PV,PO,PG,VE,VG,DP,SG,BI,SE,SM,PS, RE040 GE,NE,GA,NA,WE,WA,WO,GS,NS,rE,rM,rV,rT,TM,MP,TR,MS,DL,TX,SP,SV, RE031 RP,RK,BL,AP,AB,re,ha,GD,LD,RM,RS,IO,NP,LH,EE,ET}
Example: List all the messages in the default set of messages:
list,/msg/def RE040{jps/JP,jps/MF,jps/PM,jps/EV,jps/XA,jps/XB,jps/RT,jps/RD,jps/SI, RE040 jps/NN,jps/EL,jps/FC,jps/RC,jps/DC,jps/EC,jps/TC,jps/CP,jps/1R, RE040 jps/1P,jps/2R,jps/2P,jps/E1,jps/D2,jps/E2,jps/SS,jps/SE,jps/PV, RE040 jps/ST,jps/DP,jps/TO,jps/DO,jps/UO,jps/IO,jps/GE,jps/NE,jps/GA, RE01D jps/NA,jps/WE,jps/WA,jps/WO}

GREIS

www.javad.com

GREIS

2.3.4 em & out

RECEIVER INPUT LANGUAGE Commands em & out

Name
em, out enable periodic output of messages.

Synopsis
Format: Format: Options:

em,[target],messages out,[target],messages {period, phase, count, flags}

Arguments
target any output stream or message set. If no target is specified, the current terminal, /cur/term, is assumed.
messages the list (either with or without surrounding braces) of message names and/or message set names to be enabled. If some of the specified names do not begin with “/”, then “/msg/” prefix is automatically inserted before such names prior to executing the command.

Options

Table 2-3. em and out options summary

Name Type

Values

Default

period float [0…86400)

–

phase float [0…86400)

–

count integer [-256…32767] 0 for em 1 for out

flags integer [0…0xFFFF] –

period, phase, count, flags message scheduling parameters.
Description
These commands enable periodic output of the specified messages into the target, enforcing the message scheduling parameters to be those specified by options. No response is generated unless there is an error, or response is forced by the statement identifier.
The em and out commands are the same except the default value of the count option is set to 0 for em, and 1 for out. The out command is just a more convenient way to request

www.javad.com

RECEIVER INPUT LANGUAGE Commands em & out

Note:

one-time output of message(s). We will speak only about em in this description though everything applies to the out as well.
The description below expects the reader is familiar with the material in the section “Periodic Output” on page 22.
For every output stream, there is corresponding output list of messages1,2 that are currently enabled to be output to the given stream. When a message passed as argument to em command is not currently in the output list, the em command appends specified message to the end of the list. When a message passed to em command is already in the output list, the em command just changes this message’s scheduling parameters and doesn’t modify message’s position inside the list.
As the em command merges the specified messages to the output list, it’s often a good idea to use dm command to clear the output list for the given stream before issuing em commands.
The em command processes the messages list one message at a time, from left to right, and from the first message of message set to the last message of message set. Should it encounter a name that doesn’t correspond to any supported receiver message or message set, it remembers there was an error during execution, but doesn’t stop processing of the messages list. This way all messages from the messages list that could be enabled will be enabled, and only single error will be reported when one or more of the specified messages can’t be enabled.
When the em command processes a message at hand, the final operating message scheduling parameters in the corresponding output list of messages are calculated taking into account multiple sources of information about scheduling parameters, specifically:
1. Values explicitly specified in the options of the em command.
2. The default values of options of em command.
3. Scheduling parameters specified for the given message as part of the corresponding message set. These are taken into account only when enabling a message by specifying message set, not an individual message.
4. Current scheduling parameters of the message in the corresponding output list (if any).
5. Default scheduling parameters specified for the given message as part of the corresponding message group.
The above sources of parameters are listed in the order of their precedence, the first one having the highest precedence, and are applied individually to each of the four scheduling parameters. Therefore, values from (1) override values from (2), the resulting value

GREIS

1. For a stream NAME, corresponding output list is called /par/out/NAME 2. Current firmware has arbitrary limit for maximum number of messages in an output list set to 49.

www.javad.com

RECEIVER INPUT LANGUAGE Commands em & out

overrides value from (3), etc. However, if some of the F_FIX_PERIOD, F_FIX_PHASE, F_FIX_COUNT, or F_FIX_FLAGS bits are set in the flags field of the next source, corresponding fields of this next source will not be overridden.

Examples

Example: Enable one time output of NMEA GGA message to the current terminal:

em,,nmea/GGA:{,,1}

The same as above, but using out instead of em:

out,,nmea/GGA
Example: Enable the output of the default set of messages to the current log-file A using the default output parameters. Either of:

Example:

em,/cur/file/a,/msg/def em,/cur/file/a,def
Enable output of the default set of messages to the current log-file A every 10 seconds For the other output parameters, their default values will be used:

em,/cur/file/a,def:10
Example: Enable output of the default set of messages to the current terminal using default output parameters. Either of:

Example:

em,/cur/term,/msg/def em,,/msg/def em,,def
Enable output of GREIS messages [~~](RT) and [RD] to the current terminal. Either of:

Example:

em,,/msg/jps/RT,/msg/jps/RD em,,jps/{RT,RD}
Enable output of NMEA messages GGA and ZDA to the current terminal every 20 seconds:

Example:

em,,nmea/{GGA,ZDA}:20
Enable output of messages [SI], [EL] and [AZ] to serial port A. Set scheduling parameters for [SI] so that interval between any two subsequent [SI] messages will be equal to 10 seconds, if they coincide, and 1 second otherwise; output only the first fifty [SI] messages. In addition, the receiver, set output interval to 2 seconds for [EL] and [AZ] messages:

em,/dev/ser/a,jps/{SI:{1,10,50,0×2},EL,AZ}:2

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands em & out
Example: Enable output of RTCM 2.x message types 1 and 31 to serial port B with output interval 3 seconds, and RTCM 2.x message types 18, 19, 3, 22 to port C with output interval 1 second for types 18 and 19; and 10 seconds for types 3 and 22:
em,/dev/ser/b,rtcm/{1,31}:3; em,/dev/ser/c,rtcm/{18:1,19:1,22,3}:10
Example: Customize the default set of messages to only contain NMEA ZDA and GGA:
dm,/msg/def em,/msg/def,/msg/nmea/{ZDA,GGA}

GREIS

www.javad.com

2.3.5 dm

RECEIVER INPUT LANGUAGE Commands dm

Name
dm disable periodic output of messages.
Synopsis
Format: dm[,[target][,messages]] Options: none
Arguments
target any output stream or message set. If no target is specified, the current terminal, /cur/term, is assumed. If some of the specified names do not begin with “/”, then “/msg/” prefix is automatically inserted before such names prior to executing the command.
messages the list of messages to be disabled, either with or without surrounding braces, or any message group or message set. If no messages are specified, all periodic output to the target is disabled.
Options
None.
Description
This command disables periodic output of the specified messages into the object target. No response is generated unless there is an error, or response is forced by the statement identifier.
If no messages are specified, all the periodic output to the target is disabled. If the target is a current log-file and no messages are specified, all the output to the file is disabled, the file is closed, and corresponding current log-file is set to none.
If a message is specified in the messages list that is not currently enabled to be output to the given target, no corresponding error is generated by the dm command. Though this condition doesn’t disable other possible errors from being reported.
Examples
Example: Disable all of the messages being output into the current log-file A and close the file:
dm,/cur/file/a

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands dm
Example: Disable all the periodic output into the current terminal. Either of:
dm,/cur/term dm
Example: Disable output of GREIS message [~~](RT) into the serial port B:
dm,/dev/ser/b,/msg/jps/RT
Example: Disable output of the GREIS message [DO] into the current log-file B:
dm,/cur/file/b,/msg/jps/DO
Example: Remove GREIS message [PM] from the default set of messages:
dm,/msg/def,/msg/jps/PM
Example: Disable output of all NMEA messages to the current terminal:
dm,/cur/term,/msg/nmea
Example: Disable output of the NMEA messages GGA and ZDA into the current terminal. Either of:
dm,/cur/term,/msg/nmea/GGA,/msg/nmea/ZDA dm,,/msg/nmea/GGA,/msg/nmea/ZDA dm,,nmea/GGA,nmea/ZDA dm,,nmea/{GGA,ZDA}

GREIS

www.javad.com

2.3.6 init

RECEIVER INPUT LANGUAGE Commands init

Name
init initialize objects.

Synopsis
Format: init,object[/] Options: none

Arguments
object the object to be initialized. / if present and the object is of type list, initialize all the contained objects instead
of the object itself.

Options
None.

Note: Note:

Description
This command initializes specified objects. No response is generated unless there is an error, or response is forced by the statement identifier.
The exact semantics of initialization depends on the object being initialized, but in general could be considered as turning an object to its “default” or “clean” state. For example, for parameters it means setting their values to corresponding defaults, for the filestorage device it means re-formatting the underlying medium, etc.
Initializing some of objects will result in receiver reboot. This is currently the case for initialization of receiver non-volatile memory (/dev/nvm/a).
Though it may change in the future, current implementation of this generic command in the receivers is rather limited. In fact only initialization of objects that are found in the examples below is currently supported.

Examples
Example: Clear NVRAM and reboot receiver. All the data stored in the NVRAM (almanacs, ephemeris, etc.) will be lost, all the parameters will be set to their default values after reboot:
init,/dev/nvm/a
Example: Clear ephemeris:
init,/eph/

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands init
Example: Set all the receiver parameters to their default values:
init,/par/
Example: Set all WLAN parameters to their default values. Reboot of the unit is required for the changes to take effect:
init,/par/net/wlan/
Example: Initialize the file system (i.e., reformat the underlying medium). All files stored in the receiver will be lost:
init,/dev/blk/a
Example: Initialize all the message sets to their default values:
init,/msg/

GREIS

www.javad.com

2.3.7 create

RECEIVER INPUT LANGUAGE Commands create

Name
create create a new object.

Synopsis
Format: create[,object] Options: {log}

Arguments
object object identifier of the object to be created. If object does not begin with “/”, then “/log/” prefix is automatically inserted before the object prior to executing the command. If omitted, then creation of a file is assumed and an unique file name is automatically generated.

Options

Table 2-4. create options summary

Name Type Values
log string a,b,…

Default
a

log the log-file the created file is to be assigned to. The log-file selected is /cur/log/X, where X is the value of the option1.
Description
This command creates a new object. No response is generated unless there is an error, or response is forced by the statement identifier.
Both the location in the tree and the type of the created object are defined by the object argument.
Two kinds of objects could be created:
1. Files. A new file is created whenever the object identifier specifies an object in a /log sub-tree, or when the object argument is omitted.
2. Message specifiers. A new message specifier is created whenever the object identifier specifies an object in a message set (e.g., /msg/def).

GREIS

1. Current firmware supports either one or two simultaneous log-files depending on particular receiver.

www.javad.com

RECEIVER INPUT LANGUAGE Commands create
Creating Files
When creating files, the object argument is either omitted or has a format /log/NAME, where NAME is the name of the file to be created, and /log/ is optional. In the former case receiver will automatically select an unique name for the file. In the latter case the NAME specified should be a string of up to 31 characters and should contain neither spaces nor the following characters: “,{}()@&”/”.
If the file /log/NAME already exists, the create command will fail and produce an error message. As a consequence, there is no way to clobber some of existing files with the create command.
After a new file is successfully created, it’s assigned to one of the current log-files depending on the value of the log_file option. If corresponding log-file already points to another file when create is executed, the old log-file will be closed and the output will continue into the new file without any interruption.
Creating Message Specifiers
When adding messages to a message set, the object argument has a format /msg/SET/GROUP/MSG, where SET is the name of the message set where new message should be created, GROUP is the name of the group the message belongs to, and MSG is the name of the message itself (e.g., /msg/def/nmea/GGA, or /msg/jps/rtk/min/jps/ET).
The message scheduling parameters will be copied from those defined for given message in the message group. Use set command to customize the scheduling parameters if required.
Examples
Creating Files
Example: Create a new file with an automatically generated name and assign it to the current logfile A (/cur/file/a). Either of:
create create,:a
Example: Create a new log-file with the name “my_file”. Either of:
create,/log/my_file:a create,my_file
Example: Create files “file1” and “file2”, and assign them to /cur/file/a and /cur/file/b:
create,file1:a; create,file2:b

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands create
Creating Message Specifiers
Example: Add /msg/jps/ET messages to the default set of messages:
create,/msg/def/jps/ET
Example: Add NMEA GGA message to the default set of messages and force its period and phase to be always 10 and 5, respectively, no matter what values for them will be specified in a em or out command:
create,/msg/def/nmea/GGA set,/msg/def/nmea/GGA,{10,5,,0×30}

GREIS

www.javad.com

2.3.8 remove

RECEIVER INPUT LANGUAGE Commands remove

Name
remove remove an object.
Synopsis
Format: remove,object[/] Options: none
Arguments
object object identifier of the object to be removed. If object does not begin with “/”, then “/log/” prefix is automatically inserted before the object prior to executing the command.
/ if present and the object is of type list, remove all the object contents instead of the object itself.
Options
None.
Description
This command removes (deletes) an existing object. No response is generated unless there is an error, or response is forced by the statement identifier. If there is no object specified by object, or if the object can’t be removed, an error is generated. Two kinds of objects could be removed:
1. Files. If the file is one of current log-files, the command will fail and error message will be generated.
2. Message specifiers from message sets.
Examples
Example: Remove the log-file with the name “NAME”. Either of:
remove,/log/NAME remove,NAME
Example: Remove all log-files:
remove,/log/

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands remove
Example: Remove GREIS standard [GA] message from the default set of messages:
remove,/msg/def/jps/GA
Example: Remove all the messages from the default set of messages:
remove,/msg/def/
Example: Remove all the messages from the minimal set of standard GREIS messages suitable for RTK:
remove,/msg/rtk/jps/min/

GREIS

www.javad.com

2.3.9 event

RECEIVER INPUT LANGUAGE Commands event

Name
event generate free-form event.

Synopsis
Format: event,string Options: none

Arguments
string an arbitrary1 string comprising up to 63 characters.

Options
None.

Note: Example:

Description
This command generates a free-form event. No response is generated unless there is an error, or response is forced by the statement identifier.
The given string along with the time of receiving the event command is stored in the receiver in the special event buffer2. The contents of this buffer is output to all the output streams where the standard GREIS message [==](EV) (described on page 131) is enabled.
The free-form event mechanism is intended for the control programs to forward arbitrary text information to post-processing applications without interpreting this information in the receiver. The receiver firmware’s core never generates free-form events on its own, nor does it somehow interpret the information sent through the event commands.
All of the strings starting with the underscore character (ASCII 0x5F) are reserved for JAVAD GNSS applications. Care should be taken that such strings are not used with the event commands unless you can’t accomplish your task otherwise or intend to cooperate with some JAVAD GNSS software. In the latter case please refer to detailed description of free-form events reserved for JAVAD GNSS applications in the “Frame Format for Free-Form Events” guide, available from http://www.javad.com.
Generate a free-form event containing the string “Info1″:
event,Info1

GREIS

1. Recall that if a string contains any of the characters reserved for the receiver input language, you should enclose this string in double quotes.
2. The current firmware provides a buffer large enough to store up to sixteen 64 byte free-form events.

www.javad.com

RECEIVER INPUT LANGUAGE Commands event
Example: Generate a free-form event containing reserved characters:
event,”EVENT{DATA,SENT}”
Example: Generate free-form event reserved for JAVAD GNSS application software (this event notifies post-processing application about change of dynamics):
event,”_DYN=STATIC”
Example: Generate a free-form with empty string:
event,””
Example: Generate a few free-form events and get back the [==](EV) messages (in the contents of [==] messages non-printable bytes are replaced with dots in the example):
em,,jps/EV %accepted% event,”some string” RE00A%accepted% ==011…..some_string. %1% event,1; %2% event,2 RE003%1% RE003%2% ==007…..1. ==007…..2. dm,,jps/EV

GREIS

www.javad.com

2.3.10 get

RECEIVER INPUT LANGUAGE Commands get

Name
get start retrieving of file contents using DTP1.

Synopsis
Format: get,object[,offset] Options: {timeout,block_size,period,phase,attempts}

Arguments
object object identifier of the file to be retrieved. If object does not begin with “/”, then “/log/” prefix is automatically inserted before the object prior to executing the command. If the object does not exist or can’t be retrieved, an error message is generated.
offset offset in bytes from the beginning of the file at which to start retrieving. If omitted, 0 is assumed.

Options

Table 2-5. get options summary

Name

Type

Values

timeout

integer [0…86400], seconds

block_size integer [1…163841]

period

float [0…86400), seconds

phase

float [0…86400), seconds

attempts integer [-257…100] 1. 2048 for receivers that don’t support TCP or USB.

Default
10 512 0 0 10

timeout the timeout for DTP. block_size the size of a DTP data block. period the output period for filtering (see below). phase the output phase for filtering (see below). attempts different meaning depending on the range, as follows:

1. See “Data Transfer Protocol” on page 580.

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands get
[1…100] maximum number of attempts DTP transmitter will take to send single block. When set to 1, special streaming mode is activated (see below).
0 rather than starting DTP, output raw contents of the object. [-256…-1] rather than starting DTP, output the contents of the object wrapped into
[>>] messages.
-257 rather than starting DTP, output the contents of the object wrapped into [RE] messages.
Description
This command starts retrieving of a file into the host computer using the Data Transfer Protocol (DTP) or raw output format. No response is generated unless there is an error, or response is forced by the statement identifier.
When in DTP mode, after the get command succeeds, the DTP transmitter is started on the receiver and waits for DTP receiver to be run on the host. Therefore, to actually retrieve any data, one needs DTP receiver implementation on the host.
The optional offset argument allows host to implement support for resuming of interrupted data transfer. Note that seeking to a large offset may require rather long time to perform in the receiver. To correctly implement resumption in the host software, force receiver response to the get command using statement identifier and wait for the reply from the receiver before running DTP on the host. This method takes advantage of the fact that receiver replies to the get command after the seek is performed.
When the attempts option is set to 1, the DTP transmitter will be put into so-called streaming mode. In this mode, after receiving the first NACK from the DTP receiver, the DTP transmitter will stream data blocks without waiting for ACKs from the DTP receiver, and the transmitter will immediately abort data transfer should NACK be received. This approach allows significantly faster data transfer over reliable connections having high latencies (such as TCP) or relatively high direction switch overhead (such as USB). Correctly implemented receiving part of the protocol does not require any special care to support this method.
When the period option is non-zero special filtering mode is activated. For example, it allows to download 1Hz data from a file that was written using 10Hz update rate. Specifically, the receiver will send the data only for the epochs where receiver time modulo one day (Tr) satisfies the following equation:
Tr {mod period} = phase
To achieve this, receiver parses the contents of the file and filters-out some of the messages. Note that implementation of resumption of interrupted download is very hard if

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands get

not impossible in this case due to the fact that the host has no idea at what offset of the receiver file the download has been interrupted.
Any of the types of transfer could be aborted by data receiving end by sending any DTP error symbol (e.g., ASCII ‘#’).
When transferring data in [RE] messages, the value of block_size will determine maximum size of data payload for every [RE] message (limited also by the size of internal firmware buffer). As usual, every [RE] message will be started with the command ID (if any).
When transferring data in [>>] messages, the value of the attempts option will determine the id field of the [>>] messages as follows:
id = -1 – attempts
and the value of “block_size” will determine maximum size of data payload for every [>>] message (limited also by the size of internal firmware buffer).
The next byte after id (the first byte of the data field) in the [>>] message will then be sequence character starting with ASCII symbol 0 and being incremented modulo 64 for every message, resulting in the sequence of ASCII symbols from 0 to o, inclusive:
seq = 0 loop { seq_char = ‘0’ + (seq++ % 64) }
The sequence character allows receiving end to detect loss of [>>] message(s) in the sequence.
Then the object data payload of up to block_size bytes will follow, and then the check sum, according to the format of [>>] message.
Successful output in the wrapped mode will always be finalized by [>>] message with no data payload, to allow receiving end to reliably determine the end of transfer.

Examples

Example: Start retrieving the contents of the file NAME using DTP. Either of:

Example:

get,/log/NAME get,NAME
Start retrieving the contents of the file NAME starting from byte number 3870034 (counting bytes from zero). Expect rather long time to pass between the command and the reply:

%%get,NAME,3870034 RE002%%

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands get
Example: Start retrieving the contents of the file my_logfile starting from byte 3000 using timeout 50 seconds and block size of 8192 bytes:
get,my_logfile:{50,8192},3000
Example: Start retrieving the contents of the file NAME filtering out epochs so that the resulting retrieved file would be 0.1Hz data:
get,NAME:{,,10}
Example: Start retrieving the contents of the file NAME using streaming mode (attempts option set to 1):
get,NAME:{,,,,1}
Example: Send contents of the file NAME wrapped into [>>] messages with id 61 (being ASCII symbol ‘=’), using up to 128 bytes of data per message:
get,NAME:{,128,,,-62}
Example: Send contents of the file NAME wrapped into [RE] messages using up to 190 bytes of data per message, prepended by %MY_ID%:
%MY_ID%get,NAME:{,190,,,-257}

GREIS

www.javad.com

2.3.11 put

RECEIVER INPUT LANGUAGE Commands put

Name
put start file uploading using DTP1.

Synopsis
Format: put,object[,offset] Options: {timeout, block_size}

Arguments
object object identifier of the file to write data to. If object does not begin with “/”, then “/log/” prefix is automatically inserted before the object prior to executing the command.
offset offset in bytes from the beginning of the file at which to start writing. If omitted, 0 is assumed.

Options

Table 2-6. put options summary

Name

Type

Values

Default

timeout

integer [0…86400], seconds 10

block_size integer [1…163841]

512

1. 2048 for receivers that don’t support TCP or USB.

timeout the timeout for DTP. block_size the size of a DTP data block.

Description
This command starts uploading of data from host computer into a file in the receiver using the Data Transfer Protocol (DTP). No response is generated unless there is an error, or response is forced by the statement identifier.
After the put command succeeds, the DTP receiver is started on the receiver and waits for DTP transmitter to be run on the host. Therefore, to actually upload any data, one needs DTP transmitter implementation on the host.

1. See “Data Transfer Protocol” on page 580.

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands put

The optional offset argument allows host to implement support for resuming of interrupted data transfer. A non-zero offset value allows host to request appending data to the end of an existing file of matching size.
If offset is 0 and the file object doesn’t exist, receiver will try to create and open for writing a new file with the name defined by object. In this case the command will fail if there already exist a file with given name.
If offset is greater than 0, and there is a file object, and the file size is equal to the value of offset, then the put command will open the file object for append. In this case the command will fail if there is no existing file with given name or if the size of the existing file doesn’t match those specified by offset.

Examples

Example: Start data uploading to a fresh file “NAME” using DTP. Either of:

Example:

put,/log/NAME put,NAME
Start uploading data and append them to existing file “NAME”. Use default DTP timeout and DTP block size 4096 bytes. Get the size of the file before starting the upload (note that the file size is required on host anyway so that it can skip this number of bytes from its source data file):

Example:

print,/log/NAME&size RE008 3870034 put,/log/NAME:{,4096},3870034
Start data uploading to a fresh file “my_logfile” using timeout 50 seconds and block size of 8192 bytes:

put,my_logfile:{50,8192}

GREIS

www.javad.com

2.3.12 fld

RECEIVER INPUT LANGUAGE Commands fld

Name
fld firmware loading.

Synopsis
Format: fld,id,object Options: {timeout, block_size}

Arguments
id string containing the receiver electronic ID1. If specified ID does not correspond to the actual electronic ID of the receiver, the command will fail and produce error message.
object object identifier of the source of the firmware to be loaded. Either the name of receiver file, or the name of an input port. When it’s the name of input port, either /cur/term or actual name of the current port should be given, otherwise error will be reported.

Options

Table 2-7. fld options summary

Name

Type

Values

timeout

integer [0…86400], seconds

block_size integer [1…163841] 1. 2048 for receivers that don’t support TCP or USB.

Default
10 512

timeout the timeout for DTP. block_size the size of a DTP data block.

Description
This command loads firmware from specified object into receiver and then resets the receiver. No response is generated unless there is an error, or response is forced by the statement identifier.

1. The ID could be obtained using print,/par/rcv/id command.

GREIS

www.javad.com

RECEIVER INPUT LANGUAGE Commands fld

Warning:

Should a power failure or fatal interruption of firmware transfer through a port occur during the loading, the receiver may go into a semi-working state where only firmware loading through RS-232 ports using “power-on capture” method is possible.
If the object designates an existing file1, the receiver will first check whether the file contains valid firmware for the receiver (it takes a number of seconds to complete). If the check succeeds, the receiver will load the firmware and then perform self-reset. Note that the reply to the command (if any) will be sent after the check is performed but before firmware loading begins. The timeout and block_size options are ignored in this case.
If object designates an input stream, the command will send the reply (if any) and then start DTP receiver that will wait for DTP transmitter to be run on the host. Therefore, to actually upload the firmware, one needs DTP transmitter implementation on the host. Self reset (reboot) will be performed by the receiver after the loading successfully completes or is interrupted.

Examples
Example: Load firmware from the file “firmware.ldp” into receiver with electronic ID 123456789AB. Expect a few seconds to pass between sending the command and receiving reply, while receiver checks the file for firmware validity:
%%fld,123456789AB,/log/firmware.ldp RE002%%
Example: Start firmware uploading from the USB port using block size 16384 bytes and timeout 20 seconds. Obtain electronic ID before issuing the command:
print,rcv/id RE00C 8PZFM10IL8G fld,8PZFM10IL8G,/dev/usb/a:{20,16384}

GREIS

1. It is expected that the file containing the firmware is uploaded to the receiver in advance, e.g., using the put command.

www.javad.com

RECEIVER INPUT LANGUAGE Commands fld

GREIS

www.javad.com

Chapter 3
RECEIVER MESSAGES

This chapter describes general format of GREIS standard messages as well as particular formats of all the predefined messages. Besides the GREIS standard messages, receiver supports quite a few messages of different formats, such as NMEA or BINEX. The formats of those “foreign” messages are described at the end of this chapter.
3.1 Conventions
3.1.1 Format Specifications
To describe some format as a sequence of bytes1 in a compact form, we define formats for a few primary field types and then use notation close to those used in the C programming language to build definitions of more complex formats:
struct NAME {LENGTH} { TYPE FIELD[COUNT]; // DESCRIPTION … TYPE FIELD[COUNT]; // DESCRIPTION
};
where:
NAME the name assigned to this format. It could be used in other format definitions as the TYPE of a field.
LENGTH the length in bytes of entire sequence. For a fixed length format, it is a number, for a variable length message, it may be either an arithmetic expression depending on some other variable parameters or just the string var.
TYPE FIELD[COUNT] field descriptor. It describes a sequence of COUNT elements of the same TYPE which is assigned the name FIELD. The TYPE could be either one of the primary field types described below, or a NAME of another format. When [COUNT] is absent, the field consists of exactly one element. When COUNT is absent (i.e., there are only empty square brackets, []), it means that the field consists of unspecified number of elements.

GREIS

1. In the context of this chapter, “byte” means 8-bit entity. Least significant bit of a byte has index zero.

www.javad.com

RECEIVER MESSAGES Conventions
Format Specifications

DESCRIPTION description of the field along with its measurement units and allowed range of values, where appropriate. Measurement units are surrounded by square brackets.
The following primary field types are defined:

Table 3-1. Primary Field Types

Type Name

Meaning

Length in Bytes

ASCII character

signed integer

unsigned integer

IEEE-754 single precision floating point

IEEE-754 double precision floating point

str

zero-terminated sequence of ASCII characters variable

To entirely define particular format, we also have to specify bytes order in the primary non-aggregate fields that are multi-byte (i2, i4, u2, u4, f4, f8). For GREIS messages this order is defined by the [MF] message, see “[MF] Messages Format” on page 74 for details.
Using the above definitions it’s possible to (recursively) expand any format specification to corresponding sequence of bytes. For example, the format
struct Example {9} { u1 n1; f4 n2; i2 n3[2];
};
expands to the following sequence of bytes assuming least significant byte first (LSB) order:
n1[0](0), n2[0](0),n2[0](1),n2[0](2),n2[0](3), n3[0](0),n3[0](1),n3[1](0),n3[1](1)

GREIS

www.javad.com

GREIS

RECEIVER MESSAGES Standard Message Stream
Special Values
and to the following sequence of bytes assuming most significant byte first (MSB) order:
n1[0](0), n2[0](3)n2[0](2)n2[0](1)n2[0](0) n3[0](1)n3[0](0)n3[1](1)n3[1](0)
where x[i](j) designates j-th byte (byte #0 being least significant one) of an i-th element of the field x.

3.1.2 Special Values

For binary messages, some of their integer and floating point fields may contain special values, which are used instead of actual data when no data for the field are available. Binary fields for which checking for special values is required during data extraction are marked with the exclamation mark, “!” in the first column of the field definition.
The following table defines special values for various data field types:

Table 3-2. Special Values for Fields

Field Type
i1 u1 i2 u2 i4 u4 f4 f8

Special Value
127 255 32767 65535 2147483647 4294967295 quiet NaN quiet NaN

HEX Representation
7F FF 7FFF FFFF 7FFF_FFFF FFFF_FFFF 7FC0_0000 7FF8_0000_0000_0000

3.2 Standard Message Stream

Standard GREIS message stream is a sequence of at most two kinds of messages, GREIS standard messages, and non-standard text messages.
Most important and widely used kind of messages is a rich set of GREIS standard messages. Their general format is carefully designed to allow for both binary and text mes-

www.javad.com

RECEIVER MESSAGES General Format of Messages
Standard Messages
sages, and to make it possible for applications to efficiently skip the messages the application doesn’t know about or is not interested in.
Support for non-standard text messages, that should still adhere to the format defined for them in this manual, makes it possible to mix GREIS standard messages with messages of some other formats in the standard GREIS data stream. An example of such a format are NMEA messages.
Non-standard text messages of a special case, the messages that contain only ASCII <CR> and/or <LF> characters, are inserted by the message formatting engine in the receiver between the GREIS standard messages to make the resulting message stream more human-readable when it is sent to a terminal or generic text viewer or editor application.
Besides GREIS standard messages and non-standard text messages, JAVAD GNSS receivers typically support plenty of other formats (e.g., RTCM, BINEX, CMR). However, those formats are incompatible with the format of standard GREIS message stream. Should a stream contain messages of those formats, it can’t be called GREIS standard message stream anymore, and can’t be parsed by the same rules as the standard stream.1

3.3 General Format of Messages

3.3.1 Standard Messages

The format of every standard message is as follows:

struct StdMessage {var} {

a1 id[2];

// Identifier

a1 length[3];

// Hexadecimal body length, [000…FFF]

u1 body[length]; // Body

};

Each standard message begins with the unique message identifier comprising two ASCII characters. Any characters from the subset “0” through “~” (i.e., decimal ASCII codes in the range of [48…126]) are allowed in identifier.

GREIS

1. In fact, the format of GREIS standard messages is so flexible that it can incorporate any data stream into the standard GREIS data stream, but then the original incompatible stream should be wrapped into a sequence of special GREIS messages. The predefined message with identifier “>>” serves this purpose.

www.javad.com

RECEIVER MESSAGES General Format of Messages
Non-standard Text Messages
Message identifier is followed by the length of message body field. This field, which comprises three upper-case hexadecimal digits, specifies the length of the message body in bytes. Thus the maximum message body length is 4095 (0xFFF) bytes.
Message body follows immediately after the length field and contains exactly the number of bytes specified by the length field. There are no restrictions on the contents of the message body implied by the general format. The format of the message body in a message is implicitly defined by the message identifier. Formats of message bodies of all the predefined messages

3.3.2 Non-standard Text Messages

The format of non-standard text messages is as follows:

struct NonStdTextMessage {var} {

a1 id;

// Identifier, [!…/]

a1 body[];

// Body of arbitrary length, [0…)

a1 eom;

// End of message (<CR> or <LF>)

};

Message identifier is any character in the range [!… /] (decimal ASCII codes in the range [33…47]). Message identifier is optional. If absent, the message body should have length zero (i.e., should be absent as well).

Message body is a sequence of ASCII characters except <CR> (decimal code 13) and <LF> (decimal code 10) characters. No limitation on the body length is imposed by the format.

The end of message marker is either <CR> or <LF> character.

Note that the format allows for non-standard messages comprising only CR or LF characters. This feature allows to make standard GREIS message streams look more humanreadable when outputting data to a general-purpose terminal or viewing with generic text viewer or editor.

One of the non-standard text message identifiers, the character “$”, is already reserved as the identifier for standard NMEA messages. No other non-standard text messages should use the “$” as identifier.

3.3.3 Parsing Message Stream
In this section, you will find some hints and tips on how to write code intended to parse a GREIS receiver’s message streams. Although we are not going to discuss this subject in detail in this reference manual, we’d like to emphasize here that the standard message

GREIS

www.javad.com

RECEIVER MESSAGES General Format of Messages
Parsing Message Stream
format will allow you to effectively process/parse nearly any GREIS message stream you may encounter in practice.

Note:

Synchronization
When parsing a message stream, you first need to find nearest message boundary. This is what is usually called “synchronization”. Message synchronization is carried out when parsing is started or when synchronization is lost due to an error in the data stream. In fact, to simplify the algorithm, you may consider that you are already synchronized when you start to parse the data stream. If it happens that it’s not indeed the case, the parsing error should occur. You then skip one character from the input stream and pretend you are synchronized again. Such approach effectively eliminates synchronization task as a separate part of the parsing algorithm.
Due to the fact that the errors rate in a reasonably useful data stream should be rather low, the synchronization shouldn’t be a frequent task. In addition, the GREIS data stream typically consists of rather short messages, so the distance to the nearest message boundary is typically small. Taking into account these considerations, there is no requirement for synchronization algorithm to be very fast.

Note:

Skipping to the Next Message
Having the length in the general format of the standard GREIS messages allows you to easily ignore messages without knowing the format of their body. We indeed strongly recommend writing parsers so that they do skip unknown messages.
To go from the current message to the next one, take the following steps:
1. Assume the current message starts at position “N”. Determine the current message length (decode characters ## N+2, N+3, N+4). Assume the message length is equal to L. Skip the first L+5 characters starting from position “N”.
2. Skip all of <CR> and <LF> characters (if any).
Strictly speaking, we do not recommend that you use in your parsing code any apriori information about the sizes and the contents of the message bodies. If you respect this recommendation, you will not have trouble with the parsing program should some of the messages be changed.
The rules and hints on parsing of message bodies of the standard predefined GREIS messages are discussed later in “Parsing Message Bodies” on page 67.

GREIS

www.javad.com

GREIS

RECEIVER MESSAGES Standard Predefined Messages
Parsing Message Bodies
3.4 Standard Predefined Messages
In this section we will familiarize the reader with the predefined set of standard GREIS messages. When referring to a message with the identifier XX, we use the notation [XX]. While most messages are called by their message identifier in GREIS, some of them, specifically those that have non-alphanumeric identifiers, have names that are different. For such messages the notation [XX](NN) is used, where XX is message identifier, and NN is message name to be used in the GREIS commands. For example the message [~~](RT) has header “~~” and is called /msg/jps/RT in GREIS commands.
This section defines the formats of the bodies for all the standard predefined messages. Bear in mind that in a data stream every message has a standard header defined by the general format as well.
3.4.1 Parsing Message Bodies
Allowed Format Extensions
Formats of binary messages having fixed message size allow to add more data fields in the future. New fields are allowed to be inserted only at the end of message body just before the checksum field (if any). Such modifications to the message bodies are considered to be format extensions, not incompatible changes.
Though standard GREIS text messages aren’t messages with fixed message size, new fields may still appear in these messages in the future. New fields can be either inserted at the end of an existing text message just before the checksum field, or immediately before any right-hand brace (}). For example, a message that is currently read as:
…1,{21,22},3,@CS
can be later extended to
…1,{2.1,2.2,2.3},3,4,@CS
where two additional fields, “2.3” and “4”, were added.
Implement your parsing algorithms taking into account the following rules to make them work even with future format extensions:
1. Don’t assume that the size of message body of the received message should exactly match specific size defined in this document. Only if the message is too short does it mean you can’t use its contents. If the message is longer than expected, just ignore the excess data.
2. Address the checksum field relative to the end of the message body.

www.javad.com

RECEIVER MESSAGES Standard Predefined Messages
General Notes
3. Address other data fields relative to the beginning of the message body. 4. Take into consideration the above rule for extending of text messages when
writing data extractors for text messages.
Checksums
After a message has been extracted from the data stream using techniques described in the “Parsing Message Stream” on page 65, and the message identifier appears to be one of those the application is interested in, the message body should be parsed to extract the data. Before extracting the contents, the message checksum should be calculated and compared against the checksum contained in the message.
Most of predefined messages contain checksum. Checksum is computed using both the message header (i.e., “message identifier” plus “the length of message body”) and the body itself. See “Computing Checksums” on page 579 for more information on checksum computation.
The checksum is always put at the very end of the message body. If a message’s structure is modified by adding a new data field(s), the new data fields will be added before the checksum field. This explains why it is recommended to address the checksum field relative to the end of the message body.
3.4.2 General Notes
Time Scales
There are five time scales your receiver may handle:
Tr receiver time Tg GPS system time Tu UTC(USNO). Universal Coordinated Time supported by the U.S. Naval Obser-
vatory. Tn GLONASS system time. Ts UTC(SU). Universal Coordinated Time supported by the State Time and Fre-
quency Service, Russia.
“Receiver time” is the only time grid that is always available in your receiver (i.e., the other time grids from the above list may or may not be currently available).
In fact, JAVAD GNSS receiver always synchronizes its receiver time with one of the four global time scales: GPS time, UTC(USNO), GLONASS time, or UTC(SU). The

GREIS

www.javad.com

GREIS

RECEIVER MESSAGES Standard Predefined Messages
General Notes
time grid thus selected is referred to as “receiver reference time” (Trr) hereafter in this section1.
Different time systems may have different time notations (formats) associated with them (e.g., for GPS time, we use such terms as “week number”, “time of week”, etc.). Note, however, that the “receiver time” representation will not depend on the selected receiver reference time and is always represented as receiver date and time of day.
Most of the predefined messages don’t contain reference time information inside. In our view, it would be excessive to use one and the same time tag with all of the many messages the receiver generates at the current epoch. When outputting receiver information available for the current epoch, you usually get various messages. Instead of supplying each of them with an individual time tag data field, we use a special message that carries receiver time information common for these messages. This message is called “Receiver Time” and has the identifier [~~].
There is, however, a mode of operation, called RTK delayed mode, when at a given epoch receiver may produce solution referenced to some other epoch in the past. To provide time tag for such solution, special Solution Time-Tag [ST] message is used. In fact this message provides the correct time tag for a solution in all modes of operations, though in most modes it has exactly the same time as [~~].
There are some other messages having a time tag data field. Those are messages that contain information that appears independently on the receiver epoch grid. An example of such a message is “Event” [==].
Delimiters
In fact, “Receiver Time” message is supposed to precede all of the other messages generated at the current epoch thus delimiting messages corresponding to different epochs. From a formal point of view, it is up to the user to define the order of messages in the output stream. However, care should be taken to ensure that the order in which messages are written into the output stream does not break the “epoch synchronization”, which is very essential for post-processing the logged data with JAVAD GNSS software packages. For more details on the default set of messages see “Message Sets” on page 562.
For real-time applications it’s essential to determine the end of epoch as soon as possible. For such applications just delimiting epochs by a “start of epoch” marker is not convenient. We suggest to use the “Epoch Time” [::](ET) message as the “end of epoch” marker. This message contains the same time of day field that is found in the “Receiver Time” message that allows for better integrity checking. The idea is to compare time tag

1. In the current receiver firmware the receiver reference time is either GPS or GLONASS system time, refer to /par/raw/time/ref on page 220

www.javad.com

GREIS

RECEIVER MESSAGES Standard Predefined Messages
General Notes
from [::] message against the time tag from corresponding [~~] message. Mismatched tags are an indication of broken epoch.
You will notice that most of the messages have identifiers comprising only digits and/or English letters. In fact, “Receiver Time” [~~] is the only message whose identifier uses the character “~”. It makes sense as the [~~] message plays a very important part serving as an epoch delimiter. Thus there are special precautions in order to minimize the probability of losing this key message. Similarly, the identifier of the “Event” ([==]) message, too, must be as distinctive as possible since application software may use free-form events just as delimiters.
The idea of using “highly distinctive” identifiers for the messages that serve as delimiters is very clear. Should a message’s checksum be wrong, just check its identifier. If neither of the identifier’s characters coincides with “~”, then it is very unlikely that this is a corrupted [~~] message. Therefore, you needn’t skip to the next [~~] message in this case.
On the other hand, if a message has the correct checksum yet one of the identifier characters is “~”, then it would be safer to treat this message as a corrupted [~~] message. In this case skip to the next [~~] message.

Solution Types

The field “solType” used in many of the predefined messages designates the type of corresponding solution and may have the following values:
Table 3-3. Solution Types

Value

Meaning

Documents / Resources

JAVAD GREIS GNSS Receiver External Interface [pdf] User Guide
GREIS GNSS Receiver External Interface, GREIS, GNSS Receiver External Interface, Receiver External Interface, External Interface, Interface

References

User Manual

JAVAD GREIS GNSS Receiver External Interface

Specifications

Product Information

Introduction

Receiver Input Language

Receiver Messages

FAQs

Documents / Resources

References

Leave a comment

Cancel reply