Re: GR-3.9 Windows BETA "Installer"

[Geof Nieboer]

The gr-fosphor build was not successful on the python side, which is why I
didn't mention it, but I didn't remove the parts that did succeed.

This block is a personal favorite, so after the essential blocks to use SDR
devices are solid, this will be the next priority to look for.

Geof

On Thu, Jan 21, 2021 at 5:16 AM Sylvain Munaut <246...@gmail.com> wrote:

> Hi Geof,
>
> I had a quick look, seems you included fosphor, thank you. However it
> seems the python/grc binding weren't built ? I only see the c++ block
> in there.
>
> Cheers,
>
> Sylvain
>
>

GR-3.9 Windows BETA "Installer"

[Geof Nieboer]

All,

As I was on a roll, I pressed forward from 3.8.2 to 3.9.0, and have posted
a BETA GR-3.9.0.0 package for Windows 10.

The file is located here


A couple key caveats:
1- There is not an actual .msi installer file, the msi WIX created began to
fire 2907 errors due to some strange vccor dll issue, so this is merely a
ZIP file that can be unzipped where you desire.  The only real downside is
that there is no shortcut cleanly placed in the start menu.  RUN_GRC.BAT
found in the /bin folder is all you need to remember.
2- gr-soapy and gr-osmosdr were built from non-official repos that have
already added some 3.9 support, so your mileage may vary.

So please poke around with it and post your bugs.  While in theory the
3.7/3.8/3.9 packages could all be installed simultaneously, there are some
potential issues with the user-specific configuration files causing
problems (as all 3 installations share the same "per-user" config).

Once a couple more OOT packages become officially compatible, a full
installer will be release "soon" afterwards.

Geof

Re: Windows install link

[Geof Nieboer]

The link is back up, there was an error discovered in a package released
last night.  It's now been fixed.

Geof

On Tue, Jan 19, 2021 at 1:41 PM Jay Patel  wrote:

> Hi All,
>
> We are teaching students GNURadio this year in DSP class. Most of the
> students are using Windows as classes are online. We ask them to download
> GNURadio 3.8 for windows install from here
> .
>
> But unfortunately, the link was working a few days back and now had been
> removed  the installer link due to a file chooser bug.
>
> Is there any other way or server that we can use ? We are ok with the
> newer version of GNURadio (3.9) as well.
>
> Any help would be appreciated
>
> *With Regards,*
> *Jay Patel*
> *+1 902-818-8034*
> *+91 9510032033*
>

Windows Installer for GR 3.8.2 Just In Time!

[Geof Nieboer]

All,

To celebrate the release of GR 3.9, I'm releasing a Python3-based Windows
Installer for GR 3.8.2* !

Download it here

.

This uses vcpkg to build (nearly*) all the C++ dependencies, and as
mentioned in an earlier email, uses standard pip with Python 3.9 to install
the GR python dependencies as well.

It includes several commonly used SDR drivers; UHD, rtl-sdr, SoapySDR,
HackRF, BladeRF, and airspy, with most wrapped in the gr-osmosdr package.

In addition it includes the popular gqrx application and the gr-fosphor
blocks.

As with previous installers, gr-3.7 and gr-3.8 can be installed side by
side, and the same will apply to gr-3.9 when released.

*Caveats: Technically it's not the 3.8.2 release, it's the head of
maint-3.8 to include several important fixes.
Also, vcpkg worked fine, except for gobject-introspection.  While I have a
solid idea what the problem is, it wasn't worth delaying the release so did
a bit of manual magic outside the scripts to get gtk properly copied over.

Known Bugs: flowgraphs that include a gr-fosphor sink crash on when the
flowgraph is closed.

Enjoy!  Now that a GR 3.9 release is out and the scripts have been updated,
expect a GR 3.9 installer soon (or at least a minimum pull requests
submitted...)

Geof

Update on windows installer

[Geof Nieboer]

All,

Just wanted to drop a note that while I have not released an installer for
a bit, there is in fact work in progress.

The longer version...

The original installers used Py2.7, which was designed to use VS 2008..
which then forced packages to use the same compiler...  But GR 3.7 required
newer compilers... the net result was that handy tools like "pip" and most
pre-built binaries were nearly useless due to ABI conflicts, and everything
in those packages had to be built from scratch with VS 2015... So the Win64
build scripts have painful manual compilation of libraries never originally
intended for windows, and built with VS 2015+ consistently.

THIS in work version, using python 3.x, does not have this issue, as VS
2015/17/19 are pretty much cross-compatible now and the expected compilers
for Py3 versions.  As a result, we can use the nifty "vcpkg" project to do
most of the dependency heavy lifting, and get standard packages from pip.
Plus 64-bit packages are now pretty much standard.

The good news here is that the final product will be simpler to maintain,
as now windows-unique issues will be handled upstream, and the installer
scripts will just need to handle GNURadio and a handful of specialized
packages not found elsewhere.  And for 95% of the packages, a single line
of script code will add the package.  So that means more rapid turnaround
of releases, and inching closer to be able to integrate into a CI framework.

The bad news is that 5%.  Things like the most recent numpy (1.19.4) being
completely broken on windows... most of that 5% is in my personal nemesis,
*gobject-introspection*, which is not currently supported by vcpkg, and is
required by GTK.  This library is a nightmare to build... but I am working
to try to add it to the vcpkg ports.  To add it to vcpkg of course now
requires upgrading other glib components... and if I may rant for a moment,
the build chain for GI in vcpkg is [sometimes]:
vcpkg calls cmake
cmake calls meson
meson calls ninja
ninja calls python
python calls C compiler to build extension
extension scans C header files to build XML files

each step making their own unique changes to the build environment, and
they may or may not pass error information verbatim upstream... what could
go wrong??  Right now I'm stuck with an extraordinarily helpful error
"non-zero exit status 3221225781" from someplace in the gir data generation
phase.  It's a nightmare :).

BUT... It will eventually be completed one way or another, so wanted the
community to know it's not been dropped.

Geof

Re: Error running GNU radio V. 3.8.1 on windows 10

[Geof Nieboer]

This appears to be issue related to the one here:
https://stackoverflow.com/questions/36003023/json-dump-failing-with-must-be-unicode-not-str-typeerror/36003774,
and probably caused because this Win10 version is the last with py2.7
integrated.

I haven't run into this error myself, so I'm not sure why it's happening
for you.

I see three options for you:
1- Figure out what unicode characters were being used that caused python to
want to save it as unicode and don't use those (possible temp workaround)
2- Modify cache.py manually using the information on the SO link so it's
compatible.
3- Wait until I release a Python 3 version of GR 3.8 for Win10.  This is
the next task in my list, but I make no promises as to timelines.  In the
meantime, you could try 3.8.0 or 3.7.x versions.

Geof

On Tue, Aug 11, 2020 at 11:52 AM Steffen Kiel 
wrote:

> Hello!
>
> I am trying to run the newest stable release of gnu radio on windows, and
> i am running into some issues which im not sure how to fix.
> Here is the error log when im trying to start the application:
>
> *"setting gnuradio environment*
> *WARNING:gnuradio.grc.core.platform:Slow YAML loading (libyaml not
> available)*
> *Traceback (most recent call last):*
> *  File "gnuradio-companion.py", line 102, in *
> *run_main()*
> *  File "gnuradio-companion.py", line 95, in run_main*
> *exit(main())*
> *  File "C:\Program
> Files\GNURadio-3.8\lib\site-packages\gnuradio\grc\main.py", line 83, in
> main*
> *platform.build_library()*
> *  File "C:\Program
> Files\GNURadio-3.8\lib\site-packages\gnuradio\grc\core\platform.py", line
> 182, in build_library*
> *continue*
> *  File "C:\Program
> Files\GNURadio-3.8\lib\site-packages\gnuradio\grc\core\cache.py", line 89,
> in __exit__*
> *self.save()*
> *  File "C:\Program
> Files\GNURadio-3.8\lib\site-packages\gnuradio\grc\core\cache.py", line 78,
> in save*
> *cache_file.write(json.dumps(self.cache, ensure_ascii=False))*
> *TypeError: must be unicode, not str*
> *"*
>
> Anyone know how i can fix this error, or why im getting it in the first
> place? This is a fresh install of 3.8.1.
>
>

Windows Binaries for 3.8.1.0 Available

[Geof Nieboer]

All,

Windows installers have been updated for GR 3.8.1.0 and are out of "beta"
status.  This can be installed side-by-side with the 3.7 versions (but not
other 3.8 versions)

Download it here

:


*Expect this to be the final release that will include Python 2.7. *

Issues Fixed:

-Errant AVX2 instructions removed

The following versions were updated (to include necessary changes in build
scripts to accommodate upstream changes):

   - GNURadio -> 3.8.1.0
   - volk -> 2.3
   - UHD -> 3.15
   - scipy -> 1.2.2
   - boost -> 1.66.0
   - openssl -> 1.0.2r
   - gqrx -> 2.12.1

Re: GNU 3.8.0.0 doesn’t show result after execute & run_gr.bat

[Geof Nieboer]

Wei-Wen,

1- What generation is your CPU?  Does it have AVX/AVX2 extensions?  If not,
that is likely the cause of this error, two others have reported it as well
2- If so, the "fix" for the moment is to download the more stable 3.7.13.5
windows installer (you can have both installed at the same time) and try
using that.  This has worked for others

Please keep an eye out for a new GR 3.8 Windows release.  I am planned on
releasing one "soon" (probably in the next 30 days)

Geof

On Mon, Jun 15, 2020 at 11:09 PM wei-wen Cheng <
evelyncheng.e...@g2.nctu.edu.tw> wrote:

>
>
> On Tue, Jun 16, 2020 at 10:53 AM wei-wen Cheng <
> evelyncheng.e...@g2.nctu.edu.tw> wrote:
>
>> Thank Shin!
>> Your description of run_gr.bat makes me clear about the physical meaning
>> of it!
>> For problem 1, I uninstalled 3.8.0.0 and install 3.7.10 instead, and the
>> plot pop out. I don’t know what’s wrong with 3.8.0.0. But if anyone has the
>> same problem, you can try install 3.7.10
>>
>> On Tue, Jun 16, 2020 at 10:17 AM Kyeong Su Shin 
>> wrote:
>>
>>> Hello Wei-Wen:
>>>
>>> First, Windows tends to behave erratically when you run scripts by just
>>> typing their file paths (tends to mix up binary/library paths; remember
>>> that CP/M-like OSs do not support shebang). So, I suggest trying "python
>>> name_of_a_script.py" instead of "name_of_a_script.py" when using
>>> Windows.
>>>
>>> Did you run your scripts on GNU Radio Command Prompt? If so, you can
>>> simply ignore run_gr.bat. run_gr.bat _is_ what is used to initiate GNU
>>> Radio Command Prompt, so you do not need to use it again if you are already
>>> on GNU Radio Commmand Prompt.  GNU Radio Command Prompt is just a generic
>>> Windows command prompt, but with a few additional variables configured to
>>> deal with customized Python binary/library paths.
>>>
>>> Regards,
>>> Kyeong Su Shin
>>> --
>>> *보낸 사람:* wei-wen Cheng  대신
>>> Discuss-gnuradio 
>>> *보낸 날짜:* 2020년 6월 16일 화요일 오전 10:48
>>> *받는 사람:* discuss-gnuradio@gnu.org 
>>> *제목:* Re: GNU 3.8.0.0 doesn’t show result after execute & run_gr.bat
>>>
>>> The following is all the message show on my cmd line, I hope this helps.
>>> Great thanks for viewing my problem!
>>>
>>> Microsoft Windows [Version 10.0.17763.1217]
>>> (c) 2018 Microsoft Corporation. 著作權所有，並保留一切權利。
>>>
>>> C:\Program Files\GNURadio-3.8\bin>run_gr.bat ..\share\gnuradio\examples\
>>> analog\fmtest.py
>>> setting gnuradio environment
>>>
>>> C:\Program Files\GNURadio-3.8\bin>gnuradio-companion.py
>>> WARNING:gnuradio.grc.core.platform:Slow YAML loading (libyaml not
>>> available)
>>> <<< Welcome to GNU Radio Companion 3.8.0.0 >>>
>>>
>>> Block paths:
>>> C:\Users\User\.grc_gnuradio
>>> C:\Program Files\GNURadio-3.8\share\gnuradio\grc\blocks
>>>
>>> Loading: "C:\Program Files\GNURadio-3.8\share\
>>> gnuradio\examples\channels\demo_ofdm.grc"
>>> >>> Done
>>>
>>> Loading: "C:\Users\User\Desktop\gnu_radio\demo_gmsk.grc"
>>> >>> Done
>>>
>>> Generating: 'C:\\Users\\User\\Desktop\\gnu_radio\\demo_gmsk.py'
>>>
>>> Executing: C:\Python27\python.exe -u C:\Users\User\Desktop\gnu_
>>> radio\demo_gmsk.py
>>>
>>> >>> Done (return code -1073741795)
>>>
>>> On Tue, Jun 16, 2020 at 9:29 AM wei-wen Cheng <
>>> evelyncheng.e...@g2.nctu.edu.tw> wrote:
>>>
>>> Hi,
>>> I am a starter of gnu radio. I followed the tutorial on the wiki, simply
>>> add the signal source, throttle, QT time sink. When I run the  flow graph,
>>> there is no result plot pop out. Instead, the command line shows:
>>> done(return code -1073741795). Can you tell me how can I see my result? I
>>> would like  both plot result on grc and export data to .dat file in the
>>> directory.
>>> Another question is run_gr.bat filename.py on the download document for
>>> windows website. I cannot tell what is the purpose of the run_gr.bat, and
>>> might do it wrong.
>>> I run gnu radio in Windows 10.
>>> Thank you
>>>
>>>

Re: GRC Windows installer page "gcndevelopment" unavailable

[Geof Nieboer]

It's back up and running.  The server needed a kick in the head.

On Mon, Apr 6, 2020 at 10:50 AM Bernd Schleicher 
wrote:

> Hi all,
>
> trying to install Windows version of GnuRadio, but the page
> http://www.gcndevelopment.com/gnuradio/downloads.htm  shows “Service
> Unavailable”.
>
> Can anybody help?
>
> Thanks, Bernd
>
>
>
>
>
>
>
>
>
>
>

Re: GRC 3.8 Output language Py2 or Py3 (Windows)

[Geof Nieboer]

Jerom,

Confirming what Marus and the others have said, the current installers use
py2.7 and only py2.7.

It is indeed a major effort to move to py3 (because compilers), and once
it's done, it'll be done forever, I can't maintain 2 versions.  So since
py2.7 was the legacy standard, I'm planning on one more GR 3.8 build before
converting the installers to py3.

Py3 once the old code is ripped out will actually be much easier to
maintain, but for now, you are stuck.  However, at some point in the
future-at-a-date-I-won't-commit-to-because-life, GR3.8+py3 will be
available on Windows in a handy-dandy installer.

Geof

On Thu, Feb 20, 2020 at 11:55 AM Michael Dickens 
wrote:

> If you install from an EXE, then you'll get whatever it was built for
> (Py27 or Py3). If there's any way to build from source then you can select
> the Python version directly. I don't run Windows, nor do I build for it;
> hopefully someone is providing different Windows installer for GR38 with
> variants for Py27 and Py3 ... - MLD
>
> On Thu, Feb 20, 2020 at 10:08 AM Jerom Maas - LR 
> wrote:
>
>> Hello Michael, thanks for the quick response!
>>
>> I've just reinstalled GRC, but I've not seen a single option about Py2 or
>> Py3. Maybe it's because I use the .exe installer, that it automatically
>> chooses Py2 then? As said before, I don't even have Py2 installed on my pc.
>> Should I give it a go using Powershell, or try another method?
>>
>>
>> Jerom
>> --
>> *Van:* Michael Dickens 
>> *Verzonden:* donderdag 20 februari 2020 15:50:43
>> *Aan:* Jerom Maas - LR
>> *CC:* discuss-gnuradio@gnu.org
>> *Onderwerp:* Re: GRC 3.8 Output language Py2 or Py3 (Windows)
>>
>> Hi Jerom - I believe GRC outputs Py script based on how GR is installed.
>> Since GR38 can be installed using Py27 or Py3, if it's installed using Py27
>> then GRC will output for Py27. If installed for Py3 then it'll output for
>> Py3. Pretty sure this is correct. Hence, I'd advise you to check how GR is
>> installed in the first place & if for Py27 then see about getting it
>> installed for Py3. Hope this is useful! - MLD
>>
>> On Thu, Feb 20, 2020 at 9:06 AM Jerom Maas - LR 
>> wrote:
>>
>>> Hello all,
>>>
>>>
>>> after installing GRC 3.8, I find that the .py files that are created
>>> from grc are python 2, instead of python 3.
>>>
>>> I use Py3 and not Py2, so that's a problem.
>>>
>>> How do I change the output language of GRC? If I use the 'option block'
>>> I can only choose 'Python'  or ' C++' , but I can't specify the version of
>>> Python. I am using Windows.
>>>
>>>
>>> Thanks for your help,
>>>
>>>
>>> Jerom Maas
>>>
>>>
>>> PS I am not so familiar with C, so if the solution is to alter a bit in
>>> Cmake or something, can you specifically name the file that needs to be
>>> changed? That would be very helpful!
>>>
>>>
>>>
>>>
>>
>> --
>> Michael Dickens
>> Ettus Research Technical Support
>> Email: supp...@ettus.com
>> Web: https://ettus.com/
>> 
>>
>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>

Re: GNURadio Leaking memory during repeated simulations

[Geof Nieboer]

It's possible I suppose, but the IDE wouldn't have been my first guess,
unless it's running in some kind of debugging mode where it can't garbage
collect freed memory?  I haven't used PyCharm so can't comment specifically
on how it works.  I would try to just to run the python example script from
a run_gr.bat command line without anything else involved at all and see
what happens.  I ran the sample using VS 2015 Community (which I start
["devenv.exe"] from the run_gr.bat command line so that not only are the
python environment vars included, but all the $PATH changes as well).

Geof

On Tue, Feb 18, 2020 at 12:40 PM Roman A Sandler 
wrote:

> Him Geof,
>
> I am running GR using the standard install but from PyCharm (I imported
> all the necessary environment variables from run_gr.bat into PyCharm
> myself). I installed tqdm on top of the GR python via pip. I also confirmed
> that the issue occurs even without tqdm. Could PyCharm be causing these
> problems?
>
> -Roman
>
> On Thu, Feb 13, 2020 at 7:10 PM Geof Nieboer 
> wrote:
>
>> Roman,
>>
>> I was able to run your code, and got a consistent 150-160 it/s through
>> the whole run, with about 65MB of memory in use (as reporting by Task
>> Manager).  This was on Windows 10 running GR 3.8.0.0.
>>
>> I noticed there was another package installed (tqdm) that's not part of
>> the GR install.  So I want to confirm... did you add that package to the
>> python that installed as part of GR, or are you using a different python?
>>
>> If you are using a different python install, a possible explanation is
>> compilers; the GR packages and binaries are all built with VS 2015, but the
>> py2.7 standard is VS 2008 (which won't build GR any more), and mixing (VS)
>> compilers can cause odd issues.  So for GR, the entire python 2.7 and every
>> package is built from scratch w/ 2015.  tqdm doesn't seem to be affected, I
>> added that to the GR python install using a pip install, nothing fancy, and
>> it seems to have worked.
>>
>> If you are, however, running the script with the GR-installed python
>> after opening with run_gr.bat, then I'm scratching my head what's happening.
>>
>> Geof
>>
>> On Thu, Feb 13, 2020 at 12:00 PM Roman A Sandler 
>> wrote:
>>
>>> Hi Marcus,
>>>
>>> Thanks for the reply!
>>>
>>> My GNURadio version: *3.8.0.0 (Python 2.7.10)*
>>> It is the Windows 3.8.0.0 version downloaded from:
>>> http://www.gcndevelopment.com/gnuradio/downloads.htm
>>>
>>> Complete reproducible code is below. I use the tqdm package to monitor
>>> iterations per second. On my PC, the it/sec declines very precipitously
>>> (starts at 85it/sec, then down to 22it/s after 40s and keeps dropping.
>>> Eventually as low as 1 it/sec).
>>>
>>>
>>> ```
>>>
>>> import numpy as np
>>> from gnuradio import gr, gr_unittest
>>> from gnuradio import blocks
>>> from gnuradio import digital
>>> from gnuradio.filter import firdes
>>> from gnuradio import channels
>>> from tqdm import tqdm
>>>
>>>
>>> def decode(channel_sigs):
>>> tb = gr.top_block()
>>>
>>> ##
>>> # Variables
>>> ##
>>> nfilts = 32
>>> sps = 4
>>> timing_loop_bw = 3 * 6.28 / 100.0  # NOTE: this controls convergence 
>>> speed!
>>> constellation_scheme = digital.constellation_8psk().base()
>>> rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 / float(sps), 
>>> 0.35, 11 * sps * nfilts)
>>>
>>>  Actual blocks
>>> channel_src = blocks.vector_source_c(channel_sigs, False)
>>> digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps, 
>>> timing_loop_bw, rrc_taps, nfilts,
>>> nfilts / 2, 1.5, 1)
>>> constellation_soft_decoder = 
>>> digital.constellation_soft_decoder_cf(constellation_scheme)
>>> binary_slicer = digital.binary_slicer_fb()
>>> blocks_char_to_float = blocks.char_to_float(1, 1)
>>> recovered_bits_dst = blocks.vector_sink_f()
>>>
>>> ##
>>> # Connections
>>> ##
>>> tb.connect((channel_src, 0), (digital_pfb_clock_sync, 0))
>>> tb.connect((digital_pfb_clock_sync, 0), (constellation_soft_deco

Re: UHD and USRP1

[Geof Nieboer]

Michael,

I still have my USRP1, and ran the same test w/ 3.14 and got the same
results on Win10, dropped packets down to the minimum supported rate.  Same
test, same driver against the B200 works fine up to about 20MSps which
appears to be my USB 3 chip's limit.
For kicks I downloaded the same older version of UHD you had success with,
and ran it without a problem up to 8 MSps.

For "real" usage, the issue is similar... I just checked that the UHD_WBFM
sample .grc file still works with the latest UHD drivers, etc, audio is
fine (even if I kick up the samp_rate to 4MSps) though the same "D" dropped
packets are reported.

My VirtualBox installation needs to be updated, or I'd check in Linux as
well.

So I think it's a driver issue, though if it's really dropping packets or
just reporting them dropped is a question for Ettus.

Geof

On Sun, Feb 16, 2020 at 11:52 AM Marcus Müller 
wrote:

> Hi Michael,
>
> GR 3.3?! Wow, that *is* retro :)
>
> > Now I wanted to give it a try on W10 and a modern PC, but when I run a
> RX benchmark_rate test with latest UHD 3.15 but also 3.10  the command
> window gets filled up with DD messages and number of dropped samples
> is huge.
>
> That shouldn't happen. The maximum rates of the USRP1 should never even
> stress a modern PC.
>
> BTW, not even sure libusrp1 had indications for dropped samples. In
> fact, I remember the documentation back in the day of GR 3.4's gr-usrp
> said it would simply drop samples on multi-device reception until
> streams aligned. Don't remember whether that included any signalling.
>
> Anyway, I suspect USB strangeness under windows 10.
>
> Did you try UHD 3.15 on Linux? If you just set up a Ubuntu 19.10 system,
> the GNU Radio you can install directly through apt-get there will bring
> in UHD 3.15.
> I don't have a USRP1 at hand, so I can't test this :(
>
> Best regards,
> Marcus
>
> On 16.02.20 07:51, Michael Margaras wrote:
> > Hello All,
> > I have been using my USRP1 mainly on an older Linux PC with GNU radio
> 3.3 .
> > Now I wanted to give it a try on W10 and a modern PC, but when I run a
> RX benchmark_rate test with latest UHD 3.15 but also 3.10  the command
> window gets filled up with DD messages and number of dropped samples is
> huge.
> >
> > Have also tried the older UHD 3.005.004 on the same PC and there I am no
> getting any dropped samples !
> >
> > Anyway , with UHD 3.15 an 3.10, at the end of the test , the number of
> dropped samples is huge but remarkably overflows are 0.
> > This happens at all sample rates but the number of dropped samples  is
> decreasing as the sample rates decreases but still remains huge even a
> lowest sampling rate.
> >
> > On the other hand , on an older Dell D630 PC running  Ubuntu 9.10 and
> GNU Radio 3.3 (libusrp) no dropped samples or overflows have been observed
> up to almost 8 MSPS.
> >
> > Please find benchmark_rate results of the W10 PC using UHD 3.10 at the
> end of this message for 6MSPS , 2MSPS and 0.1875 MSPS.
> > BTW, master clock was modified to 48 MHz but same results have been
> observed with the default 64 MHz clock.
> >
> > Is anybody successfully using USRP1 on W10 or Linux with latest UHD
> releases?
> > How can this dropped-samples issue be fixed?
> >
> > Any suggestion would be very welcome.
> >
> > Many thanks in advance !
> >
> > Michael Margaras
> > SV1CAL
> >
> >
> > Below testing 6 MSPS , 2 MSPS  and 0.1875 MSPS :
> >
> >
> > C:\Program Files\UHD\lib\uhd\examples>benchmark_rate --rx_rate 6e6
> --rx_cpu sc16 --rx_otw sc16
> > Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.010.001.001-0-unknown
> >
> >
> > -- Loading firmware image: C:\Program
> Files\UHD\share\uhd\images\usrp1_fw.ihx... done
> > *** Warning! ***
> > Benchmark results will be inaccurate on USRP1 due to insufficient
> features.
> >
> > Creating the usrp device with: ...
> > -- Opening a USRP1 device...
> > -- Loading FPGA image: C:\Program
> Files\UHD\share\uhd\images\usrp1_fpga.rbf... done
> > -- Using FPGA clock rate of 48.00MHz...
> > Using Device: Single USRP:
> >   Device: USRP1 Device
> >   Mboard 0: USRP1
> >   RX Channel: 0
> > RX DSP: 0
> > RX Dboard: B
> > RX Subdev: TVRX
> >   TX Channel: 0
> > TX DSP: 0
> > TX Dboard: A
> > TX Subdev: WBXv2 TX+GDB
> >
> > Setting device timestamp to 0...
> > Testing receive rate 6.00 Msps on 1 channels
> >
> 

Re: GNURadio Leaking memory during repeated simulations

[Geof Nieboer]

Roman,

I was able to run your code, and got a consistent 150-160 it/s through the
whole run, with about 65MB of memory in use (as reporting by Task
Manager).  This was on Windows 10 running GR 3.8.0.0.

I noticed there was another package installed (tqdm) that's not part of the
GR install.  So I want to confirm... did you add that package to the python
that installed as part of GR, or are you using a different python?

If you are using a different python install, a possible explanation is
compilers; the GR packages and binaries are all built with VS 2015, but the
py2.7 standard is VS 2008 (which won't build GR any more), and mixing (VS)
compilers can cause odd issues.  So for GR, the entire python 2.7 and every
package is built from scratch w/ 2015.  tqdm doesn't seem to be affected, I
added that to the GR python install using a pip install, nothing fancy, and
it seems to have worked.

If you are, however, running the script with the GR-installed python after
opening with run_gr.bat, then I'm scratching my head what's happening.

Geof

On Thu, Feb 13, 2020 at 12:00 PM Roman A Sandler 
wrote:

> Hi Marcus,
>
> Thanks for the reply!
>
> My GNURadio version: *3.8.0.0 (Python 2.7.10)*
> It is the Windows 3.8.0.0 version downloaded from:
> http://www.gcndevelopment.com/gnuradio/downloads.htm
>
> Complete reproducible code is below. I use the tqdm package to monitor
> iterations per second. On my PC, the it/sec declines very precipitously
> (starts at 85it/sec, then down to 22it/s after 40s and keeps dropping.
> Eventually as low as 1 it/sec).
>
>
> ```
>
> import numpy as np
> from gnuradio import gr, gr_unittest
> from gnuradio import blocks
> from gnuradio import digital
> from gnuradio.filter import firdes
> from gnuradio import channels
> from tqdm import tqdm
>
>
> def decode(channel_sigs):
> tb = gr.top_block()
>
> ##
> # Variables
> ##
> nfilts = 32
> sps = 4
> timing_loop_bw = 3 * 6.28 / 100.0  # NOTE: this controls convergence 
> speed!
> constellation_scheme = digital.constellation_8psk().base()
> rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 / float(sps), 
> 0.35, 11 * sps * nfilts)
>
>  Actual blocks
> channel_src = blocks.vector_source_c(channel_sigs, False)
> digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps, timing_loop_bw, 
> rrc_taps, nfilts,
> nfilts / 2, 1.5, 1)
> constellation_soft_decoder = 
> digital.constellation_soft_decoder_cf(constellation_scheme)
> binary_slicer = digital.binary_slicer_fb()
> blocks_char_to_float = blocks.char_to_float(1, 1)
> recovered_bits_dst = blocks.vector_sink_f()
>
> ##
> # Connections
> ##
> tb.connect((channel_src, 0), (digital_pfb_clock_sync, 0))
> tb.connect((digital_pfb_clock_sync, 0), (constellation_soft_decoder, 0))
> tb.connect((constellation_soft_decoder, 0), (binary_slicer, 0))
> tb.connect((binary_slicer, 0), (blocks_char_to_float, 0))
> tb.connect((blocks_char_to_float, 0), (recovered_bits_dst, 0))
>
> tb.run()
> recovered_bits = np.array(recovered_bits_dst.data())
>
> return recovered_bits
>
>
> if __name__ == '__main__':
> n_trls = 1
> n_samples = 
> sig = np.random.normal(size=(n_samples,)) + 1j * 
> np.random.normal(size=(n_samples,))
>
> for n in tqdm(range(n_trls)):
> decode(sig)
>
> ```
>
>
> On Thu, Feb 13, 2020 at 2:11 AM Müller, Marcus (CEL) 
> wrote:
>
>> Hi,
>>
>> huh. That looks hard to debug; also, the slow down is suspicious (as
>> long as there's memory available, it shouldn't take significantly
>> longer to get some – usually, memory fragmentation isn't *that* bad,
>> and this shouldn't be doing *that* much memory allocation).
>>
>> Could you put all your code in one .py file (or a set of these) that
>> one can simply execute right away? That would allow us to reproduce.
>> Also, could you tell us your specific GNU Radio version (all four
>> digits of it?).
>>
>> Best regards,
>> Marcus
>>
>> On Tue, 2020-02-11 at 16:34 -0800, Roman A Sandler wrote:
>> > Hi,
>> >
>> > I am using GNURadio to decode a large amount of 1024-sample complex
>> > vectors of different modulation schemes. Thus, I have a for loop
>> > which runs gr.top_block.run() at each iteration and uses a vector
>> > sink to collect the results. The issue is that as the simulation
>> > keeps going, each itertion takes longer (e.g. starts of at 120it/sec,
>> > and then after 5000 iterations slows down to 10it/sec). I can see in
>> > task manager (I am on windows) that memory is increasing so clearly
>> > there is a memory leak where somehow the results of the iterations
>> > arent being deleted.
>> >
>> > Is there an explicit way to delete runs or is this a bug?
>> >
>> 

Re: GNURadio with Python 3 for Windows

[Geof Nieboer]

Roman,

1.: No, there is not currently a precompiled version w/ Py3

2.: Not relatively easily.  The scripts that create the pre-compiled
version build py2.7 from source, and also pull in the entire
dependency chain, and many have to be custom-compiled.  So a lot of
the build process will have to change.  But it *is* possible, and the
final result will be a simpler build process, but getting there might
be moderately difficult, depending on your CMake / Powershell
experience.

3.: I'm sure there are options here depending on what the role of your
custom code is.  Run the code in two separate processes, and set up
sockets between them would be an example.

So my plan for the installers is, to wait for 3.8 OOT blocks to get a
bit more stable (which is happening nicely now I think), and
re-release a final gr3.8-py2.7 version. Then convert the scripts to
py3 for good.  However, since this is a part-time hobby on my part, I
will not even attempt to put a timeline to it.

Geof

On 1/22/20, Roman A Sandler  wrote:
> Hi,
>
> Currently, the windows precompiled GNUradio installers found here
> feature GNURadio 3.8,
> but only with Python 2.7. My questions are:
>
>1. Is there a currently precompiled Windows version of GNURadio 3.8 w/
>Python 3?
>2. If there is not, is there a relatively easy way that I could compile
>one myself?
>3. If also not, how could I interface my current Python 3 codebase w/
>the GNURadio Python 2 output?
>
> Thanks!
>

Re: Compiling OOT modules on WIndows

[Geof Nieboer]

Dan,

Yes it is possible (though I haven't tried with 3.8), but like Derek said,
it's currently not easy.  After 3.8 is stable, I'd like to work OOT
development as the next task, but that'll probably be a while (6+ months).
I don't see any major roadblocks, it's just going to take some time to make
it cross-platform friendly, most of the issues as I recall are around
permissions and folders, since Windows uses a different approach to program
code/data.

Setting up a Linux VM is pretty straightforward, and is what I'd do in a
Windows lab until them.  They used to be troublesome because of the USB
performance made working with SDR's difficult, but seems to have mostly
gone away as an issue.

Geof

On Fri, Jan 10, 2020 at 7:43 AM Derek Kozel  wrote:

> Hello Dan,
>
> No, I wouldn't say that it is easy yet. A lot of very good work has been
> done in the last year, I see you've found Geof's installers. Analog
> Devices and SDR Play have used it to build their OOT and core
> installers. However it is highly inconvenient as a process if you are
> trying to do development. Using a Linux or MacOS environment is still
> highly preferable.
>
> We are short of people with Windows development experience. If anyone
> reading this does have experience with Windows installers, CMake/NSIS,
> or AppVeyor we very much could use your assistance! Progress is being
> made, but it remains slow.
>
> Regards,
> Derek
>
> On 10/01/2020 00:50, Daniele Nicolodi wrote:
> > Hello,
> >
> > is there an "easy" way to compile OOT modules on Windows?
> >
> > I found a couple of old threads on the mailing list describing with
> > instructions and, unless things got much simpler in recent times, it may
> > be simpler to convince my colleagues that having a Linux machine in the
> > lab is not that scary after all :-)
> >
> > Thank you.
> >
> > Cheers,
> > Dan
> >
>
>
>
>

Re: Windows Installers 3.8.0.0 BETA Available

[Geof Nieboer]

OK thanks for the report.

We need a bit more information.  When you saw the executables "don't run",
can you give us some more detail?  When you run the GNURadio Command Prompt
from the Start Menu, what kind of error does it give?

If all you see are windows opening and closing, then go the "Program
Files/GNURadio-3.8/bin" directory and open a command prompt.  Then type
"run_gr.bat" and let us know what that outputs (it should just open another
window).
Then try "CALL run_gr.bat gnuradio-companion.py" and see what you get (it
should open GRC)

In most cases, the next steps would be to open python and start importing
modules to start narrowing down what's failing, which would be the same as
on linux.  Hopefully you'll be able to get some more detailed error
information in the console windows since they won't try to close on you.

Geof

On Thu, Jan 9, 2020 at 7:37 PM Daniele Nicolodi  wrote:

> Hello Geof,
>
> I tried your binaries of GNURadio 3.8 on Windows 10 and they do not work
> for me. None of the executables run on my system: launching any of them
> nothing happens. I don't have much experience with developing
> applications on Windows, thus I don't know where to look to be able to
> report more useful information.
>
> The GNURadio 3.7 binaries work fine.
>
> Thank you.
>
> Cheers,
> Dan
>
> On 11-11-2019 19:07, Geof Nieboer wrote:
> > All,
> >
> > A BETA version of the windows 64-bit installer for GR3.8 is available
> > here http://www.gcndevelopment.com/gnuradio/index.htm
>
>
>
>

Re: Re: Gnuradio 3.8 on Windows generates negative return codes

[Geof Nieboer]

Marcus,

True, but if one was just debugging the python code, an older version may
be fine.  For serious mixed-mode C++/Python debugging I would head to VS
2019 for the most reliable experience.

Geof

On Sun, Dec 1, 2019 at 3:25 PM Müller, Marcus (CEL)  wrote:

> Correct me, as I'm really not a Visual Studio expert but:
>
> VS2008 predates C++11 support; you shouldn't be able to sensibly use it
> for GNU Radio 3.8's C++11 codebase.
> If I remember correctly, that's why we set the minimum MSVC version to
> 1800 (which corresponds to Visual Studio 2012, I think).
>
> Best regards,
> Marcus
>
> On Sat, 2019-11-30 at 10:57 -0500, Geof Nieboer wrote:
> > >  I have Visual Studio 2008 installed for C++ development. However,
> > I do not understand how this works with python.
> >
> > I'm not sure if VS 2008 supports python debugging, but I know that
> > 2015 does, just have to be sure that the python features are
> > installed.  Then you can create a python-based project, then add the
> > existing .py file to it, and "Step Into" Run like a C++ file.  The
> > only tricky part is setting up the python environment correctly, but
> > the variables you need are all in the run_gr.bat file.
> >
> > A simpler but cruder option is the old "add print 'made to here'
> > lines everywhere" and let us know where it's dying.  Unfortunately I
> > suspect it will be on "tb.start()" which won't provide much of a
> > smoking gun.
> >
> > Geof
> >
> > On Fri, Nov 29, 2019 at 7:00 PM Lukas Haase 
> > wrote:
> > > Hi Geof,
> > >
> > > Thank you very much for your help.
> > >
> > > On 2019-11-29 17:37, Geof Nieboer wrote:
> > > > Lukas,
> > > >
> > > > [...]
> > > >
> > > > So obviously something is failing early in the python script
> > > before it
> > > > really gets the flowgraph going.   That error code is fairly
> > > vague,
> > > > google tells me it's a generic system error.
> > > >
> > > > Please try this, open the GR command prompt, and attempt to run
> > > the
> > > > generated python file manually, and see if it produces any more
> > > useful
> > > > detail.
> > >
> > > Nope, nothing:
> > >
> > > O:\local>python test_qt.py
> > >
> > > O:\local>
> > >
> > > > The next step after that would be to try to run the python
> > > > script in Visual Studio (or your preferred debugger) in debug
> > > mode and
> > > > figure out what line is causing the failure.
> > >
> > > Could you elaborate on this briefly?
> > >
> > > I have Visual Studio 2008 installed for C++ development. However, I
> > > do not understand how this works with python.
> > >
> > > > Another thing to try to would be to run it as admin and see if
> > > anything
> > > > different occurs.  Also try setting to "No Gui" just for kicks.
> > >
> > > As admin: exactly the same output.
> > >
> > > No Gui: exactly the same.
> > >
> > > > The fact that the second flowgraph does show the radio
> > > initializing is a
> > > > good sign, it shows that block is starting up as expected.
> > >
> > > I should have mentioned that this one is from another workstation
> > > (same version/configuration).
> > >
> > > Additionally: Resizing the companion window makes it crash:
> > >
> > > Assertion failed: CAIRO_REFERENCE_COUNT_HAS_REFERENCE (
> > > >ref_count), file cairo-surface.c, line 955
> > >
> > > (for this one I will file a bug report).
> > >
> > >
> > > Thanks,
> > > Luke
> > >
> > >
>

Re: Re: Gnuradio 3.8 on Windows generates negative return codes

[Geof Nieboer]

>  I have Visual Studio 2008 installed for C++ development. However, I do
not understand how this works with python.

I'm not sure if VS 2008 supports python debugging, but I know that 2015
does, just have to be sure that the python features are installed.  Then
you can create a python-based project, then add the existing .py file to
it, and "Step Into" Run like a C++ file.  The only tricky part is setting
up the python environment correctly, but the variables you need are all in
the run_gr.bat file.

A simpler but cruder option is the old "add print 'made to here' lines
everywhere" and let us know where it's dying.  Unfortunately I suspect it
will be on "tb.start()" which won't provide much of a smoking gun.

Geof

On Fri, Nov 29, 2019 at 7:00 PM Lukas Haase  wrote:

> Hi Geof,
>
> Thank you very much for your help.
>
> On 2019-11-29 17:37, Geof Nieboer wrote:
> > Lukas,
> >
> > [...]
> >
> > So obviously something is failing early in the python script before it
> > really gets the flowgraph going.   That error code is fairly vague,
> > google tells me it's a generic system error.
> >
> > Please try this, open the GR command prompt, and attempt to run the
> > generated python file manually, and see if it produces any more useful
> > detail.
>
> Nope, nothing:
>
> O:\local>python test_qt.py
>
> O:\local>
>
> > The next step after that would be to try to run the python
> > script in Visual Studio (or your preferred debugger) in debug mode and
> > figure out what line is causing the failure.
>
> Could you elaborate on this briefly?
>
> I have Visual Studio 2008 installed for C++ development. However, I do not
> understand how this works with python.
>
> > Another thing to try to would be to run it as admin and see if anything
> > different occurs.  Also try setting to "No Gui" just for kicks.
>
> As admin: exactly the same output.
>
> No Gui: exactly the same.
>
> > The fact that the second flowgraph does show the radio initializing is a
> > good sign, it shows that block is starting up as expected.
>
> I should have mentioned that this one is from another workstation (same
> version/configuration).
>
> Additionally: Resizing the companion window makes it crash:
>
> Assertion failed: CAIRO_REFERENCE_COUNT_HAS_REFERENCE
> (>ref_count), file cairo-surface.c, line 955
>
> (for this one I will file a bug report).
>
>
> Thanks,
> Luke
>
>
>

Re: Gnuradio 3.8 on Windows generates negative return codes

[Geof Nieboer]

Lukas,

Interesting.  I ran the same very simple null->null and it did open another
command prompt window and, well, did nothing, which was expected.

I do have the following extra line displaying:

> gr::pagesize: no info; setting pagesize = 4096

and then after I close the window I get the same "Done" but no return code
provided.

So obviously something is failing early in the python script before it
really gets the flowgraph going.   That error code is fairly vague, google
tells me it's a generic system error.

Please try this, open the GR command prompt, and attempt to run the
generated python file manually, and see if it produces any more useful
detail.  The next step after that would be to try to run the python script
in Visual Studio (or your preferred debugger) in debug mode and figure out
what line is causing the failure.

Another thing to try to would be to run it as admin and see if anything
different occurs.  Also try setting to "No Gui" just for kicks.

The fact that the second flowgraph does show the radio initializing is a
good sign, it shows that block is starting up as expected.

Geof

On Fri, Nov 29, 2019 at 3:50 PM Lukas Haase  wrote:

> Hi,
>
> I just installed Gnuradio 3.8.0.0 (Python 2.7.10) from the website.
> The most simple application with gnuradio fails with
>
> >>> Done (return code -1073741795)
>
> and no windows appears. This is how it looks:
>
> https://snipboard.io/o4ZjvA.jpg
>
> When I add a USRP block I run into the same trouble but this time with a
> slighly different negative return value:
>
> Executing: C:\Program Files\GNURadio-3.8\gr-python27\python.exe -u
> X:\Prototype\gnuradio\SaveSignal.py
>
> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_3.14.1.HEAD-0-g0347a6d8
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
> [INFO] [X300] Using LVBITX bitfile C:\Program
> Files\GNURadio-3.8\share\uhd\images\usrp_x310_fpga_HG.lvbitx...
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [GPS] No GPSDO found
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1310 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1307 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
>
> >>> Done (return code -1073740791)
>
>
>
>
> I could not find any useful information about this.
>
>
> I know Windows is not officially supported and it is marked as
> "v3.8.0.0/v1.7 BETA" but I would still be happy if this can be
> resolved/debugged somehow.
>
> Thanks,
> Luke
>
>
>
>
>

Windows Installers 3.8.0.0 BETA Available

[Geof Nieboer]

All,

A BETA version of the windows 64-bit installer for GR3.8 is available here
 (
https://www.gcndevelopment.com/gnuradio/index.htm).  The top link is for
the 3.7 version, beta 3.8 is the second link down from the top.

The good news is that this installer can be used *side by side* with the
GR-3.7 installer.  While there may be minor issues where they overlap, i.e.
shared per-user configuration files and overwritten shortcuts, generally
one should be able to simultaneously install (and run) 3.7 and 3.8
installations on windows.

The bad news; why a beta after GR-3.8 has been in release for a while?
Because many of the OOT blocks that were included in the installer in the
past have either not been ported, or have been ported via fork.  gr-osmosdr
is a critical one.  So this version may include OOT blocks that may be
unstable or partially functional.  I have, however, found a version of
gr-osmosdr that appears to be working so that was a key driver for the
release.

While several OOT blocks have not been included, I *have* added the
following: gr-soapy and SoapySDR and AirSpyHF drivers (both untested due to
lack of hardware).  Also, this version still uses Python 2.7.  As mentioned
in another email thread, once we have a good stable version of GR3.8 w/
py2.7, then I focus on the python3 upgrade.  I'm actually looking forward
to that as everything will be using standard compilers and there should be
an immense simplification of the build process.  I also hope to be able to
add some of the new blocks that have been built recently as well.

Another minor fix is the removal of a environment variable assignment that
was causing nuisance warnings about duplicate blocks on GRC startup.

Enjoy and please send feedback.  I have not yet pushed all the script
changes to the github repo, so do not expect to be able to build 3.8 at
this point straight out of the gate with them.  Also, I'm not releasing
Debug and AVX2 optimized versions while in beta.  I'm not sure if anyone is
actually using these, so if these options are something you'd like to
continue to see, please let me know.  Otherwise I'm thinking about
scrubbing them out when I do the py3 upgrade.

Geof

Re: Gnuradio for windows

[Geof Nieboer]

Sorry didn’t realize the site went down. I will sort it out today.

Geof


On Fri, Nov 1, 2019 at 02:26 alireza nazari  wrote:

> Hi,
>
> It looks like the link for downloading gnuradio for windows in wiki
>  is broken and the
> website is down. Is there anywhere other than Pothos that I can download
> gnuradio binary files for windows? I am having some problems with Pothos
> UHD drivers and I am trying to stay away from it.
>
> Regards,
> Ali
>

Re: [Discuss-gnuradio] Error compiling gr-qtgui/lib

[Geof Nieboer]

Ah I forgot to mention, I had to build a patch for Qwt6, my scripts
retrieve that file and patch qwt6.

The URL for the patched files is:
https://www.gcndevelopment.com/gnuradio/downloads/sources/qwt6_patch.7z

I don't recall off the top of my head what the changes were, and can't
verify from this computer, sorry.  But give them a shot.

Geof



On 10/21/19, Geof Nieboer  wrote:
> The Qwt/Qt linkage is indeed a problem, as when compiling one must be
> very careful to link the right version of Qwt to the right version of
> Qt or else all hell breaks loose.
>
> GR3.7 needs Qwt5 linked to Qt4
> GR3.8 needs Qwt6 linked to Qt5
>
> If you are building 3.7 on windows, I'd recommend just using the
> installers here: http://www.gcndevelopment.com/gnuradio, which will
> bring down all your dependencies in a self-contained fashion.  For 3.8
> the build scripts will do it, but I haven't released an installer as
> I've been waiting for gr-osmosdr and couple OOTs to be converted.
>
> Geof
>
> On 10/21/19, Michael Dickens  wrote:
>> Hi Gisle - Which version of GR are you trying to build? GR37
>> uses qwt52+qt4, while GR38 uses qwt6+qt5 ... I'm guessing Qwt 6.1.4
>> should
>> work, though I don't think I've tried it out yet. - MLD
>>
>> On Mon, Oct 21, 2019 at 9:40 AM Gisle Vanem 
>> wrote:
>>
>>> Hello list.
>>>
>>> I have some errors while compiling 'gr-qtgui' using MSVC
>>> and/or clang-cl. From clang-cl:
>>>TimeRasterDisplayPlot.cc(199,30):  error: allocating an object of
>>> abstract class type 'TimeRasterData'
>>>d_data.push_back(new TimeRasterData(d_rows, d_cols));
>>>   ^
>>>f:/Qt/Qwt/src\qwt_raster_data.h(100,25):  note: unimplemented pure
>>> virtual method 'interval' in 'TimeRasterData'
>>>virtual QwtInterval interval( Qt::Axis ) const = 0;
>>>  ^
>>>TimeRasterDisplayPlot.cc(374,20):  error: no member named
>>> 'setInterval'
>>> in 'TimeRasterData'
>>>d_data[i]->setInterval(Qt::ZAxis, QwtInterval(minIntensity,
>>> maxIntensity));
>>>  ~  ^
>>>
>>> The error on 'setInterval' is in other files too.
>>>
>>> I suspect I'm using the wrong Qwt library.
>>> This is the one I'm using:
>>> svn://svn.code.sf.net/p/qwt/code/trunk/qwt
>>>
>>> ver. 6.1.4 Or are we supposed to use another (older) one?
>>>
>>> --
>>> --gv
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> --
>> Michael Dickens
>> Ettus Research Technical Support
>> Email: supp...@ettus.com
>> Web: https://ettus.com/
>>
>


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

Re: [Discuss-gnuradio] Error compiling gr-qtgui/lib

[Geof Nieboer]

The Qwt/Qt linkage is indeed a problem, as when compiling one must be
very careful to link the right version of Qwt to the right version of
Qt or else all hell breaks loose.

GR3.7 needs Qwt5 linked to Qt4
GR3.8 needs Qwt6 linked to Qt5

If you are building 3.7 on windows, I'd recommend just using the
installers here: http://www.gcndevelopment.com/gnuradio, which will
bring down all your dependencies in a self-contained fashion.  For 3.8
the build scripts will do it, but I haven't released an installer as
I've been waiting for gr-osmosdr and couple OOTs to be converted.

Geof

On 10/21/19, Michael Dickens  wrote:
> Hi Gisle - Which version of GR are you trying to build? GR37
> uses qwt52+qt4, while GR38 uses qwt6+qt5 ... I'm guessing Qwt 6.1.4 should
> work, though I don't think I've tried it out yet. - MLD
>
> On Mon, Oct 21, 2019 at 9:40 AM Gisle Vanem  wrote:
>
>> Hello list.
>>
>> I have some errors while compiling 'gr-qtgui' using MSVC
>> and/or clang-cl. From clang-cl:
>>TimeRasterDisplayPlot.cc(199,30):  error: allocating an object of
>> abstract class type 'TimeRasterData'
>>d_data.push_back(new TimeRasterData(d_rows, d_cols));
>>   ^
>>f:/Qt/Qwt/src\qwt_raster_data.h(100,25):  note: unimplemented pure
>> virtual method 'interval' in 'TimeRasterData'
>>virtual QwtInterval interval( Qt::Axis ) const = 0;
>>  ^
>>TimeRasterDisplayPlot.cc(374,20):  error: no member named
>> 'setInterval'
>> in 'TimeRasterData'
>>d_data[i]->setInterval(Qt::ZAxis, QwtInterval(minIntensity,
>> maxIntensity));
>>  ~  ^
>>
>> The error on 'setInterval' is in other files too.
>>
>> I suspect I'm using the wrong Qwt library.
>> This is the one I'm using:
>> svn://svn.code.sf.net/p/qwt/code/trunk/qwt
>>
>> ver. 6.1.4 Or are we supposed to use another (older) one?
>>
>> --
>> --gv
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>


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

Re: [Discuss-gnuradio] best way to do a total removal GNU Radio installation on windows 10?

[Geof Nieboer]

Beau,

Just use the regular windows tools to uninstall a program in control
panel as you've previously accomplished.

The error you are receiving is NOT because you had 3.7.13.4 before,
it's a new bug introducing in .13.5 (caused by a fix for a different
problem).  Again, they are just warnings though and have no effect on
the usability of the system... it's scanning the same folder twice for
blocks and finding the exact same one again.

Geof

On 10/17/19, Beau Thompson  wrote:
> Hi All
>
> I had  GNU Radio Companion 3.7.13.4 installed I went to add/remove
> programs  and uninstalled it
>
> then installed GNU Radio Companion 3.7.13.5 I get a lot of warnings on
> start up
>
> Warning: Block with key "acars2_decode" already exists.
>      Ignoring: D:\Program
> Files\GNURadio-3.7\share\gnuradio\grc\blocks\acars2_decode.xml
>
> my question how do I do a total removal of a GNU Radio installation  ?
>
> thanks Beau n9mfk
>
>


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

Re: [Discuss-gnuradio] RTL-SDR source not working in 3.7.14.5

[Geof Nieboer]

Beau,

OK, let's see..

First let's look at this...

gr-osmosdr 4d83c606 (0.1.5git) gnuradio 3.7.13.5
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
airspy redpitaya
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_106000;
UHD_3.14.1.HEAD-0-g5491b80e
---
This seems to indicate that the gr-osmosdr is looking for a UHD
device, not your RTL-SDR.  This can be set in the "Device Arguments"
section.  I can't recall the exact parameter to put in, but look in
the documentation for the block and I think there is an example.  That
could be the whole issue possibly, because UHD and gr-osmocom don't
play well together.

Let me know if that works.  I won't be able to test your files myself
until later on.

Geof

On 10/16/19, Beau Thompson  wrote:
> Hi Geof,
>
> I see these in a black window on start up
>
> i get
>
>
 SNIP -
> Warning: Block with key "xmlrpc_server" already exists.
>  Ignoring: D:\Program
> Files\GNURadio-3.7\share\gnuradio\grc\blocks\xmlrpc_server.xml
> <<< Welcome to GNU Radio Companion 3.7.13.5 >>>
> and it will not run two file i ha that use rtl
>
> yes the rtl works fine with other windows software
>
> the code never runs like it not loading when i click run no other
> windows open
>
> here a link to my files
> https://www.dropbox.com/s/hl4gt6atqioqfzy/FM_RX_1a.zip?dl=0
>
>  From main
> Generating:
> 'D:\\n9mfk\\Documents\\gnu\\GNURadio-FM-Receiver-FM_RX_1a\\fm_receiver.py'
>
> Generating:
> 'D:\\n9mfk\\Documents\\gnu\\GNURadio-FM-Receiver-FM_RX_1a\\fm_receiver.py'
>
> Executing: D:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
> D:\n9mfk\Documents\gnu\GNURadio-FM-Receiver-FM_RX_1a\fm_receiver.py
>
> gr-osmosdr 4d83c606 (0.1.5git) gnuradio 3.7.13.5
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
> airspy redpitaya
> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_3.14.1.HEAD-0-g5491b80e
>
>  >>> Done
>
>  From dos window
>
> Generating:
> 'D:\\n9mfk\\Documents\\gnu\\GNURadio-FM-Receiver-FM_RX_1a\\fm_receiver.py'
>
> Generating:
> 'D:\\n9mfk\\Documents\\gnu\\GNURadio-FM-Receiver-FM_RX_1a\\fm_receiver.py'
>
> Executing: D:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
> D:\n9mfk\Documents\gnu\GNURadio-FM-Receiver-FM_RX_1a\fm_receiver.py
>
> gr-osmosdr 4d83c606 (0.1.5git) gnuradio 3.7.13.5
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
> airspy redpitaya
> [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_3.14.1.HEAD-0-g5491b80e
>
>  >>> Done
> Traceback (most recent call last):
>File "D:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\ActionHandler.py",
> line 409, in _handle_action
>  file_path = SaveConsoleFileDialog(page.get_file_path(), main).run()
>File "D:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\FileDialogs.py",
> line 128, in __init__
>  FileDialogHelper.__init__(self, gtk.FILE_CHOOSER_ACTION_SAVE, 'Save
> Console to a File...', parent)
>File "D:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\gui\FileDialogs.py",
> line 102, in __init__
>  gtk.FileChooserDialog.__init__(self, title, parent, action,
> ('gtk-cancel', gtk.RESPONSE_CANCEL, ok_stock, gtk.RESPONSE_OK))
> TypeError: parent must be a GtkWindow or None
> D:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\main.py:54:
> GtkWarning: Input method multipress should not use GTK's translation
> domain gtk20
>gtk.main()
> D:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\grc\main.py:54:
> GtkWarning: Input method multipress should not use GTK's translation
> domain gtk20
>gtk.main()
>
> On 10/15/2019 19:17, Geof Nieboer wrote:
>> OK, can you be more specific about how it doesn't run?  What error is
>> it giving you?
>>
>> Have you used any other RTL-SDR software successfully in windows?
>>
>> Did you use the zadig utility to install the correct driver for the
>> RTL-SDR?  If the answer to this one and one above is no, then this is
>> 90% your issue.
>>
>> Geof
>>
>> On Tue, Oct 15, 2019 at 6:56 PM Beau Thompson > <mailto:n9m...@gmail.com>> wrote:
>>
>> that is how i installed it
>>
>>
>> On 10/15/2019 17:17, Geof Nieboer wrote:
>>> There are installers for windows:
>>>
>>> http://www.gcndevelopment.com/gnuradio
>>>
>>> That will come with RTL-SDR drivers, etc.  Just run the
>>> "run_grc.bat" from the /bin directory (or use the instal

Re: [Discuss-gnuradio] RTL-SDR source not working in 3.7.14.5

[Geof Nieboer]

There are installers for windows:

http://www.gcndevelopment.com/gnuradio

That will come with RTL-SDR drivers, etc.  Just run the "run_grc.bat" from
the /bin directory (or use the installed shortcuts)

Geof

On Sat, Oct 12, 2019 at 8:42 AM Chris Gorman 
wrote:

> Hmm,
>
> Not too sure what is wrong.  First off are you sure you have version
> 3.7.14.5?  I have 3.7.13.5 and can't find your newer version in the
> releases (https://www.gnuradio.org/releases/gnuradio/).  Assuming you
> have just made a small typo, I have built gr-osmosdr successfully with
> 3.7.13.5.  Here are the build instructions from the README
>
> git clone git://git.osmocom.org/gr-osmosdr
> cd gr-osmosdr/
> mkdir build
> cd build/
> cmake ../
> make
> sudo make install
> sudo ldconfig
>
> It has been a while since I built this, so I don't recall the
> dependencies you need to install, but you will at least need the dev
> files for your rtl-sdr source.  I recommend trying to install the
> rtl-sdr libraries and headers as described in
> https://osmocom.org/projects/rtl-sdr/wiki .  (Note this needs to be
> done before you install gr-osmosdr.)
>
> As to installing under windows, I don't know how to help with that.  Sorry.
>
> Let me know what you get after trying to build rtl-sdr and gr-osmosdr.
>
> Chris
>
> On Sat, Oct 12, 2019 at 8:07 AM Beau Thompson  wrote:
> >
> > Hi If i try an run any code with RTL-SDR source it will not run
> >
> > how can i fix this or is there a way i can have to installs under windows
> >
> > thanks beau
> >
> >
> > ___
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio 3.8 for Windows

[Geof Nieboer]

Pol,

That's great work!  I am the maintainer of the Win10 binaries you
mentioned, and while the scripts are currently capable of building 3.8
in Win10, I have delayed a binary release to allow a bit more time for
some more of the "add-on" packages to become compatible with 3.8 and
GRC specifically.  I suppose this should encourage me to "get on with
it" :)

Geof

On 10/2/19, Pol Henarejos  wrote:
> Dear all,
>
> I have been using GNU Radio since 3.2 series and the progress made in
> last years is amazing. I used to develop GNU Radio apps in linux but,
> sometimes, I also did it in Windows (specially for quick tests).
> However, I could not find the binaries of the 3.8 series and the
> documentation for Windows build is for prior releases.
>
> Finally, I managed to build it natively in Windows 10 (it should work in
> Windows 7 too).
>
> If someone is interested, the binaries for Windows can be downloaded
> from https://www.castle.cloud/gnuradio-for-windows
>
> This is the list of available modules:
>
> + python-support
> + testing-support
> + gnuradio-runtime
> + gr-ctrlport
> + gnuradio-companion
> + gr-blocks
> + gr-fec
> + gr-fft
> + gr-filter
> + gr-analog
> + gr-digital
> + gr-dtv
> + gr-audio (windows)
> + gr-channels
> + gr-qtgui
> + gr-trellis
> + gr-uhd
> + gr-utils
> + gr_modtool
> + gr-vocoder
> + gr-zeromq
>
> I cannot build gr-wavelet and gr-video-sdl due to some fails with SDL
> and GSL libraries.
>
> Please, note that the license belongs to the GNU Radio. I only
> repackaged the official release, without any modification.
>
> Any feedback is also appreciated.
>
> Thank you for your incredible efforts!
>
> Regards.
>
> --
>
> Dr. Pol Henarejos
> Researcher
> Array and Multi-Sensor Processing Department, Communication Systems
> Division
> pol.henare...@cttc.cat
>
> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels, Barcelona (Spain)
> Tel: +34 93 645 29 00  Ext: 2177
> www.cttc.cat
>
> Your identification data and the data contained in the emails and
> attached files can be incorporated into our databases, in order to
> maintain professional and / or commercial relationships, and that it
> will be preserved throughout the relationship. You can exercise your
> right to access, rectification, erasure, restriction of processing, to
> portability and to object by sending an email to d...@cttc.cat.
> This message and any attached document, where appropriate, may be
> confidential and intended for the original recipient only.
>
>


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

Re: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR

[Geof Nieboer]

t;fix" was applied.
>
> >>> 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:\Python27\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
>
> 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
>
> So evidently even though the dll is gone from System32 the issue still
> persists.
>
> Thoughts? Again I appreciate your help.
>
> Patrick
>
> -Original Message-
> From: Geof Nieboer 
> Sent: Tuesday, June 25, 2019 9:06 AM
> To: W3AXL Patrick 
> Cc: discuss-gnuradio@gnu.org
> Subject: 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.
>
> >
>
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR

[Geof Nieboer]

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  <mailto:patr...@w3axl.com> > 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 <mailto: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 

Re: [Discuss-gnuradio] GNURadio Windows Errors with OsmoSDR

[Geof Nieboer]

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] [EXT] Re: Python3 or still Python 2.7?

[Geof Nieboer]

All,

Once 3.8 is ready, I'll first release a version that is built on 2.7,
primarily because that's what the scripts are built around at the
moment, and to split the upgrade into two steps.  That version should
support those who are looking for max compatibility.

Then I'll shift the scripts to point to 3.5.  In theory, that should
actually be significantly easier, because 3.5 (and therefore the
standard packages) are built w/ MSVC 14.0, the same versions the
scripts use for everything already.

Having said that, I'm open to feedback based on the community's needs.

Geof



On 6/17/19, Chesir, Aaron M.  wrote:
> Philip, Geof (et al.),
>
> When will a Windows version of GR that supports Python 3 (and complete with
> one-click installers, much like that  advertised for Release 3.7.13.5,
> below) be available?
>
> The reason I prefer to operate within Windows (as opposed to the various
> versions of Linux) is that I can thus avoid the seemingly-endless
> irritations of dependency / incompatibility issues.
>
> Thanks in advance,
>
> Aaron
>
> -Original Message-
> From: Philip Balister 
> Sent: Monday, June 17, 2019 12:19 PM
> To: Chesir, Aaron M. ; Geof Nieboer
> ; Discuss-gnuradio@gnu.org
> Subject: [EXT] Re: [Discuss-gnuradio] Python3 or still Python 2.7?
>
> On 06/17/2019 10:49 AM, Chesir, Aaron M. wrote:
>> Will GNUradio migrate to Python3.X, or will it remain with Python 2.7?
>>
>> The reason I ask is that (for reasons that unclear), there are syntax
>> differences between the two, and Python 3 is *not* backward compatible for
>> some of them.
>
> The GNURadio master branch (which will become 3.8) supports Python3.
>
> Philip
>
>>
>> Aaron
>>
>> -Original Message-
>> From: Discuss-gnuradio
>>  On Behalf Of Geof
>> Nieboer
>> Sent: Saturday, June 15, 2019 5:25 PM
>> To: Discuss-gnuradio@gnu.org
>> Subject: [EXT] [Discuss-gnuradio] Windows Installers v1.6 for v3.7.13.5
>> published
>>
>> All,
>>
>> Updated windows installers that include 3.7.13.5 have now been published.
>>
>> They can be found as always at http://www.gcndevelopment.com/gnuradio.
>>
>> Key windows specific fixes in the installers include:
>> 1- Windows Audio Sink now doesn't distort for certain audio streams
>> 2- ZeroMQ is working again
>> 3- GR_PREFIX is now defined in the run_gr.bat so that sys-wide
>> configuration files will be used correctly.
>>
>> Numerous dependencies have been updated:
>> GNURadio -> 3.7.13.5
>> Qt > 5.12.3
>> numpy -> 1.64.4
>> libxml2 -> 2.9.9
>> libpng -> 1.6.37
>> UHD -> 3.14.1*
>> zmq -> 4.3.1
>> libusb -> 1.0.22
>> openssl -> 1.0.1r
>> qwt6 -> 6.1.4
>> log4cpp -> 1.1.3
>> pycairo -> 1.17.1
>> sip -> 4.18
>>
>> * RC1... a new version will be pushed if RC1 requires changes prior to
>> formal release
>>
>> While no new OOT modules have been added, here's the list of what is
>> included:
>>
>> gr-acars2
>> gr-adsb
>> gr-ais
>> gr-air-modes
>> gr-ax25
>> gr-burst (incl. bitarray)
>> gr-cdma
>> gr-display (incl. matplotlib)
>> gr-eventstream
>> gr-fosphor
>> gr-gsm
>> gr-inspector (incl. tensorflow)
>> gr-iqbal
>> gr-lte
>> gr-mapper
>> gr-nacl
>> gr-osmosdr
>> gr-paint (incl. PIL)
>> gr-radar
>> gr-rds
>> gqrx
>>
>> and driver support for: UHD / RTL2382 / HackRF / BladeRF / AirSpy /
>> Funcube Dongle
>>
>> Known Issues:
>>
>> - (new) Windows Audio Source only supports single channel input.
>> Use portaudio for stereo source use cases.
>> - gr-air-modes gui does not work, but the command line interface will
>> - Switching between debug and release versions will cause
>> intermittent heap corruption issues.  Re-run application.
>> - TCP Sink/Server are deprecated and do not function in the
>> windows version, use zeromq blocks
>> - File Sink/Server blocks do not function in the windows version.
>> - gr-newmod still does not work without a great deal of workarounds
>> - agc3 block will run, but will respond more slowly than on
>> linux... still under investigation.
>>
>> A complete stack of symbols is available for the release and debug builds,
>> to allow tracing all the way down to python itself.
>>
>> For those intrepid enough to want to build all of this yourself, the
>> scripts are now compatible with building 3.8 or 3.7 by changing the
>> version in ConfigInfo.psd1 to 3.8.0, then it

[Discuss-gnuradio] Windows Installers v1.6 for v3.7.13.5 published

[Geof Nieboer]

All,

Updated windows installers that include 3.7.13.5 have now been published.

They can be found as always at http://www.gcndevelopment.com/gnuradio.

Key windows specific fixes in the installers include:
1- Windows Audio Sink now doesn't distort for certain audio streams
2- ZeroMQ is working again
3- GR_PREFIX is now defined in the run_gr.bat so that sys-wide
configuration files will be used correctly.

Numerous dependencies have been updated:
GNURadio -> 3.7.13.5
Qt > 5.12.3
numpy -> 1.64.4
libxml2 -> 2.9.9
libpng -> 1.6.37
UHD -> 3.14.1*
zmq -> 4.3.1
libusb -> 1.0.22
openssl -> 1.0.1r
qwt6 -> 6.1.4
log4cpp -> 1.1.3
pycairo -> 1.17.1
sip -> 4.18

* RC1... a new version will be pushed if RC1 requires changes prior to
formal release

While no new OOT modules have been added, here's the list of what is included:

gr-acars2
gr-adsb
gr-ais
gr-air-modes
gr-ax25
gr-burst (incl. bitarray)
gr-cdma
gr-display (incl. matplotlib)
gr-eventstream
gr-fosphor
gr-gsm
gr-inspector (incl. tensorflow)
gr-iqbal
gr-lte
gr-mapper
gr-nacl
gr-osmosdr
gr-paint (incl. PIL)
gr-radar
gr-rds
gqrx

and driver support for: UHD / RTL2382 / HackRF / BladeRF / AirSpy /
Funcube Dongle

Known Issues:

- (new) Windows Audio Source only supports single channel input.
Use portaudio for stereo source use cases.
- gr-air-modes gui does not work, but the command line interface will
- Switching between debug and release versions will cause
intermittent heap corruption issues.  Re-run application.
- TCP Sink/Server are deprecated and do not function in the
windows version, use zeromq blocks
- File Sink/Server blocks do not function in the windows version.
- gr-newmod still does not work without a great deal of workarounds
- agc3 block will run, but will respond more slowly than on
linux... still under investigation.

A complete stack of symbols is available for the release and debug
builds, to allow tracing all the way down to python itself.

For those intrepid enough to want to build all of this yourself, the
scripts are now compatible with building 3.8 or 3.7 by changing the
version in ConfigInfo.psd1 to 3.8.0, then it should build the correct
dependencies to support it.  Drivers are built but OOT blocks are not
yet built for 3.8.  While most of the work in this release was to
enable a functioning build for 3.8, I am not planning to release an
installer for 3.8 at this point, but email me if you have a need for a
pre-alpha build.

When a 3.8 build is released, they will be installable simultaneously
without issue.

And finally, to make things a bit easier for the intrepid, I have
published an AWS AMI image set to a validated build configuration to
make it a bit easier for others to run the build scripts.  Details on
the github site:
http://github.com/gnieboer/GNURadio_Windows_Build_Scripts

Cheers,

Geof


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

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[Geof Nieboer]

I apologize for missing this email chain.

FYI, anytime you see a "Z:\gr-build" somewhere in a Windows install, know
that that is the path I use when buildiing the installers, so exactly as
was already deduced, that is a path that ended up being hardcoded
someplace.  It's particular of the cultural difference between Linux/Win,
as Linux tends to assume that code is running on the machine that built it.

The best approach to modification of environment variables specific to GR
usage on Windows is to modify the "run_gr.bat" in C:\Program
Files\Gnuradio-3.7\bin, which sets up a complete set of variable to support
the custom python install etc., and will also then allow side-by-side of
multiple installs (when we release a 3.8 version).

So I will create an issue on the scripts github to set this environment
variable automatically in run_gr.bat in the next version (I'll also include
the stereo source fix as well).

Geof



On Sat, May 11, 2019 at 5:48 AM Marcus Müller 
wrote:

> Hi Gary,
>
> I'm sorry for the long silence, but just to let you know:
> a) if you think you can get me fed up with you, you'll have to do
> better than to patiently report bugs, take suggestions, give feedback.
> That's absolutely no way to annoy me!
> b) Your work has led me to writing a small patch that we'll hopefully
> be able to roll out soon, see
> https://github.com/gnuradio/gnuradio/pull/2475
>
> Best regards,
> Marcus
>
> On Mon, 2019-05-06 at 12:16 +0100, Gary.Simpkins wrote:
> > Hi Marcus.
> >
> > It was late last night and I missed the errors in the
> > grnradio-config-info -- prefsdir response.
> >
> > It had the dirs twice. So I changed the Prefix in windows to be just
> > GNUradio-3.7, and the tried again.
> >
> > The prefs now has details includng portaudio.
> >
> > When I start gnuradio companion  I now see lots of warnings about
> > files
> > already existing.
> >
> > When try to generate with the audio source I get a lot of audio
> > config
> > lines. all to do with portaudio
> >
> > BUT  --IT Looks like portaudio is working for me on windows.
> >
> > Certainly I get two outputs. If they are the I and Q Ioutputs t is
> > my
> > next test, but looking very good.
> >
> > Many Many thanks.
> >
> > Regards
> >
> > Gary
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On 05/05/2019 17:43, Marcus Müller wrote:
> > > Hi Gary,
> > >
> > > > This confuses simple folk like me.
> > > this confuses simple folks such as me, too!
> > >
> > > That --prefsdir output is most defintely bogus. I can speculate
> > > what
> > > happened there, however:
> > >
> > > > Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
> > > That --prefsdir value is part of the source code that gets compiled
> > > into the tool/the GNU Radio libraries. Normally, you wouldn't do
> > > that,
> > > "hardwiring" a directory path into a library, but write it in a
> > > configuration file or something.
> > >
> > > However, in this case, that's the place we start looking into to
> > > find
> > > the configuration files. So, that's the one thing that actually
> > > need to
> > > hardwire.
> > >
> > > So, there's a text string "Z:\gr-build\src-
> > > stage3\staged_install\Release\etc\gnuradio\conf.d" in there, which
> > > is
> > > probably a remnant of the machine that your GNU Radio got built on
> > > (again, how did you install that?).
> > > Sadly, the "\" gets interpreted by the compiler to be "escape
> > > symbol",
> > > so that you can have things like "\n" for newline in strings.
> > > Luckily,
> > > none of the first letters of directory names combined with "\" give
> > > a
> > > valid escape sequence, so the compiler just silently drops the "\"
> > > and
> > > this is the string you end up with.
> > >
> > > I'll admit it: that's funky, and I didn't know that happened. We'll
> > > most definitely will have to rewrite something to make this work
> > > under
> > > windows (which uses backslashes for directory separation, unlike
> > > unixoids, which use forward slashes).
> > >
> > > So, why does --userprefsdir work, but --prefsdir not?
> > >
> > > Well, --userprefsdir is built from environment variables at
> > > runtime, so
> > > it's correct, not mangled by a compiler.
> > >
> > > I hear you say, that's fine and all, and now?
> > >
> > > Welll! I thought it strange that, although your userprefsdir
> > > seems
> > > correct, GNU Radio didn't read the configuration file you modified.
> > > So,
> > > down the rabbit hole it goes. Here's our culprit, in prefs.cc:
> > >
> > >std::vector
> > >prefs::_sys_prefs_filenames()
> > >{
> > >  std::vector fnames;
> > >
> > >  fs::path dir = prefsdir();
> > >  if(!fs::is_directory(dir))
> > >return fnames; // > >
> > >   […]
> > >
> > >  // Find if there is a ~/.gnuradio/config.conf file and add
> > > this to
> > >  // the end of the file list to override any preferences in the
> > >  // installed path 

Re: [Discuss-gnuradio] gr_zeromq on MS-Windows ?

[Geof Nieboer]

I'm not at the machine at the moment, but as I recall pyzmq ends up looking
for one version and gnuradio the other, so maybe I have the name error
backwards.

Either way, I will fix it in the next release, as worst case I just
downgrade to the version of ZMQ that was bundled with 3.7.12.

Geof

On Thu, Apr 18, 2019 at 1:58 PM jmfriedt 
wrote:

> Thank you for your reply which helped me find a (temporary at least)
> solution to my problem: indeed you reminded me that we had been
> streaming data from GNU Radio to a MS-Windows computer running ZeroMQ
> on its GNU Radio flowgraph and that was working well last
> december/january. So downgrading to 3.7.12 solved my short term problem
> of getting GNU Radio+ZMQ running on MS-Windows. Unfortunately I am
> not able to identify the name mismatch you state in your email: I did
> find some name mismatch with vc140 sentences for the boost library but
> not for ZeroMQ.
>
> Thanks for the support,
> Jean-Michel
>
> > There is a problem with the latest installer related to the changes
> > in the way libzmq's build process works.
> > So the libraries are misnamed.
> > Rename the zmq library to libzmq.dll (it'll be something like
> > libzmq_v140_mt_something.dll currently) and see if that resolves the
> > issue.
> >
> > Geof
> >
> > On Wed, Apr 17, 2019 at 12:30 PM Andrej Rode  wrote:
> >
> > > Hi Jean-Michael,
> > >
> > > On Wed, 17 Apr 2019 15:34:21 +
> > > "jean-michel.fri...@femto-st.fr" 
> > > wrote:
> > > > Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\zeromq_swig.py",
> > > > line 18, in swig_import_helper return
> > > > importlib.import_module('_zeromq_swig') File "C:\Program
> > > > Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", line
> > > > 41, in import_module __import__(name)
> > > > ImportError: DLL load failed: Le module spÚcifiÚ est introuvable.
> > > > ^^^ French for "The specified module cannot be found"
> > >
> > > This usually indicates that `_zeromq_swig.(so|dll)` was found, but
> > > contains unresolvable dynamic linking. Maybe libzmq is missing in
> > > the library_path/dll_path.
> > >
> > > On a Linux host I'd go here: "C:\Program
> > > Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\" and look at
> > > the `_zeromq_swig.so` with `ldd`. I don't know what the tool of
> > > choice on a Windows platform is for looking up the dynamic linking
> > > of a library, but certainly that information will help you locate
> > > the missing pieces.
> > >
> > > Cheers
> > > Andrej
> > >
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
>
>
>
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
>
> ___
> 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] gr_zeromq on MS-Windows ?

[Geof Nieboer]

There is a problem with the latest installer related to the changes in the
way libzmq's build process works.
So the libraries are misnamed.
Rename the zmq library to libzmq.dll (it'll be something like
libzmq_v140_mt_something.dll currently) and see if that resolves the issue.

Geof

On Wed, Apr 17, 2019 at 12:30 PM Andrej Rode  wrote:

> Hi Jean-Michael,
>
> On Wed, 17 Apr 2019 15:34:21 +
> "jean-michel.fri...@femto-st.fr"  wrote:
>
> > Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\zeromq_swig.py",
> > line 18, in swig_import_helper return
> > importlib.import_module('_zeromq_swig') File "C:\Program
> > Files\GNURadio-3.7\gr-python27\lib\importlib\__init__.py", line 41,
> > in import_module __import__(name)
> > ImportError: DLL load failed: Le module spÚcifiÚ est introuvable.
> > ^^^ French for "The specified module cannot be found"
>
> This usually indicates that `_zeromq_swig.(so|dll)` was found, but
> contains unresolvable dynamic linking. Maybe libzmq is missing in the
> library_path/dll_path.
>
> On a Linux host I'd go here: "C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\zeromq\" and look at the
> `_zeromq_swig.so` with `ldd`. I don't know what the tool of choice on a
> Windows platform is for looking up the dynamic linking of a library,
> but certainly that information will help you locate the missing pieces.
>
> Cheers
> Andrej
>
>
> ___
> 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] Windows OOT Module Attribute Error module object has no attribute

[Geof Nieboer]

Horky,

Installation on windows is now very simple, there have been .msi installers
available for a while.  I recommend you give them a try.  There are some
features which do not work, but the vast majority work fine.

Unfortunately, custom OOT modules is one of the problematic areas.  And as
I believe 3.8 completely changes how OOT modules are built and registered,
I think I'll focus work more on that aspect.

Mehmet, When you say you put the files in the relevant directories, can you
be more specific?  Just to be sure.

Geof

On Wed, Apr 10, 2019 at 9:24 AM Horký Petr  wrote:

> Dear Mehmet,
>
> according to my experience. I made a video guide, How to install gnuradio
> on windows. This took me 4 days of installing, since the guides on the
> internet are outdated.
> After that I tried Linux and installation took 10 minutes. The GNU is just
> not suited for Windows. I would recommend you using Linux. This saved me a
> lot of time.
>
>
> Regards,
>
> Petr
> --
> *Od:* Discuss-gnuradio  unob...@gnu.org> za uživatele Mehmet Ozcelebi 
> *Odesláno:* pátek 5. dubna 2019 13:20:08
> *Komu:* GNURadio Discussion List
> *Předmět:* [Discuss-gnuradio] Windows OOT Module Attribute Error module
> object has no attribute
>
> I know this question was asked a lot but this case is for a Windows OOT.
> I tried to build a OOT, tried in Linux and got the error: module object
> has no attribute.
> I fixed this by running sudo ldconfig.
> I tried the same with windows, The dll's xml and py files were generated
> nicely and I placed them into the relevant directories.
> I got the same error but this time I don't know how to fix it in windows.
> It's an annoying error.
> What are the ways to debug this error in windows?
>
> ___
> 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] B205 mini on Windows 10? USB Driver not found

[Geof Nieboer]

UHD drivers are installed with the GnuRadio windows installer.  However,
the system may not have located them automatically and so it's installed a
different driver instead that it thinks is compatible.

There are couple UHD utilities in the installation as well... I think they
are under Gnuradio-3.7/share/UHD perhaps?  (Not near my PC).  I would start
with those and confirm if the issue is with the UHD drivers themselves, or
the GnuRadio side.

In there are a couple UHD driver files, and you can go to Control Panel,
Update Driver, and Manual Choose, then navigate to that directory and pick
the *.inf file that is closest.   I suspect this is the issue.

Once it's correct the UHD probe utility should find the device, and it
should show up in Device manager as an "Ettus USRP B205mini" or similar.

Then hopefully GRC will pick that up and work as well.

Geof


On Tue, Feb 5, 2019 at 11:18 AM Tom McDermott  wrote:

> I have installed the latest Windows version of Gnuradio from the MSI
> installer on the gnuradio website.
> It has UHD source and sink blocks. Gnuradio Companion seems to work fine
> except for UHD device detection.
>
> Have plugged a B205mini into USB3 connector on the computer. The B205
> lights up and
> Device Manager indicates that   Westbridge   is present.  The first time
> plugging it in, Windows
> went through the new device detected process and claimed it installed the
> driver.
>
> However Windows device manager indicates that there is no driver for
> Westbridge, thus when I try to
> run the flowgraph from GRC (with "" for device specifier in the UHD source
> block which the documentation
> indicates will search for first found device if the default empty string
> is used).
> Flowgraph indicates that no UHD device is found.
>
> Trying to do a Windows Device manager driver update for Westbridge says
> that there is no
> driver to be found, even when searching.
>
> Any suggestions as to where to find the Windows 10 USB drivers for
> B205mini?
>
> -- Tom, N5EG
>
>
> ___
> 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] First attempt at GRC crash and burn

[Geof Nieboer]

The GNURadio windows package comes with the HackRF drivers pre-installed,
as well as the helper functions like hackrf_info.exe .  So I'd run Cinead's
recommendations from the "GNURadio Command Prompt" so your paths are
correct.



On Sat, Jan 26, 2019 at 5:33 PM Cinaed Simson 
wrote:

> Try from a command line window
>
>   hackrf_info
>
> This will give the serial number - but if you only have one HackRF
> device you don't need it - leave the device blank.
>
> But for future reference, the serial number should look like this
>
>   14d463dc2f2136e1
>
> The number you want to use is
>
>   2f2136e1
>
> or the last 8 characters.
>
> I'm presuming the drivers for the HackRF have been installed.
>
> It's possible since it's Windows that there's a USB problem.
>
> I don't know anything about Windows - but if you can't access the device
> then Google should be able to help you.
>
> -- Cinaed
>
>
> On 1/26/19 2:00 PM, cliff palmer wrote:
> > My first attempt at using GNU Radio Companion produced this error log:
> > -- begin error log --
> > <<< Welcome to GNU Radio Companion 3.7.13.4 >>>
> >
> > Block paths:
> > G:\GNURadio-3.7\share\gnuradio\grc\blocks
> >
> > Loading: "C:\Users\Cliff\Documents\lesson1.grc"
>  Done
> >
> > Generating: 'C:\\Users\\Cliff\\Documents\\top_block.py'
> >
> > Executing: G:\GNURadio-3.7\gr-python27\python.exe -u
> > C:\Users\Cliff\Documents\top_block.py
> >
> > gr-osmosdr 4d83c606 (0.1.5git) gnuradio 3.7.13.4
> > built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
> > airspy redpitaya
> > [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> > UHD_3.13.0.1-0-unknown
> > Traceback (most recent call last):
> >   File "C:\Users\Cliff\Documents\top_block.py", line 102, in 
> > main()
> >   File "C:\Users\Cliff\Documents\top_block.py", line 96, in main
> > tb = top_block_cls()
> >   File "C:\Users\Cliff\Documents\top_block.py", line 64, in __init__
> > self.osmosdr_source_0 = osmosdr.source( args="numchan=" + str(1) + "
> > " + '' )
> >   File "G:\GNURadio-3.7\lib\site-packages\osmosdr\osmosdr_swig.py", line
> > 1330, in make
> > return _osmosdr_swig.source_make(*args, **kwargs)
> > RuntimeError: No supported devices found (check the connection and/or
> > udev rules).
> >
>  Done
> > --- end of error log --
> > I am running GRC 3.7.13.4 on a Windows 10 Pro workstation.
> > I am using a Hack RF One from Great Scott Gadgets which has a label on
> > the side "r4-p6" but does not identify this as a model/rev ID.
> > I ran the first example from Great Scott Gadgets Hack RF One Tutorials
> > which is located here: https://greatscottgadgets.com/sdr/1/
> > This example combines the OSMOCOM Souce and WX GUI FFT Sink modules.
> > I have attached the grc file, the top_block.py and the GRC configuration
> > file.
> > The error occurred when I clicked on the "Execute the Flow Graph" Icon.
> > I would appreciate any help getting past this error.
> > Thanks!
> >
> >
> > ___
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unable to download Windows binary install files

[Geof Nieboer]

OK, looks like everything is working now.  A couple stuck system updates
had locked things up.

Geof

On Thu, Dec 13, 2018 at 1:42 PM Saverio Mercurio <
smercu...@prescientwireless.com> wrote:

> Thanks for the response. As an FYI, in case it helps to troubleshoot, it
> appears that the first page request works, but then when you click on
> another link for a resource that's in the same domain, the server times out.
>
> -Saverio
>
> On 12/13/2018 12:17 PM, Geof Nieboer wrote:
>
> smercurio,
>
> Apologies, that server has been hiccuping this week, and I haven't had a
> chance to RDP in and figure out why.  Please check back next week.
>
> Geof
>
> On Fri, Dec 7, 2018 at 7:09 PM smercurio 
> wrote:
>
>> I'm not sure if this is the right place to ask this, so if not, please
>> let me know where this should be addressed. I was unable to find any
>> support link or mail sub-list for this, so the closest I got was this list.
>>
>> I have successfully installed GNU Radio on Linux, but now need to get it
>> installed on Windows as well. This is for a project at work. The GNU Radio
>> Wiki's page on installing GNU Radio on Windows pointed to this site:
>> http://www.gcndevelopment.com/gnuradio/downloads.htm. There are several
>> .msi files available there, but I have been unable to download them. This
>> is only occurring for the .msi files. Whenever I try I get a "network
>> error". I have tried IE, Firefox, Chrome, both at work and at home, and
>> even my phone using a cellular connection. In all cases I get that error,
>> and only with the .msi files. I can download any of the other files - just
>> not the .msi files. This appears to be a server issue, but as I said, I
>> could not find any contact information on the gncdevelopment.com web
>> site.
>>
>> Thanks.
>> ___
>> 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unable to download Windows binary install files

[Geof Nieboer]

smercurio,

Apologies, that server has been hiccuping this week, and I haven't had a
chance to RDP in and figure out why.  Please check back next week.

Geof

On Fri, Dec 7, 2018 at 7:09 PM smercurio 
wrote:

> I'm not sure if this is the right place to ask this, so if not, please let
> me know where this should be addressed. I was unable to find any support
> link or mail sub-list for this, so the closest I got was this list.
>
> I have successfully installed GNU Radio on Linux, but now need to get it
> installed on Windows as well. This is for a project at work. The GNU Radio
> Wiki's page on installing GNU Radio on Windows pointed to this site:
> http://www.gcndevelopment.com/gnuradio/downloads.htm. There are several
> .msi files available there, but I have been unable to download them. This
> is only occurring for the .msi files. Whenever I try I get a "network
> error". I have tried IE, Firefox, Chrome, both at work and at home, and
> even my phone using a cellular connection. In all cases I get that error,
> and only with the .msi files. I can download any of the other files - just
> not the .msi files. This appears to be a server issue, but as I said, I
> could not find any contact information on the gncdevelopment.com web site.
>
> Thanks.
> ___
> 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] Windows Crashing while Installing and Running GNU Radio

[Geof Nieboer]

OK I think I misread your post a bit.  So you are *dual booting* Windows
and Ubuntu, and installed GNURadio to the Ubuntu installation, and now
windows won't boot?

I thought you had installed GNURadio in Windows.

In this case, I doubt it is GNURadio related (directly at least).  Probably
due to the dual-boot configuration, possibly due to UEFI issues if you have
a newer system??

Geof

On Fri, Oct 19, 2018 at 12:19 AM Rensi Mathew  wrote:

>
> Geof,
>
> I booted Windows without connecting the Hardware and then only this
> happened.
>
> I instaled GNU Radio using '*sudo apt install gnuradio*' command.
>
> I will try to boot in safe mode and see.
>
> Thnaking you
> Rensi Sam
> On Friday, October 19, 2018, 2:03:28 AM GMT+5:30, Geof Nieboer <
> gnieb...@corpcomm.net> wrote:
>
>
> Rensi,
>
> I have never run into this problem.  What happens if you physically
> disconnect the USRP and boot the device?
>
> This has to be a driver problem as obviously GNURadio isn't running when
> your are just logging in.  Sounds like a problem between the UHD drivers
> and the USB chipset.
>
> Boot in safe made and remove the drivers, then try a reinstall.  Which
> version of the GNURadio installer are you using?  There is a recent version
> posted that has recent UHD drivers (don't recall this moment which ones)
>
> Geof
>
> On Tue, Oct 16, 2018 at 4:33 AM Rensi Mathew  wrote:
>
> Dear all
>
> I have installed Windows and then Ubuntu 16.04, as second OS. (Windows
> booting fine at this point)
>
> Then I installed GNU radio and UHD drivers.(Windows booting fine at this
> point)
>
> Then I connected my USRP and run an FM receiver program.
>
> After this when I tried to login to Windows, Windows has crashed and
> doesn't boot.
>
> I has this experience twice.
>
> Has anyone experienced such as mine? What is the possible reason? Can
> someone suggest how to avoid this.
>
> Thanking you
> Rensi
>
> ___
> 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] Windows Crashing while Installing and Running GNU Radio

[Geof Nieboer]

Rensi,

I have never run into this problem.  What happens if you physically
disconnect the USRP and boot the device?

This has to be a driver problem as obviously GNURadio isn't running when
your are just logging in.  Sounds like a problem between the UHD drivers
and the USB chipset.

Boot in safe made and remove the drivers, then try a reinstall.  Which
version of the GNURadio installer are you using?  There is a recent version
posted that has recent UHD drivers (don't recall this moment which ones)

Geof

On Tue, Oct 16, 2018 at 4:33 AM Rensi Mathew  wrote:

> Dear all
>
> I have installed Windows and then Ubuntu 16.04, as second OS. (Windows
> booting fine at this point)
>
> Then I installed GNU radio and UHD drivers.(Windows booting fine at this
> point)
>
> Then I connected my USRP and run an FM receiver program.
>
> After this when I tried to login to Windows, Windows has crashed and
> doesn't boot.
>
> I has this experience twice.
>
> Has anyone experienced such as mine? What is the possible reason? Can
> someone suggest how to avoid this.
>
> Thanking you
> Rensi
>
> ___
> 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] AirSpy HF+ with GNU Radio and gr-osmosdr

[Geof Nieboer]

Glad to help!

On Mon, Sep 24, 2018 at 2:40 PM Richard Hedlund 
wrote:

> Hello Geof and Kyeong,
>
> Thank you for such quick response.
>
> I started with your suggestions Kyeong, i had udev rules set in
> /etc/udev/rules.d for the device. I tried running GNU Radio as root, still
> without luck.
>
> As for your suggestion Geof, to play with the arguments for the osmocom
> source block in GNU Radio, this actually solved my problem, however not in
> the way i expected. I have of course tried "airspy", "airspy=0", etc, as
> the argument for the source block which is suggested in the documentation at
> https://osmocom.org/projects/gr-osmosdr/wiki
>
> Then i though why not try "airspyhf=0"...
>
> No where in any documentation that i found is it stated that i should use
> "airspyhf=0". THIS solved the problem. Perhaps this is obvious for all of
> you, but it is not for a newbie like me.
>
> Finally! My week long headache was solved by a simple argument line in the
> source block.
>
> Hopefully my embarrassment will help someone else out there. Thank you for
> your help! This thread can be marked as solved.
>
> Kind regards,
> Richard
>
>
>
> Den mån 24 sep. 2018 kl 18:18 skrev Geof Nieboer :
>
>> I would recommend experimenting with the osmosdr source parameters.  GQRX
>> uses GNURadio behind the scenes, so if GQRX can see it in Ubuntu, then so
>> should GNURadio, so I suspect it's a block setup problem.
>>
>> On Mon, Sep 24, 2018 at 7:35 AM Richard Hedlund <
>> richard.hedl...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> First of all, this is my first post on a mailing list and i apologize if
>>> this is the wrong place to ask this kind of question.
>>>
>>> After having spent almost a full work week on getting the AirSpy HF+ to
>>> work with GNU Radio i thought it was time to post here. It feels like i
>>> have searched everywhere; different mailing lists, forums, AirSpy support
>>> along with their github and the web in general.
>>>
>>> I have tried installing GNU Radio using pybombs following the guide:
>>> https://www.gnuradio.org/blog/pybombs-the-what-the-how-and-the-why
>>>
>>> I have tried installing GNU Radio following the guide by Alexandru Csete:
>>> http://gqrx.dk/download/install-ubuntu
>>>
>>> I have tried building and installing:
>>> https://github.com/airspy/airspyone_host
>>> https://github.com/airspy/airspyhf
>>>
>>> *The AirSpy HF+ works with:*
>>> SDR# under Windows 10
>>> GQRX under the Ubuntu system below
>>>
>>> I does however not work with GNU Radio under Linux which is were i
>>> intend to use the HF+.
>>>
>>> *My system info (Dell Latitude 7480):*
>>>
>>>- Ubuntu 18.04.1 LTS (full installation on a USB-stick)
>>>- 4.15.0-34-generic #37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018
>>>x86_64 x86_64 x86_64 GNU/Linux
>>>- 16 GB RAM
>>>- Intel Core i7 7600U
>>>
>>> *Output of: dmesg | grep usb*
>>> [ 7243.420121] usb 1-2: new high-speed USB device number 13 using
>>> xhci_hcd
>>> [ 7243.569041] usb 1-2: New USB device found, idVendor=03eb,
>>> idProduct=800c
>>> [ 7243.569052] usb 1-2: New USB device strings: Mfr=1, Product=2,
>>> SerialNumber=3
>>> [ 7243.569060] usb 1-2: Product: AIRSPY HF+
>>> [ 7243.569067] usb 1-2: Manufacturer: www.airspy.com
>>> [ 7243.569074] usb 1-2: SerialNumber: AIRSPYHF SN:3652A98094C73FA0
>>>
>>> *Output of: airspy_info*
>>> airspy_lib_version: 1.0.9
>>> airspy_open() board 1 failed: AIRSPY_ERROR_NOT_FOUND (-5)
>>>
>>> *Running GNU Radio:*
>>> I try to run a simple flowgraph in GNU Radio with an osmocom source
>>> connected to a WX gui FFT sink. The output is the following:
>>>
>>> Generating: '/home/hedric/top_block.py'
>>>
>>> Executing: /usr/bin/python -u /home/hedric/top_block.py
>>>
>>> Warning: failed to XInitThreads()
>>> linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
>>>
>>> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.11
>>> built-in source types: file osmosdr fcd rtl rtl_tcp uhd plutosdr miri
>>> hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
>>> Traceback (most recent call last):
>>>   File "/home/hedric/top_block.py", line 101, in 
>>> main()
>>>   File "/home/hed

Re: [Discuss-gnuradio] AirSpy HF+ with GNU Radio and gr-osmosdr

[Geof Nieboer]

I would recommend experimenting with the osmosdr source parameters.  GQRX
uses GNURadio behind the scenes, so if GQRX can see it in Ubuntu, then so
should GNURadio, so I suspect it's a block setup problem.

On Mon, Sep 24, 2018 at 7:35 AM Richard Hedlund 
wrote:

> Hello,
>
> First of all, this is my first post on a mailing list and i apologize if
> this is the wrong place to ask this kind of question.
>
> After having spent almost a full work week on getting the AirSpy HF+ to
> work with GNU Radio i thought it was time to post here. It feels like i
> have searched everywhere; different mailing lists, forums, AirSpy support
> along with their github and the web in general.
>
> I have tried installing GNU Radio using pybombs following the guide:
> https://www.gnuradio.org/blog/pybombs-the-what-the-how-and-the-why
>
> I have tried installing GNU Radio following the guide by Alexandru Csete:
> http://gqrx.dk/download/install-ubuntu
>
> I have tried building and installing:
> https://github.com/airspy/airspyone_host
> https://github.com/airspy/airspyhf
>
> *The AirSpy HF+ works with:*
> SDR# under Windows 10
> GQRX under the Ubuntu system below
>
> I does however not work with GNU Radio under Linux which is were i intend
> to use the HF+.
>
> *My system info (Dell Latitude 7480):*
>
>- Ubuntu 18.04.1 LTS (full installation on a USB-stick)
>- 4.15.0-34-generic #37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 x86_64
>x86_64 x86_64 GNU/Linux
>- 16 GB RAM
>- Intel Core i7 7600U
>
> *Output of: dmesg | grep usb*
> [ 7243.420121] usb 1-2: new high-speed USB device number 13 using xhci_hcd
> [ 7243.569041] usb 1-2: New USB device found, idVendor=03eb, idProduct=800c
> [ 7243.569052] usb 1-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 7243.569060] usb 1-2: Product: AIRSPY HF+
> [ 7243.569067] usb 1-2: Manufacturer: www.airspy.com
> [ 7243.569074] usb 1-2: SerialNumber: AIRSPYHF SN:3652A98094C73FA0
>
> *Output of: airspy_info*
> airspy_lib_version: 1.0.9
> airspy_open() board 1 failed: AIRSPY_ERROR_NOT_FOUND (-5)
>
> *Running GNU Radio:*
> I try to run a simple flowgraph in GNU Radio with an osmocom source
> connected to a WX gui FFT sink. The output is the following:
>
> Generating: '/home/hedric/top_block.py'
>
> Executing: /usr/bin/python -u /home/hedric/top_block.py
>
> Warning: failed to XInitThreads()
> linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
>
> gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.11
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd plutosdr miri
> hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
> Traceback (most recent call last):
>   File "/home/hedric/top_block.py", line 101, in 
> main()
>   File "/home/hedric/top_block.py", line 95, in main
> tb = top_block_cls()
>   File "/home/hedric/top_block.py", line 65, in __init__
> self.osmosdr_source_0 = osmosdr.source( args="numchan=" + str(1) + " "
> + 'airspy=0' )
>   File "/usr/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line
> 1170, in make
> return _osmosdr_swig.source_make(*args, **kwargs)
> RuntimeError: Failed to open AirSpy device (-5) AIRSPY_ERROR_NOT_FOUND
>
>
> Hopefully this is enough information for you, if not please let me know. I
> am by no means an advanced Linux user but still eager to learn.
>
> Kind regards,
> Richard
> ___
> 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] IIR Filter ?

[Geof Nieboer]

Hello,

Which version of GR are you running in Windows?  Previous versions were not
compatible with the filter designer.

Also, could you give us a screenshot of your GRC flow graph?

Geof


On Sat, Sep 22, 2018 at 17:41 jf.dev...@gmail.com 
wrote:

> Hello
>
>
> I 'm an old  french Applied Physics Teacher   and I try to use  basic GRC
>  for  my electronics students (2 first University  years in a technical
> Department) as a learning tool since 2016
> I   use GRC  under Pentoo Linux  if I need to  run  HackRFone/osmocom
> and/or  DBTVstick/RTLSDR
>  and Windows7 if not because GRC under  W7 doesn't run the source/sink
> I'm not a computer expert   evenif  I practise a little Arduino and python
>  ( I was rised with Fortran/Pascal math computing a long time ago)
> I choosed  GRC as a free alternative to Labview  too expensive and too
> much to handle  for DSP
>
> I tried to  design a IIR  Filter  like an FIR  with / delay /  add/ sub
> /multiply const/blocks  looped  : failure
>
> I tried to run   the IIR  Filter block under W7 : failure
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Error 0: Block - blocks_add_xx_1 - Add(blocks_add_xx): Source - out(0):
> Port is not connected. Error 1: Block - blocks_add_xx_1 -
> Add(blocks_add_xx): Sink - in0(0): Port is not connected. Error 2: Block -
> blocks_add_xx_1 - Add(blocks_add_xx): Sink - in1(1): Port is not connected.
> Error 3: Block - blocks_add_xx_1 - Add(blocks_add_xx): Sink - in2(2): Port
> is not connected. Error 4: Block - blocks_add_xx_1 - Add(blocks_add_xx):
> Sink - in3(3): Port is not connected.*
>
>
> I tried  under W7 a python program
> GNUR Radio Embedded Python Example 3 - IIR Filter
>
> Prepared by Dr. Aaron Scher
> aaron.sc...@oit.edu
> Oregon Institute of Technology
> Failure
>
> The python block  ask me for an editor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Block paths: C:\Users\user\.grc_gnuradio C:\Program
> Files\GNURadio-3.7\share\gnuradio\grc\blocks Loading:
> "C:\Users\user\Desktop\RII_4_4.grc" >>> Done >>> Unable to load the default
> editor. Please choose an editor. >>> No editor selected. >>> Unable to load
> the default editor. Please choose an editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor. >>> Error opening an external
> editor. Please select a different editor.*
>
> I tried to open Notepad and then   the block is in an endless loop  It
> doen't ask for an other different  editor evenif   it's always a failure !
>
>
> Is there a simple working   IIR Filter with taps ?
>
> Thank you for your insights
>
>
>
>
>
> --
> jf.dev...@gmail.com
>
>
> 
>  Garanti
> sans virus. www.avast.com
> 
> <#m_904970306889182_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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

[Discuss-gnuradio] Windows 3.7.13.4 binaries available

[Geof Nieboer]

Good afternoon all,

The windows installers have been updated for GNURadio 3.7.13.4 and are
posted here: http://www.gcndevelopment.com/gnuradio/downloads.htm

This was primarily a version update to include newer dependencies that are
out there, no new functionality added to the installers other than what
comes from the newer versions of the components.  This will likely be the
last 3.7.xx version until I get a working 3.8 build going.

Issues Fixed:

-Intel Fortran 2018 now detected

-Points to local version of no-longer-supported hexchat GTK binaries

-Fixed bug where Boost would fail to build with updated MSVC 2015
versions

-Pointed to correct git branch for gnuradio clone based on new tree
structure

The following versions were updated (to include necessary changes in build
scripts to accomodate upstream changes):

   - GNURadio -> 3.7.13.4
   - volk > 1.4
   - UHD -> 3.13.0.1
   - gqrx -> 2.11.5
   - openssl -> 1.0.2n
   - cython -> 0.28.5
   - numpy -> 1.15.1
   - scipy -> 1.1.0
   - lapack -> 3.8.0
   - OpenBLAS -> 0.3.3
   - pyzmq -> 17.1.2
   - libzmq -> 4.2.2
   - libpng -> 1.6.34

No new upstream packages were added.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Windows binaries for GR 3.7.12 released

[Geof Nieboer]

Good afternoon all,

The windows installers have been updated for GnuRadio 3.7.12 and are posted
here: http://www.gcndevelopment.com/gnuradio/downloads.htm

The following versions were updated:

   - GNURadio -> 3.7.12
   - UHD -> 3.11.0
   - gqrx -> 2.11.3

The following OOT packages have been added

   - gr-gsm

Other Issues Fixed:

   - The scripts now check for dependencies using Get-Command vs fixed paths
   - A license file mismatch was fixed
   - Added environment variable to work with RFNOC development
   - Removed unintended dependencies on Intel Fortran runtime libs

Enjoy!

Geof

PS. Here is the complete list of currently included OOT packages:

gr-acars2
gr-adsb
gr-ais
gr-air-modes
gr-ax25
gr-burst (incl. bitarray)
gr-cdma
gr-display (incl. matplotlib)
gr-eventstream
gr-inspector (incl. tensorflow)
gr-lte
gr-mapper
gr-nacl
gr-paint (incl. PIL)
gr-radar
gr-rds
gr-specest
OpenLTE
gr-gsm
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Windows DLL Error && Missing Ubuntu Apt-Get Components

[Geof Nieboer]

Christopher,

On the windows side, there is a tool called Dependency Walker that has been
really vital for me to track down missing DLL's.  To use it here,
right-click on the appropriate Python DLL (Probably C:\Program
Files\GNURadio-3.7\gr-python27\lib\site-packages\scipy-0.18.1-py2.7-win-amd64.egg\scipy\special\_ufuncs.pyd)
and simply go "Analyze DLL".  It will then walk through all the
dependencies and figure out what DLL is actually missing.

The version on my machine is looking for LIBMMD.DLL which is part of the
Intel Fortran compiler redistributable, not MKL.  I would look for that
file, I will take a note to ensure it is included in the next binary if in
fact that's the issue.  If you do have it on your machine, make sure it's
path is included in PATH.

Geof


On Thu, Mar 8, 2018 at 3:58 PM, Martin Braun  wrote:

> Hey Christopher,
>
> sorry to hear you're having so much trouble.
>
> On 02/22/2018 07:00 PM, Christopher Harper wrote:
> > I've been struggling to get this working.  I've ended up with partial
> > success from the Ubuntu package, the Win binary, and the PyBombs source
> > script.  Really, any three of the following options would be great if
> > somebody could give me pointers.
> >
> > 1) Ubuntu 16.04 package
> > Using the apt-get package for Ubuntu 16.04, I'm missing components in
> > the companion.  Specifically, at least the following (found trying to
> > load a partial-success from 2):
> >
> > >>> Error: Block key "blocks_multiply_const_xx" not found
> > >>> Error: Block key "burst_fsk_time_sync" not found
> > >>> Error: Block key "burst_slicer" not found
> > >>> Error: Block key "es_handler_pdu" not found
> > >>> Error: Block key "es_trigger_edge_f" not found
> > >>> Error: Block key "rtlsdr_source" not found
>
> Which apps/examples are you running? rtlsdr_source, for example, is not
> actually part of core GNU Radio. That said, some of the others are.
>
>
> > 2) Windows 10
> > Failing that, I switched to Windows and got much further on the binary
> > (3.7.11.1).  Unfortunately, I can't use the "Burst FSK Time Sync"
> > block.  It's giving me the following DLL error:
> >
> >   File "C:\Program
> > Files\GNURadio-3.7\gr-python27\lib\site-packages\
> scipy-0.18.1-py2.7-win-amd64.egg\scipy\special\__init__.py",
> > line 636, in 
> > from ._ufuncs import *
> > ImportError: DLL load failed: The specified module could not be
> found.
> >
> >
> > A little bit of Googling got me to install Intel's MKL Windows package;
> > didn't help.
>
> Not sure about this. First, the FSK time sync block shouldn't be
> importing scipy. And if that's the issue, I'd except an import error,
> not a DLL load error. Do you have a _ufuncs_import DLL anywhere?
>
> > 3) Linux, PyBombs
> > I decided to go back to Linux, and picked the PyBombs route (really cool
> > app btw - kudos to that team!).  Unfortunately, I ended up at the
> > following compile error (I found something in this mailing list from
> > 2016 with it, but didn't quite follow what fixed the issue):
> >
> > [ 86%] Building CXX object
> > gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
> > /home/Chris/grc/src/gnuradio/build/gr-uhd/swig/uhd_
> swigPYTHON_wrap.cxx:
> > In function ‘PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*,
> > PyObject*, PyObject*)’:
> > /home/Chris/grc/src/gnuradio/build/gr-uhd/swig/uhd_
> swigPYTHON_wrap.cxx:27935:15:
> > error: ‘class uhd::usrp::dboard_iface’ has no member named
> > ‘set_gpio_debug’
> >(arg1)->set_gpio_debug(arg2,arg3);
> >^
> > ...
> >
> > CMakeFiles/Makefile2:13309: recipe for target
> > 'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all' failed
> > make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2
> > Makefile:160: recipe for target 'all' failed
> > make: *** [all] Error 2
> > PyBOMBS.Packager.source - ERROR - Build failed. See output above for
> > error messages.
> > PyBOMBS.Packager.source - ERROR - Problem occurred while building
> > package gnuradio:
> > Build failed.
> > PyBOMBS.install_manager - ERROR - Error installing package gnuradio.
> > Aborting.
>
> I think this is a UHD error that is now resolved. Can you try this again?
>
> -- M
>
> ___
> 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] Using rtl-sdr dongle with grc on Windows 10

[Geof Nieboer]

You probably need to run zadig.exe to get the right driver loaded... see (
https://www.rtl-sdr.com/getting-the-rtl-sdr-to-work-on-windows-10/).  I
believe a copy of zadig.exe should be in the ./gnuradio-3.7/bin directory.

Have you used the rtl-sdr dongle with any other windows applications?

If not, I would try to get it running in gqrx that came bundled with
gnuradio.  That will rule out if it's your gnuradio setup or a driver issue.

If it works in gqrx, then which source block are you using and what
parameters have you provided to the source block?

I suspect it's the driver issue which is easily sorted with zadig (and
should only need to be done once).

Geof

On Wed, Nov 1, 2017 at 10:05 AM, vempati Sarma  wrote:

> I need help in using rtl-sdr dongle with grc.
> I loaded gnuradio on Windows 10 os with binary packages and it is working
> well.
> I trying to use rtl-sdr dongle as source in spectrum monitor setup in grc.
> Flow graph is not detecting output from rtl-sdr, where as it is working
> with Ubuntu 16.04 os on another laptop.
> Are there any configuration requirements as in blacklist file in case of
> Ubuntu os? If so how to setup the requirement?
>
> ___
> 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] Audio sink + windows binaries

[Geof Nieboer]

It seems the problem resides in the relationship between the wav file
source and the windows audio sink.

The win audio sink is playing "live" audio fine
The wav file sink can record that same audio to a file
That file plays back fine in VLC.

These steps appear to validate that audio sink is working as expected...

However, that file is returning an error when playing in the wav file
source in GRC, that it does not contain any samples.  So that's not
helpful.  Then when playing the pre-recording file from you, I get the same
distortion you are.  But the WAV file source is not windows-unique (unlike
the audio sink/source).

SO, the only thing different about the file sources is that they are
un-throttled.  So of course you'd set "Ok to block" in the audio sink,
which was implemented in a later update to the windows audio sinks.  If I
recall correctly, the windows WAVE_MAPPER device did some odd things during
testing... like when pushed too many samples, it would internally drop
excess samples without reporting anything to the calling code about the
overrun, until pushed past 96KHz, though I also found some of that behavior
was driver-dependent.  But frankly it's been some time since I re-wrote the
sinks, so I don't recall for certain.

Unfortunately the quick testing and playing around with throttle rates,
channels, and sample rates didn't fix anything, so in the end I don't have
a good answer.  The only likely possibility is various minor differences in
types and implementation between GCC and MSVC that could have affected the
wav file source, but again, a quick scan of the source didn't show a
smoking gun.

If you come up with more data points during troubleshooting, I'll see what
I can do.

Geof



On Wed, Oct 25, 2017 at 6:12 PM, Achilleas Anastasopoulos <anas...@umich.edu
> wrote:

> Great Geof,
>
> thanks for the feedback!
>
> The wav file was downloaded from the internet and the data file was
> generated by the simple matlab script that is also present in the
> Dropbox directory I provided: essentially it opens the wav file, reads the
> samples, extracts only one of the two channels and saves the data in
> float32 format.
>
> Just to clarify: both files (data and wav) are played perfectly OK on my
> Linux Box, so the issue is not with wav vs data but with Linux vs Windows.
>
> thanks again,
> Achilleas
>
>
>
>
>
>
>
>
>
> On Wed, Oct 25, 2017 at 5:28 PM, Geof Nieboer <gnieb...@corpcomm.net>
> wrote:
>
>> Achilleas,
>>
>> I have duplicated the problem with the same setup, playing the .data file
>> w/ the file source, and also playing the wav file with the wav file source
>> produces similar distorted results.
>>
>> However, I don't have a quick solution to return.  I'll need to keep
>> looking.
>>
>> Can you describe how you created the .data file and .wav files?
>>
>> Geof
>>
>> On Wed, Oct 25, 2017 at 4:22 PM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> Hi Marcus,
>>>
>>> thanks for offering to help.
>>>
>>> As i say in my email the audio file sounds with a different speed than
>>> the original!
>>>
>>> I have added a new file in the Dropbox link that I sent last time,
>>> "experiment.m4a"
>>> If you play it you'll hear the two different sounds: one from my
>>> standard wav player and the other from within grc.
>>>
>>> thanks again,
>>> Achilleas
>>>
>>> ___
>>> 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] Audio sink + windows binaries

[Geof Nieboer]

Achilleas,

I have duplicated the problem with the same setup, playing the .data file
w/ the file source, and also playing the wav file with the wav file source
produces similar distorted results.

However, I don't have a quick solution to return.  I'll need to keep
looking.

Can you describe how you created the .data file and .wav files?

Geof

On Wed, Oct 25, 2017 at 4:22 PM, Achilleas Anastasopoulos  wrote:

> Hi Marcus,
>
> thanks for offering to help.
>
> As i say in my email the audio file sounds with a different speed than the
> original!
>
> I have added a new file in the Dropbox link that I sent last time,
> "experiment.m4a"
> If you play it you'll hear the two different sounds: one from my standard
> wav player and the other from within grc.
>
> thanks again,
> Achilleas
>
> ___
> 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] Implementing feedback loops

[Geof Nieboer]

> A few solutions I have read online say that all feedbacks can be done
internal to the custom block. The problem i have is that my application
will no longer be real time.

Why don't you think it will be in real time?  If you have a code branch so
that y0 still outputs (invalid) data on flowgraph startup until y1 has
filled the internal queue, then you could design it with near real time
response.


On Thu, Oct 5, 2017 at 1:09 PM, Marcus Müller  wrote:

> Hi Vipin,
> sorry, I don't fully understand. So you only have one block, A, but it
> implements multiply functions x() and y()? What are y0 and y1? Are they
> just two values, or are they two streams?
>
> I think I would very greatly benefit from having a drawing. Really, just
> anything on a piece of paper, photographed with a potato.
>
> Thanks!
> Marcus
>
>
> On 10/05/2017 06:46 PM, Vipin Sharma wrote:
>
> I am aware that GNURadio doesn't support feedback loops in the flow graph.
> However, I have an application scenario where every execution of a GRC
> block, I need some of the previous outputs of that block.
>
> For example, if I have a block called A which produces y0,y1 and consumes
> i0, i1. Assume all input/output buffers are of size d. Also assume the
> block implements some signal processing function, y0[n] = x(i0[n], i1[n])
> and y1[n] = y(i0[n]) where 'x' and 'y' are some arbitrary functions that
> the GRC block implements. i0 is some BPSK independent source. i1 is the
> delayed output y1. In other words, i1 = y[n - d].
>
> In the flow graph, y1 will go through a delay block and become i1 to the
> GRC block. However this creates a feedback loop in the flow graph.
>
> How do I go about implementing such a scenario?
>
> A few solutions I have read online say that all feedbacks can be done
> internal to the custom block. The problem i have is that my application
> will no longer be real time.
>
> Ideally I would like to have the block process a sample size of 'd' at a
> time where a USRP board dumps the BPSK stream in real time.
>
> Any pointers?
>
> Vipin
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> 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] Windows install building oot modules

[Geof Nieboer]

Yes, ability to build OOT modules is the key work for the next release.
(a), (b), and (c) are all generated during the build, so it's just a
question of including them in the .msi.

I will keep your requests in mind as I build the next installer, thanks!

Geof

On Fri, Sep 29, 2017 at 5:27 PM, Eugene Grayver 
wrote:

> First, kudos for getting Windows builds up and running.  I’ve been doing
> it manually myself for years and it has always been a pain.  Can I request
> two small changes:
>
> 1.   Please include enough extras to allow building oot modules
>
> a.   Boost includes and .libs
>
> b.  Swig.exe
>
> c.   Zeromq includes and .libs (I think a few oot use this)
>
> 2.   I could not get ‘pip’ to work.  The pip-script.py works just
> fine, but pip.exe gives ‘failed create process’  Not a big deal, but threw
> me for a loop.
>
>
>
>
>
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274 <(310)%20336-1274>
> 
>
>
>
> ___
> 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 installs with pybombs on Windows 7 computer with VMWare 10 but not on Windows 10 computer with VMWare 12 Ubuntu 17.04

[Geof Nieboer]

You could of course always install GNURadio directly to the native OS using
the windows installers, if GNURadio is the only reason for using the VM.

On Mon, Sep 25, 2017 at 1:31 PM, West, Nathan 
wrote:

> As the error says, that's an internal error to the compiler. That usually
> means that you ran out of memory. The quick-and-dirty method to resolve
> this is to add swap. The better solution may be apt-get install gnuradio
>
> On Mon, Sep 25, 2017 at 12:55 PM, Ed Troy  wrote:
>
>> I've been trying to get gnuradio up and running on 2 computers. Both run
>> Ubuntu 17.04. In both cases, I started with a clean install of Ubuntu
>> followed by the instructions on https://www.gnuradio.org/blog/
>> pybombs-the-what-the-how-and-the-why/
>> In the case of the Windows 7 machine using VMWare 10, it went fine. No
>> problems. Now, I need to figure out how to install GQRX without messing up
>> gnuradio-companion.
>> But, on the other computer, which is a notebook running Windows 10 and
>> VMWare version 12, the installation failed. It actually looked like it
>> would work. But, after an hour or so, I got the following error lines:
>> Scanning dependencies of target _blocks_swig2
>> [ 30%] Building CXX object gr-blocks/swig/CMakeFiles/_blo
>> cks_swig2.dir/blocks_swig2PYTHON_wrap.cxx.o
>> [ 31%] Linking CXX shared module _blocks_swig2.so
>> [ 31%] Built target _blocks_swig2
>> [ 31%] Built target blocks_swig0_swig_doc
>> [ 31%] Built target _blocks_swig0_swig_tag
>> [ 31%] Built target blocks_swig0_gr_blocks_swig_a6e57
>> Scanning dependencies of target _blocks_swig0
>> [ 31%] Building CXX object gr-blocks/swig/CMakeFiles/_blo
>> cks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o
>> c++: internal compiler error: Killed (program cc1plus)
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See  for instructions.
>> gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/build.make:70: recipe for
>> target 
>> 'gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o'
>> failed
>> make[2]: *** 
>> [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o]
>> Error 4
>> CMakeFiles/Makefile2:2907: recipe for target
>> 'gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all' failed
>> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all] Error 2
>> Makefile:160: recipe for target 'all' failed
>> make: *** [all] Error 2
>> PyBOMBS.Packager.source - ERROR - Build failed. See output above for
>> error messages.
>> PyBOMBS.Packager.source - ERROR - Problem occurred while building package
>> gnuradio:
>> Build failed.
>> PyBOMBS.install_manager - ERROR - Error installing package gnuradio.
>> Aborting.
>>
>> the last command issued was pybombs prefix init -a default
>> prefix/default/ -R gnuradio-default
>>
>> Like I said, this worked perfectly on the other computer using the same
>> commands. And, I got this same problem last week when I was trying to load
>> gnuradio onto the notebook. I think I was using a different version of
>> Ubuntu that time, but I am not sure.
>> ED
>>
>> --
>> RF, Microwave, Antenna, and Analog Design,
>> Development,Simulation, and Research Consultinghttp://aeroconsult.com
>> Aerospace Consulting LLC
>> P.O. Box 536
>> Buckingham, Pa. 18912(215) 345-7184(215) 345-1309 FAX
>>
>>
>> ___
>> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FW: Re: File sink permission error on Windows

[Geof Nieboer]

Kim,

Ok, I'm feeling somewhat confident that this is a unicode or slash issue.
The character you said is your path separator appears in my email client as
a W with a horizontal line through it, but when I cut/pasted that
character, it became a back slash.  Interesting.

But I think that fact it ends up as a back slash is the more important
part,  So try using forward slashes instead of back slashes as a
workaround.  It's possible the file path parser is treating the back slash
as a character escape in Windows python, which might indicate why \bad.bin
doesn't work but \good.bin does, since \b is a backspace escape character.

I will take a closer look later on, but try that to keep moving forward.

Geof

On Tue, Aug 8, 2017 at 2:35 AM, 김태영 <d...@radarnspace.kr> wrote:

> Geof
>
>
>
> 'good.bin' exist and no 'bad.bin'.
>
> The separator is \. I confirm that by selecting some file on file sink
> block file menu.
>
> How can I check if any unicode?
>
>
>
> Regards
>
> Kim taeyeong
>
>
>
> Original Message
>
> *Subject :* Re: [Discuss-gnuradio] FW: Re: File sink permission error on
> Windows
>
> *Date :* 2017-08-08 12:30:52
>
> *From :* Geof Nieboer <gnieb...@corpcomm.net>
>
> *To :* 김태영 <d...@radarnspace.kr>
>
> *Cc :* "Discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
> Kim,
>
> That's a very odd error.  Can you confirm that neither good.bin or bad.bin
> existed in that folder?  Are there any unicode characters in the filename?
> Your path separators were copied as \. Can you confirm which direction
> slashes you were using?
>
> Geof
>
> On Mon, Aug 7, 2017 at 11:16 PM, 김태영 <d...@radarnspace.kr> wrote:
>>
>> Thanks.
>>
>>
>>
>> But I still have problem. Some file name works good, but not the another.
>>
>>
>>
>> For ex. 'C:\Work\GRC_Work\good.bin' whithout error,
>>
>> But 'C:\Work\GRC_Work\bad.bin' fail.
>>
>>
>>
>> It looks like some kind of bug.
>>
>>
>>
>>
>>
>> Regards
>>
>> Kim taeyeong
>>
>>
>>
>> Original Message
>>
>> *Subject :* Re: [Discuss-gnuradio] File sink permission error on Windows
>>
>> *Date :* 2017-08-07 17:17:57
>>
>> *From :* Marcus Müller <muel...@kit.edu>
>>
>> *To :* <discuss-gnuradio@gnu.org>
>>
>> *Cc :*
>>
>> Hi Kim,
>>
>>
>>
>> can you try to select an absolute file name rather then just "new.bin",
>> in a directory that you definitely can generate new files in?
>>
>> To me, this looks like the reason really is that you're not allowed to
>> create or write to new.bin.
>>
>>
>>
>> Best regards,
>>
>> Marcus
>>
>> On 08/07/2017 09:31 AM, 김태영 wrote:
>>
>> Hi all
>>
>>
>>
>> When I test file sink block on Windows 10 platform, I got permission
>> error. GRC version is 3.7.9.2
>>
>> This flowgraph works well on Ubuntu environment.
>>
>> How can I overcome this issue.
>>
>>
>>
>> One more issue is the deference before "Stream to tagged stream" and
>> after.
>>
>> I want to know what this block meaning.
>>
>>
>>
>>
>>
>> Regards
>>
>> Kim taeyeong
>>
>>
>>
>>
>>
>>  Error message 
>>
>>
>> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
>> C:\Work\GRC_Work\file_sink.py
>>
>> Using Volk machine: avx2
>> new.bin: Permission denied
>> Traceback (most recent call last):
>>   File "C:\Work\GRC_Work\file_sink.py", line 82, in 
>> main()
>>   File "C:\Work\GRC_Work\file_sink.py", line 76, in main
>> tb = top_block_cls()
>>   File "C:\Work\GRC_Work\file_sink.py", line 37, in __init__
>> self.blocks_file_sink_0_1 = blocks.file_sink(gr.sizeof_int*1,
>> "new.bin", False)
>>   File "C:\Program Files\GNURadio-3.7\lib\site-pa
>> ckages\gnuradio\blocks\blocks_swig0.py", line 1016, in make
>> return _blocks_swig0.file_sink_make(itemsize, filename, append)
>> RuntimeError: can't open file
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> 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] FW: Re: File sink permission error on Windows

[Geof Nieboer]

Andrew,

There are windows installers available for GNURadio, located at
http://www.gcndevelopment.com/gnuradio.  They contain all dependencies and
are 64-bit only, compatible with Win 8 & 10.  They also include a number of
drivers, OOT blocks, and ancillary packages like gqrx.

The current version is based on 3.7.11.1.  The most recent version provides
probably 95%+ of the Linux functionality, including WX + QT GUIs.  TCP
sinks/sources do not work, creation of OOT blocks is very difficult still,
and some things (like file sink paths) need adjustment to work properly,
but in general the packages are pretty decent now.  (I am biased as I am
the maintainer of the installers)

Geof


On Mon, Aug 7, 2017 at 11:31 PM, Andrew Rich 
wrote:

> How do u run gnu radio on windows ?
>
> A
>
> Sent from my iPhone
>
> On 8 Aug 2017, at 1:16 pm, 김태영  wrote:
>
> Thanks.
>
>
>
> But I still have problem. Some file name works good, but not the another.
>
>
>
> For ex. 'C:\Work\GRC_Work\good.bin' whithout error,
>
> But 'C:\Work\GRC_Work\bad.bin' fail.
>
>
>
> It looks like some kind of bug.
>
>
>
>
>
> Regards
>
> Kim taeyeong
>
>
>
> Original Message
>
> *Subject :* Re: [Discuss-gnuradio] File sink permission error on Windows
>
> *Date :* 2017-08-07 17:17:57
>
> *From :* Marcus Müller 
>
> *To :* 
>
> *Cc :*
>
> Hi Kim,
>
>
>
> can you try to select an absolute file name rather then just "new.bin", in
> a directory that you definitely can generate new files in?
>
> To me, this looks like the reason really is that you're not allowed to
> create or write to new.bin.
>
>
>
> Best regards,
>
> Marcus
>
> On 08/07/2017 09:31 AM, 김태영 wrote:
>
> Hi all
>
>
>
> When I test file sink block on Windows 10 platform, I got permission
> error. GRC version is 3.7.9.2
>
> This flowgraph works well on Ubuntu environment.
>
> How can I overcome this issue.
>
>
>
> One more issue is the deference before "Stream to tagged stream" and after.
>
> I want to know what this block meaning.
>
>
>
>
>
> Regards
>
> Kim taeyeong
>
>
>
>
>
>  Error message 
>
>
> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
> C:\Work\GRC_Work\file_sink.py
>
> Using Volk machine: avx2
> new.bin: Permission denied
> Traceback (most recent call last):
>   File "C:\Work\GRC_Work\file_sink.py", line 82, in 
> main()
>   File "C:\Work\GRC_Work\file_sink.py", line 76, in main
> tb = top_block_cls()
>   File "C:\Work\GRC_Work\file_sink.py", line 37, in __init__
> self.blocks_file_sink_0_1 = blocks.file_sink(gr.sizeof_int*1,
> "new.bin", False)
>   File "C:\Program 
> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig0.py",
> line 1016, in make
> return _blocks_swig0.file_sink_make(itemsize, filename, append)
> RuntimeError: can't open file
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> 
>
> 
>
> ___
> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FW: Re: File sink permission error on Windows

[Geof Nieboer]

Kim,

That's a very odd error.  Can you confirm that neither good.bin or bad.bin
existed in that folder?  Are there any unicode characters in the filename?
Your path separators were copied as \. Can you confirm which direction
slashes you were using?

Geof

On Mon, Aug 7, 2017 at 11:16 PM, 김태영  wrote:

> Thanks.
>
>
>
> But I still have problem. Some file name works good, but not the another.
>
>
>
> For ex. 'C:\Work\GRC_Work\good.bin' whithout error,
>
> But 'C:\Work\GRC_Work\bad.bin' fail.
>
>
>
> It looks like some kind of bug.
>
>
>
>
>
> Regards
>
> Kim taeyeong
>
>
>
> Original Message
>
> *Subject :* Re: [Discuss-gnuradio] File sink permission error on Windows
>
> *Date :* 2017-08-07 17:17:57
>
> *From :* Marcus Müller 
>
> *To :* 
>
> *Cc :*
>
> Hi Kim,
>
>
>
> can you try to select an absolute file name rather then just "new.bin", in
> a directory that you definitely can generate new files in?
>
> To me, this looks like the reason really is that you're not allowed to
> create or write to new.bin.
>
>
>
> Best regards,
>
> Marcus
>
> On 08/07/2017 09:31 AM, 김태영 wrote:
>
> Hi all
>
>
>
> When I test file sink block on Windows 10 platform, I got permission
> error. GRC version is 3.7.9.2
>
> This flowgraph works well on Ubuntu environment.
>
> How can I overcome this issue.
>
>
>
> One more issue is the deference before "Stream to tagged stream" and after.
>
> I want to know what this block meaning.
>
>
>
>
>
> Regards
>
> Kim taeyeong
>
>
>
>
>
>  Error message 
>
>
> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
> C:\Work\GRC_Work\file_sink.py
>
> Using Volk machine: avx2
> new.bin: Permission denied
> Traceback (most recent call last):
>   File "C:\Work\GRC_Work\file_sink.py", line 82, in 
> main()
>   File "C:\Work\GRC_Work\file_sink.py", line 76, in main
> tb = top_block_cls()
>   File "C:\Work\GRC_Work\file_sink.py", line 37, in __init__
> self.blocks_file_sink_0_1 = blocks.file_sink(gr.sizeof_int*1,
> "new.bin", False)
>   File "C:\Program 
> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig0.py",
> line 1016, in make
> return _blocks_swig0.file_sink_make(itemsize, filename, append)
> RuntimeError: can't open file
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> 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] Crash of gqrx in gr block deallocator when building gnuradio w/o log4cpp on Ubuntu 16-17

[Geof Nieboer]

Doing this from memory, but as I recall the corruption happens because
iqbal/gqrx libraries believe sizeof(block) is different than what
gnuradio's libraries believe.  So one library malloc's a different amount
of memory than the other library uses and frees.  If during debugging you
call sizeof() from different parts of the call stack, it should become
clear.

The problem I found is that if logger.h is included without ENABLE_GR_LOG,
it defines logger_ptr as a void*, whereas with it enabled and without
log4cpp it defines it as a std::string... and those are not guaranteed to
be the same size.

Now having said that, this was on Windows, so perhaps on GCC
sizeof(std::string) == sizeof(void*) and you are facing a completely
different issue.  But it sounds likely it's the same.  Like yourself, I
didn't have time to dig any further as to what code change caused this
issue to surface at the time.

Geof


On Fri, Jul 14, 2017 at 11:07 AM, Anon Lister <listera...@gmail.com> wrote:

> Hmm, so in my last test I completely skipped gr-iqbal. I had gnuradio,
> osmosdr with only file playback and python modules enabled, and gqrx.
> You'll still get a crash if you start file playback, then goto demod and
> change the type to nbfm, then wbfm. Believe it hits some cout in gnuradio
> like "Resampling audio from 96000 -> 48000."
>
> Given that line is just a cout, I'm geussing whatever logging facility is
> hijacking cout and leaves it in a bad state after some destructor is
> called.
>
> Also, if you build with -fsanitize=address, you do see that there's a
> memory corruption way before that destructor gets called, but I'm not sure
> if it's related.
>
> I gotta submit a PR for something in gr-dtv this weekend, so I might dig
> in more while I have things setup.
>
>
> On Jul 14, 2017 9:50 AM, "Geof Nieboer" <gnieb...@corpcomm.net> wrote:
>
> Don,
>
> I ran into the same exact issue while updating the windows build scripts.
>
> Another fix is to manually define ENABLE_GR_LOG during build of iqbal and
> gqrx to work around the issue without installing log4cpp.  It appears to
> just affect those two so far.  The windows build does not currently include
> log4cpp on 3.7.x builds.
>
> Geof
>
>
> On Thu, Jul 13, 2017 at 10:55 AM, Anon Lister <listera...@gmail.com>
> wrote:
>
>> Hey all, just an FYI,
>>
>> I don't have the time to go figure out what exactly is causing it, but if
>> you build from source with the log4cpp dep missing after a merged PR in
>> April/May(that fixed some log4cpp headers), then in certain circumstances,
>> you will get a segfault, due to a heap buffer overflow.
>>
>> There are a few code paths that crash. If gr-iqbal is installed, it will
>> crash right on opening gqrx. If not it will crash when switching demod
>> type.
>>
>> I believe both cases a call to a destructor on at least 1 block, followed
>> by some kind of printed message is the culprit.
>>
>> Took me a few days to find the "fix", as I thought it was related to some
>> new hardware I had, but then upon pulling I was able to reproduce on my
>> normal workstation and it went away when I installed log4cpp and recompiled
>> GR. Just though I'd throw this out Incase anyone else was having the issue.
>>
>> I'll try to file a bug report, but ideally I would like to include more
>> information and I don't have time for that atm, and from what I understand
>> it might be OBE when 3.8 comes out as that's getting added as a required
>> dependency.
>>
>> I have not reproduced the crash in anything besides gqrx, but it seems
>> pretty solid that it's a bug in GR. I bet other apps that reconfigure
>> flowgraphs like shinysdr would trigger it as well.
>>
>> -Don
>>
>> ___
>> 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] Crash of gqrx in gr block deallocator when building gnuradio w/o log4cpp on Ubuntu 16-17

[Geof Nieboer]

Don,

I ran into the same exact issue while updating the windows build scripts.

Another fix is to manually define ENABLE_GR_LOG during build of iqbal and
gqrx to work around the issue without installing log4cpp.  It appears to
just affect those two so far.  The windows build does not currently include
log4cpp on 3.7.x builds.

Geof


On Thu, Jul 13, 2017 at 10:55 AM, Anon Lister  wrote:

> Hey all, just an FYI,
>
> I don't have the time to go figure out what exactly is causing it, but if
> you build from source with the log4cpp dep missing after a merged PR in
> April/May(that fixed some log4cpp headers), then in certain circumstances,
> you will get a segfault, due to a heap buffer overflow.
>
> There are a few code paths that crash. If gr-iqbal is installed, it will
> crash right on opening gqrx. If not it will crash when switching demod
> type.
>
> I believe both cases a call to a destructor on at least 1 block, followed
> by some kind of printed message is the culprit.
>
> Took me a few days to find the "fix", as I thought it was related to some
> new hardware I had, but then upon pulling I was able to reproduce on my
> normal workstation and it went away when I installed log4cpp and recompiled
> GR. Just though I'd throw this out Incase anyone else was having the issue.
>
> I'll try to file a bug report, but ideally I would like to include more
> information and I don't have time for that atm, and from what I understand
> it might be OBE when 3.8 comes out as that's getting added as a required
> dependency.
>
> I have not reproduced the crash in anything besides gqrx, but it seems
> pretty solid that it's a bug in GR. I bet other apps that reconfigure
> flowgraphs like shinysdr would trigger it as well.
>
> -Don
>
> ___
> 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] Successful installation of GNURadio 3.6.4.1 on Window XP and Windows 8

[Geof Nieboer]

I have built windows installers for gnuradio that have been available for a
bit over a year.  They include 3.7.11.1 and just last week updated them to
version 1.3,  and include a wide variety of drivers and packages all
purpose built for windows 10 64-bit.

Hopefully that will save you some trouble.  They are located at:

www.gcndevelopment.com/gnuradio/downloads.htm

Geof


On Wed, Jul 5, 2017 at 17:45 Bhaskar11  wrote:

> I've been out of touch with this work for some years, but find that many
> are still searching for the drivers referred to in this guide. As a help to
> all, I've uploaded all these drivers to a shared folder on Google Drive
> here: https://drive.google.com/open?id=0Byk3JPiq4KUKY3B1enR6djAyX1k
>
> I hope this will remain as an active archive for many years to come, even
> if the original driver links break.
>
> If I can make time, I hope someday to update these instructions for
> working under Windows 10 -- if it has not already been done by then! :)
>
> B.
>
>
> On Thu, Dec 26, 2013 at 9:40 PM, Bhaskar11  wrote:
>
>> *After much experimentation I have finally found a way to successfully
>> install and fully run GRC 3.6.4.1 both under Windows XP and Windows 8.*
>> I presume it should therefore work equally well under Vista and 7.
>>
>> First a few comments on the common causes of problems that most people
>> have had:
>>
>> a. It is critical to have the correct *matching* and *complete* versions
>> of the various required libraries. Most installations instructions online
>> fail because of this reason. The Ettus installation instructions officially
>> recommended on GNURadio website and provided here
>>  fail
>> now because many of the original binary versions referred to are no longer
>> available. Hence those instructions are now outdated and should be replaced
>> by the instructions provided in this email.
>>
>> b. Although it is possible to successfully install GNURadio binaries for
>> versions 3.7.x, none of them include runtime DLLs for WX GUI blocks. Hence
>> these blocks are not displayed, and so most of the example files available
>> cannot be used as they need WX GUI blocks. Moreover, some of the QT GUI
>> blocks do not work in certain versions. Since I do not know how to make
>> these binaries, I request those who have created these version 3.7.x
>> Windows binaries to repack them so that we can run the latest versions of
>> GNURadio in Windows. Until that is done, there is no point trying to
>> install those versions.
>>
>> c. Only GNURadio version 3.6.x binaries have WX GUI blocks. But versions
>> 3.6.2 does not allow moving the blocks. Only 3.6.4.1 is usable, and works
>> perfectly well for all available examples tested so far including all QT
>> GUI and WX GUI blocks.
>>
>> d. The required Python libraries versions are available only for Python
>> version 2.7.3 and are NOT all available for versions 2.7.6 or above, or at
>> least I could not find them online. Hence we have to use libraries
>> compatible only with Python 2.7.3.
>>
>> e. Some library versions have their quirks or bugs. For example PyGTK
>> 2.24.0 does not allow you to add blocks in GRC. Only version PyGTK 2.24.2
>> works ok. Also wxPython binary called
>> "wxPython2.8-win32-unicode-2.8.12.1-py27" just does not work, but the same
>> version but different binary called "wxPython-2.8.12.1.win32-py2.7" works
>> correctly. Most online instructions do not mention the need for
>> "wxPython-common" library, which is absolutely necessary. Also some odd
>> problems such as this
>> 
>> cease to exist when the correct libraries are matched.
>>
>> f. In the instructions below I have listed all the correct working
>> libraries and binaries with links from which to download them. Please use
>> only the binaries from these links and install them in the sequence
>> provided. Other versions or binaries may not work. Keep all default options
>> unless otherwise specified here. If you have problems working with the
>> instructions below, check your binaries, and ensure that you are doing a
>> clean install.
>>
>> Finally, please share your experiences with success and failures on this
>> list so that others may benefit.
>>
>> *Instructions to install GNURadio in Windows XP and Windows 8:*
>>
>> 1. Uninstall all earlier installations and libraries of GNURadio and
>> Python and their add-ons. Ensure that the GNURadio directory and Python
>> directory are entirely removed by the uninstalls.
>> For Windows XP GNURadio default directory is: C:\Program Files\gnuradio
>> For Windows 8 it is: C:\Program Files (x86)\gnuradio
>> For all platforms the Python default directory is: C:\Python27
>> Both the GNURadio and Python directories should be non-existent. If they
>> still exist, then delete them and reboot. We 

[Discuss-gnuradio] Windows Binaries v1.3.0 posted

[Geof Nieboer]

All,

A new set of windows binaries are now posted.  A number of new packages
have been added.

http://www.gcndevelopment.com/gnuradio/downloads.htm

Changes:

   1. A complete debug version is now available, with the whole stack
   including all dependencies built in debug mode.  Symbols for Debug/Release
   are available as separate downloads.
   2. gr-fec features should now be operational.
   3. The following versions were updated:
  - GNURadio -> 3.7.11.1
  - gqrx -> 2.6.1
  - fftw -> 3.3.6-pl2
  - swig -> 3.0.12
  - libpng -> 1.6.29
   4. The following new OOT packages are now included:
  - gr-air-modes
  - gr-ais
  - gr-ax25
  - gr-burst (incl. bitarray)
  - gr-cdma
  - gr-display (incl. matplotlib)
  - gr-eventstream
  - gr-inspector (incl. tensorflow)
  - gr-lte
  - gr-mapper
  - gr-nacl
  - gr-paint (incl. PIL)
  - gr-radar
  - gr-rds
  - gr-specest
  - OpenLTE
   5. The build scripts received a tons of robustness upgrades, though
   again, end users are should use the installers, NOT build from source
   (that's not the windows way...)

There are examples for most of the OOT blocks in the /share directory tree.

While I have accomplished basic functional testing for most of the these
blocks, I could not accomplish the unit tests on many of them for a variety
of reasons (missing test data set etc.).
For the more complex blocks, (gr-lte, OpenLTE, gr-cdma), frankly I don't
have enough familiarity with these packages to know if they were acting as
intended.  SO, I'd appreciate any use reports on those blocks, even if it
is as simple as "worked as expected".

Known Issues:
-- gr-air-modes gui does not work, but the command line interface will

-- Switching a selector block with a UHD source will cause a crash

-- Switching between debug and release versions will cause intermittent
heap corruption issues.  Re-run application.

-- TCP Sink/Server are deprecated and do not function in the windows
version, use zeromq blocks

-- gr-newmod still does not work without a great deal of workarounds
(fixing that is the way ahead for 1.4.0)

-- agc3 block will run, but will adjust gain more slowly than on linux...
under investigation.

Enjoy!

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

Re: [Discuss-gnuradio] gnuradio bugtracker

[Geof Nieboer]

Vladimir,

The bug tracker was recently moved to github, so head to
http://github.com/GNURadio/GNURadio to find the issues/bug tracker.

Geof


On Sun, May 7, 2017 at 07:19 Владимир Мартьянов 
wrote:

> Hello, I'm new in gnuradio and maybe don't know some obvious things... But
> where is a bugtracker? I found a link
> https://gnuradio.org/redmine/projects/gnuradio/issues in the FAQ, but it
> redirected me to the https://gnuradio.org and it's strange, I think ;-)
> ___
> 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] GRC 3.7.11 on Windows crashes python.exe

[Geof Nieboer]

Martjin,

On the windows build, most likely the problem is in the build scripts... we
build two versions, one with maximum optimizations for AVX2 capable CPUs,
and a generic one.  Sometimes, however, AVX2 instructions get into the
regular build for a number of reasons (qwt in particular has been an issue
because of qmake's build system).  That will cause the "illegal
instruction" error.

SO, if you can confirm the below:
1- The machine you are running on has a somewhat older CPU
2- You downloaded the installer from the "any CPU" link.

If those cases are true, then the bug is in my scripts.  As I don't have a
HackRF, it's difficult to test.  Please let me know the answer to the
above.  In the meantime, download the HackRF dll directly from
www.gcndevelopment.com/gnuradio/downloads.htm (near the bottom), and drop
that in the /bin directory to see if that fixes the problem (renaming the
old version to .old just in case), and see if that patches things up.
That's the DLL from the last build, but I don't believe the driver has
changed so it should work.

Geof

On Fri, Apr 14, 2017 at 12:40 PM, Marcus Müller 
wrote:

> Hi Martijn,
>
> "Illegal Instruction" is actually a proper processor fault (ie. your
> processor noticed a problem, and jumped to an interrupt routine telling
> your OS that hey, things need to be handled) that happens when one tries to
> execute code that isn't actually code or uses an instruction that your CPU
> doesn't have.
>
> I'm pretty optimistic that hackrf.dll wasn't compiled for a CPU that's
> incompatible to yours, so this might essentially be a bug – either in the
> hackrf driver dll (which might be jumping into machine code that isn't
> code), or in the way the windows DLL loader is used. Hm. Maybe even a
> compiler bug.
> Now, I have to admit that under Unixes, I'd know how to debug this, but
> under Windows, I'm out of my depth. So if you happen to be more capable
> than I am with that, you could try to run "python
> C:\path\to\your\flow_graph_python_file.py" in a debugger and see where it
> crashes. But even then, I don't know if things would be easy to figure out.
>
> Best regards,
> Marcus
>
> On 14.04.2017 16:34, Martijn Scale wrote:
>
> Trying to use a HackRF One with GNU Radio on Windows 10 (64-bits),
> installed from gnuradio_3.7.11_win64.msi.
>
> When using osmocom Source and executing the flow graph, execution halts
> with message: python.exe has stopped working. GRC remains alive.
>
> Crashes happen both with WX and QT. The HackRF One module is put into
> Receive mode (Rx Led of HackRF One is on).
>
>
>
> GNU Radio, GRC, Hack RF and computer do work as expected with the
> GNURadioLiveDVD .
>
>
>
> Debugging shows: Unhandled exception at 0x7FFCCDDD3CCB (hackrf.dll) in
> python.exe: 0xC01D: Illegal Instruction.
>
> Additional info from Event Viewer:
>
> Faulting application path: C:\Program Files\GNURadio-3.7\gr-
> python27\python.exe
>
> Faulting module path: C:\Program Files\GNURadio-3.7\bin\hackrf.dll
>
> And info from Console Panel in GRC:
>
> Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.010.001.001-0-unknown
>
>
>
> hackrf.dll info: 2017-03-03, 66.560 Bytes
>
>
>
> gr-osmosdr ae686c46 (0.1.5git) gnuradio 3.7.11
>
> built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
> airspy redpitaya
>
> Number of USB devices: 17
>
> USB device 1d50:: a06063c82xxx match
>
> Using HackRF One with firmware 2017.02.1
>
>
>
> Hardware:
>
> Processor   Intel(R) Core(TM) i7 CPU 860  @ 2.80GHz, 2794
> Mhz, 4 Core(s), 8 Logical Processor(s)
>
> Display adapterAMD Radeon HD 5700 Series
>
>
>
> Your support is highly appreciated (I tried building GNU Radio from
> sources, which failed as “gr-newmod/CMakeLists.txt was not found and is
> required”, but I decided not to pursue the building path any further as it
> exceeds my knowledge).
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> 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] Trouble compiling a program using GNU Radio with MSVC17 (was: Global namespace Errors with Complex and xlocNum)

[Geof Nieboer]

Melvin,

I would recommend using MSVC 2015, as I can verify that GNURadio builds
fine with that, and the installation process for windows builds all
dependencies with that to ensure consistency.

That way you can at least rule out a compiler difference as the reasons.
MSVC 2017 implements more of the C++11/14 standards, and (unlike GCC)
doesn't provide a way to not use them, so it's *possible* it's that causing
a problem.

Past that, I couldn't really comment more without the same information that
Marcus was asking about, how GR was installed and how the dependencies were
installed.  If you used my installers, which version did you use?

Geof

On Thu, Mar 16, 2017 at 6:43 AM, Marcus Müller 
wrote:

> Dear Melvin,
>
> as much as I'd like to help you with this, it's very likely not a GNU
> Radio but a MSVC-related problem – Now, it's completely possible this is
> *really* GNU Radio-related, so we should keep on this. However,
>
> > UPDATE: I removed Iostream since I commented out all cin,cout lines in
> > order to just have the blocks declarations and connections,  and the
> > original errors returned.
> If moving header includes around, and commenting out usage of cin
> **introduces** errors that disappeared by moving stdafx.h to the top of
> the file, my diagnosis is:
>
> The very, very likeliest explanation for all this is some strangeness
> going on in your build system (in this, case, Visual Studio).
>
> You should probably do two things:
>
> 1. Describe how you (built? and) installed GNU Radio and other
> dependencies. Is this exactly the same Visual Studio version used to
> compile the dependencies (among those, especially GNU Radio)?
> 2. make a clean C++ project without any GNU Radio includes. Build that.
> If it works, add one GNU Radio #include, but don't do anything else,
> recompile. Re-construct your source code "piece by piece". Compile
> early, compile often. Where exactly do things start breaking?
>
> Note that 2. is really necessary, I'm afraid, since the errors are
> definitely effect of "something in the dark, something coming from the
> swamp, something elder, sinister that twists the minds of humans and
> compilers alike"; also note that I hate to put this burden on you, since
> it really sucks as an early C++ experience.
>
> So, hoping this will make it possible for you to continue working on the
> actual things you want to do:
> Is it possible for you to try a Linux system instead, if you don't have
> to install it at all, but can run it off a USB stick?
>
> Best regards,
> Marcus
>
> On 16.03.2017 01:20, Melvin J Malave Sanchez wrote:
> > ovice to c++ and the handling of library has been quite troubling.
> > UPDATE: I removed Iostream since I commented out all cin,cout lines in
> > order to just have the blocks declarations and connections,  and the
> > original errors returned.  Ill include the flowgraph of what the code
> > is supposed to resemble in case it helps.
>
>
> ___
> 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] gr-fec: why BOOST_CONSTEXPR_OR_CONST?

[Geof Nieboer]

If it sheds light... the original issue was that the static const float was
being defined and initialized with a value in the header, which worked with
GCC because of a GCC-extension.  This, however failed with MSVC (or gcc
running in -pedantic mode apparently).

So the declaration/init was split between the .h and .cc file, which fixed
that problem, but obviously introduced this new issue.

I agree replacing the macro with "const" in the header and leaving the
initialization in the .cc file would work.

Geof

On Tue, Mar 7, 2017 at 2:26 PM, Martin Braun  wrote:

> Agree with Michael, especially since we don't allow C++11 features yet.
>
> Martin
>
> On 6 Mar 2017 7:41 am, "Michael Dickens" 
> wrote:
>
>> I have a MacPorts ticket requesting that I enable CTRLPORT, which
>> requires Thrift, which was recently updated to 0.10.0 in MacPorts -- so
>> I thought it worth a try again to see if it works.
>>
>> Thrift requires C++11 for building, which means that "gnuradio
>> +ctrlport" will also require C++11. Easy enough, or so I thought, by
>> forcing CMake to use C++11 via using the right compiler and adding
>> "-DCMAKE_CXX_STANDARD=11" as a commandline argument.
>>
>> This combination works well until it reaches gr-fec, which errors out
>> due to a BOOST_CONSTEXPR_OR_CONST declaration that's valid C++ when it
>> is "const" ... but the C++ code isn't valid for a "constexpr", which
>> requires that the variable value be defined in the declaration.
>>
>> gr-fec/include/gnuradio/fec/polar_decoder_common.h:70
>> {{{
>>   private:
>> static BOOST_CONSTEXPR_OR_CONST float D_LLR_FACTOR;
>> }}}
>>
>> gr-fec/lib/polar_decoder_common.cc:37
>> {{{
>>   const float polar_decoder_common::D_LLR_FACTOR = -2.19722458f;
>> }}}
>>
>> Looks like D_LLR_FACTOR was correctly defined to work with the
>> "constexpr" or "const" version of BOOST_CONSTEXPR_OR_CONST in <
>> https://github.com/gnuradio/gnuradio/commit/a1cf11937665392b
>> cfa223a5095ff903eb44c69b
>> > by Jaroslav Škarvada, and then broken in <
>> https://github.com/gnuradio/gnuradio/commit/a981e6a18c4f28cc
>> 6058fef4167c01ad3dc7d58a
>> > by Josh Blum.
>>
>> In my searching, the code above is the -only- place where a "constexpr"
>> is potentially used. Thus, can we please just get rid of it and use
>> "const" instead? Why the need for a constexpr here and no other place?
>>
>> One can work around this issue by defining BOOST_NO_CXX11_CONSTEXPR, but
>> the code should be able to build without this workaround.
>>
>> Thoughts? Comments? - MLD
>>
>> ___
>> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Windows binaries 3.7.11 released

[Geof Nieboer]

Good afternoon all,

The windows installers have been updated for GnuRadio 3.7.11 and are posted
here: http://www.gcndevelopment.com/gnuradio/downloads

Of note, this is the first version that required no patching to build
natively on Windows!  Thanks to all that made that happen.

Some of the windows-specific changes:

1- Audio Source implemented
2- Audio Sink block mode implemented
3- Filter Design Tool implemented
4- GRC / GQRX icons all appear
5- Nuisance errors on GRC startup no longer appear
6- UDP Source/Sinks bug fixed, now work as expected
7- GRC save dialog will now default to the Documents dir on windows.

Still open:
OOT module creation requires significant alterations (see mailing list)

Version updates:
GR -> 3.7.11
UHD -> 3.10.1.1
gqrx -> 2.6
libusb -> 1.0.21
libpng -> 1.6.28
numpy -> 1.12
scipy -> 0.18.1
openssl -> 1.0.2j
log4cpp (new) -> 1.1.1
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GSL_FOUND both TRUE and FALSE

[Geof Nieboer]

I would take a look at the FindGSL.cmake script.  I suspect the issue is
related to the change to run FindPackage twice.  Perhaps the pkgconfig
detection isn't pulling in the variables the second time so they are being
set to nulls?

For a quick test, I would try commenting out the "find_package(GSL)" in the
gr-dtv CMakeLists.txt and see what happens.

Geof

On Wed, Feb 22, 2017 at 10:42 AM, Achilleas Anastasopoulos <
anas...@umich.edu> wrote:

> Hi all,
>
> thank you for your input.
>
> Some clarifications:
>
> I was indeed cmaking the latest version from git
>
> "Building for version: v3.7.10.1-237-g81e7af7b / 3.7.11git"
>
> and was working from scratch with a clean built.
>
> I attach here the whole output of cmake.
>
> thanks for the help ,
> Achilleas
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Feb 21, 2017 at 6:01 PM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Hi all,
>>
>> after a long time update from source on a Fedora 23 I came across the
>> following problem when cmaking:
>>
>> -- Configuring gr-fec support...
>> --   Dependency ENABLE_VOLK = ON
>> --   Dependency Boost_FOUND = 1
>> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>> --   Dependency ENABLE_GR_BLOCKS = ON
>> --   Dependency GSL_FOUND = TRUE <
>> --   Enabling gr-fec support.
>> --   Override with -DENABLE_GR_FEC=ON/OFF
>> -- Checking for module 'fftw3f >= 3.0'
>> --   Found fftw3f , version 3.3.4
>> -- Found FFTW3F: /lib64/libfftw3f.so
>>
>> but then
>>
>> -- Configuring gr-dtv support...
>> --   Dependency Boost_FOUND = 1
>> --   Dependency GSL_FOUND = FALSE  <
>> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>> --   Dependency ENABLE_GR_ANALOG = ON
>> --   Dependency ENABLE_GR_FILTER = ON
>> --   Dependency ENABLE_GR_FEC = ON
>> --   Disabling gr-dtv support.
>> --   Override with -DENABLE_GR_DTV=ON/OFF
>> -- Could NOT find GSL (missing:  GSL_INCLUDE_DIRS GSL_LIBRARY_DIRS)
>> --
>> -- Configuring gr-atsc support...
>> --   Dependency Boost_FOUND = 1
>> --   Dependency GSL_FOUND = FALSE   <
>> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>> --   Dependency ENABLE_GR_FFT = ON
>> --   Dependency ENABLE_GR_BLOCKS = ON
>> --   Dependency ENABLE_GR_FEC = ON
>> --   Dependency ENABLE_GR_FILTER = ON
>> --   Dependency ENABLE_GR_ANALOG = ON
>> --   Disabling gr-atsc support.
>> --   Override with -DENABLE_GR_ATSC=ON/OFF
>>
>> --
>> -- Configuring gr-wavelet support...
>> --   Dependency Boost_FOUND = 1
>> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
>> --   Dependency ENABLE_GR_BLOCKS = ON
>> --   Dependency ENABLE_GR_ANALOG = ON
>> --   Dependency GSL_FOUND = FALSE  <
>> --   Disabling gr-wavelet support.
>> --   Override with -DENABLE_GR_WAVELET=ON/OFF
>> --
>>
>> and so the packages
>>
>> --   * gr-dtv
>> --   * gr-atsc
>> --   * gr-wavelet
>>
>> are not being built.
>>
>> BTW: I have gsl and gsl-devel installed (version 1.16-17)
>>
>> Can anyone give me a hint as to what may be wrong here?
>>
>> thanks
>> Achilleas
>>
>>
>
> ___
> 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] GSL_FOUND both TRUE and FALSE

[Geof Nieboer]

A patch was applied a couple weeks ago because gr-dtv wasn't running the
same check for GSL that the previous libraries were (in CMAKE), which
caused the same problem.  Perhaps this is the same issue?  Really depends
exactly which version you were running.  If you are running from git
between I think October and recently that could be it.  If so, then just
update your repo and you should pick it up.

Geof

On Wed, Feb 22, 2017 at 4:02 AM, Bastian Bloessl  wrote:

> Hi,
>
> On 02/22/2017 12:01 AM, Achilleas Anastasopoulos wrote:
>
> > after a long time update from source on a Fedora 23 I came across the
> > following problem when cmaking:
> >
> > Can anyone give me a hint as to what may be wrong here?
> >
>
> Does that happen even after you delete the build directory and start
> from scratch?
>
> Best,
> Bastian
>
> ___
> 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] Quesiton about GNU Radio binaries

[Geof Nieboer]

Ben,

I currently do not build 32-bit binaries.  Based on the trend in windows
deployment, I don't see the 32-bit side as having a long term future.
Because it's not just GNURadio, it's all the dependencies that would need
separate builds as well.  And there is plenty to do to improve the 64-bit
side.

Geof


On Sun, Jan 29, 2017 at 18:24 Ben Hutchinson  wrote:

> I saw you have 64 bit Windows binaries available, but couldn't find any
> 32bit Windows binaries. Is it possible for you to post up some 32bit
> binaries?
> ___
> 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] Problem running gr_filter_design on Windows 7

[Geof Nieboer]

Peter,

This is a known issue for the v1.1.2 windows installation.  I hope to have
to resolved for the next release which will be shortly after the impending
3.7.11 release.

Geof

On Wed, Jan 25, 2017 at 1:23 PM, sreeraj r  wrote:

> Swartz,
>
> So it is clearly fftpack loading issue. Make sure that all your lib
> versions are correct (32/64 bit) and other math lib dependencies for
> fftpack is satisfied on your windows version.
>
> Regards
> Sreeraj Rajendran
>
> On Wed, Jan 25, 2017 at 6:56 PM, Swartz, Peter <
> pswa...@riversideresearch.org> wrote:
>
>> Output from test:
>>
>> Traceback (most recent call last):
>>
>>   File "gr_scipi_test.py", line 25, in 
>>
>> from scipy import fftpack, poly1d, signal
>>
>>   File "C:\Program Files\GNURadio-3.7\gr-python27
>> \Lib\site-packages\scipy\fftpac
>>
>> k\__init__.py", line 95, in 
>>
>> from .basic import *
>>
>>   File "C:\Program Files\GNURadio-3.7\gr-python27
>> \Lib\site-packages\scipy\fftpac
>>
>> k\basic.py", line 12, in 
>>
>> from . import _fftpack
>>
>> ImportError: DLL load failed: The specified module could not be found.
>>
>>
>>
>> *From:* sreeraj r [mailto:rsree...@gmail.com]
>> *Sent:* Wednesday, January 25, 2017 11:04 AM
>> *To:* Swartz, Peter
>> *Cc:* discuss-gnuradio@gnu.org
>> *Subject:* Re: [Discuss-gnuradio] Problem running gr_filter_design on
>> Windows 7
>>
>>
>>
>> Hi Swartz,
>>
>> I have never tested gr_filter_design in windows. That said, can you
>> please test whether the following imports work in your windows python shell
>> / as a standalone python script.
>>
>> >>import scipy
>> >>from scipy import fftpack, poly1d, signal
>>
>> Regards
>> Sreeraj Rajendran
>>
>>
>>
>> On Wed, Jan 25, 2017 at 4:50 PM, Swartz, Peter <
>> pswa...@riversideresearch.org> wrote:
>>
>> I have GNU radio v3.7.10.1/v1.1.2 installed from
>> http://www.gcndevelopment.com/gnuradio/downloads.htm on my Windows 7
>> machine.  I am using USRP B200 as well.  When I try to run gr_filter_design
>> from the command prompt, I get a SciPi not installed error.  I have
>> verified that SciPi is installed.  I know this would work on a Linux box,
>> but I want to know how to get gr_filter_design.py to import SciPi on
>> Windows 7.
>>
>>
>> ___
>> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installing GNUradio from source on Windows 7

[Geof Nieboer]

Yep, that would be it (at least for the binaries).  The binaries were
building against 3.9, so you'll need a newer binary then.  No worries, give
that part a few days.

For the script error, do you have permissions to create c:\gr-build?  Are
you running as an admin?  Let me know if c:\gr-build exists.

Given how soon we will release new binaries and the pain you'd likely go
through to build yourself, I recommend just waiting until we get out a new
MSI.

Experiences on a linux VM are spotty, particularly over USB, but I'd be
curious how a X310 via GigE works.

Geof



On Mon, Jan 23, 2017 at 6:05 PM, Ernest Potenziani <epotenzi...@comcast.net>
wrote:

> Derek, Geoff
>
> That might be the problem. The x310 came with version 13 for the FPGA, FW
> at version 4. But when you do a uhd_usrp_probe command when the x310 is
> first removed from its box, it comes back saying that version 33 of the
> FPGA build and version 5 of the Firmware is needed. I think that the new
> FPGA load is needed because the the TwinRx modules are very new (released
> last fall I believe).
>
> Ernie
>
> Sent from Ernie's iPad ...
>
> On Jan 23, 2017, at 5:44 PM, Derek Kozel <derek.ko...@ettus.com> wrote:
>
> Hello Ernie,
>
> What version of the FPGA image is currently on your X310? I believe that
> the Geof's installer is linked against UHD 3.9 so the 3.10 FPGA images will
> not work.
>
> Regards,
> Derek
>
> On Mon, Jan 23, 2017 at 1:21 PM, Geof Nieboer <gnieb...@corpcomm.net>
> wrote:
>
>> Ernie,
>>
>> I'm the maintainer of the scripts.  I assume you are using the most
>> updated git repo version.  We're about to do a new release to coincide with
>> the new release of GR, so there are a good number of changes from the last
>> release.
>>
>> So you picked the default install location at that prompt?  Try filling
>> in the prompt manually with the default value purely based on the error
>> code.
>> When I get home in a few hours I will take a closer look, should be
>> something simple.
>>
>> Also, what FPGA errors were you getting?  My intent is that user's should
>> never have to build it themselves and can use the msi's, so I'm interested
>> in any cases where they fail.  We'll release new binary installers shortly
>> after the new GR release, though I don't believe I've made any changes what
>> would impact USRP.
>>
>> Geof
>>
>>
>>
>>
>> On Mon, Jan 23, 2017 at 10:28 AM, Ernie Potenziani <
>> epotenzi...@comcast.net> wrote:
>>
>>> Any advice will be much appreciated (I'm new to this board so please
>>> excuse me if this is not the proper forum to pose this question):
>>>
>>> I wonder if anyone can point out what I may be doing wrong to get this
>>> error while installing GNUradio from source on a Windows 7 machine (I am
>>> using an Ettus x310 and the binary version of GNUradio gives an error with
>>> the FPGA builds, so I'm trying to build it from the ground up):
>>>
>>> I am using the instructions from the web page
>>> https://github.com/gnieboer/gnuradio_windows_build_scripts
>>>
>>> The error I encounter is when running the install script is:
>>>
>>> C:\Users\user\GNURadio_Windows_Build_Scripts>Set-ExecutionPolicy
>>> Unrestricted
>>> C:\Users\user\GNURadio_Windows_Build_Scripts>powershell
>>> Windows PowerShell
>>> Copyright (C) 2009 Microsoft Corporation. All rights reserved.
>>>
>>> PS C:\Users\user\GNURadio_Windows_Build_Scripts> Set-ExecutionPolicy
>>> Unrestricted
>>> PS C:\Users\user\GNURadio_Windows_Build_Scripts> ./~RUNME_FIRST.ps1
>>> Please choose an absolute root directory for this build <c:\gr-build>:
>>> Performing initial setup
>>> Setting up directories and checking dependencies...
>>>
>>> cmdlet Import-LocalizedData at command pipeline position 1
>>> Supply values for the following parameters:
>>> BindingVariable:
>>> Import-LocalizedData : Cannot validate argument on parameter
>>> 'BindingVariable'. The argument is null or empty. Supply a
>>> n argument that is not null or empty and then try the command again.
>>> At C:\Users\user\GNURadio_Windows_Build_Scripts\Setup.ps1:239 char:31
>>> + $Config = Import-LocalizedData <<<<  -BaseDirectory $mypath -FileName
>>> ConfigInfo.psd1
>>> + CategoryInfo  : InvalidData: (:) [Import-LocalizedData],
>>> ParentContainsErrorRecordException
>>> + FullyQualifiedErrorId : ParameterArgumentValidationErr
>>> or,Microsoft.

Re: [Discuss-gnuradio] Installing GNUradio from source on Windows 7

[Geof Nieboer]

Ernie,

I'm the maintainer of the scripts.  I assume you are using the most updated
git repo version.  We're about to do a new release to coincide with the new
release of GR, so there are a good number of changes from the last release.

So you picked the default install location at that prompt?  Try filling in
the prompt manually with the default value purely based on the error code.
When I get home in a few hours I will take a closer look, should be
something simple.

Also, what FPGA errors were you getting?  My intent is that user's should
never have to build it themselves and can use the msi's, so I'm interested
in any cases where they fail.  We'll release new binary installers shortly
after the new GR release, though I don't believe I've made any changes what
would impact USRP.

Geof




On Mon, Jan 23, 2017 at 10:28 AM, Ernie Potenziani 
wrote:

> Any advice will be much appreciated (I'm new to this board so please
> excuse me if this is not the proper forum to pose this question):
>
> I wonder if anyone can point out what I may be doing wrong to get this
> error while installing GNUradio from source on a Windows 7 machine (I am
> using an Ettus x310 and the binary version of GNUradio gives an error with
> the FPGA builds, so I'm trying to build it from the ground up):
>
> I am using the instructions from the web page https://github.com/gnieboer/
> gnuradio_windows_build_scripts
>
> The error I encounter is when running the install script is:
>
> C:\Users\user\GNURadio_Windows_Build_Scripts>Set-ExecutionPolicy
> Unrestricted
> C:\Users\user\GNURadio_Windows_Build_Scripts>powershell
> Windows PowerShell
> Copyright (C) 2009 Microsoft Corporation. All rights reserved.
>
> PS C:\Users\user\GNURadio_Windows_Build_Scripts> Set-ExecutionPolicy
> Unrestricted
> PS C:\Users\user\GNURadio_Windows_Build_Scripts> ./~RUNME_FIRST.ps1
> Please choose an absolute root directory for this build :
> Performing initial setup
> Setting up directories and checking dependencies...
>
> cmdlet Import-LocalizedData at command pipeline position 1
> Supply values for the following parameters:
> BindingVariable:
> Import-LocalizedData : Cannot validate argument on parameter
> 'BindingVariable'. The argument is null or empty. Supply a
> n argument that is not null or empty and then try the command again.
> At C:\Users\user\GNURadio_Windows_Build_Scripts\Setup.ps1:239 char:31
> + $Config = Import-LocalizedData   -BaseDirectory $mypath -FileName
> ConfigInfo.psd1
> + CategoryInfo  : InvalidData: (:) [Import-LocalizedData],
> ParentContainsErrorRecordException
> + FullyQualifiedErrorId : ParameterArgumentValidationErr
> or,Microsoft.PowerShell.Commands.ImportLocalizedData
>
> PS C:\Users\user\GNURadio_Windows_Build_Scripts>
>
>
> Thanks in advance for any advice,
> Ernie
> epotenzi...@comcast.net
>
>
> ___
> 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 not working with SDRplay in Windows10

[Geof Nieboer]

Just to chime in to confirm,

SDRPlay support is not included in the windows build for 3.7.8.1 at this
time.

As Marcus said, since this driver is not GPL compatible, it can not be
directly included in the installer, so it's a low priority to consider.

Geof



On Sat, Jan 14, 2017 at 12:18 PM, Arie Kleingeld PA3A 
wrote:

> Thanks for your advice guys.
>
> I will continue working on getting a solution for this.
>
> Kind regards,
>
> Arie
>
>
>
>
> ___
> 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] problems with windows binaries and audio

[Geof Nieboer]

>
> Could you please confirm that indeed in this version the audio block DOES
> NOT BLOCK regardless of the setting


Yes, that's is exactly what I was saying... the blocking option is not
currently implemented but the fix is already in the repo awaiting release.

apologies if the email was not clear: I guess for me getting some sound was
> not considered good enough :-)


When troubleshooting, it is just helpful to get as much information as
possible.  No sound is technically very different than distorted sound, not
a question of good or bad.



On Monday, November 7, 2016, Achilleas Anastasopoulos <anas...@umich.edu>
wrote:

> I think I figured out what is going on:
>
> The audio block DOES NOT BLOCK no matter what the value of the "OK to
> block" setting is.
>
> The reason that the 440 Hz tone was heard perfectly was that although
> samples were dropped by the audio device, the remaining samples where
> enough to reconstruct a nice tone.
>
> This unfortunately does not work with other audio signals.
>
> The solution of putting a throttle unfortunately does not work well: it
> produces a very choppy sound on-off all the time.
>
>
> Geof: thanks for all the help. I guess I will have to wait for version
> 3.7.10.2.
>
> Could you please confirm that indeed in this version the audio block DOES
> NOT BLOCK regardless of the setting.
>
> thanks again,
> Achilleas
>
>
>
> On Mon, Nov 7, 2016 at 3:24 PM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> Hi Geof,
>>
>> apologies if the email was not clear: I guess for me getting some sound
>> was not considered good enough :-)
>>
>>
>> The audio sink IS BLOCKING (OK to block is indeed set to YES)
>> and as I mentioned in the last email, a nice 440Hz tone generated by a
>> signal source is PERFECTLY audible.
>>
>> As I mentioned earlier, I am starting to believe that the "wav file
>> source" is not working properly.
>>
>> Can anyone confirm a working configuration with:
>>
>> Wav File Source --> Audio Sink
>>
>> Thanks
>> Achilleas
>>
>>
>> On Mon, Nov 7, 2016 at 2:49 PM, Geof Nieboer <gnieb...@corpcomm.net>
>> wrote:
>>
>>> OK, so you are getting *some* sound.  Your first email seemed to
>>> indicate nothing at all was happening.
>>>
>>> In that case, please add a throttle block to your flowgraph, set to the
>>> audio sample rate you desire.
>>>
>>> The audio sink is being overwhelmed with data from the file source and
>>> is not blocking.
>>> When 3.7.10.2 is released the windows audio sink will block when "OK to
>>> block" is set to true.
>>>
>>> Geof
>>>
>>>
>>> On Mon, Nov 7, 2016 at 1:25 PM, Achilleas Anastasopoulos <
>>> anas...@umich.edu> wrote:
>>>
>>>> oopps I meant "a nice 440 Hz" cosine can be heard nicely.
>>>>
>>>> Achilleas
>>>>
>>>> On Mon, Nov 7, 2016 at 11:57 AM, Achilleas Anastasopoulos <
>>>> anas...@umich.edu> wrote:
>>>>
>>>>> I also would like to report that a nice 440KHz cosine can be heard
>>>>> perfectly OK with the default audio sink.
>>>>>
>>>>> So now I have my doubts about the wav file source block instead of the
>>>>> audio sink block
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> thanks
>>>>> Achilleas
>>>>>
>>>>> On Mon, Nov 7, 2016 at 10:20 AM, Achilleas Anastasopoulos <
>>>>> anas...@umich.edu> wrote:
>>>>>
>>>>>> Hi Geof,
>>>>>>
>>>>>> thank you for your suggestions.
>>>>>>
>>>>>>
>>>>>> Here is some more information from my Windows 7 running gnuradio
>>>>>> binaries 3.7.10.1
>>>>>>
>>>>>> 1)
>>>>>> When I use a simple wav file source with audio sink and without
>>>>>> setting the "Device Name" entry I get the following output:
>>>>>>
>>>>>> INFO: Audio sink arch: windows
>>>>>> gr::pagesize: no info; setting pagesize = 4096
>>>>>> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>>>>>>
>>>>>> I can hear the sound but it is not coming out at the right speed/etc
>>>>>> regardless of what sample rate I choose.
>>>

Re: [Discuss-gnuradio] problems with windows binaries and audio

[Geof Nieboer]

OK, so you are getting *some* sound.  Your first email seemed to indicate
nothing at all was happening.

In that case, please add a throttle block to your flowgraph, set to the
audio sample rate you desire.

The audio sink is being overwhelmed with data from the file source and is
not blocking.
When 3.7.10.2 is released the windows audio sink will block when "OK to
block" is set to true.

Geof


On Mon, Nov 7, 2016 at 1:25 PM, Achilleas Anastasopoulos <anas...@umich.edu>
wrote:

> oopps I meant "a nice 440 Hz" cosine can be heard nicely.
>
> Achilleas
>
> On Mon, Nov 7, 2016 at 11:57 AM, Achilleas Anastasopoulos <
> anas...@umich.edu> wrote:
>
>> I also would like to report that a nice 440KHz cosine can be heard
>> perfectly OK with the default audio sink.
>>
>> So now I have my doubts about the wav file source block instead of the
>> audio sink block
>>
>> Any ideas?
>>
>> thanks
>> Achilleas
>>
>> On Mon, Nov 7, 2016 at 10:20 AM, Achilleas Anastasopoulos <
>> anas...@umich.edu> wrote:
>>
>>> Hi Geof,
>>>
>>> thank you for your suggestions.
>>>
>>>
>>> Here is some more information from my Windows 7 running gnuradio
>>> binaries 3.7.10.1
>>>
>>> 1)
>>> When I use a simple wav file source with audio sink and without setting
>>> the "Device Name" entry I get the following output:
>>>
>>> INFO: Audio sink arch: windows
>>> gr::pagesize: no info; setting pagesize = 4096
>>> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>>>
>>> I can hear the sound but it is not coming out at the right speed/etc
>>> regardless of what sample rate I choose.
>>>
>>> So I tried the second method that Geof suggested: entering explicitly
>>> the device ID and/or the string representing the device's name.
>>>
>>> 2)
>>> Following Geof's advice I went to the "Device Manager" and the "Sounds,
>>> video and game controllers" section and I see a device "High Definition
>>> Audio Device". I clink on the "Details" tab and under the Property "device
>>> description" i see "High Definition Audio Device", so this is what I put as
>>> the string under the "Device Name" property of the audio sink.
>>>
>>> The output then is:
>>>
>>> INFO: Audio sink arch: windows
>>> INFO: Warning: waveOut device 'High Definition Audio Device' was not
>>> found, defaulting to WAVE_MAPPER
>>> gr::pagesize: no info; setting pagesize = 4096
>>> aOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaOaO
>>> aOaOaOaOaOaOaOaOaOa
>>> aOaOaOaOaOaOaOaOaOaO
>>>
>>> And the sound is the same as above.
>>>
>>> So my question is the following:
>>>
>>> How exactly can I find in the control panel the name of my audio device?
>>> Clearly the one I used ("High Definition Audio Device") was not found...
>>>
>>> Can it be that the problem is with the "wav file source" block and not
>>> with the audio sink block?
>>>
>>> Thanks
>>> Achilleas
>>>
>>>
>>> On Sun, Nov 6, 2016 at 5:12 PM, Geof Nieboer <gnieb...@corpcomm.net>
>>> wrote:
>>>
>>>> The audio device in the windows audio sink can be used one of two ways,
>>>>
>>>> First is to use a number which is the device ID of the audio device,
>>>> the second is to enter a string representing the device's name.
>>>>
>>>> Realize, however, that there is no way to interactively iterate through
>>>> the list of available devices, so you'll have to figure out the ID's/names
>>>> yourself through the control panel.  It will give a warning in the output
>>>> log if what you entered is not found so you can least use trial and error.
>>>> If it can't find the device you entered, or you don't put an entry in, it
>>>> will use the WAVE_MAPPER device.
>>>>
>>>> Geof
>>>>
>>>>
>>>> On Sun, Nov 6, 2016 at 5:15 AM, Tarquin Roode <tarquin.ro...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>>
>>>>>
>>>>> Mine works, I am using 3.7.9.2
>>>>>
>>>>> So not a problem with the inary, it worked on Both Win 7 and Win 10
>>>>>
>>&g

Re: [Discuss-gnuradio] problems with windows binaries and audio

[Geof Nieboer]

The audio device in the windows audio sink can be used one of two ways,

First is to use a number which is the device ID of the audio device, the
second is to enter a string representing the device's name.

Realize, however, that there is no way to interactively iterate through the
list of available devices, so you'll have to figure out the ID's/names
yourself through the control panel.  It will give a warning in the output
log if what you entered is not found so you can least use trial and error.
If it can't find the device you entered, or you don't put an entry in, it
will use the WAVE_MAPPER device.

Geof


On Sun, Nov 6, 2016 at 5:15 AM, Tarquin Roode 
wrote:

> Hi
>
>
>
> Mine works, I am using 3.7.9.2
>
> So not a problem with the inary, it worked on Both Win 7 and Win 10
>
>
>
> I am not a home a he moment so don’t have  ss to my PC, bt I just plopped
> the Audio Sink down and it worked
>
>
>
> Ood luck
>
> arqun
>
>
>
> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+tarquin.roode=
> gmail@gnu.org] *On Behalf Of *Achilleas Anastasopoulos
> *Sent:* Saturday, 05 November 2016 2:46 AM
> *To:* Discuss-gnuradio@gnu.org
> *Subject:* [Discuss-gnuradio] problems with windows binaries and audio
>
>
>
> Hi,
>
>
>
> I have installed the windows binaries from GCNDevelopment
>
> http://www.gcndevelopment.com/gnuradio/
>
>
>
> A simple test with a wav file and an audio sink does not seem to work.
>
> I have changed the config file to use audio - windows but still this is
> not working.
>
> (same grc file works fine on Linux).
>
> I have tried this on both Windows 7 and 10 with no success.
>
>
>
> Can someone report if they had success with audio on Windows with these
> binaries?
>
>
>
> Any ideas as to what else I can try?
>
>
>
> thanks
>
> Achilleas
>
> ___
> 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] problems with windows binaries and audio

[Geof Nieboer]

Achilleas,

There are several others who had had success, so there must be something
unique in your setup .  Do you have more then one audio device installed?
If you do perhaps it is being routed to the wrong audio device.  The
default is the windows wave mapper which normally should send it to your
default audio device.  You can try specifying the audio device in the block
settings.

The audio -source- is not yet implemented but it will be in 3.7.10.2 when
released

Geof

On Friday, November 4, 2016, Achilleas Anastasopoulos 
wrote:

> Hi,
>
> I have installed the windows binaries from GCNDevelopment
> http://www.gcndevelopment.com/gnuradio/
>
> A simple test with a wav file and an audio sink does not seem to work.
> I have changed the config file to use audio - windows but still this is
> not working.
> (same grc file works fine on Linux).
> I have tried this on both Windows 7 and 10 with no success.
>
> Can someone report if they had success with audio on Windows with these
> binaries?
>
> Any ideas as to what else I can try?
>
> thanks
> Achilleas
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT Block on Windows (barely feasible?)

[Geof Nieboer]

ot;
> (??1?$intrusive_ptr@Vpmt_base@pmt@@@boost@@QEAA@XZ) _pager2_swig
> F:\grc\OOTmodules\gr-pager2\build\swig\pager2_swigPYTHON_wrap.obj 1
>
> After commenting out like this:
>
> %{
> /* #include "pager2/flex_deinterleave.h" */
> %}
>
> /*
> %include "pager2/flex_deinterleave.h"
> GR_SWIG_BLOCK_MAGIC2(pager2, flex_deinterleave);
> */
>
> It builds again, what am i missing
>
> Imre Biacsics
>
>
>
>
>
>
> On Sat, 22 Oct 2016 03:54:38 +0200, Geof Nieboer <gnieb...@corpcomm.net>
> wrote:
>
> Look in the cmake file(s) for something along the lines of:
> COMMAND ""
>
> If you find it, delete the double quotes.  I searched and found one in
> cmake\Modules\UseSWIG.cmake, so I would start there.
>
> Geof
>
> On Fri, Oct 21, 2016 at 9:20 PM, Imre Biacsics <techn...@livep2000.nl>
> wrote:
>
>> Dear specialists,
>>
>> One step solved, creating two other issues. I'am sure: overlooking
>> something very obvious. Sorry for that.
>> The two projects throw a "Error MSB6006 "cmd.exe" exited with code 9009."
>>
>> Wich makes sense becease:
>>
>> '""' is not recognized as an internal or external command, operable
>> program or batch file.
>>
>> I hope someone can shine a light on this. Thanks in advance.
>>
>> Imre Biacsics
>>
>> Partial build output:
>>
>> 7>Target "CustomBuild" in file "C:\Program Files
>> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets" from
>> project "F:\grc\OOTmodules\gr-pager2\build\swig\_pager2_swig.vcxproj"
>> (target "_BuildGenerateSourcesAction" depends on it):
>> 7> Using "CustomBuild" task from assembly "C:\Program Files
>> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Build.
>> CppTasks.Common.dll".
>> 7> Task "CustomBuild"
>> 7> Forcing rebuild of all source files due to missing command TLog
>> "F:\grc\OOTmodules\gr-pager2\build\swig\_pager2_swig.dir\
>> Debug\_pager2_swig.tlog\custombuild.command.1.tlog".
>> 7> setlocal
>> 7> "C:\Program Files (x86)\cmake\bin\cmake.exe"
>> -HF:/grc/OOTmodules/gr-pager2 -BF:/grc/OOTmodules/gr-pager2/build
>> --check-stamp-file F:\grc\OOTmodules\gr-pager2\build\swig\CMakeFiles\
>> generate.stamp
>> 7> if %errorlevel% neq 0 goto :cmEnd
>> 7> :cmEnd
>> 7> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
>> 7> :cmErrorLevel
>> 7> exit /b %1
>> 7> :cmDone
>> 7> if %errorlevel% neq 0 goto :VCEnd
>> 7> setlocal
>> 7> ""
>> 7> if %errorlevel% neq 0 goto :cmEnd
>> 7> :cmEnd
>> 7> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
>> 7> :cmErrorLevel
>> 7> exit /b %1
>> 7> :cmDone
>> 7> if %errorlevel% neq 0 goto :VCEnd
>> 7> setlocal
>> 7> ""
>> 7> if %errorlevel% neq 0 goto :cmEnd
>> 7> :cmEnd
>> 7> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
>> 7> :cmErrorLevel
>> 7> exit /b %1
>> 7> :cmDone
>> 7> if %errorlevel% neq 0 goto :VCEnd
>> 7> Building Custom Rule F:/grc/OOTmodules/gr-pager2/swig/CMakeLists.txt
>> 7> CMake does not need to re-run because F:\grc\OOTmodules\gr-pager2\
>> build\swig\CMakeFiles\generate.stamp is up-to-date.
>> 7> '""' is not recognized as an internal or external command,
>> 7> operable program or batch file.
>> 7> 1>
>> 7>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
>> v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe"
>> exited with code 9009.
>> 7> Done executing task "CustomBuild" -- FAILED.
>> 7> 1>
>> 7>Done building target "CustomBuild" in project "_pager2_swig.vcxproj" --
>> FAILED.
>> 7>
>> 7>Build FAILED.
>> 7>
>> 7>Time Elapsed 00:00:00.11
>> == Rebuild All: 6 succeeded, 1 failed, 0 skipped ==
>>
>>
>>
>>
>>
>> On Wed, 19 Oct 2016 14:09:10 +0200, Geof Nieboer <gnieb...@corpcomm.net>
>> wrote:
>>
>> Imre,
>>
>> Glad you had success.  I'll work to replicate your steps, and then
>> towards building a "developer pack" as an add-on to the basic install (to
>> include adding all the many symbol files for debugging purposes).
>>
>> Geof
>>
>> On Wed, Oct 19, 2016 at 3:45 AM, Imre Biac

Re: [Discuss-gnuradio] OOT Block on Windows (barely feasible?)

[Geof Nieboer]

Looks like it is trying to link to the gnuradio-pmt library and it can't
find it, so check to see if the /lib subdir is being included in the
library search path.

Geof

On Saturday, October 22, 2016, Imre Biacsics <techn...@livep2000.nl> wrote:

> Thank you, -o- wise one.
>
> In fact that was de only problem: Now i can build all projects and even
> build install.
> But the module was not properly installed and threw the:  AttributeError:
> 'module' object has no attributeIn the GRC terminal.
>
> I narrowed that down to the file /swig/pager2_swig.i  (Forgot to use the
> gr_modtool add command)
> After properly adding the block it looks like this:
>
>
> /* -*- c++ -*- */
>
> #define PAGER2_API
>
> %include "gnuradio.i" // the common stuff
>
> //load generated python docstrings
> %include "pager2_swig_doc.i"
>
> %{
> #include "pager2/flex_deinterleave.h"
> %}
>
> %include "pager2/flex_deinterleave.h"
> GR_SWIG_BLOCK_MAGIC2(pager2, flex_deinterleave);
> Wich created new issues i do not understand:
>
> Severity Code Description Project File Line Suppression State
> Error LNK2019 unresolved external symbol "__declspec(dllimport) void
> __cdecl pmt::intrusive_ptr_release(class pmt::pmt_base *)"
> (__imp_?intrusive_ptr_release@pmt@@YAXPEAVpmt_base@1@@Z) referenced in
> function "public: __cdecl boost::intrusive_ptr pmt::pmt_base>::~intrusive_ptr(void)"
> (??1?$intrusive_ptr@Vpmt_base@pmt@@@boost@@QEAA@XZ) _pager2_swig
> F:\grc\OOTmodules\gr-pager2\build\swig\pager2_swigPYTHON_wrap.obj 1
>
> After commenting out like this:
>
> %{
> /* #include "pager2/flex_deinterleave.h" */
> %}
>
> /*
> %include "pager2/flex_deinterleave.h"
> GR_SWIG_BLOCK_MAGIC2(pager2, flex_deinterleave);
> */
>
> It builds again, what am i missing
>
> Imre Biacsics
>
>
>
>
>
>
> On Sat, 22 Oct 2016 03:54:38 +0200, Geof Nieboer <gnieb...@corpcomm.net
> <javascript:_e(%7B%7D,'cvml','gnieb...@corpcomm.net');>> wrote:
>
> Look in the cmake file(s) for something along the lines of:
> COMMAND ""
>
> If you find it, delete the double quotes.  I searched and found one in
> cmake\Modules\UseSWIG.cmake, so I would start there.
>
> Geof
>
> On Fri, Oct 21, 2016 at 9:20 PM, Imre Biacsics <techn...@livep2000.nl
> <javascript:_e(%7B%7D,'cvml','techn...@livep2000.nl');>> wrote:
>
>> Dear specialists,
>>
>> One step solved, creating two other issues. I'am sure: overlooking
>> something very obvious. Sorry for that.
>> The two projects throw a "Error MSB6006 "cmd.exe" exited with code 9009."
>>
>> Wich makes sense becease:
>>
>> '""' is not recognized as an internal or external command, operable
>> program or batch file.
>>
>> I hope someone can shine a light on this. Thanks in advance.
>>
>> Imre Biacsics
>>
>> Partial build output:
>>
>> 7>Target "CustomBuild" in file "C:\Program Files
>> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets" from
>> project "F:\grc\OOTmodules\gr-pager2\build\swig\_pager2_swig.vcxproj"
>> (target "_BuildGenerateSourcesAction" depends on it):
>> 7> Using "CustomBuild" task from assembly "C:\Program Files
>> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Build.
>> CppTasks.Common.dll".
>> 7> Task "CustomBuild"
>> 7> Forcing rebuild of all source files due to missing command TLog
>> "F:\grc\OOTmodules\gr-pager2\build\swig\_pager2_swig.dir\
>> Debug\_pager2_swig.tlog\custombuild.command.1.tlog".
>> 7> setlocal
>> 7> "C:\Program Files (x86)\cmake\bin\cmake.exe"
>> -HF:/grc/OOTmodules/gr-pager2 -BF:/grc/OOTmodules/gr-pager2/build
>> --check-stamp-file F:\grc\OOTmodules\gr-pager2\build\swig\CMakeFiles\
>> generate.stamp
>> 7> if %errorlevel% neq 0 goto :cmEnd
>> 7> :cmEnd
>> 7> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
>> 7> :cmErrorLevel
>> 7> exit /b %1
>> 7> :cmDone
>> 7> if %errorlevel% neq 0 goto :VCEnd
>> 7> setlocal
>> 7> ""
>> 7> if %errorlevel% neq 0 goto :cmEnd
>> 7> :cmEnd
>> 7> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
>> 7> :cmErrorLevel
>> 7> exit /b %1
>> 7> :cmDone
>> 7> if %errorlevel% neq 0 goto :VCEnd
>> 7> setlocal
>> 7> ""
>> 7> if %errorlevel% neq 0 goto :cmEnd
>> 7> :cmEnd
&

Re: [Discuss-gnuradio] OOT Block on Windows (barely feasible?)

[Geof Nieboer]

Look in the cmake file(s) for something along the lines of:
COMMAND ""

If you find it, delete the double quotes.  I searched and found one in
cmake\Modules\UseSWIG.cmake, so I would start there.

Geof

On Fri, Oct 21, 2016 at 9:20 PM, Imre Biacsics <techn...@livep2000.nl>
wrote:

> Dear specialists,
>
> One step solved, creating two other issues. I'am sure: overlooking
> something very obvious. Sorry for that.
> The two projects throw a "Error MSB6006 "cmd.exe" exited with code 9009."
>
> Wich makes sense becease:
>
> '""' is not recognized as an internal or external command, operable
> program or batch file.
>
> I hope someone can shine a light on this. Thanks in advance.
>
> Imre Biacsics
>
> Partial build output:
>
> 7>Target "CustomBuild" in file "C:\Program Files
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets" from
> project "F:\grc\OOTmodules\gr-pager2\build\swig\_pager2_swig.vcxproj"
> (target "_BuildGenerateSourcesAction" depends on it):
> 7> Using "CustomBuild" task from assembly "C:\Program Files
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Build.
> CppTasks.Common.dll".
> 7> Task "CustomBuild"
> 7> Forcing rebuild of all source files due to missing command TLog
> "F:\grc\OOTmodules\gr-pager2\build\swig\_pager2_swig.dir\
> Debug\_pager2_swig.tlog\custombuild.command.1.tlog".
> 7> setlocal
> 7> "C:\Program Files (x86)\cmake\bin\cmake.exe"
> -HF:/grc/OOTmodules/gr-pager2 -BF:/grc/OOTmodules/gr-pager2/build
> --check-stamp-file F:\grc\OOTmodules\gr-pager2\build\swig\CMakeFiles\
> generate.stamp
> 7> if %errorlevel% neq 0 goto :cmEnd
> 7> :cmEnd
> 7> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
> 7> :cmErrorLevel
> 7> exit /b %1
> 7> :cmDone
> 7> if %errorlevel% neq 0 goto :VCEnd
> 7> setlocal
> 7> ""
> 7> if %errorlevel% neq 0 goto :cmEnd
> 7> :cmEnd
> 7> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
> 7> :cmErrorLevel
> 7> exit /b %1
> 7> :cmDone
> 7> if %errorlevel% neq 0 goto :VCEnd
> 7> setlocal
> 7> ""
> 7> if %errorlevel% neq 0 goto :cmEnd
> 7> :cmEnd
> 7> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
> 7> :cmErrorLevel
> 7> exit /b %1
> 7> :cmDone
> 7> if %errorlevel% neq 0 goto :VCEnd
> 7> Building Custom Rule F:/grc/OOTmodules/gr-pager2/swig/CMakeLists.txt
> 7> CMake does not need to re-run because F:\grc\OOTmodules\gr-pager2\
> build\swig\CMakeFiles\generate.stamp is up-to-date.
> 7> '""' is not recognized as an internal or external command,
> 7> operable program or batch file.
> 7> 1>
> 7>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\
> v4.0\V140\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe"
> exited with code 9009.
> 7> Done executing task "CustomBuild" -- FAILED.
> 7> 1>
> 7>Done building target "CustomBuild" in project "_pager2_swig.vcxproj" --
> FAILED.
> 7>
> 7>Build FAILED.
> 7>
> 7>Time Elapsed 00:00:00.11
> == Rebuild All: 6 succeeded, 1 failed, 0 skipped ==
>
>
>
>
>
> On Wed, 19 Oct 2016 14:09:10 +0200, Geof Nieboer <gnieb...@corpcomm.net>
> wrote:
>
> Imre,
>
> Glad you had success.  I'll work to replicate your steps, and then towards
> building a "developer pack" as an add-on to the basic install (to include
> adding all the many symbol files for debugging purposes).
>
> Geof
>
> On Wed, Oct 19, 2016 at 3:45 AM, Imre Biacsics <techn...@livep2000.nl>
> wrote:
>
>> I am going to answer my own question.
>>
>> "How simple is the solution when the cause is known"
>>
>> I was a bit dumb:
>>
>> Somewhere in the scripts, spaces are removed. The result was that is
>> looked for:
>>
>> F:/grc/OOTmodules/
>>
>> My real path :
>>
>> F:/grc/OOT modules/
>>
>> :( sorry
>>
>> Imre Biacsics
>>
>>
>> (Swigwin issue)
>>>
>>> Following up this message
>>> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-07/
>>> msg00108.html
>>> With another question.
>>>
>>> My goal was to sort out all the dependecies and paths to succesfully
>>> automate the process.
>>> When done I will share my findings.
>>>
>>> In short, I did this:
>>>
>>> - Installed Geof's win64 by msi, Cmake 3.3, VS201

Re: [Discuss-gnuradio] OOT Block on Windows (barely feasible?)

[Geof Nieboer]

Imre,

Glad you had success.  I'll work to replicate your steps, and then towards
building a "developer pack" as an add-on to the basic install (to include
adding all the many symbol files for debugging purposes).

Geof

On Wed, Oct 19, 2016 at 3:45 AM, Imre Biacsics 
wrote:

> I am going to answer my own question.
>
> "How simple is the solution when the cause is known"
>
> I was a bit dumb:
>
> Somewhere in the scripts, spaces are removed. The result was that is
> looked for:
>
> F:/grc/OOTmodules/
>
> My real path :
>
> F:/grc/OOT modules/
>
> :( sorry
>
> Imre Biacsics
>
>
> (Swigwin issue)
>>
>> Following up this message
>> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-07/msg00108.html
>> With another question.
>>
>> My goal was to sort out all the dependecies and paths to succesfully
>> automate the process.
>> When done I will share my findings.
>>
>> In short, I did this:
>>
>> - Installed Geof's win64 by msi, Cmake 3.3, VS2015 (community edition).
>> - Copied the dependecies from Geof's 'GNURadio_Windows_Build_Scripts'
>> after running it once: CppUnit, Boost, Swig, pkg-config.
>> - Used Gavin's tips to automate the gr-modtool New & Add functionality.
>> - Created a new terminal link, called: "Gnuradio modtool prompt",
>> implementing:
>>
>> * The orginal "Gnuradio command prompt"
>> * The the "vs 2015 win64 prompt".
>> * Added path's for the dependecies statically. (For better control).
>>
>> - Created .bat files for cmake & build.
>>
>> (As example project I converted the gr-pager modules to OOT code)
>>
>> Roadmap:
>>
>> 1. Create OOT (MT_New.bat)
>> 2. Add module 'pager2' (MT_Add.bat)
>> 3. Insert converted pager code.
>> 4. Cmake (CCmake.bat)
>> 5. Build (Build.bat)
>>
>> For readabillity i won't post the complete output, but step 4 gives me
>> some warnings (4x) i don't understand (Maybe linked to the error in step
>> 5):
>>
>> CMake Warning (dev) at cmake/Modules/UseSWIG.cmake:300
>> (target_link_libraries):
>>Link library type specifier "optimized" is followed by specifier
>> "debug"
>>instead of a library name.  The first specifier will be ignored.
>> Call Stack (most recent call first):
>>cmake/Modules/GrSwig.cmake:174 (SWIG_LINK_LIBRARIES)
>>swig/CMakeLists.txt:50 (GR_SWIG_MAKE)
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> But the result:
>>
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: F:/grc/OOT modules/gr-pager2/build
>>
>> Step 5 produces 1 error:
>>
>> (SNIP!)
>>
>> building ZERO_CHECK => Succes
>> building gnuradio-pager2 => Succes!!!
>>
>> building pager2_swig_swig_2d0df,
>> is building _pager2_swig_swig_tag,
>> is building pager2_swig_swig_doc,
>> is building _pager2_swig_doc_tag  => Succes
>>
>> Then:
>>
>> CUSTOMBUILD : error : tag OUTPUT_DIRECTORY: Output directory
>> `F:/grc/OOTmodules/gr-pager2/build/swig/pager2_swig_doc_swig_docs'
>> does not exist and cannot be created [F:\grc\OOT
>> modules\gr-pager2\build\swig\pager2_swig_swig_doc.vcxproj]
>>
>> That folder exists and is readable/writable (It holds a doxygen file and a
>> /xml subfolder), but following the naming conventions (These folders names
>> reflects the project names), something is wrong: there is no project named
>> 'pager2_swig_doc_swig_docs'.
>>
>> Do not know how to fix this, but think it should be :
>> "_pager2_swig_swig_doc"
>>
>> --
>> Okay so ignored it and inserted the .dll, .lib, block xml in GRC,
>> almost worked!
>> Blocks are visible and insertable, but starting the flowgraph is throws:
>>
>> 'module' object has no attribute 
>>
>> Googling on that it's told "Your modules is not propery swigged", that
>> makes sense, given the errors.
>>
>> --
>>
>> Someone got clue to overcome this bump?
>>
>> Thanks in Advance,
>>
>> Imre Biacsics
>>
>
> ___
> 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 3.7.10.1 gqrx fails again?

[Geof Nieboer]

to the run_gqrx.bat file, add:

set QT_QPA_PLATFORM_PLUGIN_PATH=%~dp0

and copy the qwindows.dll to the bin directory.

I will update that and include some other needed Qt5 dll's in the next
update in about 2 weeks.

Geof

On Sun, Oct 2, 2016 at 10:01 PM, Geof Nieboer <gnieb...@corpcomm.net> wrote:

> Gisle,
>
> Try putting the qwindows.dll into the GNURadio-3.7/bin directory itself
> and let me know the results.
>
> Geof
>
> On Sun, Oct 2, 2016 at 4:26 AM, Gisle Vanem <gva...@yahoo.no> wrote:
>
>> André Godau wrote:
>>
>> > gqrx fails when trying to start, with the message  ...could not find or
>> > load the Qt platform "windows" in "".
>> > I see that`s been an issue (and resolved) before. Can you tell me how to
>> > fix this? There's an empty platforms folder in the Gnuradio tree, I
>> > tried to copy an qwindows.dll from Qt 5.5 into it, but to no avail. Do I
>> > need to set another Env Var (the " could not find...in ""  " makes me
>> > wonder).
>>
>> Maybe changing (or deleting) the env-var 'QT_QPA_PLATFORM_PLUGIN_PATH'
>> can change anything. Ref:
>>   https://github.com/pyqt/python-qt5/wiki/Qt-Environment-
>> Variable-Reference
>>
>> --
>> --gv
>>
>> ___
>> 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 3.7.10.1 gqrx fails again?

[Geof Nieboer]

Gisle,

Try putting the qwindows.dll into the GNURadio-3.7/bin directory itself and
let me know the results.

Geof

On Sun, Oct 2, 2016 at 4:26 AM, Gisle Vanem  wrote:

> André Godau wrote:
>
> > gqrx fails when trying to start, with the message  ...could not find or
> > load the Qt platform "windows" in "".
> > I see that`s been an issue (and resolved) before. Can you tell me how to
> > fix this? There's an empty platforms folder in the Gnuradio tree, I
> > tried to copy an qwindows.dll from Qt 5.5 into it, but to no avail. Do I
> > need to set another Env Var (the " could not find...in ""  " makes me
> > wonder).
>
> Maybe changing (or deleting) the env-var 'QT_QPA_PLATFORM_PLUGIN_PATH'
> can change anything. Ref:
>   https://github.com/pyqt/python-qt5/wiki/Qt-
> Environment-Variable-Reference
>
> --
> --gv
>
> ___
> 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] 32bit version motivations

