Re: [Discuss-gnuradio] gnuradio for Windows

[Marcus Müller]

Hi Lyman,

to add to what Geof said, try the LiveSDR environment. It's kept for the
sole purpose of offering people with a ready-to-run environment, even if
they don't have a readily set up Linux box at hand.

http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD

Best regards,

Marcus


On 09/24/2016 05:05 PM, Geof Nieboer wrote:
> Lyman,
>
> Glad you were able to install GNURadio.  The warnings you mentioned
> are indeed known but are just warnings.
>
> If you can be more specific about what didn't work, it would be quite
> helpful.
>
> GNURadio is more stable on Linux as that is the primary platform for
> most users.  This Windows installer is relatively new so we are still
> working on a few issues, but we would like to hear what didn't work
> for you.
>
> Geof
>
> On Saturday, September 24, 2016, Lyman Paquette
> > wrote:
>
> Greetings,
>
> Recently I downloaded gnuradio for Windows to try as I do not have
> a working Linux box at present.
>
> The install went smoothly but upon starting gnuradio the command
> window came up and gave the following errors:
>
> Snip>>>
>
> setting gnuradio environment
>
> ** (python.exe:10624): WARNING **: Trying to register gtype
> 'GMountMountFlags' as enum when in fact it is of type 'GFlags'
>
> ** (python.exe:10624): WARNING **: Trying to register gtype
> 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
>
> ** (python.exe:10624): WARNING **: Trying to register gtype
> 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
> C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\main.py:43:
> GtkWarning: Could not find the icon 'gnuradio-grc'. The 'hicolor'
> theme
> was not found either, perhaps you need to install it.
>
> <<
> You probably already know about these but in case no one has let
> you know I am posting here.
>
> Using Win 10 - 64bit with Python 3.5 installed.
>
> It seems to be able to do some things but not others. As I am just
> trying to learn gnuradio I have not tested extensively.
>
> I will try your ubuntu build and upgrade gnuradio.
>
>
> regards
> L
>
>
>
> ___
> 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 for Windows

[Geof Nieboer]

Lyman,

Glad you were able to install GNURadio.  The warnings you mentioned are
indeed known but are just warnings.

If you can be more specific about what didn't work, it would be quite
helpful.

GNURadio is more stable on Linux as that is the primary platform for most
users.  This Windows installer is relatively new so we are still working on
a few issues, but we would like to hear what didn't work for you.

Geof

On Saturday, September 24, 2016, Lyman Paquette 
wrote:

> Greetings,
>
> Recently I downloaded gnuradio for Windows to try as I do not have a
> working Linux box at present.
>
> The install went smoothly but upon starting gnuradio the command window
> came up and gave the following errors:
>
> Snip>>>
>
> setting gnuradio environment
>
> ** (python.exe:10624): WARNING **: Trying to register gtype
> 'GMountMountFlags' as enum when in fact it is of type 'GFlags'
>
> ** (python.exe:10624): WARNING **: Trying to register gtype
> 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
>
> ** (python.exe:10624): WARNING **: Trying to register gtype
> 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
> C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\main.py:43:
> GtkWarning: Could not find the icon 'gnuradio-grc'. The 'hicolor' theme
> was not found either, perhaps you need to install it.
>
> <<
> You probably already know about these but in case no one has let you know
> I am posting here.
>
> Using Win 10 - 64bit with Python 3.5 installed.
>
> It seems to be able to do some things but not others. As I am just trying
> to learn gnuradio I have not tested extensively.
>
> I will try your ubuntu build and upgrade gnuradio.
>
>
> regards
> L
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio in windows

[Geof Nieboer]

Sorry for the late response, in general the dll's for gnuradio go in the
/bin directory of the installation.

Geof

On Sun, Jul 17, 2016 at 9:44 AM, Mostafa Alizadeh 
wrote:

