|
TReK Applications
User Guides
|
This section describes the file used by the Generator application to auto-generate data values based on specific rules. You can create your own file to change the default behavior of the generated data or the file can be autogenerated from any existing packet definition. The following sections include a description of the generator file format and an example.
The generator file is read one line at a time (maximum line size is 10,000 bytes). Any characters after a # is treated as a comment. Keywords are not case sensitive but are generally shown as all uppercase. Checks are performed as the file is read to make sure each keyword has the appropriate number and type of arguments available. Additional checks may occur later depending on the keyword. Each keyword and the required arguments are explained below. The overall structure of the file will be described later.
Note: Strings with spaces are supported with double quotes.
FIXED – Describes a fixed value that requires two arguments:
FIXED <name> <value>
| • | <name> - The name for this value. The name must be unique for all values (not just fixed values). The name is used as a reference to apply the value to an actual parameter name. |
| • | <value> - The value to use. Since this could really be any data type no type checks are made here. When the value is applied, type checks are performed (e.g., if you used the value for an unsigned integer, a check makes sure only digits appear). |
SYSTIME – Describes a system time that requires two arguments:
SYSTIME <name> <offset>
| • | <name> - The name for this value. The name must be unique for all values. |
| • | <offset> - This is the offset (+/-) to the system time to be used. If you just want system time a value of 0 should be used. The value is read as a floating point number. |
RAMP – Describes a ramping value that requires five arguments:
RAMP <name> <start> <delta> <min> <max>
| • | <name> - The name for this value. The name must be unique for all values. |
| • | <start> - The start value. This value is confirmed to be numeric here, but additional checks would be made if applied to an integer. The same type of checks are made for each of the other values. |
| • | <delta> - The value to increment after each use. Can be positive or negative. |
| • | <min> - The minimum value for the ramp. The start will be adjusted to this value if the start value is less than the minimum. |
| • | <max> - The maximum value for the ramp. The start will be adjusted to this value if the start value is greater than the maximum. |
RANDOM – Describes a random value. Requires three arguments.
RANDOM <name> <min> <max>
| • | <name> - The name for this value. The name must be unique for all values. |
| • | <min> - The minimum value that will be generated. First check is that the value is numeric, but additional checks are performed later if applied to an integer. |
| • | <max> - The maximum value that will be generated. |
ROTATE – Values that are rotated through. Once all values are used, the rotation starts over. Requires at least 3 arguments.
ROTATE <name> <value1> <value2>…<value n>
| • | <name> - The name for this value. The name must be unique for all values. |
| • | <value[n]> - The values to rotate through. No checks made here on the values, but checks will be made as appropriate (e.g., if applied to a numeric parameter). |
OVERWRITE – Provides a means of overwriting the generated data with different patterns. Overwrites are applied after the packet is built. If overwrites are applied to the same place in the packet, the order the overwrites are made is not guaranteed. There are five arguments required.
OVERWRITE <type> <name> <start> <len> <data>
| • | <type> - The type of overwrite. Must be one of the following: | ||||||
| |||||||
| • | <name> - The name of the overwrite. This namespace is unique to overwrites so a value name for a parameter could be reused if desired. | ||||||
| • | <start> - The start location of the overwrite in bits. Start is from the beginning of the entire packet. | ||||||
| • | <len> - The length of the overwrite in bits. | ||||||
| • | <data> - The data to overwrite (read based on the <type>). Checks are performed as appropriate (e.g., to make sure data is binary and the number of bits defined match up with the length specified). |
OW_START – Applies the overwrite. Overwrite will be applied until a OW_STOP is received. Requires one argument:
OW_START <name>
| • | <name> - The name from the OVERWRITE directive. It will fail if one doesn’t exist with this name. |
OW_STOP – Stops applying the overwrite. Requires one argument:
OW_STOP <name>
| • | <name> - The name from the OVERWRITE directive. |
SET – Sets a parameter to use a generator value. You can use the same generator multiple times, but each parameter will get its own copy. Requires two arguments:
SET <param> <value>
| • | <param> - The parameter name from the Packet object. |
| • | <value> - The <name> from one of the following directives: FIXED, RAMP, RANDOM, ROTATE, or SYSTIME. |
AT – Defines the beginning of an “AT group”. All lines after this are interpreted as part of this AT group until another AT directive is found. Values are applied as part of the AT group using the SET, OW_START, and OW_STOP keywords. Requires two arguments:
AT <type> <value>
| • | <type> - Either TIME or PKT. |
| • | <value> - If the <type> is TIME, value is interpreted as a floating-point value indicating the number of seconds after start to apply the change. If the <type> is PKT, value is interpreted as an unsigned integer indicating after how many packets to apply the change. |
This section provides an example of a generator file. The example shown below is the autogenerated file version of APID 314 which is part of the Metadata Tutorial.
# CP=Version has value defined in packet definition. # CP=Type has value defined in packet definition. # CP=SecHdrFlag has value defined in packet definition. # CP=APID is a packet attribute and will not have a value defined. # CP=SeqFlags has value defined in packet definition. # CP=SeqCount is a packet attribute and will not have a value defined. # CP=PktLength is a packet attribute and will not have a value defined. # CS=Time is a packet attribute and will not have a value defined. # CS=TimeID has value defined in packet definition. # CS=CheckwordIn has value defined in packet definition. # CS=ZOE has value defined in packet definition. # CS=PktType has value defined in packet definition. # CS=VersionID has value defined in packet definition. # CS=DCCounter has value defined in packet definition. FIXED UINT_16Value 0 FIXED INT_32Value 0 RANDOM FEEE_64Value -5.0 5.0 FIXED SUND_80Value 00010203040506070809 AT TIME 0 SET UINT_16 UINT_16Value SET INT_32 INT_32Value SET FEEE_64 FEEE_64Value SET SUND_80 SUND_80Value |
The generator file is by convention divided into two sections, but the keywords do allow more flexibility. The first section is the definition of the parameter values. The autogenerated values are based on the datatype and are likely something you will want to change. The values are defined by the FIXED, RANDOM, RAMP, ROTATE, and SYSTIME keywords described in the previous section.
The second section is where each parameter in a packet gets assigned a value. The AT group defines when to apply the value. Autogenerated files will always have an AT group defined for time zero (AT TIME 0) that assigned the defaults to each parameter. You can add more parameter values and assign them either in the default AT group or create new AT groups.
A few examples may help explain the concepts. The examples will only have the new content, but the complete file can be found after the examples.
Example 1: Add rotating values for an unsigned integer.
The first addition to make is the keyword ROTATE that will define the values to be rotated:
ROTATE MyRotateValue 1 3 5 7 9
Now you must say when to apply this value. You could change the original SET keyword for parameter UINT_16 in the default AT group to use this value, but we’ll create a new AT group to apply it later.
AT TIME 10.5
SET UINT_16 MyRotateValue
This will change how the UINT_16 value is generated after 10.5 seconds have passed and will continue to be used unless another AT group changes the value used.
Example 2: Add a ramp value for a signed integer.
The first addition to make is the keyword RAMP that will define how the values will change over time. We’re going to use lowercase for the keyword here since keywords are not case-sensitive.
ramp MyRamper 10 -1 0 100
We’ll apply this value with an AT group based on the packet count. AT groups that are triggered by packet count can be useful if you want to vary the packet rates, but always have the same data in the packet.
AT PKT 30
SET INT_32 MyRamper
After 30 packets are sent the value for INT_32 is changed. If you are sending one packet a second, this would trigger after the first example. If you are sending 10 packets a second, this would trigger before the first example.
Example 3: Overwrite the APID value in the header.
It’s not suggested that you overwrite values used to identify the packet because that will mean the packet won’t be identified, but it is a good example to show the behavior. First let’s define an overwrite. The APID starts at bit 5 and is 11 bits long. The value generated is 314 (in binary 00100111010). Just flipping the last bit is enough (changing the value to 315).
OVERWRITE BIN MyOverwrite 15 1 1
The overwrite is applied as part of the AT group. In this case we are going to only use the overwrite for one packet so we will also create an AT group to remove the overwrite.
AT PKT 10
OW_START MyOverwrite
AT PKT 11
OW_STOP MyOverwrite
If you use this generator file to send packets, the 10th packet will have an APID value of 315. This will show up in the Data application as a new packet and will also cause a sequence error in APID 314.
The complete file (autogenerated contents plus modifications) is shown below.
# CP=Version has value defined in packet definition.
# CP=Type has value defined in packet definition.
# CP=SecHdrFlag has value defined in packet definition.
# CP=APID is a packet attribute and will not have a value defined.
# CP=SeqFlags has value defined in packet definition.
# CP=SeqCount is a packet attribute and will not have a value defined.
# CP=PktLength is a packet attribute and will not have a value defined.
# CS=Time is a packet attribute and will not have a value defined.
# CS=TimeID has value defined in packet definition.
# CS=CheckwordIn has value defined in packet definition.
# CS=ZOE has value defined in packet definition.
# CS=PktType has value defined in packet definition.
# CS=VersionID has value defined in packet definition.
# CS=DCCounter has value defined in packet definition.
FIXED UINT_16Value 0
FIXED INT_32Value 0
RANDOM FEEE_64Value -5.0 5.0
FIXED SUND_80Value 00010203040506070809
ROTATE MyRotateValue 1 3 5 7 9
ramp MyRamper 10 -1 0 100
OVERWRITE BIN MyOverwrite 15 1 1
AT TIME 0
SET UINT_16 UINT_16Value
SET INT_32 INT_32Value
SET FEEE_64 FEEE_64Value
SET SUND_80 SUND_80Value
AT TIME 10.5
SET UINT_16 MyRotateValue
AT PKT 10
OW_START MyOverwrite
AT PKT 11
OW_STOP MyOverwrite
AT PKT 30
SET INT_32 MyRamper |
Every parameter in the packet must have a value before the packet can be generated. The auto-generation feature will populate a text file with default values for every parameter in the packet. The file will be created in the TReK workspace generator_file folder with the name autogen_<packet key>. You can copy this file and rename it to make changes to set values according to your needs.
The first thing to occur prior to sending each packet is to check if there are any changes to be made to how values are generated (AT directives). The order that these changes are made are first by TIME and then by PKT count.
The next thing to happen is all the possible parameters in the packet are updated with another value. For data that is marked FIXED it won’t change at all, but RANDOM, RAMP, and ROTATE values will go to the next value. Note: All values are updated, but there are cases (e.g., formats or counter dependent parameters) where all the parameters may not appear in a packet. This can cause parameter values to seem to ‘skip’ in the resulting data stream.
After all the values are updated, the packet is built. Prior to sending the packet any overwrites are applied to the binary packet data. Once the overwrites are applied, then the packet is sent and the process begins over again.