[Top][All Lists]

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

[Discuss-gnuradio] GNURadio on Windows New installer available

From: Martin Dvh
Subject: [Discuss-gnuradio] GNURadio on Windows New installer available
Date: Mon, 20 Feb 2006 10:51:10 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030823

I made a new windows installer for Gnuradio and usrp.
With this new installer _usrp_prims is installed in the site-packages folder. 
(Which is where python demands it to be, even when it is on the patch somewhere 

Installer, source and instructions can be found on:


Robert Roberts wrote:
Just sending you that reminder you asked for!

----- Original Message -----
From: Martin Dvh <address@hidden>
Date: Monday, February 6, 2006 10:48 pm
Subject: Re: [Discuss-gnuradio] GNURadio on Windows

Robert Roberts wrote:

----- Original Message -----
From: Martin Dvh <address@hidden>
Date: Sunday, February 5, 2006 3:12 pm
Subject: Re: [Discuss-gnuradio] GNURadio on Windows

Stephane Fillod wrote:

Hi Chris,

On Sat, Feb 04, 2006 at 03:26:29PM -0500, Robert Roberts wrote:

Is there anyone out there working with GNURadio on Windows with

the USRP?

Disclaimer: I'm not using the USRP on Windows, just lending a

hand in

porting the code. Among the lurker on the list, are there any
Windows gurus who can help better, starting with, for example,
beta-testing the Windows Installer Martin kindly released?
Rem: no need to own an USRP to try out GNU Radio on Windows.

The current install files from Martin have one issue with the

that I

install them. When I attempt to run any of the USRP code it

looks for

the usrp_prims.dll in the C:\Python24\site-packages directory.

The>>>>installer places that file in C:\Program Files\USRP\bin Copying
the>>file fixes this.
The installer should have automatically put C:\Program Files\USRP\bin on your PATH.
I will check, maybe I overlooked something.
Maybe I should just put usrp_prims.dll in C:\Python24\site-
packages. It is a python related and URP related file.

Your installer appears to add the Usrp directory in the path

correctly,> I've also tried adding the path by hand and I get the same error (on

multiple machines), my only solution has been to place the
usrp_prims.dll in the site-packages folder.

I should check why it worked for me, I probably forgot to delete usrp_prims.dll from the site-packages dir before I tested. (It is installed there when I run the normal install process from mingw)I will change the install location to the site-packages dir as soon as I have a little time.
(Very busy right now)
I don't mind if somebody sends me a remainder next week if I forget to do this.
(I sort of have a habit of forgetting these things)

Also, once we get some stability would you mind if I created a CD

iso> image of everything needed? This way there can be a one stop shop to

install GNURadio on Windows boxes.  :-)

"once we get some stability" is an important issue.
If it is not properly tested and you start distributing an iso, expect loads of questions flooding the mailing-list.
We really need more testers.
We need audio fixed.
We need the wxgui to perform better (especially the scope_sink)
We need the first run of the usrp not result in an error. (First run now always gives an error about not being able to attach to interface,after the firmware has been loaded it is fine on next runs. This is an usrp/usb driver issue)
We really need more testers.

It is also a good idea to update the wiki. The windows documentation is surely out-of-date/incomplete.
Feel free to add, update anything needed.

Maybe it is also a good idea to put a link to the CategoryInstall on the homepage of the wiki.


Was the C:\Program Files\USRP\bin directory in your PATH?

The audio is very choppy with the WFM_RCV example. I found that

going>>into the Task Manager and setting Pythons priority to

time" fixes

this better.   Are there any other tweaks out there?

Perhaps not enough buffering? Having source/sink in threads

sometimes.> Martin will have better insight on the topic.
The code needs fixing but I haven't spend much time on optimizing it yet. I think it does has something to do with threads. Maybe another buffer layer or number of buffers (pingpong) will fix it. Put the windows_audio sink in another thread will probably help, but I don't know howto.

I just copied the ideas for the windows_audio driver from other GPL'ed windows audio projects.

The windows_audio driver also needs an audio_source implementation.

An other solution would be to implement a direct_audio driver (directX audio) in stead of fixing this.
I suspect you would have much less synchronisation issues.

A quick-and-dirty solution test would indeed be to increase the audio-buffer.
(You need to build from source to test this)

An even more quick and dirty test is to change the default value for all buffers between blocks.
(Can be done after install)
change the value for self.fixed_buffer_size in C:\Python24\site-
packages\gnuradio\flow_graph.pyline50: self.fixed_buffer_size = 32*1024
Change this to a higher/lower value and see what it does for you.
The default is 32*1024 which means 32 kByte
Note that this value is for ALL blocks, so you might break things when you make it too low and slow things down when you make it



reply via email to

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