> Hello Geof,
>
> Thank you so much for the response. I need to know where should I place
> the dll files of qwt for the installation?
>
>
> On Sun, Jul 17, 2016 at 6:45 AM, Geof Nieboer 
> wrote:
>
>> The Qt GUI problem can be fixed by downloading a version of the qwt dll
>> from the binaries site, but Wx will work in the meantime.  By the end of
>> the month a new version of the binaries should be posted that will fix that
>> issue.
>>
>> Is the gnuradio-grc.png causing a problem other than the windows icon not
>> appearing as expected?
>>
>>
>
> No, there is no problem with grc icon and it is appearing as expected.
> However, when WX GUI is appeared, the exact bellow error message is shown:
>
> *" Failed to load image from file "C:\Program
> Files\GNURadio-3.7\share\icons\hicolor|8x48/apps\gnuradio-grc.png"*
>
>
> Best,
> Mostafa
>
>
>
>
>> Geof
>>
>> On Fri, Jul 15, 2016 at 5:14 AM, Mostafa Alizadeh > > wrote:
>>
>>> Hello all,
>>>
>>> Is there any one who tried to use GNURadio in windows?
>>>
>>> I should use it because I have some special programs in windows and I
>>> want to use them in conjunction with GNURadio. I installed the prebuild
>>> version, but there are so many problems with running a flowgraph:
>>> - "python.exe" stops working when running a flowgraph with Qt:
>>> - when using wx GUIs, it says: "can't open file : ... /gnuradio-grc.png.
>>> In fact the problem is with the path where there is a difference between
>>> windows path representations and linux one.
>>>
>>> How could I solve this problem?
>>>
>>> Best,
>>> Mostafa
>>>
>>> ***
>>> Tehran
>>> IRAN
>>> Tel: +98 (919) 158-7730
>>> Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir
>>> Homepage: Linkedin
>>> 
>>>
>>> ***
>>>
>>> ___
>>> 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 in windows

[Mostafa Alizadeh]

Hello Geof,

Thank you so much for the response. I need to know where should I place the
dll files of qwt for the installation?


On Sun, Jul 17, 2016 at 6:45 AM, Geof Nieboer  wrote:

> The Qt GUI problem can be fixed by downloading a version of the qwt dll
> from the binaries site, but Wx will work in the meantime.  By the end of
> the month a new version of the binaries should be posted that will fix that
> issue.
>
> Is the gnuradio-grc.png causing a problem other than the windows icon not
> appearing as expected?
>
>

No, there is no problem with grc icon and it is appearing as expected.
However, when WX GUI is appeared, the exact bellow error message is shown:

*" Failed to load image from file "C:\Program
Files\GNURadio-3.7\share\icons\hicolor|8x48/apps\gnuradio-grc.png"*


Best,
Mostafa




> Geof
>
> On Fri, Jul 15, 2016 at 5:14 AM, Mostafa Alizadeh 
> wrote:
>
>> Hello all,
>>
>> Is there any one who tried to use GNURadio in windows?
>>
>> I should use it because I have some special programs in windows and I
>> want to use them in conjunction with GNURadio. I installed the prebuild
>> version, but there are so many problems with running a flowgraph:
>> - "python.exe" stops working when running a flowgraph with Qt:
>> - when using wx GUIs, it says: "can't open file : ... /gnuradio-grc.png.
>> In fact the problem is with the path where there is a difference between
>> windows path representations and linux one.
>>
>> How could I solve this problem?
>>
>> Best,
>> Mostafa
>>
>> ***
>> Tehran
>> IRAN
>> Tel: +98 (919) 158-7730
>> Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir
>> Homepage: Linkedin 
>>
>> ***
>>
>> ___
>> 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 in windows

[Geof Nieboer]

The Qt GUI problem can be fixed by downloading a version of the qwt dll
from the binaries site, but Wx will work in the meantime.  By the end of
the month a new version of the binaries should be posted that will fix that
issue.

Is the gnuradio-grc.png causing a problem other than the windows icon not
appearing as expected?

Geof

On Fri, Jul 15, 2016 at 5:14 AM, Mostafa Alizadeh 
wrote:

> Hello all,
>
> Is there any one who tried to use GNURadio in windows?
>
> I should use it because I have some special programs in windows and I want
> to use them in conjunction with GNURadio. I installed the prebuild version,
> but there are so many problems with running a flowgraph:
> - "python.exe" stops working when running a flowgraph with Qt:
> - when using wx GUIs, it says: "can't open file : ... /gnuradio-grc.png.
> In fact the problem is with the path where there is a difference between
> windows path representations and linux one.
>
> How could I solve this problem?
>
> Best,
> Mostafa
>
> ***
> Tehran
> IRAN
> Tel: +98 (919) 158-7730
> Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir
> Homepage: Linkedin 
>
> ***
>
> ___
> 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 3.7.2 Windows?

[Andrew Davis]

Hello,

Has anyone actually managed to successfully install and run the latest
gnuradio in Windows 7

Yes, but not using those instruction, building from source is much more fun
:), but they look like they worked for you outside of that error.

Also If you Google your error other people are having that problem as well,
so it's not Gnuradio related but something with pyopengl on certain windows
systems. I'd say try installing an older version of pyopengl.

 I must admit to getting extremely frustrated with Gnuradio and its lack
or usability for those of us who are not professional programmers.

While I agree it's not quite user friendly it is a software defined radio
API and development system, so it's not gonna be like going to be like
installing a program and listening to the radio, you will need
some software savvyness to build a SDR. If you just want to use a SDR there
are many already made programs for individual tasks.

Andrew


On Mon, Dec 23, 2013 at 4:47 AM, Mike Willis willis...@gmail.com wrote:



 Has anyone actually managed to successfully install and run the latest
 gnuradio in Windows 7 based on these
 http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windowsinstructions?



 I don’t believe this page is up to date as I just cannot get it to work.
 It was OK if something of a struggle with 3.6.



 Although it nearly works, the gui modules do not work at all but produce a
 rather unhelpful error message. E.g. this is with a wxgui fft sink added to
 the dialtone example. The tone works fine but not with any gui.



 “TypeError: (No array-type handler for type class 'ctypes.c_ulong'
 (value: c_ulong(0L)) registered, OpenGL.converters.CallFuncPyConverter
 object at 0x0482A3D0)

 ”



 How am I supposed to understand this? It looks to me like a problem with
 pyopengl but that has been installed as indicated in the instructions. Are
 the instructions wrong? Is this the wrong version? Does it just not work
 anyway?



 I must admit to getting extremely frustrated with gnuradio and its lack or
 usability for those of us who are not professional programmers.



 Mike



 Here is the debug code.



 self._initText()

   File C:\Program
 Files\gnuradio\lib\site-packages\gnuradio\wxgui\plotter\gltext.py, line
 376, in _initText

 self._centered)

   File C:\Program
 Files\gnuradio\lib\site-packages\gnuradio\wxgui\plotter\gltext.py, line
 73, in __init__

 self.createTexture()

   File C:\Program
 Files\gnuradio\lib\site-packages\gnuradio\wxgui\plotter\gltext.py, line
 229, in createTexture

 self._texture = glGenTextures(1)

   File
 C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\latebind.py,
 line 61, in __call__

 return self.wrapperFunction( self.baseFunction, *args, **named )

   File
 C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\GL\exceptional.py,
 line 189, in glGenTextures

 baseFunction( count, textures)

   File
 C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\latebind.py,
 line 45, in __call__

 return self._finalCall( *args, **named )

   File
 C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\wrapper.py,
 line 571, in wrapperCall

 pyArgs = tuple( calculate_pyArgs( args ))

   File
 C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\wrapper.py,
 line 356, in calculate_pyArgs

 yield converter(args[index], self, args)

   File
 C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\converters.py,
 line 134, in __call__

 return self.function( incoming )

   File
 C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\arrays\arraydatatype.py,
 line 141, in asArray

 return cls.getHandler(value).asArray( value, typeCode or
 cls.typeConstant )

   File
 C:\Python27\lib\site-packages\pyopengl-3.1.0a3-py2.7.egg\OpenGL\arrays\arraydatatype.py,
 line 52, in __call__

 typ, repr(value)[:50]

 TypeError: (No array-type handler for type class 'ctypes.c_ulong'
 (value: c_ulong(0L)) registered, OpenGL.converters.CallFuncPyConverter
 object at 0x0482A3D0)

 ___
 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 3.7.2 Windows?

[Bhaskar]

Instructions for installing on Windows 7 found at:
https://www.liamschneider.com/node/9

Let us know if it works for you.

B




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Re-Gnuradio-3-7-2-Windows-tp45528p45532.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNUradio and Windows 7

[mleech]

 

That is a known issue with the wxGTK implementation on Windows, and
not specific to Gnu Radio, unfortunately. 

On 26 Jan 2013 12:46,
tok...@myranch.com wrote: 

 I have finally been able to get GNUradio
to run under Windows 7 but have the following issues when running
GNUradio-Companion.py: 
 
 1. When I select blocks to be placed in the
working window I can't move the block around.

 ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNUradio and Windows 7

[Johnathan Corgan]

On Sat, Jan 26, 2013 at 9:50 AM, mle...@ripnet.com wrote:

 **

 That is a known issue with the wxGTK implementation on Windows, and not
 specific to Gnu Radio, unfortunately.

I think Balint Seeber recently fixed this:

http://gnuradio.org/cgit/gnuradio.git/commit/?id=d3c7e93f

It's on the master branch and will be part of release 3.6.4.

Johnathan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNUradio and Windows 7

[mleech]

 

On 26 Jan 2013 13:08, Johnathan Corgan wrote: 

 On Sat, Jan 26,
2013 at 9:50 AM, mle...@ripnet.com [1] wrote:
 
 That is a known
issue with the wxGTK implementation on Windows, and not specific to Gnu
Radio, unfortunately.
 I think Balint Seeber recently fixed this:
 

http://gnuradio.org/cgit/gnuradio.git/commit/?id=d3c7e93f [2]
 
 It's
on the master branch and will be part of release 3.6.4.
 

Johnathan

Ah. Awesome! 

Not that I use Windows, but it will make Gnu
Radio seem less like rubbish to newbs on Windows, which is always a good
thing... 

 

Links:
--
[1] mailto:mle...@ripnet.com
[2]
http://gnuradio.org/cgit/gnuradio.git/commit/?id=d3c7e93f
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio on windows 7

[Josh Blum]

On 01/15/2013 12:21 PM, tok...@myranch.com wrote:
 I have installed gnuradio and uhd according to the directions given in the 
 ettus wiki. When I try to run gnuradio-companion.py I get:
 
 C:\Users\Algnuradio-companion.py
 Traceback most recent call last:
   File “C:\Program Files\gnuradio\bin\gnuradio-companion.py”, line 22, in 
 module
   Import pygtk
 ImportError: No module named pygtk
 
 I tried explicitly adding the PATH to pygtk using Rapid Environment Editor 
 but that didn’t work.
 

The pygtk installer should setup that stuff automatically. Did you see
the post install instructions on that wiki page for the python dependencies?

-josh

 Looking for suggestion.
 
 Thank you.
 
 Al
 
 
 
 ___
 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 on Windows

[Robert Roberts]

- Original Message -
From: Martin Dvh [EMAIL PROTECTED]
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 way 
 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 
 thefile 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.



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.  :-)


  
  
  Was the C:\Program Files\USRP\bin directory in your PATH?
  
  
 The audio is very choppy with the WFM_RCV example. I found that 
 goinginto the Task Manager and setting Pythons priority to real 
 time fixes
 this better.   Are there any other tweaks out there?
 
 
  
  
  Perhaps not enough buffering? Having source/sink in threads helps 
 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 too 
 high.
 
 greetings,
 Martin
 
 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio on Windows

[Martin Dvh]

Robert Roberts wrote:
 
 - Original Message -
 From: Martin Dvh [EMAIL PROTECTED]
 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 way 

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 

thefile 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.
http://comsec.com/wiki?CategoryInstall
http://comsec.com/wiki?MinGW
http://comsec.com/wiki?UsrpMinGW
http://comsec.com/wiki?Cygwin

Maybe it is also a good idea to put a link to the CategoryInstall on the 
homepage of the wiki.
http://comsec.com/wiki

Greetings,
Martin
 
 
 

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



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

goinginto the Task Manager and setting Pythons priority to real 
time fixes

this better.   Are there any other tweaks out there?



Perhaps not enough buffering? Having source/sink in threads helps 

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 too 
high.

greetings,
Martin


 
 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio on Windows

[Martin Dvh]

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 way 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.

 
 
 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 real time fixes
this better.   Are there any other tweaks out there?


 
 
 Perhaps not enough buffering? Having source/sink in threads helps 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.py
line50: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 too high.


greetings,
Martin



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio on Windows

[Eric Blossom]

On Sun, Feb 05, 2006 at 09:12:10PM +0100, Martin Dvh wrote:
  
  Perhaps not enough buffering? Having source/sink in threads helps 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.py
 line50: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 too high.
 
 greetings,
 Martin

I don't think changing the flow graph buffering is going to make any
difference.  I think that the right answer is build a very
high-functioning audio sink/source using portaudio.  It's on my list,
but if somebody else wants to do it, please do (talk to me.  I've got
some ideas.)  Using the portaudio CVS version 19 stuff, there is now good
support for windows, and under ALSA and jack under Linux.  It's also
supposed to work under OS/X using CoreAudio.

Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio on Windows

[Berndt Josef Wulf]

On Monday 06 February 2006 11:04, Eric Blossom wrote:
 On Sun, Feb 05, 2006 at 09:12:10PM +0100, Martin Dvh wrote:
   Perhaps not enough buffering? Having source/sink in threads helps
   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.py line50:   
  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 too high.
 
  greetings,
  Martin

 I don't think changing the flow graph buffering is going to make any
 difference.  I think that the right answer is build a very
 high-functioning audio sink/source using portaudio.  It's on my list,
 but if somebody else wants to do it, please do (talk to me.  I've got
 some ideas.)  Using the portaudio CVS version 19 stuff, there is now good
 support for windows, and under ALSA and jack under Linux.  It's also
 supposed to work under OS/X using CoreAudio.


There hasn't been any official releases since the 30 June 2003 with V18.1. Do 
you think its a good idea to use the CVS version?

No releases usually means an unacceptable status of the current work unfit for 
public release.

cheerio Berndt


pgpFB1CKIwsr5.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio on Windows

[Robert McGwier]

Gerald Youngblood with Flex Radio has made a multimillion dollar 
business using V.19. He would be dead in the water without it being 
reliable.  I have used V.19 on windows, linux, etc.  I converted the 
gr-audio-alsa code to gr-audio-portaudio superficially and checked it 
in.  It will soon rise to the top of my plate.  I have used portaudio on 
top of jack for the new WJST development team.  Joe Taylor (K1JT for you 
hams) opened the source and invited a few to help.  He was using 
PortAudio V.19 on Windows.  I have been watching PortAudio closely now 
for almost two years.


Recently:

Eric Wachsmann of Flex Radio finished the windows code by getting 
portaudio to run reliably on top of Windows WDM-KS.   This was Flex 
Radio's pay back to that community for the value it has received.   This 
will be lower latency than linux-2.6 with low latency and alsa or jack 
in real time mode.  I know as I have measured it.  At this low level,  
Windows allow you to preempt the kernel and just about everything else 
almost without safe guards so you can get some truly tiny latencies. 

Arne Knudsen has steadily erased all problems I have experienced in 
using PortAudio on top of OSS, ALSA, and Jack.


In the last month,  multiple people have gotten portaudio to run on 
Coreaudio and the Mac stuff is taking off.


I would say that this is the single best hope we have for reliable and 
solid audio under Windows for GnuRadio.  I will soon return to this and 
help Eric, et. al. get it running and into the general cvs download and 
then all of us can beat it into shape.


I might remind Berndt and everyone else that I have NEVER used a release 
version of GnuRadio.  They seem to stay current for about fifteen 
minutes under a major change was checked in!


Bob



Berndt Josef Wulf wrote:

On Monday 06 February 2006 11:04, Eric Blossom wrote:
  

On Sun, Feb 05, 2006 at 09:12:10PM +0100, Martin Dvh wrote:


Perhaps not enough buffering? Having source/sink in threads helps
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.py line50:   
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 too high.

greetings,
Martin
  

I don't think changing the flow graph buffering is going to make any
difference.  I think that the right answer is build a very
high-functioning audio sink/source using portaudio.  It's on my list,
but if somebody else wants to do it, please do (talk to me.  I've got
some ideas.)  Using the portaudio CVS version 19 stuff, there is now good
support for windows, and under ALSA and jack under Linux.  It's also
supposed to work under OS/X using CoreAudio.




There hasn't been any official releases since the 30 June 2003 with V18.1. Do 
you think its a good idea to use the CVS version?


No releases usually means an unacceptable status of the current work unfit for 
public release.


cheerio Berndt
  



--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity.  Guilty as charged!



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio on Windows

[Eric Blossom]