[Geof Nieboer]

Dario,

Can you send a link to the tablets in question?  I'm curious what CPU is
installed and how they are locked down.

Building a 32-bit version would be a significant effort, not particularly
because of GNURadio itself, but because of the dependencies.  I'd like to
see what other options there might be to get a 64-bit version running on
these tablet you mentioned.

Geof


On Mon, Sep 19, 2016 at 1:37 PM, Dario Paganini Aruba <
dario.pagan...@aruba.it> wrote:

> Hi,
>
>
>
> I need a 32bit version because of this :
>
>
>
> [1] I have a W10 tablet but it is only 32bit processor, like the majority
> of them in this type of product
>
> [2] These tablets are very cheap and can go very fast to manage gnuradio
>
> [3] These tablets are locked and don't permit to boot from USB port, so no
> way to install LINUX on them
>
> [4] They are small and very portable, so they are wery useful on-the-field
> !
>
>
>
> So, if the maintainer can open a 32bit section it will be of much use
> indeed.
>
> If not, it will be useful if the maintainer can explain how to compile a
> 32bit version, it will be very useful
>
> for me and/or others to do this and make it available for all.
>
>
>
> Many thanks in advance for your reply !
>
>
>
>
>
> Dario
>
> ___
> 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

[Discuss-gnuradio] Win64 installers for v3.7.10.1 released

