The ``recv == Device("LTS/RECV/1")`` device controls the RCUs, the LBA antennas, and HBA tiles. Central to its operation are the masks:
- The ``RCU_mask_RW`` attribute is an array of ``bool[N_RCUs]``. It controls which RCUs will actually be configured, when fields referring to RCUs are set. Any RCU for which the mask is False will not be configured when RCU control points are set.
- The ``Ant_mask_RW`` attribute is an array of ``bool[N_RCUs][N_Antennas_per_RCU]``. It controls which antennas will actually be configured, when fields referring to antennas are set. Any antenna for which the mask is False will not be configured when antenna control points are set.
- The ``RCU_mask_RW`` attribute is an array of ``bool[N_RCUs]``. It controls which RCUs will actually be configured, when fields referring to RCUs are set.
- The ``Ant_mask_RW`` attribute is an array of ``bool[N_RCUs][N_Antennas_per_RCU]``. It controls which antennas will actually be configured, when fields referring to antennas are set.
See :ref:`attribute-masks` for how the masks are used.
Typically, ``N_RCUs == 32``, and ``N_Antennas_per_RCU == 3``.
SDP
-----------
The ``sdp == Device("LTS/SDP/1")``` device controls the digital signal processing in SDP, performed by the firmware on the FPGAs on the Uniboards. Central to its operation is the mask:
- The ``TR_fpga_mask_RW`` attribute is an array of ``bool[N_fpgas]``. It controls which FPGAs will actually be configured, when fields referring to FPGAs are set.
See :ref:`attribute-masks` for how the masks are used.
Typically, ``N_fpgas == 16``.
SST and XST
-----------
...
...
@@ -107,53 +120,3 @@ The correct port will automatically be chosen, depending on the given mode. See
The writer can also parse a statistics stream stored in a file, so the stream can be captured and processed later using the writer. Capturing the stream could be done using ``netcat``::
nc localhost 5101 > SST-packets.bin
Performance monitoring and debugging
`````````````````````````````````````
All statistics expose attributes that provide general statistics about the data received. The counters are set to 0 when the device is initialised:
:last_packet_timestamp_R: Timestamp of the last received packets.
:type: ``uint64``
:nof_packets_received_R: Number of UDP packets received.
:type: ``uint64``
:nof_bytes_received_R: Number of bytes received (sum of UDP payload sizes).
:type: ``uint64``
:nof_packets_dropped_R: Number of packets dropped because processing was overloaded.
:type: ``uint64``
:nof_invalid_packets_R: Number of packets dropped because their header is invalid.
:type: ``uint64``
:nof_payload_errors_R: Number of packets marked as having an invalid payload, per FPGA.
:type: ``uint64[N_fpgas]``
:nof_valid_payloads_R: Number of valid packets with valid payloads received, per FPGA.
:type: ``uint64[N_fpgas]``
Note that nominally::
nof_packets_received_R = nof_packets_dropped_R
+ nof_invalid_packets_R
+ sum(nof_payload_errors_R)
+ sum(nof_valid_payloads_R)
The XSTs also expose the raw blocks as they were received from the FPGAs:
:xst_blocks_R: Blocks of crosslet statistics, as received from the FPGA (see below). Each block is easier to interpret after a ``.reshape((12,12,2))``, representing the first & second antenna within the block, and the real/imaginary components.
:type: ``int64[N_blocks][block_size]``
:xst_conjugated_R: Whether the corresponding block contains conjugated data. If so, it must be conjugated again on interpretation.
@@ -13,7 +13,7 @@ To access a device, one creates a ``Device`` object. For example::
recv = Device("LTS/RECV/1")
See :doc:`control` on how and where to execute this code.
See :doc:`../control` on how and where to execute this code.
States
------------
...
...
@@ -50,3 +50,41 @@ The attributes with an:
- ``_R`` suffix are monitoring points, reflecting the state of the hardware, and are thus read-only.
- ``_RW`` suffix are control points, reflecting the desired state of the hardware. They are read-write, where writing requests the hardware to set the specified value. Reading them returns the last requested value.
.. _attribute-masks:
Attribute masks
---------------------
Several devices employ *attribute masks* in order to toggle which elements in their hardware array are actually to be controlled. This construct is necessary as most control points consist of arrays of values that cover all hardware elements. These array control points are always fully sent: it is not possible to update only a single element without uploading the rest. Without a mask, it is impossible to control a subset of the hardware.
The masks only affect *writing* to attributes. Reading attributes (monitoring points) always result in data for all elements in the array.
For example, the ``RCU_mask_RW`` array is the RCU mask in the ``recv`` device. It behaves as follows, when we interact with the ``RCU_LED0_R(W)`` attributes::
