USER’S MANUAL__________________________________________________________________
418 _________________________________________________________________ M211322EN-D
D.12 Determining CPI's and Ray Boundaries
D.13 Using the RVP TimeSeries API
The RVP TimeSeries API is the fundamental interface through which (I,Q)
data are made available to all application code, which requires them. This
API is central to the design and operation of the RVP8 itself, and is used
by the parallel compute processes to access incoming timeseries data.
Because the API is used so heavily, the entry points have been reasonably
stable and well debugged since the early days of the RVP8.
The TimeSeries API is provided within a larger collection of RDA support
services that are located in rda/rdasubs, with the defining header file
include/rdasubs_lib.h. Refer to the documentation in that header file for
the most recent API definitions. This file is heavily documented for this
purpose. If you have any specific questions, we would be happy to improve
the comments.
D.13.1 Reader and Writer Clients
The Timeseries API is entirely 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. This was
a design goal from the start; readers should be able to come and go willy-
nilly without affecting anything else. 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 happened to look at.
Also, the API is really most valuable in providing random access to the
recent buffered (I,Q) data. Because of the PCI/DMA buffering this is a
pseudo real-time interface, and the data are typically 100–400 ms delayed
from their actual time of arrival. As such, it is not important to be able to
track the leading edge of newly arriving data with any particular precision.
There are about two seconds of data buffered within the Timeseries API;
so checking at 10–20 Hz presents a negligible CPU load, does not risk
losing any data, and matches the PCI/DMA burst transfers.
To Next Page
Loading...
Need help?
General