[Geof Nieboer]

All,

I've built a new set of Win64 installers for 3.7.10.1.

They are available here

There are no new windows-only inclusions, just a couple bug fixes
documented here .

This is actually 3.7.10.1 *plus* a couple cherry picked commits that will
be in 3.7.10.2, with luck, the next version will be completely unpatched.
There is one issue left in volk and we're all set.

I intend to start working on some of the functional issues now that the
build/install issues are looking pretty good, as well as continuing to
improve the stability of the scripts used to build the installers.

Geof
___
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 <m.alizade...@gmail.com>
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 <gnieb...@corpcomm.net>
> 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 <m.alizade...@gmail.com
>> > 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
>>> <https://ir.linkedin.com/in/mostafa-alizadeh-50a70169>
>>>
>>> ***
>>>
>>> ___
>>> 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] Installation of GNU Radio/UHD on Windows

[Geof Nieboer]

1- The gqrx label button is a known problem.
2- To examine the path settings, open run_gr.bat in a text editor and it
should be pretty apparent what it's doing.  Take a look at the paths it is
settings and see if that matches with what you would expect with where you
installed it.

And you can confirm you used the "all cpu" version of the installer,
correct?

Geof


On Fri, Jul 15, 2016 at 2:38 PM, Dave <davidcbas...@msn.com> wrote:

> Geof,
>
>
>
> Thanks for the input.  Here is what I get when running gnuradio_companion
> for the bin directory after running run_gr.bat.  I’m not a programmer so I
> don’t know what all to look for.  I used the application rapid environment
> editor to see what my environment variables were.  I don’t see a PYTHONPATH
> variable nor do I see any entries in PATH related to GNURadio other than a
> path to the bin directory which I added manually.
>
> D:\Program Files\GNURadio-3.7\bin>gunradio_companion
>
> 'gunradio_companion' is not recognized as an internal or external command,
>
> operable program or batch file.
>
>
>
> D:\Program Files\GNURadio-3.7\bin>run_gr.bat
>
> setting gnuradio environment
>
> Microsoft Windows [Version 6.1.7601]
>
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
>
>
> D:\Program Files\GNURadio-3.7\bin>gnuradio-companion.py
>
> ImportError
>
>
>
> Cannot import gnuradio.
>
>
>
> Is the python path environment variable set correctly?
>
> All OS: PYTHONPATH
>
>
>
> Is the library path environment variable set correctly?
>
> Linux: LD_LIBRARY_PATH
>
> Windows: PATH
>
> MacOSX: DYLD_LIBRARY_PATH
>
>
>
>
>
> (DLL load failed: %1 is not a valid Win32 application.)
>
>
>
> D:\Program Files\GNURadio-3.7\bin>
>
>
>
>
>
> If I run gnuradio comanion from the start menu, it does seem to load
> correctly however the WBFM receive example does not execute.  I get
> “python.exe has stopped working” windows error and the following in the grc
> window.
>
>
>
> Generating: 'D:\\Program
> Files\\GNURadio-3.7\\share\\gnuradio\\examples\\uhd\\uhd_wbfm_receive.py'
>
>
>
> Executing: D:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
> D:\Program
> Files\GNURadio-3.7\share\gnuradio\examples\uhd\uhd_wbfm_receive.py
>
>
>
> Win32; Microsoft Visual C++ version 14.0; Boost_106000;
> UHD_003.009.003-0-unknown
>
>
>
> -- USRP-B100 clock control: 10
>
> --   r_counter: 2
>
> --   a_counter: 0
>
> --   b_counter: 20
>
> --   prescaler: 8
>
> --   vco_divider: 5
>
> --   chan_divider: 5
>
> --   vco_rate: 1600.00MHz
>
> --   chan_rate: 320.00MHz
>
> --   out_rate: 64.00MHz
>
> --
>
> -- Loading FPGA image: D:\Program
> Files\GNURadio-3.7\share\uhd\images\usrp_b100_fpga.bin... done
>
> Using Volk machine: avx
>
> fft_impl_fftw: J[1]\Users\Dav1\AppData\Roaming\.gr_fftw_wisdom: Invalid
> argument
>
>
>
> As a side note, I have installed the software to my D: drive rather than
> C: if that matters.
>
> Also, when loading gqrx all of the buttons below the menu appear however
> none of them have labels (although you can see a description when you hover
> over the button).
>
>
>
> Thanks for all you help.
>
>
>
> Dave
>
>
>
> *From:* Geof Nieboer [mailto:gnieb...@corpcomm.net]
> *Sent:* Wednesday, July 13, 2016 2:04 PM
> *To:* Derek Kozel
> *Cc:* Dave; GNURadio Discussion List
>
> *Subject:* Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on Windows
>
>
>
> Derek/Dave,
>
>
>
> My development equipment is still in transit so I can't look at anything
> until Monday, but...
>
>
>
> The UHD build should be 64-bit, so it is mostly likely a labelling issue.
> But I will check to be sure.
>
>
>
> If you want to run -any- GNURadio utilities, I recommend doing so from the
> GNURadio Command Prompt (shortcut in start menu or run_gr.bat in the /bin
> subdir) ... that will set all the Python/etc environment variables up
> correctly.  Then you should not need to specify where the UHD images are.
>
>
>
> Geof
>
>
>
>
>
> On Tue, Jul 12, 2016 at 10:11 PM, Derek Kozel <derek.ko...@ettus.com>
> wrote:
>
> Hi Dave,
>
> Yes, there is no state held in UHD so you will always need to include the
> --args "fw.." in your UHD commands. I should have also mentioned that
> this means you will need to add that exact "fw= D:\Program
> Files\GNURadio-3.7\share\uhd\images\usrp_b100_fw.ihx,fpga= D:\Program
> Files\GNURadio-3.7\share\uhd\images\usrp_b100_fpga.bin"

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] Installation of GNU Radio/UHD on Windows

[Geof Nieboer]

Derek/Dave,

My development equipment is still in transit so I can't look at anything
until Monday, but...

The UHD build should be 64-bit, so it is mostly likely a labelling issue.
But I will check to be sure.

If you want to run -any- GNURadio utilities, I recommend doing so from the
GNURadio Command Prompt (shortcut in start menu or run_gr.bat in the /bin
subdir) ... that will set all the Python/etc environment variables up
correctly.  Then you should not need to specify where the UHD images are.

Geof


On Tue, Jul 12, 2016 at 10:11 PM, Derek Kozel  wrote:

> Hi Dave,
>
> Yes, there is no state held in UHD so you will always need to include the
> --args "fw.." in your UHD commands. I should have also mentioned that
> this means you will need to add that exact "fw= D:\Program
> Files\GNURadio-3.7\share\uhd\images\usrp_b100_fw.ihx,fpga= D:\Program
> Files\GNURadio-3.7\share\uhd\images\usrp_b100_fpga.bin" string in the USRP
> Source or Sink block Device Arguments field for any GNU Radio flowgraph.
> You can try modifying the wbfm example for instance.
>
> The ability to specify specific FPGA and firmware images is usually a
> development feature if you have multiple versions of UHD installed
> alongside each other or are building custom images. In this case we are
> using it to get around a path problem.
>
> If you create the D:\Program Files\UHD\share\uhd\images\... folder with
> images UHD will hopefully pick them up automatically. I have not tried a
> Windows install where D is the system drive so I'm unsure of the exact
> behavior.
>
> Ok, I had the wrong python command there, but python itself did run.
> Here's a line which certainly should work, but there's likely nothing
> additional to be gained by running it.
> python -c "import gnuradio; print gnuradio"
>
> Regards,
> Derek
>
> On Tue, Jul 12, 2016 at 7:02 PM, Dave  wrote:
>
>> Derek,
>>
>>
>>
>> I ran rx_samles _*to*_file.  Although using the location arrguments you
>> gave me for uhd_find_devices allows for the B100 to be found it does not
>> look like the knowledge of where the images are located is retained.
>> Running the samles_to_file  command again results in a condition where
>> firmware could not be found.
>>
>>
>>
>> D:\Program Files\GNURadio-3.7\share\uhd\examples>rx_samples_to_file
>>
>> Win32; Microsoft Visual C++ version 14.0; Boost_106000;
>> UHD_003.009.003-0-unknown
>>
>>
>>
>>
>>
>> Creating the usrp device with: ...
>>
>>
>>
>> UHD Warning:
>>
>> Could not locate B100 firmware. As an Administrator, please run:
>>
>> "C:\Program Files\UHD\lib\uhd\utils\uhd_images_downloader.py"
>>
>> Error: LookupError: KeyError: No devices found for ->
>>
>> Empty Device Address
>>
>>
>>
>> I also ran the python command you gave me with the results to follow:
>>
>>
>>
>>
>>
>> D:\Program Files\GNURadio-3.7>python.exe -c "from gruel import pmt; print
>> pmt"
>>
>> Traceback (most recent call last):
>>
>>   File "", line 1, in 
>>
>> ImportError: No module named gruel
>>
>>
>>
>> D:\Program Files\GNURadio-3.7>
>>
>>
>>
>> If there is anything else you want me to run, I will do so.
>>
>>
>>
>> Dave
>>
>>
>>
>> *From:* Derek Kozel [mailto:derek.ko...@ettus.com]
>> *Sent:* Tuesday, July 12, 2016 6:29 PM
>>
>> *To:* Dave
>> *Cc:* GNURadio Discussion List
>> *Subject:* Re: [Discuss-gnuradio] Installation of GNU Radio/UHD on
>> Windows
>>
>>
>>
>> Hi Dave,
>>
>> I'm glad that the B100 was able to be detected. If you want to confirm
>> that it is fully operating you could run any of the examples included with
>> UHD, for instance uhd_benchmark_rate or rx_samples_to_file. These are
>> standalone from GNU Radio so should avoid whatever Python issue may exist.
>>
>> I've just noticed, the UHD version installed is Win32. I'm surprised at
>> this as the GNU Radio binary builds are all 64 bit. If the developer of
>> these Windows binary installers sees the thread hopefully he can comment.
>>
>> GNU Radio is certainly easier to use on Linux or OS X, but there is a
>> desire to see Windows support improve over time. This may not happen
>> quickly, but it's a great sign that binary installers exist at all and I
>> believe that most if not all of the changes which were needed to make that
>> possible are now in the latest releases.
>>
>> The binary installer at the moment includes it's own Python install in
>> order to minimize external dependencies and possible conflicts. I haven't
>> seen the "Stopped working" error before, it would be interesting to find
>> out why. If you have the time and curiosity, could you try running a super
>> simple flow graph such as a signal source into a null sink? This will have
>> minimal complexity and test if GNU Radio runs on it's own without any
>> hardware interactions. The gr_fftw_wisdom warning can be ignored.
>>
>> Can you test the Python install? Here is a very simple command which
>> should execute. I'm on Linux so cannot test it at the moment.
>> python.exe 

Re: [Discuss-gnuradio] installing gnuradio on Windows

[Geof Nieboer]

Mostafa,

I'm not sure why you were not able to download it, I just checked the site
and confirmed the download link is active.  Can you tell me what sort of
error you are getting?

As Gavin mentioned, the scripts really are for the intrepid only at this
point, the windows world is more focused on installers than building from
source.  The scripts will improve over time, but I highly recommend just
using the installer, especially for your first attempt!

Geof


On Thu, Jul 7, 2016 at 3:51 AM, Mostafa Alizadeh 
wrote:

