Osmocom does not work in gnuradio companion

[doug mcdonald]

I finally got a working gtk installed and now Gnu Radio Companion works fine until
I try using my hackRF through Osmocom. Mainly I'm wanting a transmitter, but a
receiver gives the same error: Here it is

Traceback (most recent call last):

  File "C:/NewPrograms/hackrfprograms/top_block.py", line 26, in <module>

    import osmosdr

  File "C:\Program Files\PothosSDR\lib\site-packages\osmosdr\__init__.py", line 26, in <module>

    from osmosdr_swig import *

  File "C:\Program Files\PothosSDR\lib\site-packages\osmosdr\osmosdr_swig.py", line 28, in <module>

    _osmosdr_swig = swig_import_helper()

  File "C:\Program Files\PothosSDR\lib\site-packages\osmosdr\osmosdr_swig.py", line 24, in swig_import_helper

    _mod = imp.load_module('_osmosdr_swig', fp, pathname, description)

ImportError: DLL load failed: The specified module could not be found.

***************
This sounds like a path error ...  _osmosdr_swig.pyd is a dll ... is this it? That file is there
in the same directory as other osmocom.py(ocd) files. I tried copying it around to various places and that
didn't work.

[Josh Blum]

>
> ImportError: DLL load failed: The specified module could not be found.
>
> ***************
> This sounds like a path error ... _osmosdr_swig.pyd is a dll ... is this
> it? That file is there
> in the same directory as other osmocom.py(ocd) files. I tried copying it
> around to various places and that
> didn't work.
>

Often, this error means that _osmosdr_swig.pyd is found in the
PYTHONPATH, however it cant find a dependency DLL, like hackrf.dll or
boost_something.dll... in general all required DLLs should be in
C:\Program Files\PothosSDR\bin, however I have two suggestions:

1) Some of the pre-built libraries (like pthread) that I used are linked
with osmosdr and hackrf. Unfortunately, some of these pre-built
libraries require vc2010 runtime, which may or may not be available on
the system already.

Does the following command work?
c:\Program Files\PothosSDR\bin\hackrf_info.exe

If you get an error about missing VC runtime, then you will need this:
https://www.microsoft.com/en-us/download/details.aspx?id=13523

Let me know if thats the case so I can update the instructions. However,
if that is not the case....

2) Dependency walker http://www.dependencywalker.com/ is a useful way to
find out missing runtime dlls. You can run dependency walker and open
"_osmosdr_swig.pyd" to find out what dlls are missing.

Let me know what you find,
-josh

[doug mcdonald]

The first test passed.

The dependency thing failed. The file list is,
where before the two returns are files not found

MSVCR110.DLL
API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL
CONCRT140.DLL
DCOMP.DLL
IESHIMS.DLL
API-MS-WIN-CORE-THREADPOOL-L1-1-0.DLL
OLE32.DLL
DWMAPI.DLL
ESENT.DLL
IEFRAME.DLL
IMM32.DLL
MFPLAT.DLL
NCRYPT.DLL
NDFAPI.DLL
USERENV.DLL
UXTHEME.DLL
_OSMOSDR_SWIG.PYD
ADVAPI32.DLL
AIRSPY.DLL
API-MS-WIN-CORE-CONSOLE-L1-1-0.DLL
API-MS-WIN-CORE-DATETIME-L1-1-0.DLL
API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
API-MS-WIN-CORE-DELAYLOAD-L1-1-0.DLL
API-MS-WIN-CORE-ERRORHANDLING-L1-1-0.DLL
API-MS-WIN-CORE-FIBERS-L1-1-0.DLL
API-MS-WIN-CORE-FILE-L1-1-0.DLL
API-MS-WIN-CORE-FILE-L1-2-0.DLL
API-MS-WIN-CORE-FILE-L2-1-0.DLL
API-MS-WIN-CORE-HANDLE-L1-1-0.DLL
API-MS-WIN-CORE-HEAP-L1-1-0.DLL
API-MS-WIN-CORE-INTERLOCKED-L1-1-0.DLL
API-MS-WIN-CORE-IO-L1-1-0.DLL
API-MS-WIN-CORE-LIBRARYLOADER-L1-1-0.DLL
API-MS-WIN-CORE-LOCALIZATION-L1-1-0.DLL
API-MS-WIN-CORE-LOCALIZATION-L1-2-0.DLL
API-MS-WIN-CORE-LOCALREGISTRY-L1-1-0.DLL
API-MS-WIN-CORE-MEMORY-L1-1-0.DLL
API-MS-WIN-CORE-MISC-L1-1-0.DLL
API-MS-WIN-CORE-NAMEDPIPE-L1-1-0.DLL
API-MS-WIN-CORE-PROCESSENVIRONMENT-L1-1-0.DLL
API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL
API-MS-WIN-CORE-PROCESSTHREADS-L1-1-1.DLL
API-MS-WIN-CORE-PROFILE-L1-1-0.DLL
API-MS-WIN-CORE-RTLSUPPORT-L1-1-0.DLL
API-MS-WIN-CORE-STRING-L1-1-0.DLL
API-MS-WIN-CORE-SYNCH-L1-1-0.DLL
API-MS-WIN-CORE-SYNCH-L1-2-0.DLL
API-MS-WIN-CORE-SYSINFO-L1-1-0.DLL
API-MS-WIN-CORE-TIMEZONE-L1-1-0.DLL
API-MS-WIN-CORE-UTIL-L1-1-0.DLL
API-MS-WIN-CRT-CONVERT-L1-1-0.DLL
API-MS-WIN-CRT-ENVIRONMENT-L1-1-0.DLL
API-MS-WIN-CRT-FILESYSTEM-L1-1-0.DLL
API-MS-WIN-CRT-HEAP-L1-1-0.DLL
API-MS-WIN-CRT-LOCALE-L1-1-0.DLL
API-MS-WIN-CRT-MATH-L1-1-0.DLL
API-MS-WIN-CRT-MULTIBYTE-L1-1-0.DLL
API-MS-WIN-CRT-RUNTIME-L1-1-0.DLL
API-MS-WIN-CRT-STDIO-L1-1-0.DLL
API-MS-WIN-CRT-STRING-L1-1-0.DLL
API-MS-WIN-CRT-TIME-L1-1-0.DLL
API-MS-WIN-CRT-UTILITY-L1-1-0.DLL
API-MS-WIN-SECURITY-BASE-L1-1-0.DLL
API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
BLADERF.DLL
BOOST_CHRONO-VC140-MT-1_60.DLL
BOOST_DATE_TIME-VC140-MT-1_60.DLL
BOOST_FILESYSTEM-VC140-MT-1_60.DLL
BOOST_REGEX-VC140-MT-1_60.DLL
BOOST_SERIALIZATION-VC140-MT-1_60.DLL
BOOST_SYSTEM-VC140-MT-1_60.DLL
BOOST_THREAD-VC140-MT-1_60.DLL
CFGMGR32.DLL
DEVOBJ.DLL
DEVRTL.DLL
GDI32.DLL
GNURADIO-AUDIO.DLL
GNURADIO-BLOCKS.DLL
GNURADIO-FCD.DLL
GNURADIO-OSMOSDR.DLL
GNURADIO-PMT.DLL
GNURADIO-RUNTIME.DLL
GNURADIO-UHD.DLL
HACKRF.DLL
IPHLPAPI.DLL
KERNEL32.DLL
KERNELBASE.DLL
LIBUSB-1.0.DLL
LPK.DLL
MIRISDR.DLL
MSVCP140.DLL
MSVCR100.DLL
MSVCR90.DLL
MSVCRT.DLL
MSWSOCK.DLL
NSI.DLL
NTDLL.DLL
OLEAUT32.DLL
OSMOSDR.DLL
POCOFOUNDATIOND.DLL
POCOJSOND.DLL
POCONETD.DLL
POCOUTILD.DLL
POCOXMLD.DLL
PORTAUDIO_X64.DLL
POTHOS.DLL
POTHOSSERIALIZATION.DLL
PTHREADVC2.DLL
PYTHON27.DLL
RPCRT4.DLL
RTLSDR.DLL
SETUPAPI.DLL
SHELL32.DLL
SHLWAPI.DLL
SOAPYSDR.DLL
UCRTBASE.DLL
UHD.DLL
USER32.DLL
USP10.DLL
VCRUNTIME140.DLL
VOLK.DLL
WINMM.DLL
WINNSI.DLL
WS2_32.DLL
WSOCK32.DLL
ACLUI.DLL
ACTIVEDS.DLL
ADSLDPC.DLL
ADVPACK.DLL
API-MS-WIN-DOWNLEVEL-ADVAPI32-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-ADVAPI32-L2-1-0.DLL
API-MS-WIN-DOWNLEVEL-NORMALIZ-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-OLE32-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-SHELL32-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-SHLWAPI-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-SHLWAPI-L2-1-0.DLL
API-MS-WIN-DOWNLEVEL-USER32-L1-1-0.DLL
API-MS-WIN-DOWNLEVEL-VERSION-L1-1-0.DLL
API-MS-WIN-SECURITY-LSALOOKUP-L1-1-0.DLL
API-MS-WIN-SECURITY-SDDL-L1-1-0.DLL
APPHELP.DLL
ATL.DLL
AUTHZ.DLL
AVRT.DLL
BCRYPT.DLL
BROWCLI.DLL
CABINET.DLL
CERTCLI.DLL
CERTENROLL.DLL
CLBCATQ.DLL
COMCTL32.DLL
COMCTL32.DLL
COMDLG32.DLL
CREDUI.DLL
CRYPT32.DLL
CRYPTBASE.DLL
CRYPTSP.DLL
CRYPTUI.DLL
CSCAPI.DLL
D2D1.DLL
D3D11.DLL
DAVHLPR.DLL
DBGHELP.DLL
DEVMGR.DLL
DFSCLI.DLL
DHCPCSVC.DLL
DHCPCSVC6.DLL
DNSAPI.DLL
DRVSTORE.DLL
DSROLE.DLL
DUI70.DLL
DUSER.DLL
DWRITE.DLL
DXGI.DLL
EAPPCFG.DLL
EAPPPRXY.DLL
EFSADU.DLL
EFSUTIL.DLL
ELSCORE.DLL
FMS.DLL
GDIPLUS.DLL
GPAPI.DLL
GPSVC.DLL
HLINK.DLL
IEADVPACK.DLL
IERTUTIL.DLL
IEUI.DLL
IMAGEHLP.DLL
IMGUTIL.DLL
INETCOMM.DLL
LINKINFO.DLL
LOGONCLI.DLL
MFC42U.DLL
MLANG.DLL
MMDEVAPI.DLL
MPR.DLL
MPRAPI.DLL
MPRMSG.DLL
MSASN1.DLL
MSCTF.DLL
MSFEEDS.DLL
MSHTML.DLL
MSI.DLL
MSILTCFG.DLL
MSIMG32.DLL
MSLS31.DLL
MSOERT2.DLL
MSRATING.DLL
MSSIGN32.DLL
NETAPI32.DLL
NETBIOS.DLL
NETJOIN.DLL
NETPLWIZ.DLL
NETUTILS.DLL
NEWDEV.DLL
NLAAPI.DLL
NORMALIZ.DLL
NTDSAPI.DLL
NTSHRUI.DLL
OCCACHE.DLL
ODBC32.DLL
OLEACC.DLL
OLEDLG.DLL
ONEX.DLL
PCWUM.DLL
POWRPROF.DLL
PRINTUI.DLL
PRNTVPT.DLL
PROFAPI.DLL
PROPSYS.DLL
PSAPI.DLL
PUIAPI.DLL
RASAPI32.DLL
RASDLG.DLL
RASMAN.DLL
REGAPI.DLL
RSTRTMGR.DLL
RTUTILS.DLL
SAMCLI.DLL
SAMLIB.DLL
SCECLI.DLL
SECUR32.DLL
SHDOCVW.DLL
SLC.DLL
SPFILEQ.DLL
SPINF.DLL
SPPC.DLL
SRVCLI.DLL
SSPICLI.DLL
SYSNTFY.DLL
TAPI32.DLL
UIAUTOMATIONCORE.DLL
URLMON.DLL
VAULTCLI.DLL
VERSION.DLL
VPNIKEAPI.DLL
W32TOPL.DLL
WDI.DLL
WEBIO.DLL
WEBSERVICES.DLL
WINBRAND.DLL
WINDOWSCODECS.DLL
WINHTTP.DLL
WININET.DLL
WINSCARD.DLL
WINSPOOL.DRV
WINSTA.DLL
WINTRUST.DLL
WKSCLI.DLL
WLANAPI.DLL
WLANUTIL.DLL
WLDAP32.DLL
WTSAPI32.DLL
XMLLITE.DLL


I tried installing the missing msvcr110.dll. This caused gnuradio-companion to
get the osmocom going, but it didn't actually work, i.e. it didn't
transmit anything.

the message was

Win32; Microsoft Visual C++ version 14.0; Boost_106000; UHD_003.009.002-0-gf18abe54



gr-osmosdr v0.1.4-67-gac15e789 (0.1.5git) gnuradio 3.7.9

built-in sink types: uhd hackrf bladerf soapy redpitaya file

-- Using subdev spec '0:0'.

2: No such file or directory

2: Permission denied

-- Using format CF32.

gr::pagesize: no info; setting pagesize = 4096

thread[thread-per-block[1]: <block gr uhd usrp sink (3)>]: UHDSoapyTxStream::send() = -5

next I will try a receiver. It does not completey fail,
but neither does it actually work.

Generating: 'C:\\NewPrograms\\hackrfprograms\\fm_Example_1.py'

Executing: 'c:/Python27/python.exe -u C:/NewPrograms/hackrfprograms/fm_Example_1.py'

Win32; Microsoft Visual C++ version 14.0; Boost_106000; UHD_003.009.002-0-gf18abe54



x \Users\mcdonald\AppData\Roaming\.gr_fftw_wisdom: Invalid argument

Using Volk machine: generic

fft_impl_fftw: gr-osmosdr v0.1.4-67-gac15e789 (0.1.5git) gnuradio 3.7.9

built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf airspy soapy redpitaya

-- Using subdev spec '0:0'.



UHD Warning:

    Setting DC offset compensation is not possible on this device.

uhd_source_c::set_iq_balance_mode: Automatic IQ imbalance correction not implemented

: Invalid argument

: Invalid argument

-- Using format CF32.

gr::pagesize: no info; setting pagesize = 4096

thread[thread-per-block[1]: <block gr uhd usrp source (14)>]: RtAudio init error 'RtApiDs::probeDeviceOpen: error (Invalid parameter) creating input buffer (Default Device)!


>>> Done

[Josh Blum]

>
>
> I tried installing the missing msvcr110.dll. This caused gnuradio-companion
> to

Thats good news, I will modify the instructions.

> get the osmocom going, but it didn't actually work, i.e. it didn't
> transmit anything.
>

Can you try these instructions: use hackrf=0 for the device args:
https://github.com/pothosware/PothosSDR/wiki/GNURadio#grosmosdr-blocks

I think its just selecting the wrong driver.
-josh

[Josh Blum]

On 02/11/2016 10:36 PM, Josh Blum wrote:
>
>>
>>
>> I tried installing the missing msvcr110.dll. This caused
>> gnuradio-companion
>> to
>
> Thats good news, I will modify the instructions.

I added this to the tutorial step with an explanation:
https://github.com/pothosware/PothosSDR/wiki/Tutorial#download-and-install

>
>> get the osmocom going, but it didn't actually work, i.e. it didn't
>> transmit anything.
>>
>
> Can you try these instructions: use hackrf=0 for the device args:
> https://github.com/pothosware/PothosSDR/wiki/GNURadio#grosmosdr-blocks
>
> I think its just selecting the wrong driver.

Also, make sure that hackrf_info.exe can find your device. If not, you
may need to run zadig to install libusb drivers for the hackrf.

https://github.com/pothosware/PothosSDR/wiki/Tutorial#recognizing-your-device

Thanks,
-josh

[doug mcdonald]

I got a very very complicated FM stereo receiver to work properly using hackrf = 0 (this
is the best FM receiver I've ever seen using Airspy, not hackrf, which works but
has birdies due to too few bits and a nearby flamethrower.)

But my transmitter does not even load the osmocom sink properly.

Generating: 'C:\\NewPrograms\\hackrfprograms\\top_block.py'

Executing: 'c:/Python27/python.exe -u C:/NewPrograms/hackrfprograms/top_block.py'

Win32; Microsoft Visual C++ version 14.0; Boost_106000; UHD_003.009.002-0-gf18abe54



gr-osmosdr v0.1.4-67-gac15e789 (0.1.5git) gnuradio 3.7.9

built-in sink types: uhd hackrf bladerf soapy redpitaya file

Number of USB devices: 11

USB device 1d50:6089:

FATAL: Failed to open HackRF device (-5) HACKRF_ERROR_NOT_FOUND



Trying to fill up 1 missing channel(s) with null sink(s).

This is being done to prevent the application from crashing

due to gnuradio bug #528.



: Invalid argument

: Invalid argument

Doug

[Josh Blum]

On 02/11/2016 10:54 PM, doug mcdonald wrote:
> I got a very very complicated FM stereo receiver to work properly using
> hackrf = 0 (this
> is the best FM receiver I've ever seen using Airspy, not hackrf, which
> works but
> has birdies due to too few bits and a nearby flamethrower.)
>
> But my transmitter does not even load the osmocom sink properly.
>
> Generating: 'C:\\NewPrograms\\hackrfprograms\\top_block.py'
>
> Executing: 'c:/Python27/python.exe -u
> C:/NewPrograms/hackrfprograms/top_block.py'
>
> Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.009.002-0-gf18abe54
>
>
>
> gr-osmosdr v0.1.4-67-gac15e789 (0.1.5git) gnuradio 3.7.9
>
> built-in sink types: uhd hackrf bladerf soapy redpitaya file
>
> Number of USB devices: 11
>
> USB device 1d50:6089:
>
> FATAL: Failed to open HackRF device (-5) HACKRF_ERROR_NOT_FOUND
>
>

Do you have osmocom source and sink block in the same flow graph? The
only time I have seen that is when both source and sink are present.
Basically, thats not supported by hackrf since it only has one available
usb endpoint for data.

Just a guess...
-josh

[doug mcdonald]

No just a sink .... the graph has only two blocks, a signal source and osmocom sink.

The final program will have only a wave file source, a float to complex block, and the
osmocom sink.

That was my first thought, of course. I tried unloading all of gnuradiocompanion,
resetting the hackrf, and retrying ... same problem. Perhaps I should post
a screen image of the properties of the two blocks.

On Thursday, February 11, 2016 at 10:19:48 PM UTC-6, doug mcdonald wrote:

[doug mcdonald]

"NOT FOUND" problem solved!

Typical problem:

for receive you need "hackrf=0"

and for transmit

"HackRF=0"

case matters and it is required to be inconsistent!

This does not mean, of course, that my whole project works. Time will tell!

On Thursday, February 11, 2016 at 10:19:48 PM UTC-6, doug mcdonald wrote:

[doug mcdonald]

The project still does not work at all. I have exhausted all guesses why.

It has only to blocks, a signal source
sample rate 12M
waveform sine
frequency 400k
amplitude 900m
offset 0

and osmocom sink
device arguments HackRF=0 (or Hackrf=0)
sample rate 12M
Ch0:frequency 50M
Ch0:Freq corr 0
Ch0: RF Gain 6
Ch0 IF Gain 50
Ch0 bb gain 0
ch0: bandawidth 5M

Those values work great in Ubuntu GRC

The error messages are

Executing: 'c:/Python27/python.exe -u C:/NewPrograms/hackrfprograms/top_block.py'

Win32; Microsoft Visual C++ version 14.0; Boost_106000; UHD_003.009.002-0-gf18abe54

gr-osmosdr v0.1.4-67-gac15e789 (0.1.5git) gnuradio 3.7.9

built-in sink types: uhd hackrf bladerf soapy redpitaya file

[doug mcdonald]

oh ... also, the transmit light on the hackrf does not come on

[doug mcdonald]

I tried the transfer_hankrf.exe program. This sort of works. I can get it to transmit a file,

but the results are terrible. I can't get more than 6 millivolts of output no matter how
I set the gain. The frequency spectrum, while at the right center is garbage, looking like noise
in the full bandwidth. This may of course be due to my not knowing the file format.  For
receive the wav header implies its IQ, 8 bits  8 bits Q. So I used that for transmit.
The waveform I see on a scope is not quite right either. However, I only have a 100 MHz scope at home
and a 1.8 Ghz spectrum analyzer. The GHZ scopes are at work.

I need help! Or else I'll just have to reboot to Ubuntu. Which I hate doing.

[doug mcdonald]

Looking more, I'm barking up the wrong tree! What I REALLY want is just
a plain C dll and .h file that I can use to access the hackrf. i.e soapysdr.

which of the two dll/lib pair do I need, and which header files?

Is there a hackrf transmit example somewhere?

 

[Josh Blum]

On 02/13/2016 06:12 AM, doug mcdonald wrote:
>
>
>
> Looking more, I'm barking up the wrong tree! What I REALLY want is just
> a plain C dll and .h file that I can use to access the hackrf. i.e
> soapysdr.
>
> which of the two dll/lib pair do I need, and which header files?
>

The development files for hackrf are included with the environment:

headers: PothosSDR/include/libhackrf/*
and link against: PothosSDR/lib/hackrf.lib

As are the SoapySDR development files:

headers: PothosSDR/include/SoapySDR/*
and link against: PothosSDR/lib/SoapySDR.lib

You can develop against either to make a simple C or C++ program. And if
python interests you, you can probably get a simple transmit tone up
pretty quickly using SoapySDR python bindings:

https://github.com/pothosware/SoapySDR/wiki/PythonSupport#basic-example

There is a siggen app to play with:
https://github.com/pothosware/SoapySDR/blob/master/python/apps/SimpleSiggen.py

python SimpleSiggen.py --args="driver=hackrf" --other-args-here...

> Is there a hackrf transmit example somewhere?
>

For a libhackrf example, this might be a good question for hackrf
support channels. I'm sure that someone has put together a simple
transmitter in C.

I don't have a simple SoapySDR C/C++ example that I know about. But I
hope that python app helps.

-josh

[Josh Blum]

Doug,

So I think the problem is that "HackRF=0" isn't recognized, so you have
the original problem that you had with the source. Basically the driver
selection falls through to the first driver that says "im here" -- which
in this case is a false positive.

Its not an ubuntu vs windows issue, its just that a lot more sdr driver
software is installed in this windows installer than you would typically
have on ubuntu where its installed piecemeal.

I agree that it would be great if it just selected the first available
device and worked. I think in this case, there is a misbehaving driver
that says "im here" when it shouldn’t. That needs to be fixed, but for
now with osmocom source/sink, you do have to be explicit with the device
args.

So for the transmitter, gr-osmosdr sink should expect "hackrf=0". I have
no idea why its dumping that usb error: HACKRF_ERROR_NOT_FOUND
Obviously, hackrf source has seen a lot more testing.

One suggestion I have is to use the SoapyHackRF instead. We had issues
related to the gr-osmosdr hackrf support, and a user contributed
SoapyHackRF, which is an alternative wrapper to the gr-osmosdr hackrf.
To invoke it with the osmocom sink, use the args "soapy=0,driver=hackrf".

soapy=0 tells gr-osmosdr to use the soapy sdr support, and driver=hackrf
tells soapy sdr to use SoapyHackRF.

-josh

[doug mcdonald]

The receive driver works with GnuRadio on Windows, and its what I really want out of GnuRadio Companion.

GnuRadio can't do what I want transmit for (other thread).

I got it working properly by having my program generate a data file (will usually only be a few megabytes)
and then calling a command line that executes hackrf_transfer with the correct options
especially -R. AND ... this works 100% reliably at a sample rate of 16 MHZ which GnuRadio
won't do even on Ubuntu. So I'm in business.I've got it so response is flat over a 12 MHZ bandwidth with
acceptable aliasing. This is of course limited by the hackrf hardware.

The reason getting hack_transfer was so hard was that it needed several magic
incantations ... one of whose documentationa (- a) was wrong.

[Travis Porter]

Not to hijack, but I'm running into a very similar issue (well the first one at least). 

The dependency walker (for _osmosdr_swig.pyd) spits out these guys as not being found:

API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL

API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL

API-MS-WIN-CORE-WINRT-L1-1-0.DLL

API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL

API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL

API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL

DCOMP.DLL

IESHIMS.DLL

I have the 2010 redistribute package installed.

Any help is appreciated.

[Josh Blum]

On 03/10/2016 02:24 PM, Travis Porter wrote:
> Not to hijack, but I'm running into a very similar issue (well the first
> one at least).
>
> The dependency walker (for _osmosdr_swig.pyd) spits out these guys as not
> being found:
> API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
> API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
> API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL
> DCOMP.DLL
> IESHIMS.DLL
>
> I have the 2010 redistribute package installed.
>
> Any help is appreciated.

So I think that those are false flags for depedency walker. I don't see
any recognizable missing DLLs. Here is a related post about it:
https://stackoverflow.com/questions/17023419/win-7-64-bit-dll-problems

Its unfortunate that python's import isnt very verbose when about this
type of error... Does restarting after installing the 2010 redistribute
package help? Can you double check that 2010 redistribute installer is
for 64 bit windows?

Sometimes you can get a little more information by running an exe
application. For example, what happens when you run hackrf_info.exe on
the command line?

You may got a pop-up about a specific missing dll. It might crash, or
just print and exit if all is well. Obviously if you don't have a hackrf
it will just print no devices found, but that would be different than
crashing.

So, let me know. I hope that helps!
-josh