Vaisala RVP900 - RVP901 TxDAC Stand-alone Bench Test

Process Description
tsimport
tsexport
Provide the ability to receive/send time series over a network.
Either a 1000 BaseT (gigabit) or 100 BaseT Ethernet can be used depending on the
typical mode of operation and the competing network trac. For example:
1000 bins * 2 parameters/bin/pulse * 16 bits/parameter *
1000 pulses/sec = 32 Mbit/sec
In the example, 2 parameters/bin/pulse are the I and Q values, which are
represented by 16 bits each
(floating point). For dual polarization systems with two
receiver channels, the data rate would be doubled. The 32 Mbit/sec basic data rate
here would fit comfortably on a dedicated 100 BaseT network, with little or no
competing trac.
The output is through UDP broadcast. This is a very ecient way to transfer data
since there is virtually no overhead as compared to standard TCPIP. The socket ports
are configured so that the tsexport on one system connects to the tsimport on
another system.
See D.4 Installing and Configuring TS Recording (page 393).
RVP900 Processes
Collection of processes that are only present on an RVP900 machine. The important
functions are:
• IQ–Data: writes real time TS to the TS API. These are collected from an IFDR.
• RVP9Proc-n: extracts TS from the TS API and processes the data to obtain the
moments.
To view these processes, use the v command in dspx. A remote archive host is most
likely not from RVP900. In this case, these processes do not exist.
D.3 Using RVP TimeSeries API
The TimeSeries API is the interface through which (I,Q) data are made available to the
application code that requires them.
This API is central to the design and operation of RVP and is used by the parallel computer
processes to access incoming time series data.
The TimeSeries API is provided within a larger collection of RDA support services in rda/
rdasubs. For API definitions, see the header file documentation.
D.3.1
Reader and Writer Clients
The TimeSeries API is stateless and passive from a reader client's point of view. It allows
any number of callers to eavesdrop on the (I,Q) data as they arrive, but there are no control
actions passed back in the other direction.
The reason that an event driven model is not provided is that the API is fundamentally a
single-writer/multiple-reader interface. There is no private state maintained for each reader
client that hooks up to it. As such, the notion of 'notify me when new data are available'
would not be
well-defined, because 'new' would have to be a per-client notion, that is, new
since the last data that each particular client checked.
Appendix D – Time Series Recording
391