> thank you for your help, but I currently could not download the
> *"gnuradio_3.7.9.2_win64.msi"* file!!
>
>
> why?
>
> Best,
> Mostafa
>
> ***
> Tehran
> IRAN
> Tel: +98 (919) 158-7730
> Emails: m.alizade...@gmail.com, m.alizade...@aut.ac.ir
> Homepage: Linkedin 
>
> ***
>
> On Wed, Jul 6, 2016 at 9:52 PM, Gavin Jacobs 
> wrote:
>
>> Mostafa,
>> Those scripts are torturous. You can now download pre-built gnuradio for
>> windows here:
>> http://www.gcndevelopment.com/gnuradio/downloads.htm
>>
>> i am using those binaries on Windows 10 (64bit) and I can run GnuRadio
>> Companion and GQRX. So far I have not been able to create a new OOT module.
>>
>> If you really want to build from source, you can try the scripts, BUT - I
>> have tried several times and never succeeded. Your milage may vary.
>>
>> Jake
>> > Date: Wed, 6 Jul 2016 19:14:50 +0430
>> > From: Mostafa Alizadeh 
>> > To: discuss-gnuradio@gnu.org
>> > Subject: Re: [Discuss-gnuradio] installing gnuradio on Windows
>> > Message-ID:
>> > 

Re: [Discuss-gnuradio] OOT Block on Windows - barely feasible

[Geof Nieboer]

Gavin,

Thanks for that.  I will include your instructions, and see what I can do
to make it more streamlined.

Geof

On Thu, Jul 7, 2016 at 2:28 PM, Gavin Jacobs 
wrote:

> You may recall that I asked if it was feasible to build an OOT
> module/block for GRC on Windows. To answer my own question, it is barely
> feasible. The folks who created the windows binary package cleared the path
> through the jungle, but they left a lot of breadcrumbs in the resulting
> build. If anyone wants to try, here are my notes - I have been through this
> twice now, but there might be a few mistakes yet.
>
> Prerequisites:
> Windows 64bit 10 (probably works on 8 too)
> VS2010 and VS2015
>
> download and install gnuradio windows binaries 3.7.9.2, 64 bit, "any CPU"
>
> download and install CMAKE 3.3; check PATH afterwards via Control Panel >
> System > Advanced > Environment
>
> download and install BOOST 1.60 windows binaries from 3rd party site;
> destination c:\local\boost_1_60_0
> - set BOOST environment variables via control panel: BOOST_ROOT,
> BOOST_INCLUDEDIR, BOOST_LIBRARYDIR
>
> logout & login to update environment variables
>
> download & build CPPUNIT 1.12 with VS2010, 64bit, Release; sln file is
> here:
>
> http://blogs.powersoft.ca/erict/archive/2012/02/21/cppunit-in-vs2010ndashwith-a-sample.aspx
> BUT BEFORE you build the solution, you have to change the solution to
> x64 and Release
> - copy LIB and INCLUDE subdirectories to c:\local\cppunit_1.12.1
> edit C:\Program
> Files\GNURadio-3.7\share\gnuradio\modtool\gr-newmod\cmake\Modules\findcppunit.cmake
> [NB this will be a nuisance because you can't edit in situ - you have
> to copy the file somewhere, edit, then copy back]
> scroll down to FIND_PATH, down further to PATHS, add line
> C:/local/cppunit_1.12.1/include
>
> in Windows Explorer, navigate to C:\Program
> Files\GNURadio-3.7\share\gnuradio\modtool\gr-newmod\cmake\build
> - delete file: CMakeCache.txt
> - delete subdirectory and all files \CMakeFiles
>
>
> create directory gr-modules for OOT modules (e.g.
> c:\users\{yourname}\documents\gr-modules\
> - copy link to gnuradio command prompt (i.e. from the Start Menu tree)
> edit the link properties to start in the gr-modules directory; use
> this for all modtool invocations
> - create two BAT files to invoke gr-modtool.py as follows:
> @echo off
> REM MT_New.bat
> REM start from GRC Command Prompt in gr-modules directory
> python "C:\Program Files\GNURadio-3.7\bin\gr_modtool.py" newmod
> "--srcdir=C:\Program Files\GNURadio-3.7\share\gnuradio\modtool\gr-newmod"
>
> @echo off
> REM MT_Add.bat
> REM start from GRC Command Prompt, in the directory of your new
> module
> python "C:\Program Files\GNURadio-3.7\bin\gr_modtool.py" add
>
> create new module with modtool; then add block with modtool; edit code;
>
> cd gr-modules\{modulename}\build
> CMAKE ..
> [expect errors if you asked for qa/test code - haven't figured that
> out yet]
>
> copy {modulename}_{blockname}.xml file to C:\Program
> Files\GNURadio-3.7\share\gnuradio\grc\blocks
> copy 2 files: \python\{blockname}.py and __init__.py to C:\Program
> Files\GNURadio-3.7\lib\site-packages\{modulename}\
>
>
> Still todo is fix the qa code errors and work on C++.
> Jake
>
>
>
> ___
> 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] UDP Source Error (on windows)

[Geof Nieboer]

Burak,

The only immediate workaround I see is to patch the source code and rebuild
using the scripts, which is likely not worth the effort for the average
user, unless it's absolutely time critical that you get this working on
windows immediately.

Otherwise I just submitted the patch to jcorgan on the windows branch so I
would prefer to wait until it's included in the next GR release then I will
update the windows installer with that new build.  Removing those two lines
of codes appear to get it to run without error, and I ran a UDP source/sink
through a simple loopback with no issues.

Geof

On Mon, May 23, 2016 at 2:09 PM, Abdil Burak BAŞLI 
wrote:

> Hi,
>
>
>
> I think this fix will be affected at the next release. Is there a
> predetermined time for the next release. Or Is there any workaround to use
> UDP source without error at v3.7.9.2.
>
>
>
> Best regards
>
> Burak.
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Source Error (on windows)

[Geof Nieboer]

Thanks Andy,

I will submit a change to remove this set_option from the udp source then.

Geof

On Thu, May 19, 2016 at 3:59 PM, Andy Walls 
wrote:

> >
> > OK, I was able to reproduce the issue, and it appears to me to a core
> > GNURadio issue not specifically related to the installer
> >
> >
> > udp_source_impl.cc is setting the SO_LINGER option on the UDP socket,
> > which at least on Windows, causes a WSAENOPROTOOPT exception, because
> > linger doesn't really mean anything for a UDP socket.
> >
> >
> > Perhaps the Linux folks can help here, but I'm guessing that this
> > option must be simply ignored on Linux so there is no error for most
> > users.  Looking at the man pages doesn't specify any particular
> > behavior required.
> >
> >
> > Geof
>
>
> SO_LINGER gets processed by the Linux kernel generically here:
>
> http://lxr.free-electrons.com/source/net/core/sock.c#L644
>
> with no check against socket type.
>
> The UDP socket handling doesn't use the resulting SOCK_LINGER flag
> setting.
> http://lxr.free-electrons.com/source/net/ipv4/udp.c
> http://lxr.free-electrons.com/source/net/ipv6/udp.c
>
> Only TCP and the Bluetooth SCO protocol in the Linux kernel care about
> SO_LINGER.
>
> Regards,
> Andy
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP Source Error (on windows)

[Geof Nieboer]

OK, I was able to reproduce the issue, and it appears to me to a core
GNURadio issue not specifically related to the installer

udp_source_impl.cc is setting the SO_LINGER option on the UDP socket, which
at least on Windows, causes a WSAENOPROTOOPT exception, because linger
doesn't really mean anything for a UDP socket.

Perhaps the Linux folks can help here, but I'm guessing that this option
must be simply ignored on Linux so there is no error for most users.
Looking at the man pages doesn't specify any particular behavior required.

Geof



On Tue, May 17, 2016 at 10:29 PM, Geof Nieboer <gnieb...@corpcomm.net>
wrote:

> That's a new one, I will see what I can do to repro.  So the 3.6.4.1 was
> working on the same OS (2008) that 3.7.9.2 is not?
>
> On Tue, May 17, 2016 at 4:24 PM, Abdil Burak BAŞLI <aba...@havelsan.com.tr
> > wrote:
>
>> Hi all,
>>
>>
>>
>> I successfully installed GCN Development GNURadio Win64 Binary
>> (v3.7.9.2/v1.1.1) on to the windows host machine (Windows Storage Server
>> 2012 R2 standard, as you know It is the server version of Windows 8).
>>
>> However while communicating SDR via GNURadio, UDP source gives an
>> following socket connection error:
>>
>>
>>
>> My GNURadio GRC contains following units (I also attached the grc picture
>> to the email):
>>
>>
>>
>> UDP  Source->Ishort To Complex -> WX GUI FFT Sink.
>>
>>
>>
>> The same setup works (connects and get data from SDR over UDP Source)
>> with the previous windows GNURadio installation (3.6.4.1). I installed
>> 3.6.4.1 according to following link. This version works but does not
>> contain some feature as latest does.
>>
>>
>>
>>
>> file:///D:/Downloads/GnuRadioInstall/GNURADIO%20and%20WINDOWS%20_%20Michael%20Margaras%20SV1CAL%20%E2%80%93%20Amateur%20Radio%20and%20Electronics.html
>>
>>
>>
>>
>>
>> The error GCN Development GNURadio Win64 Binary (v3.7.9.2/v1.1.1) gives
>> at below:
>>
>>
>> -
>>
>> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
>> C:\DATA\GnuUDPTransfer\Crimson_grc_src.py
>>
>>
>>
>> Using Volk machine: avx
>>
>> gr::fft: can't import wisdom from C:\UTraceback (most recent call last):
>>
>>   File "C:\DATA\GnuUDPTransfer\Crimson_grc_src.py", line 92, in 
>>
>> main()
>>
>>   File "C:\DATA\GnuUDPTransfer\Crimson_grc_src.py", line 86, in main
>>
>> tb = top_block_cls()
>>
>>   File "C:\DATA\GnuUDPTransfer\Crimson_grc_src.py", line 65, in __init__
>>
>> self.blocks_udp_source_0 = blocks.udp_source(gr.sizeof_short*2,
>> "10.10.10.10", 32820, 1400, True)
>>
>>   File "C:\Program
>> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig5.py", line
>> 2260, in make
>>
>> return _blocks_swig5.udp_source_make(itemsize, host, port,
>> payload_size, eof)
>>
>> RuntimeError: set_option: An unknown, invalid, or unsupported option or
>> level was specified in a getsockopt or setsockopt call
>>
>>
>> -
>>
>>
>>
>> Any help will be appreciated.
>>
>> Best Regards,
>>
>>
>>
>> Burak.
>>
>>
>>
>>
>> Dikkat: Bu elektronik posta mesaji kisisel ve ozeldir. Eger size 
>> gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.Firmamiza 
>> gelen ve giden mesajlar virus taramasindan gecirilmektedir. Mesajdaki 
>> gorusler gondericiye ait olup HAVELSAN A.S. resmi gorusu olmak zorunda 
>> degildir. Attention: This e-mail message is private and privileged.If you 
>> are not the recipient for whom this e-mail message is intended, please 
>> notify the sender immediately and delete this e-mail message from your 
>> system.All sent and received e-mail messages go through a virus scan. Any 
>> opinions presented in this e-mail message are solely those of the author and 
>> do not necessarily represent HAVELSAN A.S.`s formal and authorized views.
>>
>>
>>
>>
>> ___
>> 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] GCN Development GNURadio Win64 Binary (v3.7.9.2/v1.1.1) UDP source connection Problem

[Geof Nieboer]

That's a new one, I will see what I can do to repro.  So the 3.6.4.1 was
working on the same OS (2008) that 3.7.9.2 is not?

On Tue, May 17, 2016 at 4:24 PM, Abdil Burak BAŞLI 
wrote:

> Hi all,
>
>
>
> I successfully installed GCN Development GNURadio Win64 Binary
> (v3.7.9.2/v1.1.1) on to the windows host machine (Windows Storage Server
> 2012 R2 standard, as you know It is the server version of Windows 8).
>
> However while communicating SDR via GNURadio, UDP source gives an
> following socket connection error:
>
>
>
> My GNURadio GRC contains following units (I also attached the grc picture
> to the email):
>
>
>
> UDP  Source->Ishort To Complex -> WX GUI FFT Sink.
>
>
>
> The same setup works (connects and get data from SDR over UDP Source) with
> the previous windows GNURadio installation (3.6.4.1). I installed 3.6.4.1
> according to following link. This version works but does not contain some
> feature as latest does.
>
>
>
>
> file:///D:/Downloads/GnuRadioInstall/GNURADIO%20and%20WINDOWS%20_%20Michael%20Margaras%20SV1CAL%20%E2%80%93%20Amateur%20Radio%20and%20Electronics.html
>
>
>
>
>
> The error GCN Development GNURadio Win64 Binary (v3.7.9.2/v1.1.1) gives at
> below:
>
>
> -
>
> Executing: C:\Program Files\GNURadio-3.7\gr-python27\python.exe -u
> C:\DATA\GnuUDPTransfer\Crimson_grc_src.py
>
>
>
> Using Volk machine: avx
>
> gr::fft: can't import wisdom from C:\UTraceback (most recent call last):
>
>   File "C:\DATA\GnuUDPTransfer\Crimson_grc_src.py", line 92, in 
>
> main()
>
>   File "C:\DATA\GnuUDPTransfer\Crimson_grc_src.py", line 86, in main
>
> tb = top_block_cls()
>
>   File "C:\DATA\GnuUDPTransfer\Crimson_grc_src.py", line 65, in __init__
>
> self.blocks_udp_source_0 = blocks.udp_source(gr.sizeof_short*2,
> "10.10.10.10", 32820, 1400, True)
>
>   File "C:\Program
> Files\GNURadio-3.7\lib\site-packages\gnuradio\blocks\blocks_swig5.py", line
> 2260, in make
>
> return _blocks_swig5.udp_source_make(itemsize, host, port,
> payload_size, eof)
>
> RuntimeError: set_option: An unknown, invalid, or unsupported option or
> level was specified in a getsockopt or setsockopt call
>
>
> -
>
>
>
> Any help will be appreciated.
>
> Best Regards,
>
>
>
> Burak.
>
>
>
>
> Dikkat: Bu elektronik posta mesaji kisisel ve ozeldir. Eger size 
> gonderilmediyse lutfen gondericiyi bilgilendirip mesaji siliniz.Firmamiza 
> gelen ve giden mesajlar virus taramasindan gecirilmektedir. Mesajdaki 
> gorusler gondericiye ait olup HAVELSAN A.S. resmi gorusu olmak zorunda 
> degildir. Attention: This e-mail message is private and privileged.If you are 
> not the recipient for whom this e-mail message is intended, please notify the 
> sender immediately and delete this e-mail message from your system.All sent 
> and received e-mail messages go through a virus scan. Any opinions presented 
> in this e-mail message are solely those of the author and do not necessarily 
> represent HAVELSAN A.S.`s formal and authorized views.
>
>
>
>
> ___
> 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] Portaudio Audio Source in Windows

[Geof Nieboer]

Yes, Wix is pretty flexible in that regard.

It looks like right now some config files are looking in the $HOME
directory and some are looking in the $APPDATA directory, so I think we
should examine thoroughly what is looking where and aim for consistency.

Geof


On Monday, May 9, 2016, Marcus Müller <marcus.muel...@ettus.com> wrote:

> Hi Geof,
>
> is there a chance to manually specify where the config files go in terms
> environment variables? I.e., tell the installer to put what is in
> PREFIX/etc into %APPDATA%?
>
> Best regards,
> Marcus
>
>
> On 09.05.2016 17:37, Geof Nieboer wrote:
>
> Tony, that's good news.
>
> The nice thing is that the environment variables can generally be made as
> relative paths, so I should be able include setting that automatically for
> everyone as part of the msi.  The $home directory is probably the best
> place as Windows doesn't want users changing files in the program files
> directory.
>
> Marcus,
>
> The way the scripts works is the first you describe, it makes a "staged
> install", during the build process, then Wix comes in and scans through
> that directory to create the installation image, including Python.  The key
> to making that work on the other end is the run_gr.bat file that used to
> set that particular environment prior to running any scripts. It sets the
> python path for instance... All based off the directory that the batch file
> is in ($installer_dir/bin)
>
> So any environment variables that gnuradio can use can be set there
> without impacting ( or being impacted by) the result of the system.
>
> Geof
>
> On Monday, May 9, 2016, Tony Richardson <richardson.t...@gmail.com> wrote:
>
>> Thanks Marcus.
>>
>> I just set the environment variable that you mentioned in the run_gr.bat
>> file that Geof mentioned and portaudio now works.  I realize it is not a
>> clean solution, but it is a working one.  I am happy.
>>
>> Tony
>>
>>
>>
>>
>>
>> On Mon, May 9, 2016 at 9:42 AM, Marcus Müller <marcus.muel...@ettus.com>
>> wrote:
>>
>>> Hi Tony,
>>>
>>> to be honest, I'll be rewriting GNU Radio's slightly dated and slightly
>>> ugly preference system, as it seems, so I'm not 100% giving up on this.
>>> So, I hope the spirit of the workaround was clear to you: you can always
>>> manually set this particular setting via python (instead of specifying it
>>> in a configuration file).
>>> The python module "detour" was just an attempt to make that a permanent
>>> feature of the flow graph. Instead, I could have just asked you to add it
>>> pretty far up in the generated top_block.py (or whatever your generated
>>> python file is called). There's also another way of specifying such
>>> settings – environment variables (which under windows are especially little
>>> fun to set...).
>>> You can (as documented in [1]) specify a setting as an environment
>>> variable; in your case, something like
>>>
>>> GR_CONF_audio_audio_module = portaudio
>>>
>>> I know you can configure environment variables *somewhere  *in windows,
>>> but I forget where – my Windows usage is just too rare.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> [1] http://gnuradio.org/doc/doxygen/page_prefs.html
>>>
>>>
>>> On 09.05.2016 14:33, Tony Richardson wrote:
>>>
>>> There appear to be some problems with "python module"s in Windows GRC
>>> too.  I get an error that the editor can't find a particular file.  If I
>>> add the python block in GRC, then have it generate code and add the code to
>>> the corresponding Python file from an external editor - I can then run the
>>> top level Python file from a command prompt and it works!  (Appears to be
>>> using portaudio).
>>>
>>> If I try to execute from GRC it replaces my Python source with a file
>>> containing the line:
>>>
>>># this module will be imported in the into your flowgraph
>>>
>>> and will not run anymore.
>>>
>>> Thanks for your help, but I agree that it is time to give up.
>>>
>>> Tony
>>>
>>>
>>> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller <marcus.muel...@ettus.com>
>>> wrote:
>>>
>>>> Hi Tony,
>>>>
>>>> > The lack of path separators is troubling.
>>>>
>>>> I couldn't agree more. But since that just means that the separator
>>>> get's "eaten&quo

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Geof Nieboer]

Tony, that's good news.

The nice thing is that the environment variables can generally be made as
relative paths, so I should be able include setting that automatically for
everyone as part of the msi.  The $home directory is probably the best
place as Windows doesn't want users changing files in the program files
directory.

Marcus,

The way the scripts works is the first you describe, it makes a "staged
install", during the build process, then Wix comes in and scans through
that directory to create the installation image, including Python.  The key
to making that work on the other end is the run_gr.bat file that used to
set that particular environment prior to running any scripts. It sets the
python path for instance... All based off the directory that the batch file
is in ($installer_dir/bin)

So any environment variables that gnuradio can use can be set there without
impacting ( or being impacted by) the result of the system.

Geof

On Monday, May 9, 2016, Tony Richardson  wrote:

> Thanks Marcus.
>
> I just set the environment variable that you mentioned in the run_gr.bat
> file that Geof mentioned and portaudio now works.  I realize it is not a
> clean solution, but it is a working one.  I am happy.
>
> Tony
>
>
>
>
>
> On Mon, May 9, 2016 at 9:42 AM, Marcus Müller  > wrote:
>
>> Hi Tony,
>>
>> to be honest, I'll be rewriting GNU Radio's slightly dated and slightly
>> ugly preference system, as it seems, so I'm not 100% giving up on this.
>> So, I hope the spirit of the workaround was clear to you: you can always
>> manually set this particular setting via python (instead of specifying it
>> in a configuration file).
>> The python module "detour" was just an attempt to make that a permanent
>> feature of the flow graph. Instead, I could have just asked you to add it
>> pretty far up in the generated top_block.py (or whatever your generated
>> python file is called). There's also another way of specifying such
>> settings – environment variables (which under windows are especially little
>> fun to set...).
>> You can (as documented in [1]) specify a setting as an environment
>> variable; in your case, something like
>>
>> GR_CONF_audio_audio_module = portaudio
>>
>> I know you can configure environment variables *somewhere  *in windows,
>> but I forget where – my Windows usage is just too rare.
>>
>> Best regards,
>> Marcus
>>
>> [1] http://gnuradio.org/doc/doxygen/page_prefs.html
>>
>>
>> On 09.05.2016 14:33, Tony Richardson wrote:
>>
>> There appear to be some problems with "python module"s in Windows GRC
>> too.  I get an error that the editor can't find a particular file.  If I
>> add the python block in GRC, then have it generate code and add the code to
>> the corresponding Python file from an external editor - I can then run the
>> top level Python file from a command prompt and it works!  (Appears to be
>> using portaudio).
>>
>> If I try to execute from GRC it replaces my Python source with a file
>> containing the line:
>>
>># this module will be imported in the into your flowgraph
>>
>> and will not run anymore.
>>
>> Thanks for your help, but I agree that it is time to give up.
>>
>> Tony
>>
>>
>> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller > > wrote:
>>
>>> Hi Tony,
>>>
>>> > The lack of path separators is troubling.
>>>
>>> I couldn't agree more. But since that just means that the separator
>>> get's "eaten" somewhere, and we don't know whether that happens when
>>> generating these paths or just when printing, I'm still full of hope…
>>>
>>> The fact these directories don't exist on my machine (even with
>>> appropriate separators) is more troubling.
>>>
>>> … my hopes being crushed.
>>>
>>> > Is there a way to override the default values?
>>>
>>> Yes, but not at runtime, I'm afraid: The "first" directory a program
>>> looks into for configuration has to be hard-coded somewhere, and in the
>>> case of GNU Radio, it's specified via the GR_PREFSDIR CMake Variable when
>>> building GNU Radio.
>>> That happens in the gnuradio/gnuradio/lib/constants.cc.in file, where
>>> CMake expands the @GR_PREFSDIR@ macro.  The actual setting of that
>>> variable happens in the main gnuradio/CMakeLists.txt, line 165
>>>
>>>set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH 
>>> "System configuration directory" FORCE)
>>>
>>> so we learn that CMAKE_INSTALL_PREFIX was set to
>>> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D
>>>
>>> So that's essentially where I'd have to give up: That code was put there
>>> during build, and I can't change it later.
>>>
>>> What I'll probably do is a bug report about GNU Radio, upon finding the
>>> prefsdir path not to be a directory (in your case: not to exist at all)
>>> giving up and not even trying to read any other paths. I might 

Re: [Discuss-gnuradio] Portaudio Audio Source in Windows

[Geof Nieboer]

Tony,

Getting the Windows audio source to work is on my "to do" list.  I
reworked the sink already, so I don't think it will be difficult to do the
source either.

The hard coded paths are troublesome, as using a Windows installer
that allows users to install in any path they desire after everything has
already been compiled is fundamentally incompatible with hardcoded paths at
compile time.   One potential way to implement Marcus's suggestion might be
to incorporate it into the run_gr.bat file that sets the gnu radio
environment prior to running the python script.

As you probably already surmised, the directories referenced that you
saw are exactly where the build scripts originally built gnuradio prior to
packing it into an .msi.

Geof

On Monday, May 9, 2016, Tony Richardson  wrote:

> There appear to be some problems with "python module"s in Windows GRC
> too.  I get an error that the editor can't find a particular file.  If I
> add the python block in GRC, then have it generate code and add the code to
> the corresponding Python file from an external editor - I can then run the
> top level Python file from a command prompt and it works!  (Appears to be
> using portaudio).
>
> If I try to execute from GRC it replaces my Python source with a file
> containing the line:
>
># this module will be imported in the into your flowgraph
>
> and will not run anymore.
>
> Thanks for your help, but I agree that it is time to give up.
>
> Tony
>
>
> On Mon, May 9, 2016 at 3:45 AM, Marcus Müller  > wrote:
>
>> Hi Tony,
>>
>> > The lack of path separators is troubling.
>>
>> I couldn't agree more. But since that just means that the separator get's
>> "eaten" somewhere, and we don't know whether that happens when generating
>> these paths or just when printing, I'm still full of hope…
>>
>> The fact these directories don't exist on my machine (even with
>> appropriate separators) is more troubling.
>>
>> … my hopes being crushed.
>>
>> > Is there a way to override the default values?
>>
>> Yes, but not at runtime, I'm afraid: The "first" directory a program
>> looks into for configuration has to be hard-coded somewhere, and in the
>> case of GNU Radio, it's specified via the GR_PREFSDIR CMake Variable when
>> building GNU Radio.
>> That happens in the gnuradio/gnuradio/lib/constants.cc.in file, where
>> CMake expands the @GR_PREFSDIR@ macro.  The actual setting of that
>> variable happens in the main gnuradio/CMakeLists.txt, line 165
>>
>>set(SYSCONFDIR "${CMAKE_INSTALL_PREFIX}/${GR_CONF_DIR}" CACHE PATH 
>> "System configuration directory" FORCE)
>>
>> so we learn that CMAKE_INSTALL_PREFIX was set to
>> C:gr-buildsrc-stage3staged_install, plus a few \, probably :D
>>
>> So that's essentially where I'd have to give up: That code was put there
>> during build, and I can't change it later.
>>
>> What I'll probably do is a bug report about GNU Radio, upon finding the
>> prefsdir path not to be a directory (in your case: not to exist at all)
>> giving up and not even trying to read any other paths. I might fix that by
>> allowing users to specify these directories as environment variables; that
>> would make sense to me, but as it kind of changes "logical" API, I'd like
>> to discuss this with a maintainer.
>>
>> I think I might come up with a workaround, however. Again, I haven't
>> tried this, especially not under windows, where the whole "launch an editor
>> and edit that file" aspect might fail, but *shrug*:
>>
>> In your GRC flow graph, add a "python module".
>> There, without indenting, add the following code
>>
>> from gnuradio import gr
>> p = gr.prefs()
>> p.set_string("audio","audio_module","portaudio")
>>
>> and close the editor. Basically, you're setting the configuration option
>> manually for the meantime.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 09.05.2016 04:38, Tony Richardson wrote:
>>
>> The command:
>>
>> gnuradio-config-info --prefsdir --sysconfdir
>>
>> returns
>>
>>   C:gr-buildsrc-stage3staged_installReleaseetc
>>   C:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
>>
>> The lack of path separators is troubling.  The fact these directories
>> don't exist on my machine (even with appropriate separators) is more
>> troubling.  I assume this is why config files in the installed etc
>> directory are not being read.  After using the Windows installer, I have
>> what appear to be corresponding directories here:
>>
>>   C:\Program Files\GNURadio-3.7\etc
>>   C:\Program Files\GNURadio-3.7\etc\gnuradio\conf.d
>>
>> I have a HOME environment variable defined in Windows, so I think GRC is
>> looking in $HOME/.gnuradio for a config.conf file.  Running GRC actually
>> creates a $HOME/.gnuradio directory and places some configuration files in
>> that directory, but doesn't appear to read from it.  I also tried putting a
>> config.conf file in the 

Re: [Discuss-gnuradio] GR win64 binaries v1.1 posted

[Geof Nieboer]

@anon: missing icons is known and for now expected.
@Paul: cppunit 64-bit is built/installed as part of the package.  I have
not yet used it, however.
@james: Excellent, thanks again for the feedback.

Geof


On Thu, May 5, 2016 at 4:03 AM, James C Mankin <n...@psu.edu> wrote:

> Geof,
>
> I just installed v1.1.1 and  gqrx now runs as expected on my system.
>
> Thanks,
> Jim
>
>
>
>
> On 05/04/2016 08:33 PM, Geof Nieboer wrote:
>
> Jim,
>
> I found the problem.  Qt5 threw me a nice curveball.  I've got a fix,
> check back tomorrow for v1.1.1 :(.
>
> Apologies.
>
> Geof
>
> On Wed, May 4, 2016 at 9:56 PM, Geof Nieboer <gnieb...@corpcomm.net>
> wrote:
>
>> Jim,
>>
>> Try dropping the below file in the c:\Program Files\gnuradio-3.7\bin
>> directory and see if it works, or at least if the error changes.  It's a
>> Qt5 platform plugin that did not appear necessary (I only included the Qt5
>> files that appeared needed to keep the size down)
>>
>> Geof
>>
>> On Wed, May 4, 2016 at 8:47 PM, James C Mankin < <n...@psu.edu>n...@psu.edu
>> > wrote:
>>
>>> After uninstalling v1.0 and installing V1.1 , I was not able to run gqrx
>>> under Windows 7.I see a command
>>> line window that says "setting gnuradio environment" and then a pop-up
>>> that says:
>>>
>>>This application failed to start because it could not find or load
>>> the Qt
>>> platform plugin  "windows"
>>> in "".
>>>
>>>Reinstalling the application may fix this problem.
>>>
>>> Otherwise things seem to work OK.
>>>
>>> Jim kb3kj
>>> n...@psu.edu
>>>
>>>
>>> On 05/03/2016 09:05 PM, Geof Nieboer wrote:
>>>
>>> All,
>>>
>>> An updated set of windows binaries and build scripts have been posted.
>>> Quick summary:
>>> 1- Added gqrx to package
>>> 2- Patched 2 x issues which would cause the generic version to crash on
>>> non-AVX systems (one in volk, one in FFTW)
>>> 3- Added gr-newmod to package
>>>
>>> Plus a number of improvements to make the scripts more robust.
>>>
>>> Binaries at <http://www.gcndevelopment.com/gnuradio/downloads.htm>
>>> http://www.gcndevelopment.com/gnuradio/downloads.htm
>>> Scripts at  <https://github.com/gnieboer/GNURadio_Windows_Build_Scripts>
>>> https://github.com/gnieboer/GNURadio_Windows_Build_Scripts
>>>
>>> A couple gqrx known bugs:
>>> 1- Toolbar icons do not appear (our Qt5 issue)
>>> 2- Switching a USRP to another modulation will cause a crash (upstream
>>> UHD)
>>> 3- Switching between a RTL-SDR device and a USRP device will cause a
>>> crash (upstream gqrx)
>>>
>>> Cheers,
>>>
>>> Geof
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> 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