[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] GnuRadio Port: The system cannot find the file specif

From: Ryan van den Bergh
Subject: [Discuss-gnuradio] GnuRadio Port: The system cannot find the file specified
Date: Fri, 15 Apr 2011 14:19:35 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9


I installed the Gnuradio Port using the Windows Binary from Josh Blum's website yesterday. I followed all the instructions, installed the latest version, and also used the dependencies files provided. Everything worked perfectly until I tried to run a simulation in the GNU Radio Companion. When I clicked generate and then execute, I get the following messages:

Generating: "C:\Program Files (x86)\gnuradio\bin\top_block.py"

Executing: "C:\Program Files (x86)\gnuradio\bin\top_block.py"
[Error 2] The system cannot find the file specified
>>> Done

At this point it does nothing. I've tried saving the files to another location (in case Windows is preventing the program from accessing that directory), and I'm running the program via a Windows Shell with Administrator rights - nothing I do makes a difference. The only other strange error that I can locate, is in the Windows Shell just after I enter the command to run the GNU Radio Companion:

D:\Python27\lib\site-packages\cheetah-2.4.4-py2.7.egg\Cheetah\Compiler.py:1509: UserWarning: You don't have the C version of NameMapper installed! I'm disabling Cheetah's useStackFrames option as it is painfully slow with the Python version of NameMapper. You should get a copy of Cheetah with the compiled C version of NameMapper.
"\nYou don't have the C version of NameMapper installed! "

Now I installed Cheetah using easy_install, and the GNU Radio Companion does start, so I'm not sure whether that error is relevant or not.

In addition, whilst looking through past emails pertaining to the GnuRadio Port, I stumbled across the emails between Mark Colin and Josh Blum, wherein Josh asked him to check whether the Gnuradio and UHD packages were missing. I figured it couldn't hurt to try and run the commands Josh recommended, so I tried them both. I received no errors when trying to load gnuradio, i.e. python.exe -c "from gnuradio import gr", but when I tried to load the uhd, I got the following errors:

C:\Windows\system32>python.exe -c "from gnuradio import uhd"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
File "c:\program files (x86)\gnuradio\lib\site-packages\gnuradio\uhd\__init__.
py", line 87, in <module>
File "c:\program files (x86)\gnuradio\lib\site-packages\gnuradio\uhd\__init__.
py", line 26, in _prepare_uhd_swig
    import uhd_swig
File "c:\program files (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.
py", line 24, in <module>
    _uhd_swig = swig_import_helper()
File "c:\program files (x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.
py", line 20, in swig_import_helper
    _mod = imp.load_module('_uhd_swig', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.

Again I don't know what any of this means, or if it has any bearing on my inability to run GNU Radio Companion simulations, but I thought I should add it to this email for completeness.

I'd really appreciate any help anyone can provide. Unfortunately I have to develop an application using GnuRadio in Windows (several of my application's dependencies are windows specific), otherwise I'd switch to Linux in a heartbeat, but I am very grateful to Josh for porting the GnuRadio project to windows.

Lastly, in case someone has a better solution, I need to develop a very lightweight "SDR API", which will enable a Java application (as I said above, it has to run in Windows as some of the other dependencies are Windows specific) to asynchronously transmit and receive packets using two USRP2s. I am planning on developing this "API" using the GnuRadio Companion, and then just running the python script using Java's interface to the Windows Shell, but if anyone knows of a way to drastically reduce the complexity of my current solution, I'd really appreciate it!

Kind regards,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]