Windows libbladeRF and Pothos

[mando238]

I've been using my bladerfx115 with matlab (on Windows 10) and GNU radio without any problems for a while. However, all of a sudden I began running into problems on the windows machine with error messages 100% of the time that can vary in content but are all along the lines of missing functions in libbladeRF. I Pulled up bladerf-cli and look what showed up in the attached image...
Both the bladerf-cli and the libbladeRF are now saying
bladeRF-cli version: 1.5.0-PothosSDR-2017.11.01-vc14-x64
libbladeRF version: 1.8.0-PothosSDR-2017.11.01-vc14-x64
Instead of the usual just-the-version number (i.e. 1.7.2) they display this whole title. I recently installed Pothos SDR (on the Windows 10 X64 machine) so perhaps whatever (modified libbladeRF?) they are using is causing issues. Shouldn't be a big deal I figured I just needed to restore libbladeRF. However, I've tried to reinstall libbladeRF with the windows installer, it succeeds, and I can see all of the files in the correct place, but still bladerf-cli displays the PothosSDR version.

So I did the where command and I get the following:
C:\Users\XXXXXX>where bladerf-cli.exe
C:\Program Files\PothosSDR\bin\bladeRF-cli.exe
C:\Program Files\bladeRF\x64\bladeRF-cli.exe

Makes sense, looks like Pothos just messed with the global environment variables - the windows installer (which I've re-run) for bladerf says that it will add variables to the system path, yet when I go to environment variables in windows I see plenty for Pothos but nothing for nuand/bladerf. Additionally MATLAB still seems to be referencing the core libbladerf directory, so it should have been unaffected.

Sooo... but does anyone have any insight as to how I would resolve this (or investigate it further)? Basically I'm just looking to get pure libbladeRF back without tearing up my system too much - and keeping PothosSDR working if possible.
I apologize if this is going to have some trivial answer, I googled around tried some things but I suspect I'm missing something obvious....

[RadioGuy]

It's been a long time since I've used Windows much, but if memory serves me most applications put shared DLLs in c:\windows\system32\. The 32 part of system may be different since your using 64 bit. Like I said, it's been a long time since I used Windows.

Anyway, one thing you can try is finding libbladerf in this shared directory, back it up somewhere like a temp directory, and manually xcopy libbraderf from the standard release over top of the one PontosSDR installed.

It's not a perfect solution, but there is a good chance it will get bladerf-cli and matlab working again. Probably will break pothos SDR through. And if it doesn't work, you can xcopy the backup file into the shared location.

[RadioGuy]

BTW, another tool to use on Windows is find

You can run "find /s" and you can do a search on your drive to see all the copies and locations of libbladerf that have been installed.

Hope this helps.

[mando238]

Thanks for the reply, I tried a version of the above and got things manually set (it was searching for the .dll in a /bin folder in the pothos directory, thats been fixed and libbladerf version was now correct) but still ran into problems. So I remove pothos completely and re-ran the windows installer and now everything prints as it should in blade-rf cli. With all that said I might have been following a red herring as the following issue persists -

I still cannot upload images for some reason so here they are from imageur:
https://imgur.com/cFTW7nd
It starts with the same no functions found - whats new is that this message is always the same functions now, this will happen once, then if I try to run it again:
https://imgur.com/7rwUpUI
This exact error will happen once, from that point on I will always get the error of "no device available", in the same way that if another application was using it one can't open the device.

Thinking back to when all of this started, I'm pretty sure it was right after I re-ran the latest windows installer so I could use the bladerf with my new installation of the R2017b version of matlab as well (had been using in R2015/R2016). Before that I had been using libbladerf 1.7.2, now it is 1.9.0 and the Pothos one was 1.8.0.
I looked through the current source code and it looks like the supposedly missing functions are still in 1.9.0, nonetheless I think its worth trying 1.7.2 again to see if this is somehow connected to the new library.
Are there old versions of the already compiled bladeRF.dll's somewhere? Specifically 1.7.2? If not I guess I'll try to compile it from an archived Github libbladeRF source release later this week.

-- EDIT/SOLUTION--
So after this taking a very roundabout way of figuring things out, I was able to get things working again using the 2016 rc2 installer from here: http://www.nuand.com/installers.php.I did have to manually delete my bladerf directory from the drive though, the uninstaller/re-installer itself would leave the current matlab bindings that cause the issue, and because I'm and idiot I never had actually gone back and verified that the files were being changed to the correct versions...
I believe there is an issue with the thunkfile/matlab bindings from the new 2017 December release as libbladeRF itself seems to contain everything it should. 2 other users had the same issue as me with the current release (viewtopic.php?f=10&p=7627#p7627 and viewtopic.php?f=9&p=7628#p7628)

[rtucker]

Greetings...

I have a new build that should hopefully work... if you could, please give it a try and let us know how it goes.

The link to it is over in another thread: viewtopic.php?f=10&p=7627#p7698

Thanks! -rt