GnuRadio Port: The system cannot find the file specified

Hi,

I installed the Gnuradio Port using the Windows Binary from Josh B.'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 “”, line 1, in
File “c:\program files
(x86)\gnuradio\lib\site-packages\gnuradio\uhd_init_.
py”, line 87, in
prepare_uhd_swig()
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
_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,

Ryan

import uhd_swig

File “c:\program files
(x86)\gnuradio\lib\site-packages\gnuradio\uhd\uhd_swig.
py”, line 24, in
_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.

That usually means a dll is not in your %PATH%.
Set the %PATH% environment variable for your gnuradio install, this is
usually:

* c:\program files (x86)\uhd\bin
* c:\program files (x86)\gnuradio\bin
* c:\python27\lib\site-packages\pyqt4\bin

-Josh

On 15/04/2011 11:13 AM, Josh B. wrote:

 import uhd_swig

That usually means a dll is not in your %PATH%.

Further, you have to add those paths to the SYSTEM instance of the
%PATH% variable. Adding them to the USER instance doesn’t appear to
allow you to load DLLs.

That usually means a dll is not in your %PATH%.
Set the %PATH% environment variable for your gnuradio install, this is
usually:

 * c:\program files (x86)\uhd\bin

it dawned on my that I didnt leave in the instructions a note to install
uhd, basically you need uhd.dll in your %PATH%, and thats where the
error is coming from

 * c:\program files (x86)\gnuradio\bin
 * c:\python27\lib\site-packages\pyqt4\bin

I tried to ship the dll dependencies w/ the installer. But I had forgot
about qt runtime. So this little requirement should go away for my next
installer.

Further, you have to add those paths to the SYSTEM instance of the
%PATH% variable. Adding them to the USER instance doesn’t appear to
allow you to load DLLs.

FWIW I have been adding everything to the user side of the environment
vars. Maybe you are running the app as a different user?

-Josh

On 15/04/2011 11:51 AM, Josh B. wrote:

FWIW I have been adding everything to the user side of the environment
vars. Maybe you are running the app as a different user?

-Josh

Hmmm, the other day when I ran into “can’t find the DLLs” issue, despite
having all the appropriate directories in the user-mode %PATH%
variable, it couldn’t find 'em. So, I added to the system
instance, and suddenly it could find the DLLs. Windows? How do I hate
thee?
Let me count the ways…

Hi Guys,

Thanks very much for the assistance!! The problem was that I hadn’t
installed the UHD binary from Ettus (I feel like a bit of an idiot, I
should
have worked that out). Once I did that, and included the path in my
environmental variables, I no longer received any errors when running:
python.exe -c “from gnuradio import uhd”.

Unfortunately this hasn’t cleared up my other problem. I’m still getting
this error when I try to run a simple flow graph in Gnu Radio Companion:

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

The graph I created is very simple and is composed of: a signal source,
a
throttle, and a QT GUI Sink. It seems that the top_block.py is actually
created (I can see it in windows explorer), but it Gnu Radio Companion
doesn’t seem to be able to find or run the file. Just in case it helps,
I’ve
added the file’s contents below my e-mail. Do you guys have any idea as
to
what could be causing this?

Thanks again and kind regards,

Ryan

#!/usr/bin/env python
##################################################

Gnuradio Python Flow Graph

Title: Top Block

Generated: Fri Apr 15 18:48:30 2011

##################################################

from PyQt4 import Qt
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from gnuradio.qtgui import qtgui
from optparse import OptionParser
import sip
import sys

class top_block(gr.top_block, Qt.QWidget):

def __init__(self):
    gr.top_block.__init__(self, "Top Block")
    Qt.QWidget.__init__(self)
    self.setWindowTitle("Top Block")
    self.setWindowIcon(Qt.QIcon.fromTheme('gnuradio-grc'))
    self.top_layout = Qt.QVBoxLayout(self)
    self.top_grid_layout = Qt.QGridLayout()
    self.top_layout.addLayout(self.top_grid_layout)

    ##################################################
    # Variables
    ##################################################
    self.samp_rate = samp_rate = 32000

    ##################################################
    # Blocks
    ##################################################
    self.qtgui_sink_x_0 = qtgui.sink_c(
        1024, #fftsize
        firdes.WIN_BLACKMAN_hARRIS, #wintype
        0, #fc
        samp_rate, #bw
        "QT GUI Plot", #name
        True, #plotfreq
        True, #plotwaterfall
        True, #plotwaterfall3d
        True, #plottime
        True, #plotconst
    )
    self._qtgui_sink_x_0_win =

