[Discuss-gnuradio] ADRV9008-2, Zynq FPGA boards, and gnuradio
Hello everyone, we are developing an application where a large bandwidth (some 100 MHz at 5-6 GHz mid frequency) needs to be processed to extract a small bandwidth payload signal. For rapid prototyping and testing algorithms I am thinking about using an ADRV9008-2 evaluation board, a Xilinx Zynq FPGA board, and gnuradio. I understand that there do exist ready-made Linux distributions that run on boards like the ZC702 (Zynq-7000 based) or ZCU102 (Ultrascale+ based) and it is possible to run gnuradio on top of it. I also found some hint that there does exist software to access an EVAL-ADRV9008 board connected to the Zync board from within gnuradio. So I assume in principle it should be possible to process the 450 MHz bandwidth from the ADRV9008-2 directly on the Zync board using gnuradio in real time. Can anyone confirm that this assumption is correct and that such a setup could work? Has this be done before? Would both the ZC702 and the ZCU102 be suitable? Where should I start reading? Lots of questions. Thank you for some answers. Erik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ADRV9008-2, Zynq FPGA boards, and gnuradio
Hi Erik, so, GNU Radio *itself* is purely host-based software; in other words, you'd be processing 100s of MHz on the poor Zynq's ARM (will not even remotely happen). What you'd need is to do the signal processing in the FPGA, for the most significant part. After you've selected your channel and reduced your sampling rate to that, yes, GNU Radio could very well deal with that data (if the ARM CPU is up for that). There's an accelerator framework, that Ettus developed for their Zynq- based products, called RFNoC. That works relatively nicely with GNU Radio. Pretty sure Analog Devices themselves also have libiio- compatible ways of signal (pre)processing on Zynqs, but I'm not knowledgeable about that at all. Which FPGA would fit your bill depends on the kind of signal processing you'd need to do. I'd assume the 7000 series Zynq would be a bit on the limits of its bandwidths dealing with 450 MS/s. Best regards, Marcus On Tue, 2019-06-25 at 10:04 +, Erik Heinz wrote: > Hello everyone, > > we are developing an application where a large bandwidth (some 100 MHz at > 5–6 GHz mid frequency) needs to be processed to extract a small bandwidth > payload signal. > > For rapid prototyping and testing algorithms I am thinking about using an > ADRV9008-2 evaluation board, a Xilinx Zynq FPGA board, and gnuradio. > > I understand that there do exist ready-made Linux distributions that run on > boards like the ZC702 (Zynq-7000 based) or ZCU102 (Ultrascale+ based) and it > is possible to run gnuradio on top of it. > I also found some hint that there does exist software to access an > EVAL-ADRV9008 board connected to the Zync board from within gnuradio. > So I assume in principle it should be possible to process the 450 MHz > bandwidth from the ADRV9008-2 directly on the Zync board using gnuradio in > real time. > > Can anyone confirm that this assumption is correct and that such a setup > could work? Has this be done before? > Would both the ZC702 and the ZCU102 be suitable? > Where should I start reading? > > Lots of questions. Thank you for some answers. > Erik > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR
Patrick,
Just to confirm, you started GRC by running the run_GRC.bat file or the
link on the start menu? Assuming so. If not that’s the problem and ignore
the rest.
There is little program out there called “dependency checker” that is
invaluable for these issues. Download it and find the .pyd module file
below with the import error. Open it in that program. It will display the
chain of DLLs it is looking for and if something is missing it should
appear. (You will get false errors about system libraries and may need to
add directories to the search tree path).
So if you run that and there is a missing DLL that seems GR related then
let us know which it is , this would indicate a problem in the installer.
Next option is the DLL is somewhere in the system and somehow the GRC isn’t
finding it, which would be odd but possible.
It’s a very odd error in general, running an RTL based flow graph is tested
when I package the installers.
On Mon, Jun 24, 2019 at 23:09 W3AXL Patrick wrote:
> Hi Kyeong
>
>
>
> This is running a GRC file inside of GNURadio Companion. Something is
> indeed broken.
>
>
>
> I simply ran the Win64 installer for GNURadio from the Windows builds site
> linked by the GNURadio wiki. I recall last year I had this same issue on my
> Windows system and gave up using GRC on Windows because of it. It’s a pain
> to load up my linux box every time I want to use GNURadio though.
>
>
>
> Thanks for the input
>
>
>
> Patrick
>
>
>
> *From:* Kyeong Su Shin
> *Sent:* Monday, June 24, 2019 9:52 PM
> *To:* W3AXL Patrick ; discuss-gnuradio@gnu.org
> *Subject:* RE: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR
>
>
>
> Hello Patrick:
>
>
>
> Are you running a GNU Radio Python code? Or, are you running a GRC file
> using GNU Radio Companion?
>
>
>
> If you are running a Python code generated from GNU Radio Companion, you
> should be running that code using "GNU Radio Command Prompt" (which comes
> with correct library PATH variables).
>
>
>
> If you are running a GRC file using GNU Radio Companion, then I guess
> something is broken..
>
>
>
> Also, please note that the GNU Radio Windows distribution comes with its
> own Python interpreter (which you can use by using GNU Radio Command
> Prompt", and does not touch or use the Python interpreter on your system.
>
>
>
> Regards,
>
> Kyeong Su Shin
>
>
> --
>
> *보낸* *사람**:* W3AXL Patrick 대신 Discuss-gnuradio <
> discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org>
> *보낸* *날짜**:* 2019년 6월 25일 화요일 오전 10:50:11
> *받는* *사람**:* discuss-gnuradio@gnu.org
> *제목**:* [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR
>
>
>
> Hi all on the list,
>
>
>
> I’ve been tearing my hair out trying to solve an issue I’m having with a
> clean install of GNURadio using the Windows builds.
>
>
>
> When trying to run a simple flowgraph, with an RTL-SDR source connected to
> a frequency sink, I receive the following traceback:
>
>
>
> Traceback (most recent call last):
>
> File "C:\Users\Patrick\Documents\top_block.py", line 29, in
>
> import osmosdr
>
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\osmosdr\__init__.py", line 26, in
>
>
> from osmosdr_swig import *
>
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 17, in
>
>
> _osmosdr_swig = swig_import_helper()
>
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 16, in
> swig_import_helper
>
> return importlib.import_module('_osmosdr_swig')
>
> File "C:\Program
> Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", line 37, in
> import_module
>
> __import__(name)
>
> ImportError: No module named _osmosdr_swig
>
>
>
> I think this is a problem with my PATH, or with the installation of
> GNURadio, but I can’t figure out how to fix it. There is almost no info on
> anyone else having errors like this with GRC so I’m stumped.
>
>
>
> Additionally, on this clean install of GNURadio, I receive over a hundred
> of errors similar to this one during startup of GRC:
>
>
>
> Warning: Block with key "xxx" already exists.
>
> Ignoring: C:\Program
> Files\GNURadio-3.7\share\gnuradio\grc\blocks\xxx.xml
>
>
>
> I feel as if these two issues might be related in some way.
>
>
>
> I would appreciate any help. My system is running Win10 and I have the
> latest Python 2.7 installed.
>
>
>
> Thanks to all,
>
>
>
> Patrick
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR
OK, I think a clue here is that a python dll is installed in System32.
Windows will always check System32 regardless of the PATH, so
something there might be causing some misdirection.
Try this... run the "run_gr.bat" file and once in, run python by
simply entering "python"
Then enter;
import subprocess
print subprocess.check_call("where python27.dll")
import sys
print(sys.executable)
for p in sys.path:
import numpy
import gnuradio
import osmosdr
This will get us some basic path info and we can see where it breaks.
THEN repeat, but before running the python command enter "cd
..\gr-python27" and see if the results are different.
Finally, repeat the above but using the run_gr_d.bat instead. That
runs the debug version of python, and it's less likely you have a
debug version installed on your machine, so if _d works that's just
further confirmation.
My suspicion is that the above will show that that the DLL from
System32 is being loaded in the first case, but not in the others. If
so, then the solution is to remove python27.dll from System32 (which
belongs to a different python installation) and move it to wherever
you have a 64-bit install of python27 (since it at least appears to be
a 64 bit Dll) in the same folder as python.exe. If you have more
than, then copy it to each one that doesn't have one of it's own.
If none of this worked, please send screen shots back.
I don't believe many Python distros are still installing to System32
for exactly this reason.
On 6/25/19, W3AXL Patrick wrote:
> Geof
>
>
>
> Yes, I’m running from that batch file. I agree, it’s a very bizzare error.
> I’ve only been able to find a couple mentions to my issue online and they’re
> all on other platforms like OSX or Linux.
>
>
>
> Attached is the dependency check on _osmosdr_swig.pyd – the older dependency
> checker tool didn’t want to work in Win10 but this one did. I don’t see any
> erorrs apart from the incorrect checksums it’s reporting in the bottom
> pane.
>
>
>
> Thanks again for your willingness to help. I really want to get GRC up and
> working properly on this machine and I know how strange this error is.
>
>
>
> Patrick
>
>
>
> From: Geof Nieboer
> Sent: Tuesday, June 25, 2019 6:33 AM
> To: W3AXL Patrick
> Cc: Kyeong Su Shin ; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR
>
>
>
> Patrick,
>
>
>
> Just to confirm, you started GRC by running the run_GRC.bat file or the link
> on the start menu? Assuming so. If not that’s the problem and ignore the
> rest.
>
>
>
> There is little program out there called “dependency checker” that is
> invaluable for these issues. Download it and find the .pyd module file
> below with the import error. Open it in that program. It will display the
> chain of DLLs it is looking for and if something is missing it should
> appear. (You will get false errors about system libraries and may need to
> add directories to the search tree path).
>
>
>
> So if you run that and there is a missing DLL that seems GR related then let
> us know which it is , this would indicate a problem in the installer.
>
>
>
> Next option is the DLL is somewhere in the system and somehow the GRC isn’t
> finding it, which would be odd but possible.
>
>
>
> It’s a very odd error in general, running an RTL based flow graph is tested
> when I package the installers.
>
>
>
>
>
> On Mon, Jun 24, 2019 at 23:09 W3AXL Patrick > wrote:
>
> Hi Kyeong
>
>
>
> This is running a GRC file inside of GNURadio Companion. Something is indeed
> broken.
>
>
>
> I simply ran the Win64 installer for GNURadio from the Windows builds site
> linked by the GNURadio wiki. I recall last year I had this same issue on my
> Windows system and gave up using GRC on Windows because of it. It’s a pain
> to load up my linux box every time I want to use GNURadio though.
>
>
>
> Thanks for the input
>
>
>
> Patrick
>
>
>
> From: Kyeong Su Shin mailto:kss...@postech.ac.kr> >
> Sent: Monday, June 24, 2019 9:52 PM
> To: W3AXL Patrick mailto:patr...@w3axl.com> >;
> discuss-gnuradio@gnu.org
> Subject: RE: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR
>
>
>
> Hello Patrick:
>
>
>
> Are you running a GNU Radio Python code? Or, are you running a GRC file
> using GNU Radio Companion?
>
>
>
> If you are running a Python code generated from GNU Radio Companion, you
> should be running that code using "GNU Radio Command Prompt" (which comes
> with correct library PATH variables).
>
>
>
> If you are running a GRC file using GNU Radio Companion, then I guess
> something is broken..
>
>
>
> Also, please note that the GNU Radio Windows distribution comes with its own
> Python interpreter (which you can use by using GNU Radio Command Prompt",
> and does not touch or use the Python interpreter on your system.
>
>
>
> Regards,
>
> Kyeong Su Shin
>
>
>
> _
>
> 보낸 사람: W3AXL Patrick mailto:patr...@w3axl.com> > 대신
> Discuss-gnuradio <
Re: [Discuss-gnuradio] Multiple-Transmitter OFDM
Hi, I guess, the receiver cannot synchronize to our transmitters. Is there a way for using occupied carriers for synchronization instead of all carriers in schmidl cox? Best regards. On 24.06.2019 15:00, Ramazan Çetin wrote: Hi Michael, Firstly, thank you for your suggestion. I have tried your solution and i have transmitted two signals using PFB synthesizer. At the receiver, i have used a PFB channelizer. In simulation, this system works perfectly. I could receive two different files at the receiver from two different transmitters. But when i tried this system on E310s, it fails. At the transmitter, E310 gives tGtGtGtGtGtGtGtG errors (I know this is related with length tags but i have already provided tag to USRP). At the receiver, it cannot receive signals. It gives this error: gr::log :INFO: header_payload_demux1 - Parser returned #f gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item 38 gr::log :INFO: header_payload_demux1 - Parser returned #f gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item 76 gr::log :INFO: header_payload_demux1 - Parser returned #f gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item 114 gr::log :INFO: header_payload_demux1 - Parser returned #f gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item 152 gr::log :INFO: header_payload_demux1 - Parser returned #f gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item 190 gr::log :INFO: header_payload_demux1 - Parser returned #f gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item 228 This is obviously related with HPD. But, it does not give this error continuously while signal is transmitting. Normally, if header cannot be decoded, this error should be seen continuously. Instead, it just gives at the beginning of signal. I have attached three GRC FGs. pfb_test is simulation environment that works perfectly. pfb_transmitter and pfb_receiver are USRP FGs. Do you have any idea about this situation? Best regards. Ramazan On 20.06.2019 21:16, Michael Dickens wrote: Hi Ramazan - Hmmm ... I'm not coming up with anything greatly useful when using a single OFDM block for Tx. Alternatively you could use a 2 channel PFB synthesizer on Tx, with 2 separate OFDM Tx and feed them into the synthesizer. On Rx use a PFB channelizer and take its 2 outputs to 2 separate OFDM Rx. The complexity of the PFBs will depend on the filtering required to keep the OFDM channels separate enough. Maybe others have useful ideas of how to do what you're looking for? Hope this is useful! - MLD On Thu, Jun 20, 2019, at 10:49 AM, Ramazan Çetin wrote: Hi MLD, You are right. I guess, one of the transmitters' preamble overlaps another's data. (Because gnuradio sends preamble in all carriers). I have attached my receiver and transmitters' FGs. Both of them uses 256 carrier OFDM. One transmitter use half of the carriers as occupied and another uses other half. I guess our receiver structure is wrong. Can you suggest a way for implementing multi user OFDM system? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple-Transmitter OFDM
Hi Ramazan - The "#f" generally indicates that you the Rx SNR isn't high enough ... nearly, but not quite. The sync symbols are being detected, but the header itself can't be decoded cleanly (CRC fails). In your "test" script, you don't have to worry so much about gains. When using actual over-the-air USRPs, gains become quite important! I'd advise you to add in 2 gains to the Tx, and 1 to the Rx: Tx: change the "Multiply Const" to a gain slider, and then add a Qt time sink to see the actual Tx signal amplitude. You want the values going into the USRP to be in [-1, +1], backed off just a touch is probably wise. Anything above |1| will result in clipping on the USRP, which will cause strange spectrum glitches & if too much clipping will lead to bad decoding. Tx: add a slider for the USRP's Tx gain setting. 30 is probably good, but it really depends on the actual USRP in use. There will be a range that works well. Rx: add a slider for the USRP's Tx gain setting. 0 is probably not enough for actual Rx, but it really depends on the actual USRP in use. There will be a range that works well. WIth those sliders in place, play with them until the signal levels look good: on Tx you want the signal hitting the USRP to be near but within [-1, +1], and on Rx you need "enough" SNR to do decoding .. there are websites and papers that list the lower end SNR for normal OFDM ... add a few (3) dB to those values for the default GR OFDM for various reasons. Hope this is useful! - MLD On Mon, Jun 24, 2019, at 8:01 AM, Ramazan Çetin wrote: > Hi Michael, > Firstly, thank you for your suggestion. I have tried your solution and i have > transmitted two signals using PFB synthesizer. At the receiver, i have used a > PFB channelizer. In simulation, this system works perfectly. I could receive > two different files at the receiver from two different transmitters. > But when i tried this system on E310s, it fails. At the transmitter, E310 > gives tGtGtGtGtGtGtGtG errors (I know this is related with length tags but i > have already provided tag to USRP). At the receiver, it cannot receive > signals. It gives this error: > gr::log :INFO: header_payload_demux1 - Parser returned #f > gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item 38 > gr::log :INFO: header_payload_demux1 - Parser returned #f > gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item 76 > gr::log :INFO: header_payload_demux1 - Parser returned #f > gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item > 114 > gr::log :INFO: header_payload_demux1 - Parser returned #f > gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item > 152 > gr::log :INFO: header_payload_demux1 - Parser returned #f > gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item > 190 > gr::log :INFO: header_payload_demux1 - Parser returned #f > gr::log :INFO: packet_headerparser_b1 - Detected an invalid packet at item > 228 > > This is obviously related with HPD. But, it does not give this error > continuously while signal is transmitting. Normally, if header cannot be > decoded, this error should be seen continuously. Instead, it just gives at > the beginning of signal. > I have attached three GRC FGs. pfb_test is simulation environment that works > perfectly. pfb_transmitter and pfb_receiver are USRP FGs. > Do you have any idea about this situation? > Best regards. > Ramazan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Calling a function after every N samples
Hi Kevin - Thanks for the additional info. It seems that you've been doing some serious work trying out various options; very good! If you're using gr-uhd, then you can use the data tag "tx_freq": If it's at the initial sample in the incoming buffer, then it indicates an immediate tune request at the specified tag value. If it's at the final sample, then it gets a little complicated ... you can read through this chunk of the source code here < https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/lib/usrp_sink_impl.cc#L568 >. Anyway if you want to change, or the option to change, the Tx freq every N samples when using gr-uhd then one option is to create a custom block that counts the number of items going through it and every N and attaches this tag at the correct sample for what you want. If you're not using gr-uhd, then there might still be tags such as this method that will work with the given Tx HW. Hope this is useful! - MLD On Thu, Jun 20, 2019, at 3:57 PM, Kevin Lee wrote: > Hello, > > Thanks for the reply! More specifically, what I'm aiming for is to change > frequency after transmitting some number of samples. I've tried having the > sink call the set frequency commands each time 'work' is run, but that > doesn't seem to help me set the length. I've tried using message passing, but > that's not sufficient because that uses a sleep timer which is too > inconsistent for what I'm doing. As for the vectorised data, it still doesn't > time correctly since what I think the sink is doing is writing to a buffer in > hardware. Though despite that, the timing result is consistent in the first > method I listed. Is there a way to trigger command execution in response to > specific samples? Or any way to precisely time frequency changes? > > Thanks, > Kevin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR
Alright, here we go
Following the first set of instructions:
C:\Program Files\GNURadio-3.7\bin>python
Python 2.7.10 (default, Jun 14 2019, 12:01:58) [MSC v.1900 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> print subprocess.check_call("where python27.dll")
C:\Program Files\GNURadio-3.7\gr-python27\DLLs\python27.dll
C:\Program Files\GNURadio-3.7\gr-python27\python27.dll
C:\Windows\System32\python27.dll
C:\Program Files (x86)\Nmap\python27.dll
0
>>> import sys
>>> print(sys.executable)
C:\Program Files\GNURadio-3.7\bin\..\gr-python27\python.exe
>>> for p in sys.path:
print p (I'm assuming that's what you
wanted me to do)
C:\Program Files\GNURadio-3.7\gr-python27\Lib\site-packages
C:\Program Files\GNURadio-3.7\gr-python27\dlls
C:\Program Files\GNURadio-3.7\gr-python27\libs
C:\Program Files\GNURadio-3.7\gr-python27\lib
C:\Program Files\GNURadio-3.7\lib\site-packages
C:\Program Files\GNURadio-3.7\gr-python27\Lib\site-packages\pkgconfig
C:\Program Files\GNURadio-3.7\gr-python27\Lib\site-packages\gtk-2.0\glib
C:\Program Files\GNURadio-3.7\gr-python27\Lib\site-packages\gtk-2.0
C:\Program Files\GNURadio-3.7\gr-python27\Lib\site-packages\wx-3.0-msw
C:\Program Files\GNURadio-3.7\gr-python27\Lib\site-packages\sphinx
C:\Program
Files\GNURadio-3.7\gr-python27\Lib\site-packages\lxml-3.4.4-py2.7-win.amd64.egg
C:\Program Files\GNURadio-3.7\gr-python27\python27.zip
C:\Program Files\GNURadio-3.7\gr-python27\lib\plat-win
C:\Program Files\GNURadio-3.7\gr-python27\lib\lib-tk
C:\Program Files\GNURadio-3.7\gr-python27
C:\Program Files\GNURadio-3.7\gr-python27\lib\site-packages\PIL
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\pip-9.0.1-py2.7.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\wheel-0.29.0-py2.7.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\cython-0.28.5-py2.7-win-amd64.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\numpy-1.16.4-py2.7-win-amd64.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\cheetah-2.4.4-py2.7-win-amd64.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\setuptools-0.0.0-py2.7.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\lxml-3.6.0-py2.7-win-amd64.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\matplotlib-2.0.0-py2.7-win-amd64.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\cycler-0.10.0-py2.7.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\functools32-3.2.3.post2-py2.7.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\python_dateutil-2.8.0-py2.7.egg
C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\bitarray-0.8.1-py2.7-win-amd64.egg
C:\Program
Files\GNURadio-3.7\gr-python27\Lib\site-packages\setuptools-0.0.0-py2.7.egg
C:\Program
Files\GNURadio-3.7\gr-python27\Lib\site-packages\functools32-3.2.3.post2-py2.7.egg
C:\Program
Files\GNURadio-3.7\gr-python27\Lib\site-packages\lxml-3.4.4-py2.7-win.amd64.egg
>>> import numpy
>>> import gnuradio
>>> import osmosdr
Traceback (most recent call last):
File "", line 1, in
File "C:\Program
Files\GNURadio-3.7\lib\site-packages\osmosdr\__init__.py", line 26, in
from osmosdr_swig import *
File "C:\Program
Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 17, in
_osmosdr_swig = swig_import_helper()
File "C:\Program
Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 16, in
swig_import_helper
return importlib.import_module('_osmosdr_swig')
File "C:\Program
Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", line 37, in
import_module
__import__(name)
ImportError: No module named _osmosdr_swig
And you were correct, we see the System32 dll being loaded. BUT...
Now trying again after a cd to ..\gr-python27:
>>> import subprocess
>>> print subprocess.check_call("where python27.dll")
C:\Program Files\GNURadio-3.7\gr-python27\python27.dll
C:\Program Files\GNURadio-3.7\gr-python27\DLLs\python27.dll
C:\Windows\System32\python27.dll
C:\Program Files (x86)\Nmap\python27.dll
0
>>> import sys
>>> print(sys.executable)
C:\Program Files\GNURadio-3.7\gr-python27\python.exe
>>> for p in sys.path:
... print p
...
C:\Program Files\GNURadio-3.7\gr-python27\Lib\site-packages
C:\Program Files\GNURadio-3.7\gr-python27\dlls
C:\Program Files\GNURadio-3.7\gr-python27\libs
C:\Program Files\GNURadio-3.7\gr-python27\lib
C:\Program File
Re: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR
Hmm. Small thing, you didn’t want to copy that system DLL to the gr-python
dir, the gr-python DLL is a custom build. But for the moment let’s not
worry about that.
Let’s try this as a test... copy the pyd file to /bin folder and see if the
error change.
If not, then reopen dependency checker and drill down into the
gnuradio-osmosdr and see if any of the device driver DLLs or other
reference is missing.
Past that I am puzzled. But I’ll have a bit of time tomorrow eve to look a
bit closer.
Geof
On Tue, Jun 25, 2019 at 19:37 W3AXL Patrick wrote:
> Alright, here we go
>
> Following the first set of instructions:
>
> C:\Program Files\GNURadio-3.7\bin>python
> Python 2.7.10 (default, Jun 14 2019, 12:01:58) [MSC v.1900 64 bit
> (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more
> information.
>
> >>> import subprocess
> >>> print subprocess.check_call("where python27.dll")
> C:\Program Files\GNURadio-3.7\gr-python27\DLLs\python27.dll
> C:\Program Files\GNURadio-3.7\gr-python27\python27.dll
> C:\Windows\System32\python27.dll
> C:\Program Files (x86)\Nmap\python27.dll
> 0
>
> >>> import sys
> >>> print(sys.executable)
> C:\Program Files\GNURadio-3.7\bin\..\gr-python27\python.exe
>
> >>> for p in sys.path:
> print p (I'm assuming that's what
> you wanted me to do)
> C:\Program Files\GNURadio-3.7\gr-python27\Lib\site-packages
> C:\Program Files\GNURadio-3.7\gr-python27\dlls
> C:\Program Files\GNURadio-3.7\gr-python27\libs
> C:\Program Files\GNURadio-3.7\gr-python27\lib
> C:\Program Files\GNURadio-3.7\lib\site-packages
> C:\Program
> Files\GNURadio-3.7\gr-python27\Lib\site-packages\pkgconfig
> C:\Program
> Files\GNURadio-3.7\gr-python27\Lib\site-packages\gtk-2.0\glib
> C:\Program Files\GNURadio-3.7\gr-python27\Lib\site-packages\gtk-2.0
> C:\Program
> Files\GNURadio-3.7\gr-python27\Lib\site-packages\wx-3.0-msw
> C:\Program Files\GNURadio-3.7\gr-python27\Lib\site-packages\sphinx
> C:\Program
> Files\GNURadio-3.7\gr-python27\Lib\site-packages\lxml-3.4.4-py2.7-win.amd64.egg
> C:\Program Files\GNURadio-3.7\gr-python27\python27.zip
> C:\Program Files\GNURadio-3.7\gr-python27\lib\plat-win
> C:\Program Files\GNURadio-3.7\gr-python27\lib\lib-tk
> C:\Program Files\GNURadio-3.7\gr-python27
> C:\Program Files\GNURadio-3.7\gr-python27\lib\site-packages\PIL
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\pip-9.0.1-py2.7.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\wheel-0.29.0-py2.7.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\cython-0.28.5-py2.7-win-amd64.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\numpy-1.16.4-py2.7-win-amd64.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\cheetah-2.4.4-py2.7-win-amd64.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\setuptools-0.0.0-py2.7.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\lxml-3.6.0-py2.7-win-amd64.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\matplotlib-2.0.0-py2.7-win-amd64.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\cycler-0.10.0-py2.7.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\functools32-3.2.3.post2-py2.7.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\python_dateutil-2.8.0-py2.7.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\lib\site-packages\bitarray-0.8.1-py2.7-win-amd64.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\Lib\site-packages\setuptools-0.0.0-py2.7.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\Lib\site-packages\functools32-3.2.3.post2-py2.7.egg
> C:\Program
> Files\GNURadio-3.7\gr-python27\Lib\site-packages\lxml-3.4.4-py2.7-win.amd64.egg
>
> >>> import numpy
> >>> import gnuradio
> >>> import osmosdr
> Traceback (most recent call last):
> File "", line 1, in
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\osmosdr\__init__.py", line 26, in
>
> from osmosdr_swig import *
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 17, in
>
> _osmosdr_swig = swig_import_helper()
> File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line 16, in
> swig_import_helper
> return importlib.import_module('_osmosdr_swig')
> File "C:\Program
> Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", line 37, in
> import_module
> __import__(name)
> ImportError: No module named _osmosdr_swig
>
> And
