TSC / CCS / MCS

Test - Integrate - Control

Telemetry Simulation

It’s now possible to simulate telemetry packets directly within TSC. This can be useful for
  • Testing your MIB content,
  • Acquiring TM data from a non packet source, such as a hardware device, and then processing as TM
  • Generating SCOE (special check out equipment) telemetry if TSC is used as a SCOE controller.
The command “processtmpacket” has several options for simulating TM.

In its most basic option, the command allows you to publish a block of binary data, and it will then be processed exactly as though it had arrived as a telemetry packet. This is intended for the use case where you might have received this data block from a hardware device or external software interface that is not directly available via a data source plugin

It’s then possible to “pre-identify” the packet, by specifying the SPID to use. If you specify the SPID, then TM identification is skipped. When extracting parameters from the data, your specified SPID will be used directly.

(Note that if you do this, it’s up to you to make sure the data is consistent with the SPID you specify. There will be no dire consequences if the SPID is not consistent with the data, but the packet properties shown on the data will be determined from the SPID instead of from the data)

It’s then possible to optionally request a packet header to be generated, and prepended to your data. The packet header will be generated consistent with your specified SPID (APID type subtype), configured from the MIB. If the MIB specifies a DFH then this will be added, and if the MIB specifies that a PEC should be calculated then this will also be added to the packet data. This feature is intended for the case where you have a block of data that you want to change directly into a TM packet. It may also be useful for the case where you want to send such a packet to somebody else (e.g. another SCOE)

It’s then possible to optionally request a packet body to be generated and appended to your data. The packet body will be generated according to the parameter definitions for your specified SPID. The parameter raw values will be injected into the packet using the current raw values of those parameters stored in TSC.

Furthermore you can then specify an array of raw and/or engineering values that will be injected into the generated packet in preference to the current parameter values stored in TSC. Any parameters in the current packet specified in your arrays will be taken from the array value. With an array of raw values, the raw values are directly injected at the right location in the packet. If desired an additional array of engineering values can be specified. In this case, the engineering value will be inverse-calibrated before inserting in the packet

Note that not all types of calibration curve can be inverted : this feature is currently restricted to points curves (CAF/CAP tables). Further, if the curve is not monotonic, then there are multiple inverse calibration results! - you will simply see the interpolated raw value corresponding to the first found range of your engineering value.

The packet body size will be dynamically scaled to fit all the desired values in the TM definition, the packet header length and PEC will be set afterwards. For bit- and byte- string parameter types, Static (PFC=n) and Variable length parameter (PFC=0) sizes can also be injected, with dynamic creation of the length field