Pluto - Issue with 'Manual' RX-Gain setting #adalmpluto


Jean (DJ0VL)
 

Hi,

With Pluto RX-Gain set to 'Manual' (default gain 50dB, visual gain -30dB), the initialization seems to fail from time to time when starting the radio (either after program start or after stopping and restarting the radio, as shown in the screenshot). The overall gain is then significantly lower, either manual gain must be rised to maximum or visual gain must be set to around 0dB to get a spectrum/waterfall comparable to the default condition. Changing RX-gain to something else than 'Manual' does not show the issue. Manually changing the RX-Gain leads to the same issue. I have to power-cycle the Pluto in order to recover to normal usage.
Looking at the logfile, I see two error entries "Radio PlutoSDR> Error writing Channel attribute voltage_filter_fir_en = 1, error 22, Invalid argument" and "Radio PlutoSDR> Error writing Channel attribute hardwaregain = 50, error 95, Unknown error", but unsure if there is a relation to these error entries.

This occurs with console 3.0.24 as well as with at least 3.0.23. There is also no difference in using the bundled libiio.dll (which seems to be v0.17) or using the current libiio.dll version 0.21.

Is there a workaround apart from not using manual RX-Gain setting?


73 Jean DJ0VL


Siegfried Jackstien
 

here for me that base setting of 50 db is a bit low ... depending on lnb used i need 60 to 70 db (with visual gain to -30) ... then the base noise (transponder noise) is at 0 dbuv (easier to calculate levels that way) and the cw beacon is a solid s9

so just try it with a bit higher setting ... when switching between manual and auto the levels should not change (much) so i set the manual gain to show same as when using autogain ... that worked fine here

no idea about the error but maybe simon can explain it

greetz sigi dg9bfc

Am 15.08.2020 um 10:24 schrieb Jean (DJ0VL):

Hi,

With Pluto RX-Gain set to 'Manual' (default gain 50dB, visual gain -30dB), the initialization seems to fail from time to time when starting the radio (either after program start or after stopping and restarting the radio, as shown in the screenshot). The overall gain is then significantly lower, either manual gain must be rised to maximum or visual gain must be set to around 0dB to get a spectrum/waterfall comparable to the default condition. Changing RX-gain to something else than 'Manual' does not show the issue. Manually changing the RX-Gain leads to the same issue. I have to power-cycle the Pluto in order to recover to normal usage.
Looking at the logfile, I see two error entries "Radio PlutoSDR> Error writing Channel attribute voltage_filter_fir_en = 1, error 22, Invalid argument" and "Radio PlutoSDR> Error writing Channel attribute hardwaregain = 50, error 95, Unknown error", but unsure if there is a relation to these error entries.

This occurs with console 3.0.24 as well as with at least 3.0.23. There is also no difference in using the bundled libiio.dll (which seems to be v0.17) or using the current libiio.dll version 0.21.

Is there a workaround apart from not using manual RX-Gain setting?


73 Jean DJ0VL


jdow
 

Um, er use dBm and fiddle visual gain to get what you want?

Watching test-team leads me to suspect Simon is reaching the point that new features introduce new faults in totally unrelated portions of the system. If it isn't broken and a work around exists for a feature such as this, don't fix it. Nobody knows what else will break.

{^_^}

On 20200815 07:43:57, Siegfried Jackstien wrote:

here for me that base setting of 50 db is a bit low ... depending on lnb used i need 60 to 70 db (with visual gain to -30) ... then the base noise (transponder noise) is at 0 dbuv (easier to calculate levels that way) and the cw beacon is a solid s9

so just try it with a bit higher setting ... when switching between manual and auto the levels should not change (much) so i set the manual gain to show same as when using autogain ... that worked fine here

no idea about the error but maybe simon can explain it

greetz sigi dg9bfc

Am 15.08.2020 um 10:24 schrieb Jean (DJ0VL):
Hi,

With Pluto RX-Gain set to 'Manual' (default gain 50dB, visual gain -30dB), the initialization seems to fail from time to time when starting the radio (either after program start or after stopping and restarting the radio, as shown in the screenshot). The overall gain is then significantly lower, either manual gain must be rised to maximum or visual gain must be set to around 0dB to get a spectrum/waterfall comparable to the default condition. Changing RX-gain to something else than 'Manual' does not show the issue. Manually changing the RX-Gain leads to the same issue. I have to power-cycle the Pluto in order to recover to normal usage.
Looking at the logfile, I see two error entries "Radio PlutoSDR> Error writing Channel attribute voltage_filter_fir_en = 1, error 22, Invalid argument" and "Radio PlutoSDR> Error writing Channel attribute hardwaregain = 50, error 95, Unknown error", but unsure if there is a relation to these error entries.

This occurs with console 3.0.24 as well as with at least 3.0.23. There is also no difference in using the bundled libiio.dll (which seems to be v0.17) or using the current libiio.dll version 0.21.

Is there a workaround apart from not using manual RX-Gain setting?


73 Jean DJ0VL


Jean (DJ0VL)
 

After some more testing, the issue seems to be related to the visual gain setting at first start. After setting the visual gain to 0dB (and slightly adjusting the low dispaly levels), I do no longer see the issue when manually changing the RF-Gain or when stopping an restarting the radio. Interestingly, after changing the visual gain setting from the default setting of -30dB, the "Radio PlutoSDR> Error writing Channel attribute hardwaregain = 50, error 95, Unknown error" does no longer show up in the logfile. The other error is still there but seems to be related to some other issue.

@Sigi; I'm fine with 50dB hardware gain, as I can lower the gain to 30dB before the SNR starts to decrease. So there is plenty of headroom with 50dB hardware gain (at least with my LNB setup and some 20dB of additional attenuation in the LNB interface).
As far as I know, signal levels of 54 dB over noise are technically not possible on the qo-100. Adjusting the gain for a noisefloor at 0dBuV and then switching the scale to S-Units shows indeed around S9 for the beacon - however  the noise is at S3-S4 with that setting. I do not see much value in using S-Units on the qo-100 as you can fiddle with the gains to get whatever value you want. The IARU recommendation for S9 differs between HF and VHF, setting the noisefloor to -20dBuV results in a more realistic S5-S6 for the CW-beacon in respect of the beacon SNR.

@jdow: I hope you are wrong when you suspect that new features introduce new issues in unrelated parts of the SDR console. For me, this would be a clear indication to step back and seriously question my development process. 

73 Jean DJ0VL


jdow
 

On 20200816 03:51:55, Jean (DJ0VL) wrote:
@jdow: I hope you are wrong when you suspect that new features introduce new issues in unrelated parts of the SDR console. For me, this would be a clear indication to step back and seriously question my development process. 

73 Jean DJ0VL

This is a known phenomenon when adding features to a project that already meets its original specifications. The new requirements were not known at the time the design was made. So choices that limit certain sorts of changes get made for one reason or another. Adding this new feature that was not provisioned for in the design can lead to violating the original design structure leading to odd seeming failures. This is probably what led Simon to move into V3 rather than simply improving V2. He was able to add features that were exceptionally difficult to add to V2 by simply starting over. He probably recycled much or most of the working code. But I bet the internal structure is noticeably different.

{^_^}


Jean (DJ0VL)
 

Just adding that the issue is still there on first start of the radio after powering on the Pluto and visual gain set to 0dB . I have to touch the hardware gain setting to get the display back to normal. Seems like the hardware gain is set to maximum (73dB) after starting a newly powered on Pluto. When this occuirs, the "Radio PlutoSDR> Error writing Channel attribute hardwaregain = 50, error 95, Unknown error" appears in the logfile.

73 Jean


Siegfried Jackstien
 

Yepp... You can set your s units wherever you want...
Setting transponder noise to 0dvuv is just an easy to reproduce setting... And you can easy see levels avove noise as plus values... 
Setting cw beacon to s9 or a few db above with s bit bigger dish givrs also "fair" reports
3by5
4b7
5by9
So that why i set it that way... Easier readout as positive numbers from 0dbuv upwards... And reports do match the s meter and readability 3by5 to 5by9
Ok some may say s3 as base is a bit high... And set that to s0...but for me above settings is easy... Give fair results.. And no need to calculate backwards from minus 104 to minus 86 dbm... (or whatever you have setup your scale)
Greetz sigi dg9bfc 

Am 16.08.2020 14:06 schrieb jdow <jdow@...>:

On 20200816 03:51:55, Jean (DJ0VL) wrote:
@jdow: I hope you are wrong when you suspect that new features introduce new issues in unrelated parts of the SDR console. For me, this would be a clear indication to step back and seriously question my development process. 

73 Jean DJ0VL

This is a known phenomenon when adding features to a project that already meets its original specifications. The new requirements were not known at the time the design was made. So choices that limit certain sorts of changes get made for one reason or another. Adding this new feature that was not provisioned for in the design can lead to violating the original design structure leading to odd seeming failures. This is probably what led Simon to move into V3 rather than simply improving V2. He was able to add features that were exceptionally difficult to add to V2 by simply starting over. He probably recycled much or most of the working code. But I bet the internal structure is noticeably different.

{^_^}


Siegfried Jackstien
 

Sorry for typos... Banging on tiny smartphone

Am 16.08.2020 14:20 schrieb Siegfried.Jackstien@...:

Yepp... You can set your s units wherever you want...
Setting transponder noise to 0dvuv is just an easy to reproduce setting... And you can easy see levels avove noise as plus values... 
Setting cw beacon to s9 or a few db above with s bit bigger dish givrs also "fair" reports
3by5
4b7
5by9
So that why i set it that way... Easier readout as positive numbers from 0dbuv upwards... And reports do match the s meter and readability 3by5 to 5by9
Ok some may say s3 as base is a bit high... And set that to s0...but for me above settings is easy... Give fair results.. And no need to calculate backwards from minus 104 to minus 86 dbm... (or whatever you have setup your scale)
Greetz sigi dg9bfc 

Am 16.08.2020 14:06 schrieb jdow <jdow@...>:
On 20200816 03:51:55, Jean (DJ0VL) wrote:
@jdow: I hope you are wrong when you suspect that new features introduce new issues in unrelated parts of the SDR console. For me, this would be a clear indication to step back and seriously question my development process. 

73 Jean DJ0VL

This is a known phenomenon when adding features to a project that already meets its original specifications. The new requirements were not known at the time the design was made. So choices that limit certain sorts of changes get made for one reason or another. Adding this new feature that was not provisioned for in the design can lead to violating the original design structure leading to odd seeming failures. This is probably what led Simon to move into V3 rather than simply improving V2. He was able to add features that were exceptionally difficult to add to V2 by simply starting over. He probably recycled much or most of the working code. But I bet the internal structure is noticeably different.

{^_^}



Jean (DJ0VL)
 

Hello jdow,

I completely agree with your writing. This occurs when the original requirements did not stipulate design for maintainability and if change management is not strictly handled. However I doubt that these kind of process requirements can be handled in a stringend way by a single developper working without a big support team. You are right, is such cases the way-out often is a time-consuming redesign.

73 Jean DJ0VL


jdow
 

Even specifying maintainability is insufficient if you do not consider the direction that design extension will take. There are so many tradeoffs inherent in the design process that it's easy to miss something.

One sage in my software life suggested you get the design basically finished, junk it, erase it completely, and stat over with everything you learned was wrong with the way it was done the first time.

{^_^}

On 20200816 05:34:30, Jean (DJ0VL) wrote:
Hello jdow,

I completely agree with your writing. This occurs when the original requirements did not stipulate design for maintainability and if change management is not strictly handled. However I doubt that these kind of process requirements can be handled in a stringend way by a single developper working without a big support team. You are right, is such cases the way-out often is a time-consuming redesign.

73 Jean DJ0VL