sip.wrapinstance(self.qtgui_sink_x_0.pyqwidget(), Qt.QWidget)
self.top_layout.addWidget(self._qtgui_sink_x_0_win)
self.gr_throttle_0 = gr.throttle(gr.sizeof_gr_complex*1,
samp_rate)
self.gr_sig_source_x_0 = gr.sig_source_c(samp_rate,
gr.GR_COS_WAVE,
1000, 1, 0)

    ##################################################
    # Connections
    ##################################################
    self.connect((self.gr_sig_source_x_0, 0), (self.gr_throttle_0, 

0))
self.connect((self.gr_throttle_0, 0), (self.qtgui_sink_x_0, 0))

def get_samp_rate(self):
    return self.samp_rate

def set_samp_rate(self, samp_rate):
    self.samp_rate = samp_rate
    self.gr_sig_source_x_0.set_sampling_freq(self.samp_rate)
    self.qtgui_sink_x_0.set_frequency_range(0, self.samp_rate)

if name == ‘main’:
parser = OptionParser(option_class=eng_option, usage="%prog:
[options]")
(options, args) = parser.parse_args()
qapp = Qt.QApplication(sys.argv)
tb = top_block()
tb.start()
tb.show()
qapp.exec_()

Unfortunately this hasn’t cleared up my other problem. I’m still getting
this error when I try to run a simple flow graph in Gnu Radio Companion:

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

2 suggestions

  1. Execute from the command line:
    c:\python27\python.exe
    And see if that gives you more verbose

  2. Move top_block.py to a different directory (like in your user home).
    Generally, dont save stuff in program files (although I cant say thats
    the problem)

-Josh

Hi Josh,

Thanks for the suggestions!

I can run top_block.py from the command line, and I’ve saved it in My
Documents folder, however I still can’t get GNU Radio Companion to
execute
the file. Do I perhaps have to do something special when running the
gnuradio-companion.py file?

The command I’m using at the moment is: D:\Python27\python.exe
“C:\Program
Files (x86)\gnuradio\bin\gnuradio-companion.py”

Thanks and kind regards,

Ryan

On 04/15/2011 11:10 AM, Ryan van den Bergh wrote:

Hi Josh,

Thanks for the suggestions!

I can run top_block.py from the command line, and I’ve saved it in My
Documents folder, however I still can’t get GNU Radio Companion to execute
the file. Do I perhaps have to do something special when running the
gnuradio-companion.py file?

Glad to hear it works. So, GRC is calling into python to exec the
generated python code. Its trying to run "python …
And this works on linux because python is in your path, but I have no
idea why this works on windows. I mean obviously not for you, but its a
mystery as to why it works for me. Python is not in my path. I have no
idea how grc manages to execute the file it generates. But somehow it
does…

The command I’m using at the moment is: D:\Python27\python.exe “C:\Program
Files (x86)\gnuradio\bin\gnuradio-companion.py”

I would stick to running it manually like this until I figure this
mystery out. You may try putting c:\python27 in your %PATH%

-Josh

Hi Josh,

I’ve already got python in my path. I agree it’s a mystery - I’ll just
chalk
it up to another reason why I really hate Windows!

I’ll just run it manually. I’ll make a batch file to do it so that it’s
not
too painful.

Thanks for the assistance though, I really appreciate it!

Kind regards,

Ryan

FYI I found a way to more robustly handle the situation by grabbing the
path to the interpreter by using sys.executable. This seems to work
nicely and I like this solution better.

http://gnuradio.org/cgit/jblum.git/commit/?h=wip/grc/python_interp_path

-Josh

Hi Josh,

Works like a charm!! Thanks a million!

Kind regards,

Ryan

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs