SoapySDR and BladeRF

[GkvJeep]

There is a "murder". Why overwrite the memory?

2018-11-24 22:35:05.694 (D) SoapySDRInput::applySettings: device argument erase_stored_fpga set to true [INFO @ host/libraries/libbladeRF/src/backend/usb/usb.c:455] Erasing 55 blocks starting at block 4 [INFO @ host/libraries/libbladeRF/src/backend/usb/usb.c:460] Erased block 58 [INFO @ host/libraries/libbladeRF/src/backend/usb/usb.c:468] Done erasing 55 blocks 2018-11-24 22:37:11.932 (D) SoapySDRInput::applySettings: device argument flash_firmware set to [ERROR] bladeRF: The provided firmware file path is empty 2018-11-24 22:37:33.926 (D) SoapySDRInput::applySettings: device argument flash_fpga set to [ERROR] bladeRF: The provided FPGA image path is empty 2018-11-24 22:37:53.749 (D) SoapySDRInput::applySettings: device argument jump_to_bootloader set to true

[GkvJeep]

Part two. After commented out the call for (const auto &oname : m_settings.m_deviceArgSettings.keys()). A new window appeared with the flag set Erase the FPGA region of flash.

Small visualization problem under LO PPM

[f4exb]

Never use SoapySDR with BladeRF see: https://github.com/f4exb/sdrangel/tree/master/plugins/samplesource/soapysdrinput#bladerf

This is an issue with the support of BladeRF in SoapySDR. This does not concern SDRangel.

As mentioned there is no point in using SoapySDR for BladeRF. BladeRF v1 and v2 are supported natively in SDRangel.

[GkvJeep]

Got it. Read the documentation carefully. Did you get my letter ?

[f4exb]

I'm afraid I lost it. Can you resend please?

[f4exb]

Will try the fix and amend comments if successful

[guruofquality]

It would be nice to know which bugs to fix rather than documenting not to use things: If no one says anything or makes PR, I have no idea what to fix:

It is very important NOT to use SoapySDR. The default parameters are set to flash the FPGA but as this does not suceeds it results in a FPGA image wipe out and the device returns in "Cypress" mode. It is not too difficult to recover but there is no point risking the hassle.

Someone added support for the flash API. I presume its useful, and potentially dangerous. I guess the settings for writeSetting() might get casually re-applied for sdrangel? I don't know, but its reasonable to make changes here. FWIW I just changed the default value for erase to false so it wont do that if the default is applied.

When installed the Red Pitaya SoapySDR plugin lists a Red Pitaya device even if there is no Red Pitaya attached. Trying to select and start it when there is no Red Pitaya will result in program crash.

Theres a whole class of super lazy devices with no way to enumerate or discover them. So who ever contributes it hard-codes an IP address or something. And this is always pretty annoying and causes a problem.

I have made changes to a few of these drivers like red pitaya and pluto sdr so they will not discover anything unless an address is explicitly specified -- or in the case of red pitaya, the driver is explicitly specified as well: https://github.com/pothosware/SoapyRedPitaya/blob/master/SoapyRedPitaya.cpp#L527

That aside if there is a segfault from the driver (and not the application). I backtrace would be appreciated, or something like that so it can be fixed.

[f4exb]

I cannot make any assumptions on what to do or not what to do depending on a particular hardware. As advertised SoapySDR is vendor neutral so it is up to the vendors to do things right. Let's make things clear: I am trying to implement things based on the SoapySDR interface (Device.hpp, Types.hpp) no more no less (in fact a little bit less at the moment).

Edit: BTW concerning BladeRF in my opinion the possibility to update FPGA from SoapySDR should be removed entirely. This is a maintenance thing and can be performed safer and better with the BaldeRF CLI utility maintained by the BladeRF guys. One should not mix maintenance and application business.

[guruofquality]

In practice, SoapySDR support modules are basically community driver. Someone with the hardware volunteers the initial support. Others may add features as needed (pull requests), make bug reports, etc. I package software, and review changes. But I don't often have the hardware, but when I do it definitely helps development. FWIW nuand did send me a bladerf which is great. :-)

The crash with bladerf involves writing the default values for the flash settings. I don't think that writing defaults should be dangerous. Its a problem that I now know about, so I fixed it. CubicSDR which does something similar doesn't write the defaults for these settings, so the issue never came up. Thats why I need to know about things like this, ideally on the issue tracker. https://github.com/pothosware/SoapyBladeRF/issues/24

Edit: BTW concerning BladeRF in my opinion the possibility to update FPGA from SoapySDR should be removed entirely. This is a maintenance thing and can be performed safer and better with the BaldeRF CLI utility maintained by the BladeRF guys. One should not mix maintenance and application business.

I agree. Its a bit overkill. But someone was nice enough to contribute the software hooks and other less dangerous things too. I think a good compromise might be a flags to indicate "ADVANCED" setting in a future API. This would separate the safe, tame, normal settings from the unusual "special" ones -- which I am sure other devices have too. It would be up to applications to show/hide/or use separate advanced tab for settings marked this way.

[f4exb]

The "advanced" flag can be a good idea indeed and I would implement it on application side. The defaults of these settings would still have to be harmless.

[f4exb]

Not sure on how to carry on with this. A dedicated ticket can be open when the "advanced" indication is available from SoapySDR.