On Mon, Feb 06, 2006 at 01:46:50PM +1030, Berndt Josef Wulf wrote:
 
  I don't think changing the flow graph buffering is going to make any
  difference.  I think that the right answer is build a very
  high-functioning audio sink/source using portaudio.  It's on my list,
  but if somebody else wants to do it, please do (talk to me.  I've got
  some ideas.)  Using the portaudio CVS version 19 stuff, there is now good
  support for windows, and under ALSA and jack under Linux.  It's also
  supposed to work under OS/X using CoreAudio.
 
 
 There hasn't been any official releases since the 30 June 2003 with V18.1. Do 
 you think its a good idea to use the CVS version?
 
 No releases usually means an unacceptable status of the current work unfit 
 for 
 public release.

Could be.  On the other hand it appears that good work is being done
in CVS.  Lots of activity on their mailing lists.  Not sure why they
haven't made a release yet.  The V18.1 stuff will not solve our
problem, so I see zero reason to even consider it.  I'm hoping to
handle *all* audio issues on *all* platforms with a single
gr-audio-portaudio module.  [ I could be dreaming, but hey, that's what
portaudio is supposed to do ;) ]

If we find that their CVS works for us on all platforms we care about,
then we talk to the developers and see what it would take to get them
to make a V19 official release.  Perhaps nobody's asked them in a few
years ;)


Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio on Windows

[Berndt Josef Wulf]

On Monday 06 February 2006 13:06, Robert McGwier wrote:
 Gerald Youngblood with Flex Radio has made a multimillion dollar
 business using V.19. He would be dead in the water without it being
 reliable.  I have used V.19 on windows, linux, etc.  I converted the
 gr-audio-alsa code to gr-audio-portaudio superficially and checked it
 in.  It will soon rise to the top of my plate.  I have used portaudio on
 top of jack for the new WJST development team.  Joe Taylor (K1JT for you
 hams) opened the source and invited a few to help.  He was using
 PortAudio V.19 on Windows.  I have been watching PortAudio closely now
 for almost two years.

 Recently:

 Eric Wachsmann of Flex Radio finished the windows code by getting
 portaudio to run reliably on top of Windows WDM-KS.   This was Flex
 Radio's pay back to that community for the value it has received.   This
 will be lower latency than linux-2.6 with low latency and alsa or jack
 in real time mode.  I know as I have measured it.  At this low level,
 Windows allow you to preempt the kernel and just about everything else
 almost without safe guards so you can get some truly tiny latencies.

 Arne Knudsen has steadily erased all problems I have experienced in
 using PortAudio on top of OSS, ALSA, and Jack.

 In the last month,  multiple people have gotten portaudio to run on
 Coreaudio and the Mac stuff is taking off.

 I would say that this is the single best hope we have for reliable and
 solid audio under Windows for GnuRadio.  I will soon return to this and
 help Eric, et. al. get it running and into the general cvs download and
 then all of us can beat it into shape.

 I might remind Berndt and everyone else that I have NEVER used a release
 version of GnuRadio.  They seem to stay current for about fifteen
 minutes under a major change was checked in!

 Bob

 Berndt Josef Wulf wrote:
  On Monday 06 February 2006 11:04, Eric Blossom wrote:
  On Sun, Feb 05, 2006 at 09:12:10PM +0100, Martin Dvh wrote:
  Perhaps not enough buffering? Having source/sink in threads helps
  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.py line50:
  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 too high.
 
  greetings,
  Martin
 
  I don't think changing the flow graph buffering is going to make any
  difference.  I think that the right answer is build a very
  high-functioning audio sink/source using portaudio.  It's on my list,
  but if somebody else wants to do it, please do (talk to me.  I've got
  some ideas.)  Using the portaudio CVS version 19 stuff, there is now
  good support for windows, and under ALSA and jack under Linux.  It's
  also supposed to work under OS/X using CoreAudio.
 
  There hasn't been any official releases since the 30 June 2003 with
  V18.1. Do you think its a good idea to use the CVS version?
 
  No releases usually means an unacceptable status of the current work
  unfit for public release.
 
  cheerio Berndt


Wow, many thanks for a very detailed report on portaudio. It has kindled my 
curiosity, so much so that I've downloaded and built the V19-devel snapshot.

It took only a few minor changes to get it going on NetBSD and sofar passed 
all test applications that I run in this short period of time. Will read the 
docs in greater details tonight.

cheerio Berndt


pgpserrUieW8Y.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio