VE7UWU/sdrangel
1
0
Fork 0
mirror of https://github.com/f4exb/sdrangel.git synced 2024-11-04 16:01:14 -05:00
Code Issues Projects Releases Wiki Activity

SDRdaemon plugin: control from the plugin documentation update

Browse Source
This commit is contained in:
f4exb 2016-03-27 22:16:23 +02:00
parent 27b6aab5f7
commit 8acfaa0458
5 changed files with 64 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Readme.md
View File

@ -199,7 +199,7 @@ You should take note that the Windows scheduler is just a piece of crap and not
There are no plugins for both flavours of Funcubes since it uses Alsa interface which is Linux exclusively. Changing for the Qt audio portable interface instead could be a solution that will be investigated in the future. There are no plugins for both flavours of Funcubes since it uses Alsa interface which is Linux exclusively. Changing for the Qt audio portable interface instead could be a solution that will be investigated in the future.
The SDRdaemon plug-in does not work mainly due to the fact that it needs an OS with a decent scheduler and Windows is definitely not this sort of OS (see my previous warning). It is kept there only to demonstrate how a crippled OS is Windows. If you want to use this plugin get yourself a decent OS first i.e. Linux. The SDRdaemon plug-in has been removed since version 1.1.4 in fact it is present only in version 1.1.3. It was not working well anyway mainly due to the fact that it needs an OS with a decent scheduler and Windows is definitely not this sort of OS (see my previous warning). With the implementation of the remote control of the SDRdaemon instance it is not working at all. I don't want to bother anymore with this. For now on it will be present in the Linux version on;y where it works beautifully.
<h3>Build environment</h3> <h3>Build environment</h3>

BIN
doc/img/SDRdaemon_plugin.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 36 KiB

BIN
doc/img/SDRdaemon_plugin_06.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 5.6 KiB

BIN
doc/img/SDRdaemon_plugin_07.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

86
plugins/samplesource/sdrdaemon/readme.md
View File

@ -2,7 +2,7 @@
<h2>Introduction</h2> <h2>Introduction</h2>
This input samples 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 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.
<h2>Interface</h2> <h2>Interface</h2>
@ -21,7 +21,7 @@ These buttons control the DSP auto correction options:
<h3>3: Date/time</h3> <h3>3: Date/time</h3>
This is the current timestamp of the block of data sent from the receiver. IT is refreshed about every second This is the current timestamp of the block of data sent from the receiver. It is refreshed about every second. This may not and is usually not the timestamp of the samples currently shown in the displays and in the audio since there is a failty large buffer in place to damper the network varying speed (see: 5.5: Main buffer length in seconds).
<h3>9: Main buffer R/W pointers gauge</h3> <h3>9: Main buffer R/W pointers gauge</h3>
@ -34,27 +34,27 @@ There are two gauges separated by a dot in the center. Ideally these gauges shou
![SDR Daemon status1 GUI](/doc/img/SDRdaemon_plugin_04.png) ![SDR Daemon status1 GUI](/doc/img/SDRdaemon_plugin_04.png)
<h4>1: Stream lock</h4> <h4>4.1: Stream lock</h4>
Turns green when stream is locked to meta data. Meta data carries the number of UDP packets in following frame. Lock status is obtained when the correct number of UDP packets have been received when the next meta data block occurs. Turns green when stream is locked to meta data. Meta data carries the number of UDP packets in following frame. Lock status is obtained when the correct number of UDP packets have been received when the next meta data block occurs.
<h4>2: Frame size</h4> <h4>4.2: Frame size</h4>
Data is sent in frames with one meta data header. This is the size of such a frame. Frames may be compressed however the frame will be copied uncompressed to the main buffer. Data is sent in frames with one meta data header. This is the size of such a frame. Frames may be compressed however the frame will be copied uncompressed to the main buffer.
<h4>3: Sample rate as sent in the meta data</h4> <h4>4.3: Sample rate as sent in the meta data</h4>
The receiver sends the stream data rate with this nominal value The receiver sends the stream data rate with this nominal value
<h4>4: Actual stream sample rate</h4> <h4>4.4: Actual stream sample rate</h4>
When the auto follow sample rate is engaged the actual system sample rate may differ from the nominal sample rate sent in the meta data. This is the actual system sample rate. When the auto follow sample rate is engaged the actual system sample rate may differ from the nominal sample rate sent in the meta data. This is the actual system sample rate.
<h4>5: Skew rate</h4> <h4>4.5: Skew rate</h4>
This is the difference in percent between nominal sample rate sent in the meta data and actual system sample rate This is the difference in percent between nominal sample rate sent in the meta data and actual system sample rate
<h4>6: Main buffer R/W pointers positions</h4> <h4>4.6: 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. 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.
@ -67,46 +67,86 @@ This corresponds to the value shown in the gauges above (9)
![SDR Daemon status2 GUI](/doc/img/SDRdaemon_plugin_05.png) ![SDR Daemon status2 GUI](/doc/img/SDRdaemon_plugin_05.png)
<h4>1: Compressed stream</h4> <h4>5.1: Compressed stream</h4>
When lit in green it means the stream is compressed using LZ4. When lit in green it means the stream is compressed using LZ4.
<h4>2: Compression ratio</h4> <h4>5.2: Compression ratio</h4>
This is the ratio between the compressed data size and the original data size. This is the ratio between the compressed data size and the original data size.
<h4>3: CRC OK ratio</h4> <h4>5.3: CRC OK ratio</h4>
This is the percentage of received data blocks with a correct CRC. It should be as closed to 100% as possible. This is the percentage of received data blocks with a correct CRC. It should be as closed to 100% as possible.
<h4>4: LZ4 successful decodes ratio</h4> <h4>5.4: LZ4 successful decodes ratio</h4>
This is the percentage of LZ4 data blocks that were successfully uncompressed. It should be as closed to 100% as possible. This is the percentage of LZ4 data blocks that were successfully uncompressed. It should be as closed to 100% as possible.
<h4>5: Main buffer length in seconds</h4> <h4>5.5: Main buffer length in seconds</h4>
This is the main buffer (writes from UDP / reads from DSP engine) length in units of time (seconds). Initially the write pointer is at the start of buffer and the read pointer is on the middle. Thus it takes half a buffer length in time to get the first useful sample. This is the main buffer (writes from UDP / reads from DSP engine) length in units of time (seconds). Initially the write pointer is at the start of buffer and the read pointer is on the middle. Thus it takes half a buffer length in time to get the first useful sample. The minimum length is 8s and can be as long as to fit 50 average read chunks.
<h4>6: Reset buffer indexes push button</h4> <h4>5.6: Reset buffer indexes push button</h4>
This forces the write and read pointers in their initial position regardless of the contents of the buffer. The write pointer position is set at the start of buffer and the read pointer position is set at the middle. This forces the write and read pointers in their initial position regardless of the contents of the buffer. The write pointer position is set at the start of buffer and the read pointer position is set at the middle.
<h4>7: Auto lock main buffer R/W pointers position toggle</h4> <h4>5.7: Auto lock main buffer R/W pointers position toggle</h4>
When set it engages the auto lock of R/W pointers position. It will try to maintain a half buffer distance between read and write pointers. When set it engages the auto lock of R/W pointers position. It will try to maintain a half buffer distance between read and write pointers.
<h4>8: Auto lock to actual stream sample rate</h4> <h4>5.8: Auto lock to actual stream sample rate</h4>
This is rarely necessary. Only use it when you suspect that the sender data sample rate is not exactly as advertised in the meta data. This is normally exclusive of the auto lock R/W pointers position however the GUI allows both. You are advised to chose only one of the two. This is rarely necessary. Only use it when you suspect that the sender data sample rate is not exactly as advertised in the meta data. This is normally exclusive of the auto lock R/W pointers position however the GUI allows both. You are advised to chose only one of the two.
<h3>6: Interface IP address</h3> <h3>6: Network parameters</h3>
Address of the network interface on your machine to which the SDRdaemon server sends samples to. ![SDR Daemon status3 GUI](/doc/img/SDRdaemon_plugin_06.png)
<h3>7: Data port</h3> <h4>6.1: Interface IP address</h4>
UDP port on your machine to which the SDRdaemon server sends samples to. Address of the network interface on the local (your) machine to which the SDRdaemon server sends samples to.
<h3>8: Validation button</h3> <h4>6.2: Data port</h4>
Whenever the address (6) or data port (7) change this button is enabled to validate the new values. UDP port on the local (your) machine to which the SDRdaemon server sends samples to.
<h4>6.3 Configuration port<h4>
TCP port on the distant machine hosting the SDRdaemon instance to send control messages to.
<h4>6.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.
<h3>7: Configuration parameters</h3>
![SDR Daemon status4 GUI](/doc/img/SDRdaemon_plugin_07.png)
<h4>7.1: Center frequency in kHz</h4>
This is the center frequency in kHz to which the hardware attached to the SDRdaemon instance will get tuned to.
<h4>7.2: Decimation factor</h4>
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.
<h4>7.3: Center frequency position</h4>
The center frequency in the passband is either:
- below the local oscillator (NCO) or infradyne. Actually -1/4th the bandwidth.
- above the local oscillator (NCO) or supradyne. Actually +1/4th the bandwidth.
- centered on the local oscillator or zero IF.
<h4>7.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 distance machine to which the SDRdaemon listens for instructions. Leave time for the buffering system to stabilize to get the samples flow through normally.
<h4>7.5: Sample rate in kS/s</h4>
This is the sample rate in kS/s of the samples sent from the hardware device to the SDRdaemon instance
<h4>7.6: 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 on line help to get information on these parameters.