diff --git a/dev/acquisition.html b/dev/acquisition.html index f8d0278a..b29abbbd 100644 --- a/dev/acquisition.html +++ b/dev/acquisition.html @@ -1,2 +1,2 @@ -Data Acquisition · RP DAQ Server
Edit on GitHub

Data Acqusition

The data acqusition of the RedPitayaDAQServer project is based on two data flows to and from the upper 128 MB of the RedPitaya memory. This memory region acts as a ring buffer for the acquired samples and can be queried by clients using SCPI commands.

Signal acquisition within a cluster is based on a shared clock and trigger signal distributed via cables between the RedPitayas. Once triggered, all FPGAs continuously write the samples from their ADC channel to the sample ring-buffer with each clock tick. Both ADC channels on a RedPitaya are written to the buffer at the same time. The 14-bit values of the ADCs are converted to 16-bit signed integer samples and then concatenated into one 32-bit value, which is then written to the buffer. The sampling rate of the system can be adjusted by setting a decimation parameter and the decimation itself is realized with a CIC filter.

Internally, the FPGA keeps track of a 64-bit writepointer register pointing into the ring-buffer and increments this value with each new sample pair. Additionally, the writepointer also counts the number of buffer overflows. As the size of the buffer region is a power of two, these two components of the writepointer can be interpreted as one 64-bit number counting the samples from acquisition start. For the 128 MB buffer, this means that the lower 25 bits of the writepointer are the buffer location and the remaining bits are the overflow counter.

As the writepointer is reset and incremented based on a shared clock and trigger signal, it is synchronized across all FPGA images in a cluster. The logic implemented with the reprogrammable hardware is also the only logic of the RedPitayaDAQServer with predictable timing behaviour. All other components of the system implement their (timing related) logic in reference to the current writepointer values. With a known sampling rate, the writepointer can also be seen as the clock of the server and client components.

Sample Transmission

To retrieve samples from the server a client can supply a similar pointer, called readpointer, together with the number of samples to retrieve. The server then extracts the buffer position from the readpointer and transmits the requested amount of samples over the data socket. This transmission happens either way, even if the samples are overwritten. However, the server uses the whole readpointer, including the buffer overflows, to check if the requested samples were overwritten.

If the distance between the write- and readpointer is larger than the buffer size the overflow status flag is set. If during the transmission the requested samples are overwritten the corrupted flag is set. These flags can be queried individually or together in a status byte via SCPI commands.

This distance can not only be used to see if samples were overwritten, but also to track how well the client is able to keep up with the FPGA during a series of sample transmissions. If this distance increases over time, the FPGA is creating more samples than the server can transmit to the client. To allow a client to track this value, this distance is stored as a 64-bit value deltaRead for the latest transmission and can be queried. Additionally, the server also tracks the duration of the transmission as writepointer "clock ticks" as a 64-bit value deltaSend, which is just the difference between the writepointer at the start and end of a transmission.

Considerations for Sample Transmission

There are several things to consider when attempting to retrieve samples at a high sampling rate, for larger cluster sizes or for longer periods of time. Most of the following points were implemented/considered in the Julia reference implementation, but would become relevant when implementing custom clients.

As the server will always transmit samples just based on the buffer position of a readpointer, if a client wants to only receive certain samples it needs to wait for them to exist in the buffer. This requires querying the writepointer until it is larger than the desired readpointer.

If the number of requested samples is larger than the buffer, the sample should be requested in smaller chunks as the server would otherwise return samples that were not written yet. In a cluster scenario the i-th chunk should be requested from all RedPitayas in the cluster before requesting the next chunk to avoid "starvation" effects.

The status and performance data of a transmission can only be queried after the transmission has finished, which requires additionaly communication overhead.

To help clients with these issues, the server offers a second type of sample transmission in which samples, status and performance data is pipelined. In such a query a client first transmits a readpointer, together with the number of requested samples and the number of samples belonging to a chunk. The server itself then tracks the writepointer and transmits a chunk as soon as it becomes available and immidiatey follows that up with the status and performance data of the transmission. This way additional communication overheard is reduced and after the inital request a client just needs to read data until the transmission finishes.

Frames, Periods and Voltage

The samples sent by the server are the 16-bit values of the ADC channel of a RedPitaya. However, one might want to work with voltage values instead or encapsulate samples into a repeating concept like frames. The Julia client library offers functions to convert samples into such a concept or to directly request a number of frames instead of a number of samples.

Here, frames are comprised of periods, which in turn are comprised of samples. During the conversion process the 16-bit binary values can also be converted to floating point numbers representing a voltage if the RedPitaya was calibrated beforehand. In this calibration process, a client can store scale and offset values for each channel in the EEPROM of the RedPitaya. When the client establishes a connection to the server, it reads these values and can use them to translate the 16-bit values into a respective voltage value.

Sampling and Data Rates, Transmission Speeds and Time-to-Live

The highest supported sampling rate of the RedPitayaDAQServer is 15.625 MHz or 15.625 MS/s, as this is the sampling rate at which a single RedPitaya can produce and transmit samples continously without data loss given the 1 Gbit/s limit of the ethernet connection from the RedPitaya. This rate is a achieved with a decimation of 8 from the base 125 MHz sampling rate of the RedPitaya hardware.

At this sampling rate a single RedPitaya produces new samples at a data rate of 500 Mbit/s. Furthermore at this rate, once a sample has been written to the buffer it exists for 2.15s before being overwritten again (Time-To-Live, TTL). An overview of these metrics for different decimation factors is shown in the following table:

DecimationMHzMByte/sMbit/sTTL
641.957.8162.517.18s
323.9115.631258.59s
167.8131.252504.29s
815.6362.55002.15s

The table only refers to the data rate of new samples being produced. The data rate of samples being transmitted to a client can differ greatly depending on how the client queries and processes the samples and the available network bandwidth and usage. At the higher sampling rates it is recommended to have client threads that exclusively receive samples and perform any computation on samples in different threads to maximise the transmission speed, as a server can only transmit data at a rate of just above 500 Mbit/s. This exceeds the highest supported sampling rate by only a few Mbit/s and a client with frequency interruptions of its sample reception might not be able to keep up with the sampling rate.

+Data Acquisition · RP DAQ Server
Edit on GitHub

Data Acqusition

The data acqusition of the RedPitayaDAQServer project is based on two data flows to and from the upper 128 MB of the RedPitaya memory. This memory region acts as a ring buffer for the acquired samples and can be queried by clients using SCPI commands.

Signal acquisition within a cluster is based on a shared clock and trigger signal distributed via cables between the RedPitayas. Once triggered, all FPGAs continuously write the samples from their ADC channel to the sample ring-buffer with each clock tick. Both ADC channels on a RedPitaya are written to the buffer at the same time. The 14-bit values of the ADCs are converted to 16-bit signed integer samples and then concatenated into one 32-bit value, which is then written to the buffer. The sampling rate of the system can be adjusted by setting a decimation parameter and the decimation itself is realized with a CIC filter.

Internally, the FPGA keeps track of a 64-bit writepointer register pointing into the ring-buffer and increments this value with each new sample pair. Additionally, the writepointer also counts the number of buffer overflows. As the size of the buffer region is a power of two, these two components of the writepointer can be interpreted as one 64-bit number counting the samples from acquisition start. For the 128 MB buffer, this means that the lower 25 bits of the writepointer are the buffer location and the remaining bits are the overflow counter.

As the writepointer is reset and incremented based on a shared clock and trigger signal, it is synchronized across all FPGA images in a cluster. The logic implemented with the reprogrammable hardware is also the only logic of the RedPitayaDAQServer with predictable timing behaviour. All other components of the system implement their (timing related) logic in reference to the current writepointer values. With a known sampling rate, the writepointer can also be seen as the clock of the server and client components.

Sample Transmission

To retrieve samples from the server a client can supply a similar pointer, called readpointer, together with the number of samples to retrieve. The server then extracts the buffer position from the readpointer and transmits the requested amount of samples over the data socket. This transmission happens either way, even if the samples are overwritten. However, the server uses the whole readpointer, including the buffer overflows, to check if the requested samples were overwritten.

If the distance between the write- and readpointer is larger than the buffer size the overflow status flag is set. If during the transmission the requested samples are overwritten the corrupted flag is set. These flags can be queried individually or together in a status byte via SCPI commands.

This distance can not only be used to see if samples were overwritten, but also to track how well the client is able to keep up with the FPGA during a series of sample transmissions. If this distance increases over time, the FPGA is creating more samples than the server can transmit to the client. To allow a client to track this value, this distance is stored as a 64-bit value deltaRead for the latest transmission and can be queried. Additionally, the server also tracks the duration of the transmission as writepointer "clock ticks" as a 64-bit value deltaSend, which is just the difference between the writepointer at the start and end of a transmission.

Considerations for Sample Transmission

There are several things to consider when attempting to retrieve samples at a high sampling rate, for larger cluster sizes or for longer periods of time. Most of the following points were implemented/considered in the Julia reference implementation, but would become relevant when implementing custom clients.

As the server will always transmit samples just based on the buffer position of a readpointer, if a client wants to only receive certain samples it needs to wait for them to exist in the buffer. This requires querying the writepointer until it is larger than the desired readpointer.

If the number of requested samples is larger than the buffer, the sample should be requested in smaller chunks as the server would otherwise return samples that were not written yet. In a cluster scenario the i-th chunk should be requested from all RedPitayas in the cluster before requesting the next chunk to avoid "starvation" effects.

The status and performance data of a transmission can only be queried after the transmission has finished, which requires additionaly communication overhead.

To help clients with these issues, the server offers a second type of sample transmission in which samples, status and performance data is pipelined. In such a query a client first transmits a readpointer, together with the number of requested samples and the number of samples belonging to a chunk. The server itself then tracks the writepointer and transmits a chunk as soon as it becomes available and immidiatey follows that up with the status and performance data of the transmission. This way additional communication overheard is reduced and after the inital request a client just needs to read data until the transmission finishes.

Frames, Periods and Voltage

The samples sent by the server are the 16-bit values of the ADC channel of a RedPitaya. However, one might want to work with voltage values instead or encapsulate samples into a repeating concept like frames. The Julia client library offers functions to convert samples into such a concept or to directly request a number of frames instead of a number of samples.

Here, frames are comprised of periods, which in turn are comprised of samples. During the conversion process the 16-bit binary values can also be converted to floating point numbers representing a voltage if the RedPitaya was calibrated beforehand. In this calibration process, a client can store scale and offset values for each channel in the EEPROM of the RedPitaya. When the client establishes a connection to the server, it reads these values and can use them to translate the 16-bit values into a respective voltage value.

Sampling and Data Rates, Transmission Speeds and Time-to-Live

The highest supported sampling rate of the RedPitayaDAQServer is 15.625 MHz or 15.625 MS/s, as this is the sampling rate at which a single RedPitaya can produce and transmit samples continously without data loss given the 1 Gbit/s limit of the ethernet connection from the RedPitaya. This rate is a achieved with a decimation of 8 from the base 125 MHz sampling rate of the RedPitaya hardware.

At this sampling rate a single RedPitaya produces new samples at a data rate of 500 Mbit/s. Furthermore at this rate, once a sample has been written to the buffer it exists for 2.15s before being overwritten again (Time-To-Live, TTL). An overview of these metrics for different decimation factors is shown in the following table:

DecimationMHzMByte/sMbit/sTTL
641.957.8162.517.18s
323.9115.631258.59s
167.8131.252504.29s
815.6362.55002.15s

The table only refers to the data rate of new samples being produced. The data rate of samples being transmitted to a client can differ greatly depending on how the client queries and processes the samples and the available network bandwidth and usage. At the higher sampling rates it is recommended to have client threads that exclusively receive samples and perform any computation on samples in different threads to maximise the transmission speed, as a server can only transmit data at a rate of just above 500 Mbit/s. This exceeds the highest supported sampling rate by only a few Mbit/s and a client with frequency interruptions of its sample reception might not be able to keep up with the sampling rate.

diff --git a/dev/architecture.html b/dev/architecture.html index 00a26c26..1ccdcd0d 100644 --- a/dev/architecture.html +++ b/dev/architecture.html @@ -1,2 +1,2 @@ -Architecture · RP DAQ Server
Edit on GitHub

Architecture

The RedPitayaDAQServer project is implemented as a distributed system in which one client connects to a cluster of RedPitaya boards. The project has four software components:

  • FPGA image running on the RedPitayas FPGA
  • C library encapsulating access to the FPGA image
  • Server running on the CPU of the RedPitayas
  • Client Julia reference library

The FPGA image is responsible for generating and acquiring synchronized out- and input signals. The server acts as an intermediary to the FPGA over a TCP/IP connection, which allows remote clients to configure the FPGA image and retrieve samples. Furthermore, the server also maintains a thread that takes part in signal generation.

The Julia client library can be used to implement a data acquisition client application, which controls a (cluster of) RedPitaya(s). This Julia library acts as a reference, but in principle it is possible to write clients in any programming language, as the communication is language agnostic. In the example directory we provide a rudimentary Python client that allows to perform a simple data acquisition experiment.

Communication

The various components of the distributed system communicate over different interfaces. Communication within a RedPitaya is based on memory-mapped I/O, while communication between the server and a client is based on SCPI commands over a TCP/IP connection, usually over Ethernet. Lastly communication between RedPitayas is limited to signals distributed over cables as described in Cluster.

FPGA and CPU

The FPGA image is directly connected to certain memory regions that can be memory mapped on the CPU side of the RedPitaya. Both the CPU and the FPGA image access the reserved main memory region as a sample buffer. The C library rp-daq-lib, which is located under src/lib/ in the project repository, encapsulates these memory accesses into a convenient C library. It is possible to use this C library directly on the RedPitaya when no communication with the host system is required, i.e. if one wants to write the acquired data into a file. When making changes to the FPGA image one may need to adapt the rp-daq-lib C library.

The server itself uses the rp-daq-lib library to interface with the FPGA image.

Client and Server

The server on each RedPitaya has two TCP sockets to which a client needs to connect. The first is the command socket on port 5025 and the second is the data socket on port 5026. Over the former, a client can send SCPI commands to the server and receive replies, while the latter is used for sending binary data such as the samples acquired by the ADCs.

SCPI commands are ASCII strings, such as RP:ADC:DECimation, which the server translates into C function calls. As an example these calls could invoke a function of the rp-daq-lib library to set the decimation of the sampling rate or instruct the server to transmit data over the data socket. A list of the available SCPI commands can be found here.

At any point a server is only connected to one client and establishing a new connection stops any current signal generation and acquisition.

+Architecture · RP DAQ Server
Edit on GitHub

Architecture

The RedPitayaDAQServer project is implemented as a distributed system in which one client connects to a cluster of RedPitaya boards. The project has four software components:

  • FPGA image running on the RedPitayas FPGA
  • C library encapsulating access to the FPGA image
  • Server running on the CPU of the RedPitayas
  • Client Julia reference library

The FPGA image is responsible for generating and acquiring synchronized out- and input signals. The server acts as an intermediary to the FPGA over a TCP/IP connection, which allows remote clients to configure the FPGA image and retrieve samples. Furthermore, the server also maintains a thread that takes part in signal generation.

The Julia client library can be used to implement a data acquisition client application, which controls a (cluster of) RedPitaya(s). This Julia library acts as a reference, but in principle it is possible to write clients in any programming language, as the communication is language agnostic. In the example directory we provide a rudimentary Python client that allows to perform a simple data acquisition experiment.

Communication

The various components of the distributed system communicate over different interfaces. Communication within a RedPitaya is based on memory-mapped I/O, while communication between the server and a client is based on SCPI commands over a TCP/IP connection, usually over Ethernet. Lastly communication between RedPitayas is limited to signals distributed over cables as described in Cluster.

FPGA and CPU

The FPGA image is directly connected to certain memory regions that can be memory mapped on the CPU side of the RedPitaya. Both the CPU and the FPGA image access the reserved main memory region as a sample buffer. The C library rp-daq-lib, which is located under src/lib/ in the project repository, encapsulates these memory accesses into a convenient C library. It is possible to use this C library directly on the RedPitaya when no communication with the host system is required, i.e. if one wants to write the acquired data into a file. When making changes to the FPGA image one may need to adapt the rp-daq-lib C library.

The server itself uses the rp-daq-lib library to interface with the FPGA image.

Client and Server

The server on each RedPitaya has two TCP sockets to which a client needs to connect. The first is the command socket on port 5025 and the second is the data socket on port 5026. Over the former, a client can send SCPI commands to the server and receive replies, while the latter is used for sending binary data such as the samples acquired by the ADCs.

SCPI commands are ASCII strings, such as RP:ADC:DECimation, which the server translates into C function calls. As an example these calls could invoke a function of the rp-daq-lib library to set the decimation of the sampling rate or instruct the server to transmit data over the data socket. A list of the available SCPI commands can be found here.

At any point a server is only connected to one client and establishing a new connection stops any current signal generation and acquisition.

diff --git a/dev/client.html b/dev/client.html index e1c28d3c..2db1a31d 100644 --- a/dev/client.html +++ b/dev/client.html @@ -1,105 +1,105 @@ -Client Library · RP DAQ Server
Edit on GitHub

Client

This page contains documentation of the public API of the Julia client. In the Julia REPL one can access this documentation by entering the help mode with ? and then writing the function for which the documentation should be shown.

Connection and Communication

RedPitayaDAQServer.RedPitaya — Type
RedPitaya

Struct representing a connection to a RedPitayaDAQServer.

Contains the sockets used for communication and connection related metadata. Also contains fields for client specific concepts such as periods, frames and calibration values.

source
RedPitayaDAQServer.RedPitaya — Method
RedPitaya(ip [, port = 5025, dataPort=5026, isMaster = false])

Construct a RedPitaya.

During the construction the connection is established and the calibration values are loaded from the RedPitayas EEPROM. Throws an error if a timeout occurs while attempting to connect.

Examples

julia> rp = RedPitaya("192.168.1.100");
+Client Library · RP DAQ Server
Edit on GitHub
Client
This page contains documentation of the public API of the Julia client. In the Julia REPL one can access this documentation by entering the help mode with ? and then writing the function for which the documentation should be shown.
Connection and Communication
RedPitayaDAQServer.RedPitaya — Type
RedPitaya
Struct representing a connection to a RedPitayaDAQServer.
Contains the sockets used for communication and connection related metadata. Also contains fields for  client specific concepts such as periods, frames and calibration values. 
source
RedPitayaDAQServer.RedPitaya — Method
RedPitaya(ip [, port = 5025, dataPort=5026, isMaster = false])
Construct a RedPitaya.
During the construction the connection is established and the calibration values are loaded from the RedPitayas EEPROM. Throws an error if a timeout occurs while attempting to connect.
Examples
julia> rp = RedPitaya("192.168.1.100");
 
 julia> decimation!(rp, 8)
 true
 
 julia> decimation(rp)
-8
source
Sockets.send — Method
send(rp::RedPitaya, cmd::String)
Send a command to the RedPitaya. Appends delimiter.
source
RedPitayaDAQServer.query — Function
query(rp::RedPitaya, cmd [, timeout = 5.0, N = 100])
Send a query to the RedPitaya command socket. Return reply as String.
Waits for timeout seconds and checks every timeout/N seconds.
See also receive.
source
query(rp::RedPitaya, cmd, T::Type [timeout = 5.0, N = 100])
Send a query to the RedPitaya. Parse reply as T.
Waits for timeout seconds and checks every timeout/N seconds.
source
RedPitayaDAQServer.receive — Function
receive(rp::RedPitaya)
Receive a String from the RedPitaya command socket. Reads until a whole line is received
source
receive(rp::RedPitaya, timeout::Number)
Receive a string from the RedPitaya command socket. Reads until a whole line is received or timeout seconds passed. In the latter case an error is thrown.
source
Sockets.send — Method
send(rp::RedPitaya, cmd::String)
Send a command to the RedPitaya. Appends delimiter.
source
RedPitayaDAQServer.query — Function
query(rp::RedPitaya, cmd [, timeout = 5.0, N = 100])
Send a query to the RedPitaya command socket. Return reply as String.
Waits for timeout seconds and checks every timeout/N seconds.
See also receive.
source
query(rp::RedPitaya, cmd, T::Type [timeout = 5.0, N = 100])
Send a query to the RedPitaya. Parse reply as T.
Waits for timeout seconds and checks every timeout/N seconds.
source
RedPitayaDAQServer.receive — Function
receive(rp::RedPitaya)
Receive a String from the RedPitaya command socket. Reads until a whole line is received
source
receive(rp::RedPitaya, timeout::Number)
Receive a string from the RedPitaya command socket. Reads until a whole line is received or timeout seconds passed. In the latter case an error is thrown.
source
RedPitayaDAQServer.serverMode — Function
serverMode(rp::RedPitaya)
Return the mode of the server.
Examples
julia> serverMode!(rp, ACQUISITION);
 true
 
 julia> serverMode(rp)
-ACQUISITION
source
serverMode(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.serverMode! — Function
serverMode!(rp::RedPitaya, mode::ServerMode)
Set the mode of the server. Valid values are "CONFIGURATION" and "ACQUISITION".
Examples
julia> serverMode!(rp, ACQUISITION);
+ACQUISITION
source
serverMode(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.serverMode! — Function
serverMode!(rp::RedPitaya, mode::ServerMode)
Set the mode of the server. Valid values are "CONFIGURATION" and "ACQUISITION".
Examples
julia> serverMode!(rp, ACQUISITION);
 true
 
 julia> serverMode(rp)
-ACQUISITION
source
serverMode!(rp::RedPitaya, mode::ServerMode)
Set the mode of the server.
Examples
julia> serverMode!(rp, ACQUISITION);
+ACQUISITION
source
serverMode!(rp::RedPitaya, mode::ServerMode)
Set the mode of the server.
Examples
julia> serverMode!(rp, ACQUISITION);
 true
 
 julia> serverMode(rp)
-ACQUISITION
source
serverMode!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.ScpiBatch — Type
ScpiBatch
Struct representing a batch of SCPI commands for a RedPitaya. Only commands that interact exclusively with the command socket should be used in a batch.
source
RedPitayaDAQServer.@add_batch — Macro
@add_batch batch cmd
Append a usual RedPitaya function to the given batch instead of evaluating it directly.
See also ScpiBatch, push!, execute!
Examples
julia>  execute!(rp) do b
+ACQUISITION
source
serverMode!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.ScpiBatch — Type
ScpiBatch
Struct representing a batch of SCPI commands for a RedPitaya. Only commands that interact exclusively with the command socket should be used in a batch.
source
RedPitayaDAQServer.execute! — Function
execute!(rp::RedPitaya, batch::ScpiBatch)
Executes all commands of the given batch. Returns an array of the results in the order of the commands. An element is nothing if the command has no return value.
source
execute!(rpc::RedPitayaCluster, batch::ScpiBatch)
Executes all commands of the given batch. Returns an array of the results in the order of the commands.
Each element of the result array is again an array containing the return values of the RedPitayas. An element of an inner array is nothing if the command has no return value.
source
execute!(f::Function, rp::Union{RedPitaya, RedPitayaCluster})
Open a ScpiBatch and evaluate the function f. If no exception was thrown, execute the opened batch.
See also ScpiBatch, push!, @add_batch
Examples
julia>  execute!(rp) do b
+        end
source
RedPitayaDAQServer.execute! — Function
execute!(rp::RedPitaya, batch::ScpiBatch)
Executes all commands of the given batch. Returns an array of the results in the order of the commands. An element is nothing if the command has no return value.
source
execute!(rpc::RedPitayaCluster, batch::ScpiBatch)
Executes all commands of the given batch. Returns an array of the results in the order of the commands.
Each element of the result array is again an array containing the return values of the RedPitayas. An element of an inner array is nothing if the command has no return value.
source
execute!(f::Function, rp::Union{RedPitaya, RedPitayaCluster})
Open a ScpiBatch and evaluate the function f. If no exception was thrown, execute the opened batch.
See also ScpiBatch, push!, @add_batch
Examples
julia>  execute!(rp) do b
           @add_batch b serverMode!(rp, CONFIGURATION)
           @add_batch b amplitudeDAC!(rp, 1, 1, 0.2)
-        end
source
Base.push! — Method
push!(batch::ScpiBatch, cmd::Pair{K, T}) where {K<:Function, T<:Tuple}
Add the given function and arguments to the batch
Examples
julia> batch = ScpiBatch() 
+        end
source
Base.push! — Method
push!(batch::ScpiBatch, cmd::Pair{K, T}) where {K<:Function, T<:Tuple}
Add the given function and arguments to the batch
Examples
julia> batch = ScpiBatch() 
 
-julia> push!(batch, amplitudeDAC! => (1, 1, 0.2))
source
Base.pop! — Method
pop!(batch::ScpiBatch)
Remove the last added command from the batch
source
RedPitayaDAQServer.RedPitayaCluster — Type
RedPitayaCluster
Struct representing a cluster of RedPitayas. Such a cluster should share a common clock and master trigger.
The structure implements the indexing and iterable interfaces.
source
RedPitayaDAQServer.RedPitayaCluster — Method
RedPitayaCluster(hosts::Vector{String} [, port = 5025])
Construct a RedPitayaCluster.
During the construction the first host is labelled the master RedPitaya of a cluster and all RedPitayas are set to using the EXTERNAL trigger mode.
See also RedPitaya, master.
Examples
julia> rpc = RedPitayaCluster(["192.168.1.100", "192.168.1.101"]);
+julia> push!(batch, amplitudeDAC! => (1, 1, 0.2))
source
Base.pop! — Method
pop!(batch::ScpiBatch)
Remove the last added command from the batch
source
RedPitayaDAQServer.RedPitayaCluster — Type
RedPitayaCluster
Struct representing a cluster of RedPitayas. Such a cluster should share a common clock and master trigger.
The structure implements the indexing and iterable interfaces.
source
RedPitayaDAQServer.RedPitayaCluster — Method
RedPitayaCluster(hosts::Vector{String} [, port = 5025])
Construct a RedPitayaCluster.
During the construction the first host is labelled the master RedPitaya of a cluster and all RedPitayas are set to using the EXTERNAL trigger mode.
See also RedPitaya, master.
Examples
julia> rpc = RedPitayaCluster(["192.168.1.100", "192.168.1.101"]);
 
 julia> rp = master(rpc)
 
 julia> rp == rpc[1]
-true
source
Base.length — Method
length(rpc::RedPitayaCluster)
Return the number of RedPitayas in cluster rpc.
source
ADC Configuration
RedPitayaDAQServer.triggerMode! — Function
triggerMode!(rp::RedPitaya, mode::String)
Set the trigger mode of the RedPitaya. Return true if the command was successful.
source
triggerMode!(rp::RedPitaya, mode::String)
Set the trigger mode of the RedPitaya. Return true if the command was successful.
source
triggerMode!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.keepAliveReset — Function
keepAliveReset(rp::RedPitaya)
Determine whether the keepAliveReset is set.
source
keepAliveReset(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.keepAliveReset! — Function
keepAliveReset!(rp::RedPitaya, val::Bool)
Set the keepAliveReset to val.
source
keepAliveReset!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
Base.length — Method
length(rpc::RedPitayaCluster)
Return the number of RedPitayas in cluster rpc.
source
ADC Configuration
RedPitayaDAQServer.triggerMode! — Function
triggerMode!(rp::RedPitaya, mode::String)
Set the trigger mode of the RedPitaya. Return true if the command was successful.
source
triggerMode!(rp::RedPitaya, mode::String)
Set the trigger mode of the RedPitaya. Return true if the command was successful.
source
triggerMode!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.keepAliveReset — Function
keepAliveReset(rp::RedPitaya)
Determine whether the keepAliveReset is set.
source
keepAliveReset(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.keepAliveReset! — Function
keepAliveReset!(rp::RedPitaya, val::Bool)
Set the keepAliveReset to val.
source
keepAliveReset!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.decimation — Function
decimation(rp::RedPitaya)
Return the decimation of the RedPitaya.
Examples
julia> decimation!(rp, 8)
 true
 
 julia> decimation(rp)
-8
source
decimation(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.decimation! — Function
decimation!(rp::RedPitaya, dec)
Set the decimation of the RedPitaya. Return true if the command was successful.
Examples
julia> decimation!(rp, 8)
+8
source
decimation(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.decimation! — Function
decimation!(rp::RedPitaya, dec)
Set the decimation of the RedPitaya. Return true if the command was successful.
Examples
julia> decimation!(rp, 8)
 true
 
 julia> decimation(rp)
-8
source
decimation!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.samplesPerPeriod — Function
samplesPerPeriod(rp::RedPitaya)
Return the number of samples per period.
Example
julia> samplesPerPeriod!(rp, 256)
+8
source
decimation!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.samplesPerPeriod — Function
samplesPerPeriod(rp::RedPitaya)
Return the number of samples per period.
Example
julia> samplesPerPeriod!(rp, 256)
 true
 
 julia> samplesPerPeriod(rp)
 256
-
source
samplesPerPeriod(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.samplesPerPeriod! — Function
samplesPerPeriod!(rp::RedPitaya, value)
Set the number of samples per period.
Example
julia> samplesPerPeriod!(rp, 256)
+
source
samplesPerPeriod(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.samplesPerPeriod! — Function
samplesPerPeriod!(rp::RedPitaya, value)
Set the number of samples per period.
Example
julia> samplesPerPeriod!(rp, 256)
 true
 
 julia> samplesPerPeriod(rp)
 256
-
source
samplesPerPeriod!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.periodsPerFrame — Function
periodsPerFrame(rp::RedPitaya)
Return the number of periods per frame.
Example
julia> periodsPerFrame!(rp, 16)
+
source
samplesPerPeriod!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.periodsPerFrame — Function
periodsPerFrame(rp::RedPitaya)
Return the number of periods per frame.
Example
julia> periodsPerFrame!(rp, 16)
 
 julia> periodsPerFrame(rp)
 16
-
source
periodsPerFrame(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.periodsPerFrame! — Function
periodsPerFrame(rp::RedPitaya, value)
Set the number of periods per frame.
Example
julia> periodsPerFrame!(rp, 16)
+
source
periodsPerFrame(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.periodsPerFrame! — Function
periodsPerFrame(rp::RedPitaya, value)
Set the number of periods per frame.
Example
julia> periodsPerFrame!(rp, 16)
 
 julia> periodsPerFrame(rp)
 16
-
source
periodsPerFrame!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
DAC Configuration
RedPitayaDAQServer.amplitudeDAC — Function
amplitudeDAC(rp::RedPitaya, channel, component)
Return the amplitude of composite waveform component for channel.
See amplitudeDAC!.
Examples
julia> amplitudeDAC!(rp, 1, 1, 0.5);
+
source
periodsPerFrame!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
DAC Configuration
RedPitayaDAQServer.amplitudeDAC — Function
amplitudeDAC(rp::RedPitaya, channel, component)
Return the amplitude of composite waveform component for channel.
See amplitudeDAC!.
Examples
julia> amplitudeDAC!(rp, 1, 1, 0.5);
 true
 
 julia> amplitudeDAC(rp, 1, 1)
-0.5
source
amplitudeDAC(rpc::RedPitayaCluster, chan::Integer, component::Integer)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.amplitudeDAC! — Function
amplitudeDAC!(rp::RedPitaya, channel, component, value)
Set the amplitude of composite waveform component for channel. Return true if the command was successful.
See amplitudeDAC.
Examples
julia> amplitudeDAC!(rp, 1, 1, 0.5);
+0.5
source
amplitudeDAC(rpc::RedPitayaCluster, chan::Integer, component::Integer)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.amplitudeDAC! — Function
amplitudeDAC!(rp::RedPitaya, channel, component, value)
Set the amplitude of composite waveform component for channel. Return true if the command was successful.
See amplitudeDAC.
Examples
julia> amplitudeDAC!(rp, 1, 1, 0.5);
 true
 
 julia> amplitudeDAC(rp, 1, 1)
-0.5
source
amplitudeDAC!(rpc::RedPitayaCluster, chan::Integer, component::Integer, value)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.offsetDAC — Function
offsetDAC(rp::RedPitaya, channel)
Return the offset for channel.
See offsetDAC!.
Examples
julia> offsetDAC!(rp, 1, 0.2);
+0.5
source
amplitudeDAC!(rpc::RedPitayaCluster, chan::Integer, component::Integer, value)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.offsetDAC — Function
offsetDAC(rp::RedPitaya, channel)
Return the offset for channel.
See offsetDAC!.
Examples
julia> offsetDAC!(rp, 1, 0.2);
 true
 
 julia> offsetDAC(rp, 1)
-0.2
source
offsetDAC(rpc::RedPitayaCluster, chan::Integer)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.offsetDAC! — Function
offsetDAC!(rp::RedPitaya, channel, value)
Set the offset for channel. Return true if the command was successful.
See offsetDAC.
Examples
julia> offsetDAC!(rp, 1, 0.2);
+0.2
source
offsetDAC(rpc::RedPitayaCluster, chan::Integer)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.offsetDAC! — Function
offsetDAC!(rp::RedPitaya, channel, value)
Set the offset for channel. Return true if the command was successful.
See offsetDAC.
Examples
julia> offsetDAC!(rp, 1, 0.2);
 true
 
 julia> offsetDAC(rp, 1)
-0.2
source
offsetDAC!(rpc::RedPitayaCluster, chan::Integer, value)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.frequencyDAC — Function
frequencyDAC(rp::RedPitaya, channel, component)
Return the frequency of composite waveform component for channel.
See frequencyDAC!.
Examples
julia> frequencyDAC!(rp, 1, 1, 2400);
+0.2
source
offsetDAC!(rpc::RedPitayaCluster, chan::Integer, value)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.frequencyDAC — Function
frequencyDAC(rp::RedPitaya, channel, component)
Return the frequency of composite waveform component for channel.
See frequencyDAC!.
Examples
julia> frequencyDAC!(rp, 1, 1, 2400);
 true
 
 julia> frequencyDAC(rp, 1, 1)
-2400
source
frequencyDAC(rpc::RedPitayaCluster, chan::Integer, component::Integer)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.frequencyDAC! — Function
frequencyDAC!(rp::RedPitaya, channel, component, value)
Set the frequency of composite waveform component for channel. Return true if the command was successful.
See frequencyDAC.
Examples
julia> frequencyDAC!(rp, 1, 1, 2400);
+2400
source
frequencyDAC(rpc::RedPitayaCluster, chan::Integer, component::Integer)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.frequencyDAC! — Function
frequencyDAC!(rp::RedPitaya, channel, component, value)
Set the frequency of composite waveform component for channel. Return true if the command was successful.
See frequencyDAC.
Examples
julia> frequencyDAC!(rp, 1, 1, 2400);
 true
 
 julia> frequencyDAC(rp, 1, 1)
-2400
source
frequencyDAC!(rpc::RedPitayaCluster, chan::Integer, component::Integer, value)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.phaseDAC — Function
phaseDAC(rp::RedPitaya, channel, component)
Return the phase of composite waveform component for channel.
See phaseDAC!.
Examples
julia> phaseDAC!(rp, 1, 1, 0.0);
+2400
source
frequencyDAC!(rpc::RedPitayaCluster, chan::Integer, component::Integer, value)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.phaseDAC — Function
phaseDAC(rp::RedPitaya, channel, component)
Return the phase of composite waveform component for channel.
See phaseDAC!.
Examples
julia> phaseDAC!(rp, 1, 1, 0.0);
 true
 
 julia> phaseDAC(rp, 1, 0.0)
-0.0
source
phaseDAC(rpc::RedPitayaCluster, chan::Integer, component::Integer)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.phaseDAC! — Function
phaseDAC!(rp::RedPitaya, channel, component, value)
Set the phase of composite waveform component for channel. Return true if the command was successful.
See phaseDAC.
Examples
julia> phaseDAC!(rp, 1, 1, 0.0);
+0.0
source
phaseDAC(rpc::RedPitayaCluster, chan::Integer, component::Integer)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.phaseDAC! — Function
phaseDAC!(rp::RedPitaya, channel, component, value)
Set the phase of composite waveform component for channel. Return true if the command was successful.
See phaseDAC.
Examples
julia> phaseDAC!(rp, 1, 1, 0.0);
 true
 
 julia> phaseDAC(rp, 1, 0.0)
-0.0
source
phaseDAC!(rpc::RedPitayaCluster, chan::Integer, component::Integer, value)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.signalTypeDAC — Function
signalTypeDAC!(rp::RedPitaya, channel, value)
Return the signalType of composite waveform for channel.
See signalTypeDAC!.
Examples
julia> signalTypeDAC!(rp, 1, SINE);
+0.0
source
phaseDAC!(rpc::RedPitayaCluster, chan::Integer, component::Integer, value)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.signalTypeDAC — Function
signalTypeDAC!(rp::RedPitaya, channel, value)
Return the signalType of composite waveform for channel.
See signalTypeDAC!.
Examples
julia> signalTypeDAC!(rp, 1, SINE);
 true
 
 julia> signalTypeDAC(rp, 1)
-SINE
source
signalTypeDAC(rpc::RedPitayaCluster, chan::Integer, component::Integer)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.signalTypeDAC! — Function
signalTypeDAC!(rp::RedPitaya, channel, value)
Set the signalType of composite waveform for channel. Return true if the command was successful.
See signalTypeDAC.
Examples
julia> signalTypeDAC!(rp, 1, SINE);
+SINE
source
signalTypeDAC(rpc::RedPitayaCluster, chan::Integer, component::Integer)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.signalTypeDAC! — Function
signalTypeDAC!(rp::RedPitaya, channel, value)
Set the signalType of composite waveform for channel. Return true if the command was successful.
See signalTypeDAC.
Examples
julia> signalTypeDAC!(rp, 1, SINE);
 true
 
 julia> signalTypeDAC(rp, 1)
-SINE
source
signalTypeDAC!(rpc::RedPitayaCluster, chan::Integer, component::Integer, value)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.seqChan! — Function
seqChan!(rp::RedPitaya, value)
Set the number of sequence channel. Valid values are between 1 and 6. Return true if the command was successful.
source
RedPitayaDAQServer.samplesPerStep — Function
samplesPerStep(rp::RedPitaya)
Return the number of samples per sequence step.
source
samplesPerStep(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.samplesPerStep! — Function
samplesPerStep!(rp::RedPitaya, value::Integer)
Set the number of samples per sequence step. Return true if the command was successful.
source
samplesPerStep!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.clearSequence! — Function
clearSequences!(rp::RedPitaya)
Instruct the server to remove all sequences from its list. Return true if the command was successful.
source
clearSequence!(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.sequence! — Function
sequence!(rp::RedPitaya, seq::AbstractSequence)
Transmit the client-side representation seq to the server and append it to the current list of sequences. Return true if the required commands were successful.
See prepareSequence!, clearSequences!.
source
sequence!(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
Missing docstring.
Missing docstring for RedPitayaDAQServer.length(::AbstractSequence). Check Documenter's build log for details.
Missing docstring.
Missing docstring for RedPitayaDAQServer.start. Check Documenter's build log for details.
RedPitayaDAQServer.calibDACOffset! — Function
calibDACOffset!(rp::RedPitaya, channel::Integer, val)
Store calibration DAC offset val for given channel into the RedPitayas EEPROM.  This value is used by the server to offset the output voltage. Absolute value has to be smaller than 1.0 V. 
source
RedPitayaDAQServer.calibDACScale! — Function
calibDACScale(rp::RedPitaya, channel::Integer)
Store calibration DAC scale val for given channel into the RedPitayas EEPROM. This value is used by the server to scale the output voltage.
source
Measurement and Transmission
RedPitayaDAQServer.masterTrigger — Function
masterTrigger(rp::RedPitaya)
Determine whether the master trigger is set.
Example
julia> masterTrigger!(rp, true)
+SINE
source
signalTypeDAC!(rpc::RedPitayaCluster, chan::Integer, component::Integer, value)
As with single RedPitaya. The chan index refers to the total channel available in a cluster, two per RedPitaya. For example channel 4 would refer to the second channel of the second RedPitaya.
source
RedPitayaDAQServer.seqChan! — Function
seqChan!(rp::RedPitaya, value)
Set the number of sequence channel. Valid values are between 1 and 6. Return true if the command was successful.
source
RedPitayaDAQServer.samplesPerStep — Function
samplesPerStep(rp::RedPitaya)
Return the number of samples per sequence step.
source
samplesPerStep(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.samplesPerStep! — Function
samplesPerStep!(rp::RedPitaya, value::Integer)
Set the number of samples per sequence step. Return true if the command was successful.
source
samplesPerStep!(rpc::RedPitayaCluster, value)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.clearSequence! — Function
clearSequences!(rp::RedPitaya)
Instruct the server to remove all sequences from its list. Return true if the command was successful.
source
clearSequence!(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
RedPitayaDAQServer.sequence! — Function
sequence!(rp::RedPitaya, seq::AbstractSequence)
Transmit the client-side representation seq to the server and append it to the current list of sequences. Return true if the required commands were successful.
See prepareSequence!, clearSequences!.
source
sequence!(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to all RedPitayas in a cluster.
source
Missing docstring.
Missing docstring for RedPitayaDAQServer.length(::AbstractSequence). Check Documenter's build log for details.
Missing docstring.
Missing docstring for RedPitayaDAQServer.start. Check Documenter's build log for details.
RedPitayaDAQServer.calibDACOffset! — Function
calibDACOffset!(rp::RedPitaya, channel::Integer, val)
Store calibration DAC offset val for given channel into the RedPitayas EEPROM.  This value is used by the server to offset the output voltage. Absolute value has to be smaller than 1.0 V. 
source
RedPitayaDAQServer.calibDACScale! — Function
calibDACScale(rp::RedPitaya, channel::Integer)
Store calibration DAC scale val for given channel into the RedPitayas EEPROM. This value is used by the server to scale the output voltage.
source
Measurement and Transmission
RedPitayaDAQServer.masterTrigger — Function
masterTrigger(rp::RedPitaya)
Determine whether the master trigger is set.
Example
julia> masterTrigger!(rp, true)
 
 julia>masterTrigger(rp)
-true
source
masterTrigger(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.masterTrigger! — Function
masterTrigger!(rp::RedPitaya, val::Bool)
Set the master trigger of the RedPitaya to val. Return true if the command was successful.
Example
julia> masterTrigger!(rp, true)
+true
source
masterTrigger(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.masterTrigger! — Function
masterTrigger!(rp::RedPitaya, val::Bool)
Set the master trigger of the RedPitaya to val. Return true if the command was successful.
Example
julia> masterTrigger!(rp, true)
 true
 
 julia>masterTrigger(rp)
-true
source
masterTrigger(rpc::RedPitayaCluster, val::Bool)
Set the master trigger of the cluster to val.
For val equals to true this is the same as calling the function on the RedPitaya returned by master(rpc). If val is false then the keepAliveReset is set to true for all RedPitayas in the cluster before the master trigger is disabled. Afterwards the keepAliveReset is set to false again.
See also master, keepAliveReset!.
source
RedPitayaDAQServer.currentWP — Function
currentWP(rp::RedPitaya)
Return the current writepointer of the RedPitaya.
source
currentWP(rpc::RedPitayaCluster)
As with single RedPitaya, but applied to only the master.
source
RedPitayaDAQServer.SampleChunk — Type
SampleChunk
Struct containing a matrix of samples and associated PerformanceData
Fields
  • samples::Matrix{Int16}: nxm matrix containing m samples for n channel
  • performance::Vector{PerformanceData}: PerformanceData object for each RedPitaya that transmitted samples
source
Missing docstring.
Missing docstring for RedPitayaDAQServer.PerformanceData. Check Documenter's build log for details.
RedPitayaDAQServer.readSamples — Function
readSamples(rpu::Union{RedPitaya,RedPitayaCluster, RedPitayaClusterView}, wpStart::Int64, numOfRequestedSamples::Int64; chunkSize::Int64 = 25000, rpInfo=nothing)
Request and receive numOfRequestedSamples samples from wpStart on in a pipelined fashion. Return a matrix of samples.
If rpInfo is set to a RPInfo, the PerformanceData sent after every chunkSize samples will be pushed into rpInfo.
source
readSamples(rpu::Union{RedPitaya,RedPitayaCluster, RedPitayaClusterView}, wpStart::Int64, numOfRequestedSamples::Int64, channel::Channel; chunkSize::Int64 = 25000)
Request and receive numOfRequestedSamples samples from wpStart on in a pipelined fashion. The samples and associated PerformanceData are pushed into channel as a SampleChunk.
See SampleChunk.
source
RedPitayaDAQServer.readFrames — Function
readFrames(rpu::Union{RedPitaya,RedPitayaCluster, RedPitayaClusterView}, startFrame, numFrames, numBlockAverages=1, numPeriodsPerPatch=1; rpInfo=nothing, chunkSize = 50000, useCalibration = false)
Request and receive numFrames frames from startFrame on.
See readSamples, convertSamplesToFrames, samplesPerPeriod, periodsPerFrame, updateCalib!.
Arguments
  • rpu::Union{RedPitaya,RedPitayaCluster, RedPitayaClusterView}: RedPitayas to receive samples from.
  • startFrame: frame from which to start transmitting
  • numFrames: number of frames to read
  • numBlockAverages=1: see convertSamplesToFrames
  • numPeriodsPerPatch=1: see convertSamplesToFrames
  • chunkSize=50000: see readSamples
  • rpInfo=nothing: see readSamples
  • useCalibration: convert from Int16 samples to Float32 values based on RedPitayas calibration
source
Missing docstring.
Missing docstring for RedPitayaDAQServer.convertSamplesToFrames. Check Documenter's build log for details.
Utility
Missing docstring.
Missing docstring for RedPitayaDAQServer.listReleaseTags. Check Documenter's build log for details.
Missing docstring.
Missing docstring for RedPitayaDAQServer.latestReleaseTags. Check Documenter's build log for details.
Missing docstring.
Missing docstring for RedPitayaDAQServer.update!. Check Documenter's build log for details.

+true
source
masterTrigger(rpc::RedPitayaCluster, val::Bool)

Set the master trigger of the cluster to val.

For val equals to true this is the same as calling the function on the RedPitaya returned by master(rpc). If val is false then the keepAliveReset is set to true for all RedPitayas in the cluster before the master trigger is disabled. Afterwards the keepAliveReset is set to false again.

See also master, keepAliveReset!.

source
RedPitayaDAQServer.currentWP — Function
currentWP(rp::RedPitaya)

Return the current writepointer of the RedPitaya.

source
currentWP(rpc::RedPitayaCluster)

As with single RedPitaya, but applied to only the master.

source
RedPitayaDAQServer.SampleChunk — Type
SampleChunk

Struct containing a matrix of samples and associated PerformanceData

Fields

  • samples::Matrix{Int16}: nxm matrix containing m samples for n channel
  • performance::Vector{PerformanceData}: PerformanceData object for each RedPitaya that transmitted samples
source
Missing docstring.

Missing docstring for RedPitayaDAQServer.PerformanceData. Check Documenter's build log for details.

RedPitayaDAQServer.readSamples — Function
readSamples(rpu::Union{RedPitaya,RedPitayaCluster, RedPitayaClusterView}, wpStart::Int64, numOfRequestedSamples::Int64; chunkSize::Int64 = 25000, rpInfo=nothing)

Request and receive numOfRequestedSamples samples from wpStart on in a pipelined fashion. Return a matrix of samples.

If rpInfo is set to a RPInfo, the PerformanceData sent after every chunkSize samples will be pushed into rpInfo.

source
readSamples(rpu::Union{RedPitaya,RedPitayaCluster, RedPitayaClusterView}, wpStart::Int64, numOfRequestedSamples::Int64, channel::Channel; chunkSize::Int64 = 25000)

Request and receive numOfRequestedSamples samples from wpStart on in a pipelined fashion. The samples and associated PerformanceData are pushed into channel as a SampleChunk.

See SampleChunk.

source
RedPitayaDAQServer.readFrames — Function
readFrames(rpu::Union{RedPitaya,RedPitayaCluster, RedPitayaClusterView}, startFrame, numFrames, numBlockAverages=1, numPeriodsPerPatch=1; rpInfo=nothing, chunkSize = 50000, useCalibration = false)

Request and receive numFrames frames from startFrame on.

See readSamples, convertSamplesToFrames, samplesPerPeriod, periodsPerFrame, updateCalib!.

Arguments

  • rpu::Union{RedPitaya,RedPitayaCluster, RedPitayaClusterView}: RedPitayas to receive samples from.
  • startFrame: frame from which to start transmitting
  • numFrames: number of frames to read
  • numBlockAverages=1: see convertSamplesToFrames
  • numPeriodsPerPatch=1: see convertSamplesToFrames
  • chunkSize=50000: see readSamples
  • rpInfo=nothing: see readSamples
  • useCalibration: convert from Int16 samples to Float32 values based on RedPitayas calibration
source
Missing docstring.

Missing docstring for RedPitayaDAQServer.convertSamplesToFrames. Check Documenter's build log for details.

Utility

Missing docstring.

Missing docstring for RedPitayaDAQServer.listReleaseTags. Check Documenter's build log for details.

Missing docstring.

Missing docstring for RedPitayaDAQServer.latestReleaseTags. Check Documenter's build log for details.

Missing docstring.

Missing docstring for RedPitayaDAQServer.update!. Check Documenter's build log for details.

diff --git a/dev/cluster.html b/dev/cluster.html index ac680fe7..9ce5257a 100644 --- a/dev/cluster.html +++ b/dev/cluster.html @@ -1,2 +1,2 @@ -Cluster · RP DAQ Server
Edit on GitHub

Cluster

The RedPitayaDAQServer allows to use multiple RedPitayas in a fully synchronized fashion. One of the RedPitayas will act as the master and distribute its clock to all other RedPitayas acting as slaves.

Prerequisites

Unfortunately, the STEMlab 125-4 does not allow cluster synchronization without hardware modifications. It is therefore necessary to resolder all slaves according to this documentation. The required mode for this project is 'Directly from FPGA' which requires resistors on R27 and R28. The heatsink has to be removed temporarily in order to unsolder the two resistor below it. In the following image you can see the new position of the 0 Ohm 0402 resistors. Since they get lost easily, make sure you have some in stock.

Cluster

Connections

To run a cluster of RedPitayas one needs to connect the devices using different cables. An exemplary cluster with 3 devices is shown in the following image.

Cluster

The clock is distributed from the master to the first slave via an SATA cable (green). Additional slaves can be used by connecting the next slave to the previous one. Additionally all slaves have connection from +3.3 Volt to DIO0_N.

In order to send a mutual trigger signal for starting the acquisition and the signal generation, you also have to connect the master's DIO5_P pin with the DIO0_P pin of all devices including the master.

+Cluster · RP DAQ Server
Edit on GitHub

Cluster

The RedPitayaDAQServer allows to use multiple RedPitayas in a fully synchronized fashion. One of the RedPitayas will act as the master and distribute its clock to all other RedPitayas acting as slaves.

Prerequisites

Unfortunately, the STEMlab 125-4 does not allow cluster synchronization without hardware modifications. It is therefore necessary to resolder all slaves according to this documentation. The required mode for this project is 'Directly from FPGA' which requires resistors on R27 and R28. The heatsink has to be removed temporarily in order to unsolder the two resistor below it. In the following image you can see the new position of the 0 Ohm 0402 resistors. Since they get lost easily, make sure you have some in stock.

Cluster

Connections

To run a cluster of RedPitayas one needs to connect the devices using different cables. An exemplary cluster with 3 devices is shown in the following image.

Cluster

The clock is distributed from the master to the first slave via an SATA cable (green). Additional slaves can be used by connecting the next slave to the previous one. Additionally all slaves have connection from +3.3 Volt to DIO0_N.

In order to send a mutual trigger signal for starting the acquisition and the signal generation, you also have to connect the master's DIO5_P pin with the DIO0_P pin of all devices including the master.

diff --git a/dev/connections.html b/dev/connections.html index b5d6f004..4a7955f1 100644 --- a/dev/connections.html +++ b/dev/connections.html @@ -1,2 +1,2 @@ -Connections · RP DAQ Server
Edit on GitHub

Connections

An overview of the extension connectors (see also here) is given in the following image

Connectors

The project uses most but not all connections that are used in the original RedPitaya image. From the connector E2 only the analog inputs and outputs are used. From the connector E1 several pins are reserved for the following purposes:

  • DIO0_P for the ADC and DAC trigger. Connect it with the master's DIO5_P to distribute the trigger signal to all RedPitayas in a cluster. As long as the input is high, the DACs and ADCs are running.
  • DIO1_P is the input for the watchdog (see configuration register section for further details)
  • DIO2_P is used to acknowledge a received watchdog signal.
  • DIO3_P can be set to high, to stop all DACs instantly.
  • DIO4_P outputs a high for 10 ms after a 100 ms pause on low to provide an alive signal.
  • DIO5_P can be set to high via the configuration register to provide the mutual trigger signal.
  • DIO7_P, DIO7_N, DIO6_P, DIO6_N, DIO5_N, DIO4_N, DIO3_N, DIO2_N can be used as arbitrary outputs set via the server.
  • DIO0_N and DIO1_N are used for the clock selection in a cluster.
+Connections · RP DAQ Server
Edit on GitHub

Connections

An overview of the extension connectors (see also here) is given in the following image

Connectors

The project uses most but not all connections that are used in the original RedPitaya image. From the connector E2 only the analog inputs and outputs are used. From the connector E1 several pins are reserved for the following purposes:

  • DIO0_P for the ADC and DAC trigger. Connect it with the master's DIO5_P to distribute the trigger signal to all RedPitayas in a cluster. As long as the input is high, the DACs and ADCs are running.
  • DIO1_P is the input for the watchdog (see configuration register section for further details)
  • DIO2_P is used to acknowledge a received watchdog signal.
  • DIO3_P can be set to high, to stop all DACs instantly.
  • DIO4_P outputs a high for 10 ms after a 100 ms pause on low to provide an alive signal.
  • DIO5_P can be set to high via the configuration register to provide the mutual trigger signal.
  • DIO7_P, DIO7_N, DIO6_P, DIO6_N, DIO5_N, DIO4_N, DIO3_N, DIO2_N can be used as arbitrary outputs set via the server.
  • DIO0_N and DIO1_N are used for the clock selection in a cluster.
diff --git a/dev/devtips.html b/dev/devtips.html index cdcef40c..a78eba08 100644 --- a/dev/devtips.html +++ b/dev/devtips.html @@ -1,2 +1,2 @@ -Development Tips · RP DAQ Server
Edit on GitHub

Development Hints

On this slide some development hints are summarized. These might change regularely if things are properly integrated into the framework.

Alpine Linux

  • The Alpine linux as currently a root folder with only 185.8M free space, which disallows installing more

applications. To change this one can do

mount -o remount,size=1G /
+Development Tips · RP DAQ Server
Edit on GitHub

Development Hints

On this slide some development hints are summarized. These might change regularely if things are properly integrated into the framework.

Alpine Linux

  • The Alpine linux as currently a root folder with only 185.8M free space, which disallows installing more

applications. To change this one can do

mount -o remount,size=1G /
diff --git a/dev/examples/batch.html b/dev/examples/batch.html index 19b6668d..c45e3a49 100644 --- a/dev/examples/batch.html +++ b/dev/examples/batch.html @@ -66,4 +66,4 @@ plot(vec(uCurrentPeriod[:,1,:,:])) plot(vec(uLastPeriod[:,1,:,:])) legend(("first period", "current period", "last period")) -savefig("images/batch.png")

Batch Example Results

+savefig("images/batch.png")

Batch Example Results

diff --git a/dev/examples/cluster.html b/dev/examples/cluster.html index 200e151d..e16a9f65 100644 --- a/dev/examples/cluster.html +++ b/dev/examples/cluster.html @@ -55,4 +55,4 @@ plot(vec(uCurrentPeriod[:,1,:,:])) plot(vec(uCurrentPeriod[:,3,:,:])) legend(("Channel 1", "Channel 3")) -savefig("images/cluster.png") +savefig("images/cluster.png") diff --git a/dev/examples/producerConsumer.html b/dev/examples/producerConsumer.html index 985db3f0..1851ca8a 100644 --- a/dev/examples/producerConsumer.html +++ b/dev/examples/producerConsumer.html @@ -147,4 +147,4 @@ # Frame dimensions are [samples, chan, periods, frames] plot(vec(buffer[:, 1, :, :])) savefig("images/producerConsumer.png") -end +end diff --git a/dev/examples/ramping.html b/dev/examples/ramping.html index 4dd19c9f..c01fcd07 100644 --- a/dev/examples/ramping.html +++ b/dev/examples/ramping.html @@ -60,4 +60,4 @@ plot(vec(uFirstPeriod[:,1,:,:])) plot(vec(uLastPeriod[:,1,:,:])) legend(("regular", "start", "end")) -savefig("images/asyncRamping.png")

Ramping Example Results

+savefig("images/asyncRamping.png")

Ramping Example Results

diff --git a/dev/examples/seqRamping.html b/dev/examples/seqRamping.html index 6733e947..e0e86c10 100644 --- a/dev/examples/seqRamping.html +++ b/dev/examples/seqRamping.html @@ -56,4 +56,4 @@ enableRamping!(rp, 1, false) clearSequence!(rp) -savefig("images/seqRamping.png")

Sequence Ramping Example Results

+savefig("images/seqRamping.png")

Sequence Ramping Example Results

diff --git a/dev/examples/sequence.html b/dev/examples/sequence.html index 8d12f208..ccf49489 100644 --- a/dev/examples/sequence.html +++ b/dev/examples/sequence.html @@ -52,4 +52,4 @@ masterTrigger!(rp, false) serverMode!(rp, CONFIGURATION) -savefig("images/sequence.png")

Simple Example Results

+savefig("images/sequence.png")

Simple Example Results

diff --git a/dev/examples/sequenceMultiChannel.html b/dev/examples/sequenceMultiChannel.html index 08452b60..e2711e50 100644 --- a/dev/examples/sequenceMultiChannel.html +++ b/dev/examples/sequenceMultiChannel.html @@ -52,4 +52,4 @@ masterTrigger!(rp, false) serverMode!(rp, CONFIGURATION) -savefig("images/sequence.png")

Simple Example Results

+savefig("images/sequence.png")

Simple Example Results

diff --git a/dev/examples/simple.html b/dev/examples/simple.html index 54280c33..93904a48 100644 --- a/dev/examples/simple.html +++ b/dev/examples/simple.html @@ -123,4 +123,4 @@ plt.savefig("simple.png") plt.show() - + diff --git a/dev/examples/waveforms.html b/dev/examples/waveforms.html index 2bc7988a..4d9ea921 100644 --- a/dev/examples/waveforms.html +++ b/dev/examples/waveforms.html @@ -77,4 +77,4 @@ subplots_adjust(left=0.08, bottom=0.05, right=0.98, top=0.95, wspace=0.3, hspace=0.35) savefig("images/waveforms.png") -

Simple Example Results

+

Simple Example Results

diff --git a/dev/fpga.html b/dev/fpga.html index a6d2a0ae..45581a09 100644 --- a/dev/fpga.html +++ b/dev/fpga.html @@ -1,2 +1,2 @@ -FPGA Development · RP DAQ Server
Edit on GitHub

FPGA Development

There may be needs to change the FPGA image. The following explains how this can be done.

Preparation

If you want to make changes to the FPGA design, you need to install Vivado 2021.2. More infos for setting up a development machine we refer to the following resource and here.

After following the installation steps, you need to clone the repository into a directory of your choice and then regenerate the IP cores and the project by running

make daq_bitfiles.

Afterwards you can start Vivado and open the recreated project in ./build/fpga/<xc7z010clg400-1,xc7z020clg400-1>/firmware/RedPitayaDAQServer.xpr. Apply the changes you need and then create the bitfile by using 'Flow -> Generate Bitstream'. This runs the synthesis and implementation steps and output the Bitfile to ./build/fpga/firmware/RedPitayaDAQServer.runs/impl_1/system_wrapper.bit.

After creating the respective bitfile you need to copy it to your Red Pitayas. You can use

scp ./build/fpga/<xc7z010clg400-1,xc7z020clg400-1>/firmware/RedPitayaDAQServer.runs/impl_1/system_wrapper.bit root@<IP>:/root/RedPitayaDAQServer/bitfiles/daq_<xc7z010clg400-1,xc7z020clg400-1>.bit

for this. Set your IP and FPGA version accordingly. Another option is to fully regenerate the Linux image with make all and copy it to the SD card.

Since using git with Vivado can be annoying here are some hints how you can make your changes ready for git:

  • If you only changed some stuff in the blockdesign, you just have to export the blockdesign to ./src/fpga/bd/bd.tcl by using 'File -> Export -> Export Block Design' in Vivado.
  • Changes to the project settings have to be done in ./src/fpga/build.tcl in order to not lose the ability to recreate your changed project.
  • For your own IP cores, just create a new directory in ./src/fpga/cores and copy and adapt the core_config.tcl of another core. Afterwards re-run make cores.
+FPGA Development · RP DAQ Server
Edit on GitHub

FPGA Development

There may be needs to change the FPGA image. The following explains how this can be done.

Preparation

If you want to make changes to the FPGA design, you need to install Vivado 2021.2. More infos for setting up a development machine we refer to the following resource and here.

After following the installation steps, you need to clone the repository into a directory of your choice and then regenerate the IP cores and the project by running

make daq_bitfiles.

Afterwards you can start Vivado and open the recreated project in ./build/fpga/<xc7z010clg400-1,xc7z020clg400-1>/firmware/RedPitayaDAQServer.xpr. Apply the changes you need and then create the bitfile by using 'Flow -> Generate Bitstream'. This runs the synthesis and implementation steps and output the Bitfile to ./build/fpga/firmware/RedPitayaDAQServer.runs/impl_1/system_wrapper.bit.

After creating the respective bitfile you need to copy it to your Red Pitayas. You can use

scp ./build/fpga/<xc7z010clg400-1,xc7z020clg400-1>/firmware/RedPitayaDAQServer.runs/impl_1/system_wrapper.bit root@<IP>:/root/RedPitayaDAQServer/bitfiles/daq_<xc7z010clg400-1,xc7z020clg400-1>.bit

for this. Set your IP and FPGA version accordingly. Another option is to fully regenerate the Linux image with make all and copy it to the SD card.

Since using git with Vivado can be annoying here are some hints how you can make your changes ready for git:

  • If you only changed some stuff in the blockdesign, you just have to export the blockdesign to ./src/fpga/bd/bd.tcl by using 'File -> Export -> Export Block Design' in Vivado.
  • Changes to the project settings have to be done in ./src/fpga/build.tcl in order to not lose the ability to recreate your changed project.
  • For your own IP cores, just create a new directory in ./src/fpga/cores and copy and adapt the core_config.tcl of another core. Afterwards re-run make cores.
diff --git a/dev/generation.html b/dev/generation.html index 46c3a714..8e6ce5b2 100644 --- a/dev/generation.html +++ b/dev/generation.html @@ -1,2 +1,2 @@ -Signal Generation · RP DAQ Server
Edit on GitHub

Signal Generation

Once the acquisition is triggered, each RedPitaya also starts producing signals on their output channels. Each RedPitaya features six such channels, two of those are the 16-bit DAC channel and four of those are digital pins using PDM, see Connections. The output signals are composed of three parts: parameterized waveforms $W_i(t)$, an offset $o_i$ and repeating arbitrary LUT tables. The latter are called sequences $seq_i(t)$. The resulting signal of the DAC channel can be described as:

\[S_i(t) = seq_i(t) + o_i + W_i(t)\]

Waveforms

Each of the 16-bit DAC channel can output a compositve waveform with four components. Each component can be parametrized by its amplitude $a_{i,j}$, frequency $f_{i,j}$ and phase $\varphi_{i,j}$, which can all be changed via SCPI commands. Furthermore, each component also offers different waveforms $w_{i,j}$(sine, triangle, sawtooth):

\[W_i(t) = \sum_{j=1}^{4}a_{i,j} w_{i,j}(2\pi f_{i,j}t + \varphi_{i, j})\]

Ramping

The signals output on the DAC channel can also be multiplied with an increasing/decreasing ramping factor $r(t)$. Ramping and the ramping duration can be enabled and set on a per channel basis. The increasing factor starts from 0 and goes to 1 from the acquisition start on. The decreasing factor goes from 1 to 0.

\[S_i'(t) = r(t)S(t)\]

The ramp down has to be started either by a SCPI command or by a flag from a sequence. Disabling the acquisition trigger removes the ramp down flag, but not the flag that enables ramping itself.

Sequences

The FPGA image features a LUT containing values for all output channels. This LUT is treated as a ring-buffer through which the image iterates and outputs the values on their respective channel. The image can be configured to increment its LUT access every n samples. One period of a value is also called a step. A sequence is a series of steps and the number of times this series is to be repeated.

As the LUT used by the FPGA image is small in comparison with the main memory and in order to support longer series of steps, the server itselfs maintains a sequence in its main memory and periodically reads the next steps from its sequence and writes them to the LUT of the image.

Comparable to the sample transmission of the acquisition, this updating of the LUT is also a process with timing uncertainty as it is affected by the scheduling and execution of the RedPitayas CPU. While during the sample transmission samples could be lost because they were overwritten, in the signal generation wrong signals could be output because the server was too slow in updating the values. Here, the server tracks similar performance metrics and also features a status flag lostSteps for exactly this case. In its current implementation a safe step rate is at 12 kHz.

Sequences and their steps also have additional features. A step can be marked such that during its duration the signal is set to 0. Furthermore, a step can be marked such that it triggers the ramp down. To make this easier to manage the server actually manages three sequences, that can be set individually: A ramp up, regular and ramp down sequence. The ramp up sequence is moved to the FPGA LUT at the acquisition start, followed by the regular sequence. Afterwards the ramp down sequence is started and during its execution the ramp down flag is set.

Calibration

Similar to the signal acqusition, there are also calibration scale $c_{i, scale}$ and offset $c_{i, offset}$ values for the signal generation. These are stored in the EEPROM of the RedPitaya and can be updated by a client. The calibration values are always applied, even when the master trigger is off.

Thus the total signal can be described as:

\[S_i''(t) = c_{i, scale} S_i'(t) + c_{i, offset}\]

+Signal Generation · RP DAQ Server
Edit on GitHub

Signal Generation

Once the acquisition is triggered, each RedPitaya also starts producing signals on their output channels. Each RedPitaya features six such channels, two of those are the 16-bit DAC channel and four of those are digital pins using PDM, see Connections. The output signals are composed of three parts: parameterized waveforms $W_i(t)$, an offset $o_i$ and repeating arbitrary LUT tables. The latter are called sequences $seq_i(t)$. The resulting signal of the DAC channel can be described as:

\[S_i(t) = seq_i(t) + o_i + W_i(t)\]

Waveforms

Each of the 16-bit DAC channel can output a compositve waveform with four components. Each component can be parametrized by its amplitude $a_{i,j}$, frequency $f_{i,j}$ and phase $\varphi_{i,j}$, which can all be changed via SCPI commands. Furthermore, each component also offers different waveforms $w_{i,j}$(sine, triangle, sawtooth):

\[W_i(t) = \sum_{j=1}^{4}a_{i,j} w_{i,j}(2\pi f_{i,j}t + \varphi_{i, j})\]

Ramping

The signals output on the DAC channel can also be multiplied with an increasing/decreasing ramping factor $r(t)$. Ramping and the ramping duration can be enabled and set on a per channel basis. The increasing factor starts from 0 and goes to 1 from the acquisition start on. The decreasing factor goes from 1 to 0.

\[S_i'(t) = r(t)S(t)\]

The ramp down has to be started either by a SCPI command or by a flag from a sequence. Disabling the acquisition trigger removes the ramp down flag, but not the flag that enables ramping itself.

Sequences

The FPGA image features a LUT containing values for all output channels. This LUT is treated as a ring-buffer through which the image iterates and outputs the values on their respective channel. The image can be configured to increment its LUT access every n samples. One period of a value is also called a step. A sequence is a series of steps and the number of times this series is to be repeated.

As the LUT used by the FPGA image is small in comparison with the main memory and in order to support longer series of steps, the server itselfs maintains a sequence in its main memory and periodically reads the next steps from its sequence and writes them to the LUT of the image.

Comparable to the sample transmission of the acquisition, this updating of the LUT is also a process with timing uncertainty as it is affected by the scheduling and execution of the RedPitayas CPU. While during the sample transmission samples could be lost because they were overwritten, in the signal generation wrong signals could be output because the server was too slow in updating the values. Here, the server tracks similar performance metrics and also features a status flag lostSteps for exactly this case. In its current implementation a safe step rate is at 12 kHz.

Sequences and their steps also have additional features. A step can be marked such that during its duration the signal is set to 0. Furthermore, a step can be marked such that it triggers the ramp down. To make this easier to manage the server actually manages three sequences, that can be set individually: A ramp up, regular and ramp down sequence. The ramp up sequence is moved to the FPGA LUT at the acquisition start, followed by the regular sequence. Afterwards the ramp down sequence is started and during its execution the ramp down flag is set.

Calibration

Similar to the signal acqusition, there are also calibration scale $c_{i, scale}$ and offset $c_{i, offset}$ values for the signal generation. These are stored in the EEPROM of the RedPitaya and can be updated by a client. The calibration values are always applied, even when the master trigger is off.

Thus the total signal can be described as:

\[S_i''(t) = c_{i, scale} S_i'(t) + c_{i, offset}\]

diff --git a/dev/index.html b/dev/index.html index f0ad80bc..72625bba 100644 --- a/dev/index.html +++ b/dev/index.html @@ -1,2 +1,2 @@ -Home · RP DAQ Server
Edit on GitHub

RedPitayaDAQServer

Advanced DAQ Tools for the RedPitaya (STEMlab 125-14)

Introduction

This project contains software to be used with the STEMlab 125-14 device from RedPitaya. It allows for continuous generation and measurement of signals with up to 15.625 MS/s, which is not possible with the standard image of the RedPitaya. In addition, the software allows to synchronize a cluster of multiple RedPitayas. This project contains the following parts:

  • Alpine Linux image for the RedPitaya
  • FPGA images for the 7010 and 7020
  • Library written in C to interact with the FPGA image on the RedPitaya
  • SCPI Server for accessing the functionality over TCP/IP
  • SCPI Client to access the server

The code is contained in this repository.

License / Terms of Usage

The source code of this project is licensed under the MIT license. This implies that you are free to use, share, and adapt it. However, please give appropriate credit by citing the project.

Contact

If you have problems using the software, find mistakes, or have general questions please use the issue tracker to contact us.

Contributors

Credit

This package is partly based on work of Koheron [1] and Pavel Demin [2]

[1] https://www.koheron.com/blog/2016/11/29/red-pitaya-cluster [2] https://github.com/pavel-demin/red-pitaya-notes

+Home · RP DAQ Server
Edit on GitHub

RedPitayaDAQServer

Advanced DAQ Tools for the RedPitaya (STEMlab 125-14)

Introduction

This project contains software to be used with the STEMlab 125-14 device from RedPitaya. It allows for continuous generation and measurement of signals with up to 15.625 MS/s, which is not possible with the standard image of the RedPitaya. In addition, the software allows to synchronize a cluster of multiple RedPitayas. This project contains the following parts:

  • Alpine Linux image for the RedPitaya
  • FPGA images for the 7010 and 7020
  • Library written in C to interact with the FPGA image on the RedPitaya
  • SCPI Server for accessing the functionality over TCP/IP
  • SCPI Client to access the server

The code is contained in this repository.

License / Terms of Usage

The source code of this project is licensed under the MIT license. This implies that you are free to use, share, and adapt it. However, please give appropriate credit by citing the project.

Contact

If you have problems using the software, find mistakes, or have general questions please use the issue tracker to contact us.

Contributors

Credit

This package is partly based on work of Koheron [1] and Pavel Demin [2]

[1] https://www.koheron.com/blog/2016/11/29/red-pitaya-cluster [2] https://github.com/pavel-demin/red-pitaya-notes

diff --git a/dev/installation.html b/dev/installation.html index e82bcae5..a045b367 100644 --- a/dev/installation.html +++ b/dev/installation.html @@ -27,4 +27,4 @@ xvfb fontconfig libxrender1 libxtst6 libxi6 make \ bc u-boot-tools device-tree-compiler libncurses5-dev \ libssl-dev qemu-user-static binfmt-support zip \ - squashfs-tools dosfstools parted debootstrap zerofree

in order to get the essential tools. Afterwards clone the project with

git clone https://github.com/tknopp/RedPitayaDAQServer

Then switch into this directory. You can build the whole project using

make all

With 

make daq_bitfiles

one can build both the 7010 and the 7020 versions of the FPGA image. For different build targets consult the Makefiles.

Note: make has to be run as root if you want to build the Linux image, since chroot requires root privileges.

Server

To build the RedPitaya server connect the RedPitaya to your local network and access the device via ssh:

ssh root@rp-f?????.local

where ????? is the ID that is printed on the RedPitaya. The default password is root. After logging into the RedPitaya go to the folder

/root/apps/

and clone the RedPitayaDAQServer project if it does not exist already:

git clone https://github.com/tknopp/RedPitayaDAQServer

Sometimes you might need to make the file system writable by entering

mount -o remount,rw /dev/mmcblk0p1

Then cd into RedPitayaDAQServer

cd /root/apps/RedPitayaDAQServer

and enter make server. This will compile the library, the server, and some example applications. After you restart the RedPitaya the DAQ server will automatically run and you can access it via TCP.

Developing Julia Client Library

Another option when installing the Julia client is to add the package with the dev command:

dev RedPitayaDAQServer

in the package mode ].

This installs the package in development mode and puts the files into ~/.julia/dev/RedPitayaDAQServer/. There you can the also modify the files, which is handy when trying out the examples. You need to manually git pull if you want to get updates, i.e. Julia will not update developed packages automatically.

+ squashfs-tools dosfstools parted debootstrap zerofree

in order to get the essential tools. Afterwards clone the project with

git clone https://github.com/tknopp/RedPitayaDAQServer

Then switch into this directory. You can build the whole project using

make all

With 

make daq_bitfiles

one can build both the 7010 and the 7020 versions of the FPGA image. For different build targets consult the Makefiles.

Note: make has to be run as root if you want to build the Linux image, since chroot requires root privileges.

Server

To build the RedPitaya server connect the RedPitaya to your local network and access the device via ssh:

ssh root@rp-f?????.local

where ????? is the ID that is printed on the RedPitaya. The default password is root. After logging into the RedPitaya go to the folder

/root/apps/

and clone the RedPitayaDAQServer project if it does not exist already:

git clone https://github.com/tknopp/RedPitayaDAQServer

Sometimes you might need to make the file system writable by entering

mount -o remount,rw /dev/mmcblk0p1

Then cd into RedPitayaDAQServer

cd /root/apps/RedPitayaDAQServer

and enter make server. This will compile the library, the server, and some example applications. After you restart the RedPitaya the DAQ server will automatically run and you can access it via TCP.

Developing Julia Client Library

Another option when installing the Julia client is to add the package with the dev command:

dev RedPitayaDAQServer

in the package mode ].

This installs the package in development mode and puts the files into ~/.julia/dev/RedPitayaDAQServer/. There you can the also modify the files, which is handy when trying out the examples. You need to manually git pull if you want to get updates, i.e. Julia will not update developed packages automatically.

diff --git a/dev/scpi.html b/dev/scpi.html index 1295010f..8486e768 100644 --- a/dev/scpi.html +++ b/dev/scpi.html @@ -1,2 +1,2 @@ -SCPI Interface · RP DAQ Server
Edit on GitHub

SCPI Interface

For communication betten the server and the client an SCPI interface with custom commands is used. In the following tables an overview of the available commands and their behaviour is given. The Julia Client library encapsulates these commands into function calls, abstracting their communication details and also combining commands to manage a cluster of RedPitayas at the same time.

As a safe guard the server has different communcation modes and certain commands are only available in certain modes. To give an example, during an acquisition changing the sampling rate would result in unclear behaviour. To stop such a scenario the decimation can only be set in the CONFIGURATION mode and an acquisition can only be triggered in the ACQUISITION mode. The available modes are CONFIGURATION, ACQUISITION and TRANSMISSION (C, A, T, 😺). The former two are set by the client and the latter is set by the server during sample transmission.

After each SCPI command the server replies with true or false on the command socket depending on whether the given command was successfully excecuted. The exception to this rule are the commands which themselves just query values from the server.

ADC Configuration

CommandArgumentsDescriptionModeExample
RP:ADC:DECimationdecimation value [8, ..., n]Set the decimation factor of the base sampling rateCRP:ADC:DEC 8
RP:ADC:DECimation?Return the decimation factorAnyRP:ADC:DEC?
RP:TRIGger:MODetrigger mode (EXTERNAL, INTERNAL)Set the trigger mode, which trigger the RedPitaya listens toCRP:TRIG:MOD INTERNAL
RP:TRIGger:MODe?Return the trigger modeAnyRP:TRIG:MOD?

DAC Configuration

CommandArgumentsDescriptionModeExample
RP:DAC:CHannel#:COMPonent#:SIGnaltypechannel (0, 1), (0, 1, 2, 3), signal type (SINE, TRIANGLE, SAWTOOTH)Set signal type of first component for given channelAnyRP:DAC:CH0:SIG SINE
RP:DAC:CHannel#:COMPonent#:SIGnaltype?channel (0, 1), component (0, 1, 2, 3)Return signal type of first component of given channelAnyRP:DAC:CH1:SIG?
RP:DAC:CHannel#:OFFsetchannel (0, 1), offset [-1, ..., 1]Set offset for given channelAnyRP:DAC:CH1:OFF 0.1
RP:DAC:CHannel#:OFFset?channel (0, 1)Return offset of given channelAnyRP:DAC:CH0:OFF?
RP:DAC:CHannel#:COMPonent#:AMPlitudechannel (0, 1), component (0, 1, 2, 3), amplitude[0, ..., 1]Set amplitude of given channel and componentAny
RP:DAC:CHannel#:COMPonent#:AMPlitude?channel (0, 1), component (0, 1, 2, 3)Return amplitude of given channel and componentAny
RP:DAC:CHannel#:COMPonent#:FREQuencychannel (0, 1), component (0, 1, 2, 3), frequencySet frequency of given channel and componentAny
RP:DAC:CHannel#:COMPonent#:FREQuency?channel (0, 1), component (0, 1, 2, 3)Return frequency of given channel and componentAny
RP:DAC:CHannel#:COMPonent#:PHAsechannel (0, 1), component (0, 1, 2, 3), phaseSet phase of given channel and componentAny
RP:DAC:CHannel#:COMPonent#:PHAse?channel (0, 1), component (0, 1, 2, 3)Return phase of given channel and componentAny
RP:DAC:CHannel#:RAMPingchannel (0, 1), ramping periodSet length of ramping periodC
RP:DAC:CHannel#:RAMPing?channel (0, 1)Get length of ramping periodAny
RP:DAC:CHannel#:RAMPing:ENablechannel (0, 1) ramping status (OFF, ON)Enable/disable ramping factor on given channelC
RP:DAC:CHannel#:RAMPing:ENable?channel (0, 1)Return enable ramping status of given channelAny
RP:DAC:CHannel#:RAMPing:DoWNchannel (0, 1), ramp down status (OFF, ON)Enable/disable ramp down flag for given channelA, T
RP:DAC:CHannel#:RAMPing:DoWN?channel (0, 1)Get ramp down flag for given channelAny
RP:DAC:RAMPing:STATus?Return the ramping statusAny

Sequence Configuration

The server maintains three acqusition sequences. When the server is in theCONFIGURATION mode a client can configure a set of three sequences. If the current configured sequences fits the desired signal, a client can intstruct the server to set the sequences. This moves the configuration sequences to the acquisition sequences and writes the first values to the FPGA buffer.

During an active trigger the buffer is periodically updated by the server. If the server recognizes the end of a sequence, it sets the amplitudes of the waveform components to 0.

CommandArgumentsDescriptionModeExample
RP:DAC:SEQ:CLocKdividerdividerSet the clock divider with which the sequence advancesC
RP:DAC:SEQ:CLocKdivider?Return the clock dividerAny
RP:DAC:SEQ:SAMPlesperstepsamples per stepSet the clock divider such that the sequence advances every given number of samples.C
RP:DAC:SEQ:SAMPlesperstep?Return the number of samples per stepAny
RP:DAC:SEQ:CHannumChan (1, 2, 3, 4)Set the number of sequence channelC
RP:DAC:SEQ:CHan?Return the number of sequence channel
RP:DAC:SEQ:LUTsteps, repetitionsInstruct the server to receive a LUT over the data socketCRP:DAC:SEQ:LUT 10,2
RP:DAC:SEQ:LUT:ENaBleInstruct the server to receive an enable LUT over the data socket of the same shape as the regular LUTC
RP:DAC:SEQ:LUT:UPsteps, repetitionsInstruct the server to receive a ramp up LUT over the data socketC
RP:DAC:SEQ:LUT:DOWNsteps, repetitionsInstruct the server to receive a ramp down LUT over the data socketC
RP:DAC:SEQ:CLEARClear the set sequence values from the FPGA bufferC
RP:DAC:SEQ:SETSet the current configured sequence as the acquisition sequenceC

Acquisition and Transmission

CommandArgumentsDescriptionModeExample
RP:TRIGgertrigger status (OFF, ON)Set the internal trigger statusARP:TRIG ON
RP:TRIGger?Return the trigger statusAnyRP:TRIG?
RP:TRIGger:ALiVekeep alive status (OFF, ON)Set the keep alive bypassARP:TRIG:ALV OFF
RP:TRIGger:ALiVe?Return the keep alive statusAnyRP:TRIG:ALV?
RP:ADC:WP:CURRent?Return the current writepointerA, TRP:ADC:WP?
RP:ADC:DATa?readpointer, number of samplesTransmit number of samples from the buffer component of the readpointer over the data socket. Return true on the command socket if transmission is started.ARP:ADC:DATa? 400,1024
RP:ADC:DATa:PIPElined?readpointer, number of samples, chunksizeTransmit number of samples from the readpointer on in chunks of chunksize over the data socket. After every chunk status and performance data is transmitted over the data socket. Return true if pipeline was started.ARP:ADC:DAT:PIPE? 400,1024,128
RP:STATus?Transmit status as one byte with flags from lower bits: overwritten, corrupted, lost steps, master trigger, sequence activeAnyRP:STAT?
RP:STATus:OVERwritten?Transmit overwritten flagAnyRP:STAT:OVER?
RP:STATus:CORRupted?Transmit corrupted flagAnyRP:STAT:CORR?
RP:STATus:LOSTSteps?Transmit lost steps flagAnyRP:STAT:LOSTS?
RP:PERF?Transmit ADC and DAC performance dataAnyRP:PERF?

Calibration

CommandArgumentsDescriptionModeExample
RP:CALib:ADC:CHannel#:OFFsetchannel (0, 1), offsetStore the ADC offset value for given channel in EEPROMCRP:CAL:ADC:CH0:OFF 0.2
RP:CALib:ADC:CHannel#:OFFset?channel (0, 1)Return the ADC offset value for given channel from EEPROMAnyRP:CAL:ADC:CH1:OFF?
RP:CALib:ADC:CHannel#:SCAlechannel (0, 1), scaleStore the ADC scale value for given channel in EEPROMCRP:CAL:ADC:CH1:SCA 1.0
RP:CALib:ADC:CHannel#:SCAle?channel (0, 1)Return the ADC scale value for given channel from EEPROMAnyRP:CAL:ADC:CH1:SCA?
RP:CALib:DAC:CHannel#:OFFsetchannel (0, 1), offsetStore the DAC offset value for given channel in EEPROMCRP:CAL:DAC:CH0:OFF 0.2
RP:CALib:DAC:CHannel#:OFFset?channel (0, 1)Return the DAC offset value for given channel from EEPROMAnyRP:CAL:DAC:CH1:OFF?
RP:CALib:DAC:CHannel#:SCAlechannel (0, 1), scaleStore the DAC scale value for given channel in EEPROMCRP:CAL:DAC:CH1:SCA 1.0
RP:CALib:DAC:CHannel#:SCAle?channel (0, 1)Return the DAC scale value for given channel from EEPROMAnyRP:CAL:DAC:CH1:SCA?

DIO

CommandArgumentsDescriptionExample
RP:DIO:DIRidentifier of pin, direction (IN/OUT)Set the direction of the DIORP:DIO:DIR DIO7_P,IN
RP:DIOidentifier of pin, value (0/1)Set the output of the DIORP:DIO DIO7_P,1
RP:DIO?identifier of pinGet the input of the DIORP:DIO? DIO7_P
+SCPI Interface · RP DAQ Server
Edit on GitHub

SCPI Interface

For communication betten the server and the client an SCPI interface with custom commands is used. In the following tables an overview of the available commands and their behaviour is given. The Julia Client library encapsulates these commands into function calls, abstracting their communication details and also combining commands to manage a cluster of RedPitayas at the same time.

As a safe guard the server has different communcation modes and certain commands are only available in certain modes. To give an example, during an acquisition changing the sampling rate would result in unclear behaviour. To stop such a scenario the decimation can only be set in the CONFIGURATION mode and an acquisition can only be triggered in the ACQUISITION mode. The available modes are CONFIGURATION, ACQUISITION and TRANSMISSION (C, A, T, 😺). The former two are set by the client and the latter is set by the server during sample transmission.

After each SCPI command the server replies with true or false on the command socket depending on whether the given command was successfully excecuted. The exception to this rule are the commands which themselves just query values from the server.

ADC Configuration

CommandArgumentsDescriptionModeExample
RP:ADC:DECimationdecimation value [8, ..., n]Set the decimation factor of the base sampling rateCRP:ADC:DEC 8
RP:ADC:DECimation?Return the decimation factorAnyRP:ADC:DEC?
RP:TRIGger:MODetrigger mode (EXTERNAL, INTERNAL)Set the trigger mode, which trigger the RedPitaya listens toCRP:TRIG:MOD INTERNAL
RP:TRIGger:MODe?Return the trigger modeAnyRP:TRIG:MOD?

DAC Configuration

CommandArgumentsDescriptionModeExample
RP:DAC:CHannel#:COMPonent#:SIGnaltypechannel (0, 1), (0, 1, 2, 3), signal type (SINE, TRIANGLE, SAWTOOTH)Set signal type of first component for given channelAnyRP:DAC:CH0:SIG SINE
RP:DAC:CHannel#:COMPonent#:SIGnaltype?channel (0, 1), component (0, 1, 2, 3)Return signal type of first component of given channelAnyRP:DAC:CH1:SIG?
RP:DAC:CHannel#:OFFsetchannel (0, 1), offset [-1, ..., 1]Set offset for given channelAnyRP:DAC:CH1:OFF 0.1
RP:DAC:CHannel#:OFFset?channel (0, 1)Return offset of given channelAnyRP:DAC:CH0:OFF?
RP:DAC:CHannel#:COMPonent#:AMPlitudechannel (0, 1), component (0, 1, 2, 3), amplitude[0, ..., 1]Set amplitude of given channel and componentAny
RP:DAC:CHannel#:COMPonent#:AMPlitude?channel (0, 1), component (0, 1, 2, 3)Return amplitude of given channel and componentAny
RP:DAC:CHannel#:COMPonent#:FREQuencychannel (0, 1), component (0, 1, 2, 3), frequencySet frequency of given channel and componentAny
RP:DAC:CHannel#:COMPonent#:FREQuency?channel (0, 1), component (0, 1, 2, 3)Return frequency of given channel and componentAny
RP:DAC:CHannel#:COMPonent#:PHAsechannel (0, 1), component (0, 1, 2, 3), phaseSet phase of given channel and componentAny
RP:DAC:CHannel#:COMPonent#:PHAse?channel (0, 1), component (0, 1, 2, 3)Return phase of given channel and componentAny
RP:DAC:CHannel#:RAMPingchannel (0, 1), ramping periodSet length of ramping periodC
RP:DAC:CHannel#:RAMPing?channel (0, 1)Get length of ramping periodAny
RP:DAC:CHannel#:RAMPing:ENablechannel (0, 1) ramping status (OFF, ON)Enable/disable ramping factor on given channelC
RP:DAC:CHannel#:RAMPing:ENable?channel (0, 1)Return enable ramping status of given channelAny
RP:DAC:CHannel#:RAMPing:DoWNchannel (0, 1), ramp down status (OFF, ON)Enable/disable ramp down flag for given channelA, T
RP:DAC:CHannel#:RAMPing:DoWN?channel (0, 1)Get ramp down flag for given channelAny
RP:DAC:RAMPing:STATus?Return the ramping statusAny

Sequence Configuration

The server maintains three acqusition sequences. When the server is in theCONFIGURATION mode a client can configure a set of three sequences. If the current configured sequences fits the desired signal, a client can intstruct the server to set the sequences. This moves the configuration sequences to the acquisition sequences and writes the first values to the FPGA buffer.

During an active trigger the buffer is periodically updated by the server. If the server recognizes the end of a sequence, it sets the amplitudes of the waveform components to 0.

CommandArgumentsDescriptionModeExample
RP:DAC:SEQ:CLocKdividerdividerSet the clock divider with which the sequence advancesC
RP:DAC:SEQ:CLocKdivider?Return the clock dividerAny
RP:DAC:SEQ:SAMPlesperstepsamples per stepSet the clock divider such that the sequence advances every given number of samples.C
RP:DAC:SEQ:SAMPlesperstep?Return the number of samples per stepAny
RP:DAC:SEQ:CHannumChan (1, 2, 3, 4)Set the number of sequence channelC
RP:DAC:SEQ:CHan?Return the number of sequence channel
RP:DAC:SEQ:LUTsteps, repetitionsInstruct the server to receive a LUT over the data socketCRP:DAC:SEQ:LUT 10,2
RP:DAC:SEQ:LUT:ENaBleInstruct the server to receive an enable LUT over the data socket of the same shape as the regular LUTC
RP:DAC:SEQ:LUT:UPsteps, repetitionsInstruct the server to receive a ramp up LUT over the data socketC
RP:DAC:SEQ:LUT:DOWNsteps, repetitionsInstruct the server to receive a ramp down LUT over the data socketC
RP:DAC:SEQ:CLEARClear the set sequence values from the FPGA bufferC
RP:DAC:SEQ:SETSet the current configured sequence as the acquisition sequenceC

Acquisition and Transmission

CommandArgumentsDescriptionModeExample
RP:TRIGgertrigger status (OFF, ON)Set the internal trigger statusARP:TRIG ON
RP:TRIGger?Return the trigger statusAnyRP:TRIG?
RP:TRIGger:ALiVekeep alive status (OFF, ON)Set the keep alive bypassARP:TRIG:ALV OFF
RP:TRIGger:ALiVe?Return the keep alive statusAnyRP:TRIG:ALV?
RP:ADC:WP:CURRent?Return the current writepointerA, TRP:ADC:WP?
RP:ADC:DATa?readpointer, number of samplesTransmit number of samples from the buffer component of the readpointer over the data socket. Return true on the command socket if transmission is started.ARP:ADC:DATa? 400,1024
RP:ADC:DATa:PIPElined?readpointer, number of samples, chunksizeTransmit number of samples from the readpointer on in chunks of chunksize over the data socket. After every chunk status and performance data is transmitted over the data socket. Return true if pipeline was started.ARP:ADC:DAT:PIPE? 400,1024,128
RP:STATus?Transmit status as one byte with flags from lower bits: overwritten, corrupted, lost steps, master trigger, sequence activeAnyRP:STAT?
RP:STATus:OVERwritten?Transmit overwritten flagAnyRP:STAT:OVER?
RP:STATus:CORRupted?Transmit corrupted flagAnyRP:STAT:CORR?
RP:STATus:LOSTSteps?Transmit lost steps flagAnyRP:STAT:LOSTS?
RP:PERF?Transmit ADC and DAC performance dataAnyRP:PERF?

Calibration

CommandArgumentsDescriptionModeExample
RP:CALib:ADC:CHannel#:OFFsetchannel (0, 1), offsetStore the ADC offset value for given channel in EEPROMCRP:CAL:ADC:CH0:OFF 0.2
RP:CALib:ADC:CHannel#:OFFset?channel (0, 1)Return the ADC offset value for given channel from EEPROMAnyRP:CAL:ADC:CH1:OFF?
RP:CALib:ADC:CHannel#:SCAlechannel (0, 1), scaleStore the ADC scale value for given channel in EEPROMCRP:CAL:ADC:CH1:SCA 1.0
RP:CALib:ADC:CHannel#:SCAle?channel (0, 1)Return the ADC scale value for given channel from EEPROMAnyRP:CAL:ADC:CH1:SCA?
RP:CALib:DAC:CHannel#:OFFsetchannel (0, 1), offsetStore the DAC offset value for given channel in EEPROMCRP:CAL:DAC:CH0:OFF 0.2
RP:CALib:DAC:CHannel#:OFFset?channel (0, 1)Return the DAC offset value for given channel from EEPROMAnyRP:CAL:DAC:CH1:OFF?
RP:CALib:DAC:CHannel#:SCAlechannel (0, 1), scaleStore the DAC scale value for given channel in EEPROMCRP:CAL:DAC:CH1:SCA 1.0
RP:CALib:DAC:CHannel#:SCAle?channel (0, 1)Return the DAC scale value for given channel from EEPROMAnyRP:CAL:DAC:CH1:SCA?

DIO

CommandArgumentsDescriptionExample
RP:DIO:DIRidentifier of pin, direction (IN/OUT)Set the direction of the DIORP:DIO:DIR DIO7_P,IN
RP:DIOidentifier of pin, value (0/1)Set the output of the DIORP:DIO DIO7_P,1
RP:DIO?identifier of pinGet the input of the DIORP:DIO? DIO7_P
diff --git a/dev/search.html b/dev/search.html index 75bd1166..c8057bdc 100644 --- a/dev/search.html +++ b/dev/search.html @@ -1,2 +1,2 @@ -Search · RP DAQ Server

Loading search...

    +Search · RP DAQ Server

    Loading search...