@@ -41,10 +41,14 @@ The structure of the DO is presented in :numref:`fig_DO_basic_schematics`.
Structure of the DO
The DO Server is a proxy between Devices and Users Applications. In a single network, there could be one server, multiple users and multiple devices. The applications typically are run on different machines, but it is not a restriction.
The DO Server is a proxy between Devices and Users Applications. In a
single network, there could be one server, multiple users and multiple devices.
The applications typically are run on different machines, but it is not a
restriction.
.. _user_application_intro:
=====================
`User Applications`_
...
...
@@ -53,44 +57,64 @@ The DO Server is a proxy between Devices and Users Applications. In a single net
There are currently two User Applications available:
* GUI --- it is designed to resemble standard oscilloscope.
* testbench --- it is used to test the DO Server and the Device Applications as well as to perform statistical measurements of data acquisition speed and of the precision of the synchronization.
* testbench --- it is used to test the DO Server and the Device Applications
as well as to perform statistical measurements of data acquisition speed and
of the precision of the synchronization.
The User Applications serve the following purposes:
User Applications serve the following purposes:
* Sending the configuration settings
* Collecting and processing the acquisition data
The Device Applications never communicate with the devices directly, always through the DO Server. This allows to hide all the implementation details and to provide a common interface for various types of applications.
The details on how to write User Applications are described in section :ref:`developer_guide`
Device Applications never communicate with the devices directly, always through
the DO Server. This allows to hide all the implementation details and to
provide a common interface for various types of applications.
The details on how to write User Applications are described in
section :ref:`developer_guide`
.. _do_server_intro:
================
`DO Server`_
================
The DO Server is a central unit responsible for managing all the connections, preprocessing the data and providing a common interface for connected applications.
The DO Server is a central unit responsible for managing all the connections,
preprocessing the data and providing a common interface for connected
applications.
.. _device_application_intro:
======================
`Device Application`_
======================
Device applications provide direct access to hardware resources. At the moment the only available devices are ADCs supported by the `adc-lib <https://ohwr.org/project/adc-lib/wikis/home>`_.
Device applications provide direct access to hardware resources. At the moment
the only available devices are ADCs supported by
the `adc-lib <https://ohwr.org/project/adc-lib/wikis/home>`_.
Hardware setup
================
The minimum hardware requirements necessary to demonstrate features of the DO are the following:
The minimum hardware requirements necessary to demonstrate features of the DO
are the following:
* computer with minimum 2 PCIe slots and CentOS 7.6.1810
.. note::
The DO is designed to run each application on a different machine. However, it is possible to run them on the same machine. To make the DO really distributed, the ADC cards should be installed in different locations in different machines. The described hardware setup should serve only as a demonstrator.
The DO is designed to run each application on a different machine. However,
it is possible to run them on the same machine. To make the DO really
distributed, the ADC cards should be installed in different locations in
different machines. The described hardware setup should serve only as a
demonstrator.
.. note::
CentOS 7.6.1810 guaranties that all the drivers will function properly. However, it is possible to use the DO with different OS. In case of machines where the Server and the GUI are run, the Linux version does not matter.
CentOS 7.6.1810 guaranties that all the drivers will function properly.
However, it is possible to use the DO with different OS. In case of
machines where the Server and the GUI are run, the Linux version does not
@@ -98,7 +122,9 @@ The minimum hardware requirements necessary to demonstrate features of the DO ar
.. important::
The DO will work only with SPEC 150T version. Be careful not to purchase standard SPEC 45T version.
The DO will work only with SPEC 150T version. Be careful not to
purchase standard SPEC 45T version.
* 2 `FMC ADC 100M 14b 4cha <https://www.ohwr.org/project/fmc-adc-100m14b4cha/wikis/home>`_ boards
* 2 fibers
* 4 SFP cages
...
...
@@ -117,5 +143,8 @@ The minimum hardware setup of the DO is presented in :numref:`fig_hardware_setup
The SPEC boards together with ADC cards should be installed in PCIe slots of the computer and connected to any of White Rabbit switch channels using the SFP cages and fibers. To be able to demonstrate the synchronization accuracy, the same signal from the generator should be provided to both ADCs, with cables of the same length or precisely known lengths.
The SPEC boards together with ADC cards should be installed in PCIe slots of
the computer and connected to any of the White Rabbit switch channels using
the SFP cages and fibers. To be able to demonstrate the synchronization
accuracy, the same signal from the generator should be provided to both ADCs,
with cables of the same length or precisely known lengths.
The GUI and the Server can be run on any Linux machine with python3.6. Before starting the ADC application, all the dependencies, described in section :ref:`dependencies`, have to be installed.
The GUI (:ref:`user_application_intro`) and the :ref:`do_server_intro` can be
run on any Linux machine with python3.6. Before starting the
ADC application (:ref:`device_application_intro`), all the dependencies,
described in section :ref:`dependencies`, have to be installed.
The first application that has to be run is the Server. When the Server is already started, GUIs and ADC nodes can be run in any order.
The first application that has to be run is the Server. When the Server is
already started, GUIs and ADC nodes can be run in any order.
Before starting any of the applications, start the virtual environment and install the Distributed Oscilloscope, as described in section :ref:`inst_app`.
Before starting any of the applications, start the virtual environment and
install the Distributed Oscilloscope, as described in section :ref:`inst_app`.
.. _server_application:
...
...
@@ -32,7 +37,8 @@ Optional arguments:
GUI:
----------------
Before starting the GUI applications, find out what is the IP address of the Server: SERVER_IP_ADDRESS. You can check it using the command:
Before starting the GUI applications, find out what is the IP address of the
Server: SERVER_IP_ADDRESS. You can check it using the command:
.. code-block:: console
...
...
@@ -52,19 +58,25 @@ Required arguments:
Optional arguments:
* port -- port used on the current machine to listen for notifications and acquisition data, default value -- 8001
* port_server -- port used on the Server to listen for the requests from the GUI, default value -- 8003
* port -- port used on the current machine to listen for notifications and
acquisition data, default value -- 8001
* port_server -- port used on the Server to listen for the requests from
the GUI, default value -- 8003
.. _adc_application:
ADC application:
------------------
If the Server and the ADC device are in different local networks, before staring the ADC applications, find out what is the IP address of the Server: SERVER_IP_ADDRESS. If the IP address of the Server is not provided, Zeroconf will be used to automatically find out this information.
If the Server and the ADC device are in different local networks, before
staring the ADC applications, find out what is the IP address of the Server:
SERVER_IP_ADDRESS. If the IP address of the Server is not provided, Zeroconf
will be used to automatically find out this information.
.. important::
The Zeroconf will only work if the Server and the ADC are in the same local networks. Otherwise, the IP of the Server has to be provided manually.
The Zeroconf will only work if the Server and the ADC are in the same local
networks. Otherwise, the IP of the Server has to be provided manually.
To start the GUI, run in terminal:
...
...
@@ -76,14 +88,18 @@ To start the GUI, run in terminal:
Optional arguments:
* ip_server -- IP address of the server
* port_server -- port of the server used to listen for notifications and acquisition data, default value -- 8023
* port -- port used on the current machine to listen for the requests from the Server, default value -- 8000
* port_server -- port of the server used to listen for notifications and
acquisition data, default value -- 8023
* port -- port used on the current machine to listen for the requests from the
Server, default value -- 8000
* pci_addr -- PCI address of the desired board, default value -- 0x01
Examples configuration:
-------------------------
Supposing that the IP address of the Server is 128.141.79.22, the ADCs are installed in the same machine and the PCI slots where the ADCs are installed are 01 and 02, the applications have to be started with following parameters:
Supposing that the IP address of the Server is 128.141.79.22, the ADCs are
installed in the same machine and the PCI slots where the ADCs are installed
are 01 and 02, the applications have to be started with following parameters:
@@ -19,7 +19,9 @@ The GUI application is presented in :numref:`fig_gui`.
Channels selection
------------------
Just like in standard oscilloscope, there is a possibility of observing up to 4 channels. Any channel of any available ADC can be connected to the particular channel of the GUI.
Just like in standard oscilloscope, there is a possibility of observing up to
4 channels. Any channel of any available ADC can be connected to the particular
channel of the GUI.
.. figure:: graphics/GUI_channels_selection.png
:name: fig_gui_chann_sel
...
...
@@ -34,7 +36,8 @@ Just like in standard oscilloscope, there is a possibility of observing up to 4
Triggers selection
------------------
The ADCs could be triggered either by external trigger pulse or when the signal of the observed channel crosses the threshold value.
The ADCs could be triggered either by external trigger pulse or when the signal
of the observed channel crosses the threshold value (internal trigger).
.. figure:: graphics/GUI_triggers_selection.png
:name: fig_gui_trigg_sel
...
...
@@ -49,7 +52,8 @@ The ADCs could be triggered either by external trigger pulse or when the signal
Internal trigger
^^^^^^^^^^^^^^^^
If the internal trigger is selected, the GUI could be triggered on any channel to which a signal is connected.
If the internal trigger is selected, the GUI could be triggered on any channel
to which a signal is connected.
.. figure:: graphics/GUI_internal_trigger.png
:name: fig_gui_int_trigg
...
...
@@ -64,7 +68,8 @@ If the internal trigger is selected, the GUI could be triggered on any channel t
External trigger
^^^^^^^^^^^^^^^^
If the external trigger is selected, the GUI could be triggered by the external trigger input of any connected ADC.
If the external trigger is selected, the GUI could be triggered by the external
trigger input of any connected ADC.
.. figure:: graphics/GUI_external_trigger.png
:name: fig_gui_ext_trigg
...
...
@@ -135,7 +140,8 @@ There are two available modes:
Acquisition settings
--------------------
Acquisition settings allow modifying the acquisition time and position of the trigger. Position of the trigger is given in percentage of the acquisition time.
Acquisition settings allow modifying the acquisition time and position of the
trigger. Position of the trigger is given in percentage of the acquisition time.