kopia lustrzana https://github.com/f4exb/sdrangel
SDRdaemonSource: updated documentation
f4exb
rodzic
685d5595c4
commit
ac426ab2c7
36
Readme.md
36
Readme.md
|
|
@ -1,6 +1,6 @@
|
|||
|
||||
|
||||
**SDRangel** is an Open Source Qt5/OpenGL SDR and signal analyzer frontend to various hardware.
|
||||
**SDRangel** is an Open Source Qt5 / OpenGL 3.0+ SDR and signal analyzer frontend to various hardware.
|
||||
|
||||
<h1>Source code</h1>
|
||||
|
||||
|
|
@ -20,6 +20,13 @@ channelrx:
|
|||
- demodlora
|
||||
- tcpsrc (although it has evolved please use the udpsrc plugin instead)
|
||||
|
||||
<h2>Deprecated plugins</h2>
|
||||
|
||||
These plugins are still present at least in the code but have been superceded:
|
||||
|
||||
- chanalyzer: the Channel Analyzer channel plugin is superceded by the "new generation" Channel Analyzer NG (chanalyzerng)
|
||||
- sdrdaemon: the SDRdaemon input plugin is superceded by the SDRdaemon source input plugin (sdrdaemonsource). The plugin is not part of the build anymore.
|
||||
|
||||
<h1>Specific features</h1>
|
||||
|
||||
<h2>Multiple device support</h2>
|
||||
|
|
@ -34,6 +41,7 @@ From version 3 transmission or signal generation is supported for BladeRF, HackR
|
|||
- [HackRF output plugin](https://github.com/f4exb/sdrangel/tree/dev/plugins/samplesink/hackrfoutput)
|
||||
- [LimeSDR output plugin](https://github.com/f4exb/sdrangel/tree/dev/plugins/samplesink/limesdroutput) not for Win32
|
||||
- [File output or file sink plugin](https://github.com/f4exb/sdrangel/tree/dev/plugins/samplesink/filesink)
|
||||
- [Remote device via Network with SDRdaemon](https://github.com/f4exb/sdrangel/tree/dev/plugins/samplesink/sdrdaemonsink)
|
||||
|
||||
<h1>Supported hardware</h1>
|
||||
|
||||
|
|
@ -118,9 +126,11 @@ If you use your own location for libmirisdr-4 install directory you need to spec
|
|||
|
||||
<h1>Plugins for special devices</h1>
|
||||
|
||||
These plugins do not use any hardware device connected to your system. They support "virtual" devices related to the file system or the network.
|
||||
|
||||
<h2>File input</h2>
|
||||
|
||||
The file source plugin allows the playback of a recorded IQ file. Such a file is obtained using the recording feature. Click on the record button on the left of the main frequency dial to toggle recording. The file has a fixed name `test_<n>.sdriq` created in the current directory where `<n>` is the device tab index.
|
||||
The [File source plugin](https://github.com/f4exb/sdrangel/tree/dev/plugins/samplesource/filesource) allows the playback of a recorded IQ file. Such a file is obtained using the recording feature. Click on the record button on the left of the main frequency dial to toggle recording. The file has a fixed name `test_<n>.sdriq` created in the current directory where `<n>` is the device tab index.
|
||||
|
||||
Note that this plugin does not require any of the hardware support libraries nor the libusb library. It is alwasys available in the list of devices as `FileSource[0]` even if no physical device is connected.
|
||||
|
||||
|
|
@ -128,29 +138,33 @@ The `.sdriq` format produced are the 2x2 bytes I/Q samples with a header contain
|
|||
|
||||
<h2>File output</h2>
|
||||
|
||||
The file sink plugin allows the recording of the I/Q baseband signal produced by a transmission chain to a file in the `.sdriq` format thus readable by the file source plugin described just above.
|
||||
The [File sink plugin](https://github.com/f4exb/sdrangel/tree/dev/plugins/samplesink/filesink) allows the recording of the I/Q baseband signal produced by a transmission chain to a file in the `.sdriq` format thus readable by the file source plugin described just above.
|
||||
|
||||
Note that this plugin does not require any of the hardware support libraries nor the libusb library. It is always available in the list of devices as `FileSink[0]` even if no physical device is connected.
|
||||
|
||||
<h2>SDRdaemon input</h2>
|
||||
<h2>SDRdaemon receiver input</h2>
|
||||
|
||||
This is the client side of the SDRdaemon server. See the [SDRdaemon](https://github.com/f4exb/sdrdaemon) project in this Github repository. You must specify the address and UDP port to which the server connects and samples will flow into the SDRangel application (default is `127.0.0.1`port `9090`). It uses the meta data to retrieve the sample flow characteristics such as sample rate and receiveng center frequency.
|
||||
The [SDRdaemon source input plugin](https://github.com/f4exb/sdrangel/tree/dev/plugins/samplesource/sdrdaemonsource) is the client side of the SDRdaemon receiver server `sdrdaemonrx`. See the [SDRdaemon](https://github.com/f4exb/sdrdaemon) project in this Github repository. You must specify the local address and UDP port to which the remote server connects and samples will flow into the SDRangel application (default is `127.0.0.1`port `9090`). It uses the meta data to retrieve the sample flow characteristics such as sample rate and receiveng center frequency. It also opens a TCP link to another port to send service messages such as setting parameters specific to the hadrware device connected to the server (default port is `9091`). The `libnanomsg` library is used to support this messaging.
|
||||
|
||||
The data blocks transmitted via UDP are protected against loss with a Cauchy MDS block erasure codec. This makes the transmission more robust in particular with WiFi links.
|
||||
|
||||
There is an automated skew rate compensation in place. During rate readjustemnt streaming can be suspended or signal glitches can occur for about one second.
|
||||
|
||||
This plugin will be built only if the lz4 and libnanomsg libraries are installed in your system. These libraries are available as dev packages in most distributions.
|
||||
This plugin will be built only if the libnanomsg and the [CM256cc library](https://github.com/f4exb/cm256cc) are installed in your system. libnanomsg is available as a dev package in most distributions For CM256cc if you install it in a non standard directory you will then have to specify the include and library paths on the cmake command line. Say if you install cm256cc in `/opt/install/cm256cc` you will have to add `-DCM256CC_INCLUDE_DIR=/opt/install/cm256cc/include/cm256cc -DCM256CC_LIBRARIES=/opt/install/cm256cc/lib/libcm256cc.so` to the cmake commands.
|
||||
|
||||
Note that this plugin does not require any of the hardware support libraries nor the libusb library. It is always available in the list of devices as `SDRdaemon[0]` even if no physical device is connected.
|
||||
Note that this plugin does not require any of the hardware support libraries nor the libusb library. It is always available in the list of devices as `SDRdaemonSource[0]` even if no physical device is connected.
|
||||
|
||||
<h2>SDRdaemonFEC input</h2>
|
||||
<h2>SDRdaemon transmitter output</h2>
|
||||
|
||||
This is a specialized client for the SDRdaemon server that matches the SDRdaemon with FEC option (`sdrdaemonfec` binary). The frame format is quite different from what it is without FEC and it also does not have the exact same functionnalities so a different plugin is more practiclal than trying to fit both versions in one plugin.
|
||||
The [SDRdaemon sink output plugin](https://github.com/f4exb/sdrangel/tree/dev/plugins/samplesink/sdrdaemonsink) is the client side of the SDRdaemon transmitter server `sdrdaemontx`. See the [SDRdaemon](https://github.com/f4exb/sdrdaemon) project in this Github repository. You must specify the distant address and UDP port to which the plugin connects and samples from the SDRangel application will flow into the transmitter server (default is `127.0.0.1`port `9092`). It also opens a TCP link to another port to exchange service messages such as setting the center frequency or getting status information from the server (default port is `9093`). The `libnanomsg` library is used to support this messaging.
|
||||
|
||||
Using this scheme the remote operation is more robust in case conditions are not optimal. While SDRdaemon without FEC will work fine on copper or fiber lines the FEC version is recommended for WiFi links where even in good conditions some UDP packets might get lost.
|
||||
The data blocks sent via UDP are protected against loss with a Cauchy MDS block erasure codec. This makes the transmission more robust in particular with WiFi links.
|
||||
|
||||
There is an automated skew rate compensation in place so that the generator throttling is adjusted to match the actual sample rate of the distant device. This is based on the number of buffer blocks sent back from the distant server using the TCP link.
|
||||
|
||||
This plugin will be built only if the libnanomsg and the [CM256cc library](https://github.com/f4exb/cm256cc) are installed in your system. libnanomsg is available as a dev package in most distributions For CM256cc if you install it in a non standard directory you will then have to specify the include and library paths on the cmake command line. Say if you install cm256cc in `/opt/install/cm256cc` you will have to add `-DCM256CC_INCLUDE_DIR=/opt/install/cm256cc/include/cm256cc -DCM256CC_LIBRARIES=/opt/install/cm256cc/lib/libcm256cc.so` to the cmake commands.
|
||||
|
||||
Note that this plugin does not require any of the hardware support libraries nor the libusb library. It is always available in the list of devices as `SDRdaemonFEC[0]` even if no physical device is connected.
|
||||
Note that this plugin does not require any of the hardware support libraries nor the libusb library. It is always available in the list of devices as `SDRdaemonSink[0]` even if no physical device is connected.
|
||||
|
||||
<h1>Channel plugins with special conditions</h1>
|
||||
|
||||
|
|
|
|||
Plik binarny nie jest wyświetlany.
|
Przed Szerokość: | Wysokość: | Rozmiar: 32 KiB |
Plik binarny nie jest wyświetlany.
|
Przed Szerokość: | Wysokość: | Rozmiar: 7.0 KiB |
Plik binarny nie jest wyświetlany.
|
Przed Szerokość: | Wysokość: | Rozmiar: 6.7 KiB |
Plik binarny nie jest wyświetlany.
|
Po Szerokość: | Wysokość: | Rozmiar: 36 KiB |
Plik binarny nie jest wyświetlany.
|
Po Szerokość: | Wysokość: | Rozmiar: 8.2 KiB |
Plik binarny nie jest wyświetlany.
|
Po Szerokość: | Wysokość: | Rozmiar: 5.7 KiB |
Plik binarny nie jest wyświetlany.
|
Po Szerokość: | Wysokość: | Rozmiar: 8.6 KiB |
Plik binarny nie jest wyświetlany.
|
Po Szerokość: | Wysokość: | Rozmiar: 5.8 KiB |
|
|
@ -16,7 +16,7 @@ The BladeRF Host library is also provided by many Linux distributions and is bui
|
|||
|
||||
<h3>1: Common stream parameters</h3>
|
||||
|
||||
|
||||
|
||||
|
||||
<h4>1.1: Frequency</h4>
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ The HackRF Host library is also provided by many Linux distributions and is buil
|
|||
|
||||
<h3>1: Common stream parameters</h3>
|
||||
|
||||
|
||||
|
||||
|
||||
<h4>1.1: Frequency</h4>
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Then add the following defines on `cmake` command line:
|
|||
|
||||
<h3>1: Common stream parameters</h3>
|
||||
|
||||
|
||||
|
||||
|
||||
<h4>1.1: Frequency</h4>
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ If you want to benefit from the direct sampling you will have to compile and ins
|
|||
|
||||
<h3>1: Common stream parameters</h3>
|
||||
|
||||
|
||||
|
||||
|
||||
<h4>1.1: Frequency</h4>
|
||||
|
||||
|
|
|
|||
|
|
@ -2,23 +2,23 @@
|
|||
|
||||
<h2>Introduction</h2>
|
||||
|
||||
This input sample source plugin gets its samples over tbe network from a SDRdaemon server using UDP connection. SDRdaemon refers to the SDRdaemon utility found in [this](https://github.com/f4exb/sdrdaemon) Github repostory. This plugin is specialized in the version of SDRdaemon that sends data with FEC (Forward Erasure Correction). When FEC is used the format of the data is completely different from what it is without FEC.
|
||||
This input sample source plugin gets its samples over tbe network from a SDRdaemon receiver server using UDP connection. SDRdaemon refers to the SDRdaemon utility `sdrdaemonrx`found in [this](https://github.com/f4exb/sdrdaemon) Github repostory.
|
||||
|
||||
The addition of FEC blocks and the sequence tagging of frames and blocks make the transmission more robust. While it is unlikely to be beneficial with copper or fiber links it can improve links over WiFi particularly on distant links.
|
||||
Forward Error Correction with a Cauchy MDS block erasure codec is used to prevent block loss. This can make the UDP transmission more robust particularly over WiFi links.
|
||||
|
||||
Please note that there is no provision for handling out of sync UDP blocks. It is assumed that frames and block numbers always increase with possible blocks missing.
|
||||
Please note that there is no provision for handling out of sync UDP blocks. It is assumed that frames and block numbers always increase with possible blocks missing. Such out of sync situation has never been encountered in practice.
|
||||
|
||||
<h2>Build</h2>
|
||||
|
||||
The plugin will be built only if the [CM256cc library](https://github.com/f4exb/cm256cc) is installed in your system. You will then have to specify the include and library paths on the cmake command line. Say if you install cm256cc in `/opt/install/cm256cc` you will have to add `-DCM256CC_INCLUDE_DIR=/opt/install/cm256cc/include/cm256cc -DCM256CC_LIBRARIES=/opt/install/cm256cc/lib/libcm256cc.so` to the cmake commands.
|
||||
The plugin will be built only if `libnanomsg` and the [CM256cc library](https://github.com/f4exb/cm256cc) is installed in your system. `libnanomasg` is present in most distributions and the dev version can be installed using the package manager. For CM256cc library you will have to specify the include and library paths on the cmake command line. Say if you install cm256cc in `/opt/install/cm256cc` you will have to add `-DCM256CC_INCLUDE_DIR=/opt/install/cm256cc/include/cm256cc -DCM256CC_LIBRARIES=/opt/install/cm256cc/lib/libcm256cc.so` to the cmake commands.
|
||||
|
||||
<h2>Interface</h2>
|
||||
|
||||
|
||||
|
||||
|
||||
<h3>1: Common stream parameters</h3>
|
||||
|
||||
|
||||
|
||||
|
||||
<h4>1.1: Frequency</h4>
|
||||
|
||||
|
|
@ -39,18 +39,35 @@ Record I/Q stresm toggle button
|
|||
|
||||
Stream I/Q sample rate in kS/s
|
||||
|
||||
<h3>2: Auto correction options</h3>
|
||||
<h3>2: Auto correction options and stream status</h3>
|
||||
|
||||
|
||||
|
||||
<h4>2.1: Auto correction options</h4>
|
||||
|
||||
These buttons control the local DSP auto correction options:
|
||||
|
||||
- **DC**: auto remove DC component
|
||||
- **IQ**: auto make I/Q balance
|
||||
|
||||
<h3>3: Date/time</h3>
|
||||
<h4>2.2: Receive buffer length</h4>
|
||||
|
||||
This is the main buffer (writes from UDP / reads from DSP engine) length in units of time (seconds). As read and write pointers are normally about half the buffer apart the nominal delay introduced by the buffer is the half of this value.
|
||||
|
||||
<h4>2.3: Main buffer R/W pointers positions</h4>
|
||||
|
||||
Read and write pointers should always be a half buffer distance buffer apart. This is the difference in percent of the main buffer size from this ideal position.
|
||||
|
||||
- When positive it means that the read pointer is leading
|
||||
- When negative it means that the write pointer is leading (read is lagging)
|
||||
|
||||
This corresponds to the value shown in the gauges above (9)
|
||||
|
||||
<h4>2.4: Date/time</h4>
|
||||
|
||||
This is the current timestamp of the block of data sent from the receiver. It is refreshed about every second. The plugin tries to take into account the buffer that is used between the data received from the network and the data effectively used by the system however this may not be extremely accurate. It is based on the timestamps sent from the SDRdaemon utility at the other hand that does not take into account its own buffers.
|
||||
|
||||
<h3>9: Main buffer R/W pointers gauge</h3>
|
||||
<h3>3: Main buffer R/W pointers gauge</h3>
|
||||
|
||||
There are two gauges separated by a dot in the center. Ideally these gauges should not display any value thus read and write pointers are always half a buffer apart. However due to the fact that a whole frame is reconstructed at once up to ~10% variation is normal and should appear on the left gauge (write leads).
|
||||
|
||||
|
|
@ -59,88 +76,104 @@ There are two gauges separated by a dot in the center. Ideally these gauges shou
|
|||
|
||||
The system tries to compensate read / write unbalance however at start or when a large stream distruption has occured a delay of a few tens of seconds is necessary before read / write reaches equilibrium.
|
||||
|
||||
<h3>4: Stream status and sizes</h3>
|
||||
<h3>4: Forward Error Correction setting and status</h3>
|
||||
|
||||
|
||||
|
||||
|
||||
<h4>4.1: Minimum total number of blocks per frame</h4>
|
||||
<h4>4.1: Desired number of FEC blocks per frame</h4>
|
||||
|
||||
This is the minimum total number of blocks per frame during the last polling period. If all blocks were received for all frames then this number is the nominal number of original blocks plus FEC blocks and the background lits in green.
|
||||
This is the number of FEC blocks per frame set by the user. A frame consists of 128 data blocks (1 meta data block followed by 127 I/Q data blocks) and a variable number of FEC blocks used to protect the UDP transmission with a Cauchy MDS block erasure correction.
|
||||
|
||||
<h4>4.2: Average total number of blocks received by frame</h4>
|
||||
Using the Cauchy MDS block erasure correction ensures that if at least the number of data blocks (128) is received per complete frame then all lost blocks in any position can be restored. For example if 8 FEC blocks are used then 136 blocks are transmitted per frame. If only 130 blocks (128 or greater) are received then data can be recovered. If only 127 blocks (or less) are received then none of the lost blocks can be recovered.
|
||||
|
||||
Moving average over the last 10 frames of the total number of blocks received per frame.
|
||||
<h4>4.2: Total number of frames and number of FEC blocks</h4>
|
||||
|
||||
This is the total number of frames and number of FEC blocks separated by a slash '/' as sent in the meta data block thus acknowledged by the distant server. When you set the number of FEC blocks with (4.1) the effect may not be immediate and this information can be used to monitor when it gets effectively set in the distant server.
|
||||
|
||||
<h4>4.3: Stream status</h4>
|
||||
|
||||
The color of the icon indicates stream status:
|
||||
|
||||
- Green: all original blocks have been received for all frames during the last polling timeframe
|
||||
- Pink: some original blocks were reconstructed from FEC blocks for some frames during the last polling timeframe
|
||||
- No color: some original blocks were definitely lost for some frames during the last polling timeframe
|
||||
- Green: all original blocks have been received for all frames during the last polling timeframe (ex: 136)
|
||||
- No color: some original blocks were reconstructed from FEC blocks for some frames during the last polling timeframe (ex: between 128 and 135)
|
||||
- Red: some original blocks were definitely lost for some frames during the last polling timeframe (ex: less than 128)
|
||||
|
||||
<h4>4.4: Minimum number of original blocks received by frame</h4>
|
||||
<h4>4.4: Minimum total number of blocks per frame</h4>
|
||||
|
||||
Minimum number of original blocks received by frame during the last polling timeframe. Ideally this should match the nominal number of original blocks per frame which is 128 (green lock icon). Anything below the nominal number of original blocks minus FEC blocks means data loss (lock icon off). In betweem FEC is used to recover lost blocks (pink lock icon)
|
||||
This is the minimum total number of blocks per frame during the last polling period. If all blocks were received for all frames then this number is the nominal number of original blocks plus FEC blocks (Green lock icon). In our example this is 128+8 = 136.
|
||||
|
||||
If this number falls below 128 then some blocks are definitely lost and the lock lits in red.
|
||||
|
||||
<h4>4.5: Maximum number of FEC blocks used by frame</h4>
|
||||
|
||||
Maximum number of FEC blocks used for original blocks recovery during the last polling timeframe. Ideally this should be 0 when no blocks are lost but the system is able to correct lost blocks up to the nominal number of FEC blocks (Pink lock icon).
|
||||
Maximum number of FEC blocks used for original blocks recovery during the last polling timeframe. Ideally this should be 0 when no blocks are lost but the system is able to correct lost blocks up to the nominal number of FEC blocks (Neutral lock icon).
|
||||
|
||||
<h4>4.6: Average number of FEC blocks used for original blocks recovery by frame</h4>
|
||||
<h4>4.6: Reset events counters</h4>
|
||||
|
||||
Moving average over the last 10 frames of the number of FEC blocks used for original blocks recovery per frame.
|
||||
This push button can be used to reset the events counters (4.7 and 4.8) and reset the event counts timer (4.9)
|
||||
|
||||
<h4>4.7: Receive buffer length</h4>
|
||||
<h4>4.6: Unrecoverable error events counter</h4>
|
||||
|
||||
This is the main buffer (writes from UDP / reads from DSP engine) length in units of time (seconds). As read and write pointers are normally about half the buffer apart the nominal delay introduced by the buffer is the half of this value.
|
||||
This counter counts the unrecoverable error conditions found (i.e. 4.4 lower than 128) since the last counters reset.
|
||||
|
||||
<h4>4.8: FEC nominal values</h4>
|
||||
<h4>4.6: Recoverable error events counter</h4>
|
||||
|
||||
This is the nominal (Tx side) total number of blocks sent by frame (original blocks plus FEC blocks) and the nominal number of FEC blocks sent by frame separated by a slash (/)
|
||||
This counter counts the unrecoverable error conditions found (i.e. 4.4 between 128 and 128 plus the number of FEC blocks) since the last counters reset.
|
||||
|
||||
<h4>4.9: Main buffer R/W pointers positions</h4>
|
||||
<h4>4.6: events counters timer</h4>
|
||||
|
||||
Read and write pointers should always be a half buffer distance buffer apart. This is the difference in percent of the main buffer size from this ideal position.
|
||||
|
||||
- When positive it means that the read pointer is leading
|
||||
- When negative it means that the write pointer is leading (read is lagging)
|
||||
|
||||
This corresponds to the value shown in the gauges above (9)
|
||||
This hh:mm:ss time display shows the time since the reset evetnts counters button (4.6) was pushed.
|
||||
|
||||
<h3>5: Network parameters</h3>
|
||||
|
||||
|
||||
|
||||
|
||||
<h4>5.1: Local interface IP address</h4>
|
||||
|
||||
Address of the network interface on the local (your) machine to which the SDRdaemon server sends samples to.
|
||||
Address of the network interface on the local (your) machine to which the SDRdaemon Rx server sends samples to.
|
||||
|
||||
<h4>5.2: Local data port</h4>
|
||||
|
||||
UDP port on the local (your) machine to which the SDRdaemon server sends samples to.
|
||||
UDP port on the local (your) machine to which the SDRdaemon Rx server sends samples to.
|
||||
|
||||
<h4>5.3 Distant configuration port</h4>
|
||||
|
||||
TCP port on the distant machine hosting the SDRdaemon instance to send control messages to. The IP address of the host where the SDRdaemon instance runs is guessed from the address sending the data blocks hence it does not need to be specified.
|
||||
TCP port on the distant machine hosting the SDRdaemon Rx instance to send control messages to. The IP address of the host where the SDRdaemon instance runs is guessed from the address sending the data blocks hence the distant address does not need to be specified.
|
||||
|
||||
<h4>5.4: Validation button</h4>
|
||||
|
||||
Whenever the address (6.1), data port (6.2) or configuration port (6.3) change this button is enabled to validate the new values.
|
||||
When the return key is hit within the address (5.1), data port (5.2) or configuration port (5.3) boxes the changes are effective immediately. You can also use this button to set again these values.
|
||||
|
||||
<h3>6: Configuration parameters</h3>
|
||||
<h3>6: Desired center frequency</h3>
|
||||
|
||||
|
||||
This is the center frequency sent to the distant device. This becomes reflected in the main frequency dial (1.1) only when it gets acknowledged by the distant server and this frequency is sent back in the frames meta data.
|
||||
|
||||
<h4>6.1: Center frequency in kHz</h4>
|
||||
Use the wheels to adjust the frequency. Left click on a digit sets the cursor position at this digit. Right click on a digit sets all digits on the right to zero. This effectively floors value at the digit position. The minimum value is 0 Hz and the maximum value is 9.9 GHz. Wheels are moved with the mousewheel while pointing at the wheel or by selecting the wheel with the left mouse click and using the keyboard arroews. Pressing shift simultanoeusly moves digit by 5 and pressing control moves it by 2.
|
||||
|
||||
This is the center frequency in kHz to which the hardware attached to the SDRdaemon instance will get tuned to.
|
||||
<h3>7: Delay between UDP blocks transmission</h3>
|
||||
|
||||
<h4>6.2: Decimation factor</h4>
|
||||
This sets the minimum delay between transmission of an UDP block (send datagram) and the next. This allows throttling of the UDP transmission that is otherwise uncontrolled and causes network congestion.
|
||||
|
||||
These are successive powers of two from 0 (1) to 6 (64). The SDRdaemon instance will decimate the samples coming from the attached hardware by this value. Thus the sample rate (see 7.5) will be decimated by the same value before it is sent over through the network.
|
||||
The value is a percentage of the nominal time it takes to process a block of samples corresponding to one UDP block (512 bytes). This is calculated as follows:
|
||||
|
||||
<h4>6.3: Center frequency position</h4>
|
||||
- Sample rate on the network: _SR_
|
||||
- Delay percentage: _d_
|
||||
- Number of FEC blocks: _F_
|
||||
- There are 127 blocks of I/Q data per frame (1 meta block for 128 blocks) and each I/Q data block of 512 bytes (128 samples) has a 4 bytes header (1 sample) thus there are 127 samples remaining effectively. This gives the constant 127*127 = 16219 samples per frame in the formula
|
||||
|
||||
Formula: ((127 * 127) * _d_ / _SR_) / (128 + _F_)
|
||||
|
||||
<h3>8: Desired distant device sample rate</h3>
|
||||
|
||||
This is the device sample rate sent to the distant device. It will be divided in the distant server by the decimation factor set with (9) to give the actual sample rate over the network. This becomes effective and displayed in (1.4) only when it gets acknowledged by the distant server and this sample rate is sent back in the frames meta data.
|
||||
|
||||
Use the wheels to adjust the sample rate. Left click on a digit sets the cursor position at this digit. Right click on a digit sets all digits on the right to zero. This effectively floors value at the digit position. The minimum value is 32 kS/s and the maximum value is 9.9 MS/s. Wheels are moved with the mousewheel while pointing at the wheel or by selecting the wheel with the left mouse click and using the keyboard arroews. Pressing shift simultanoeusly moves digit by 5 and pressing control moves it by 2.
|
||||
|
||||
<h3>9: Desired distant decimation factor</h3>
|
||||
|
||||
This is the decimation factor to be set in the distant server downsampler. The hardware device sample rate is divided by this factor before the I/Q blocks are sent over the network. The actual network sample rate becomes effective and displayed in (1.4) only when it gets acknowledged by the distant server and this sample rate is sent back in the frames meta data.
|
||||
|
||||
<h3>10: Center frequency position</h3>
|
||||
|
||||
The center frequency in the passband wil be set either:
|
||||
|
||||
|
|
@ -148,16 +181,10 @@ The center frequency in the passband wil be set either:
|
|||
- above the local oscillator (NCO) or supradyne. Actually +1/4th the bandwidth.
|
||||
- centered on the local oscillator or zero IF.
|
||||
|
||||
<h4>6.4: Send data to the distant SDRdaemon instance</h4>
|
||||
|
||||
Whenever any of the parameters change this button gets enabled. When clicked a message is sent on the configuration port of the distant machine to which the SDRdaemon listens for instructions. Leave time for the buffering system to stabilize to get the samples flow through normally.
|
||||
|
||||
<h4>6.5: Sample rate in kS/s</h4>
|
||||
|
||||
The sample rate of the hardware device attached to the SDRdaemon instance will be set to this value in kS/s.
|
||||
|
||||
<h4>6.6: Other parameters hardware specific</h4>
|
||||
<h4>11: Other parameters hardware specific</h4>
|
||||
|
||||
These are the parameters that are specific to the hardware attached to the distant SDRdaemon instance. You have to know which device is attached to send the proper parameters. Please refer to the SDRdaemon documentation or its line help to get information on these parameters.
|
||||
|
||||
In addition you can specify the inter-block transmission delay (txdelay) and number of FEC blocks per frame (fecblk).
|
||||
<h4>12: Send data to the distant SDRdaemon Rx instance</h4>
|
||||
|
||||
When any of the parameters change they get immediately transmitted to the distant server over the TCP link. You can however use this button to send again the complete configuration. This is handy if for some reason you are unsure of the parameters set in the distant server.
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue