Re: [Discuss-gnuradio] installing gnuradio on Windows

[Mostafa Alizadeh]

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:
> > 
> > Content-Type: text/plain; charset="utf-8"
> >
> > EDIT:
> >
> > After so may trials and searches, I found that the problem resides inside
> > the file:
> 
> >
> > what could I do?
>
>
> > > I tried to install GNURadio with the given instructions in the link
> below:
> > >
> > > https://github.com/gnieboer/gnuradio_windows_build_scripts
> > >
>
>
> ___
> 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] License for libs linked in OOT

[Jan Krämer]

Hey all,

I think I already asked this but I wanted to be sure.

I am asking permission from my employer to rewrite some of our GPU SDR
blocks
as a GNURadio OOT. Now they asked me to provide a list of possible licenses
for our code.

I think the GNURadio OOT block glue has to be GPLv3 in any case and that is
fine. But let's say GPLv3 would not be the best option for me to propose as
the license for our code.
But if I dynamically link the OOT code against our lib, it should be fine
for me to use a GPL compatible license (basically everything that is marked
green in [1]) such as modified BSD or Apache2.0. Am I right there?

Cheers and thanks for the help,
Jan

[1] https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] License for libs linked in OOT

[Sylvain Munaut]

> I think the GNURadio OOT block glue has to be GPLv3 in any case and that is
> fine.

Why ?

As long as the license is GPLv3 compatible you can publish it under
what you like.
Now of course when re-distributed as binary/complete system, the
effective license will be GPLv3 because the gplv3 compatibility often
uses the "sub-licence" clause to be compatible ...

But if someone wants to extract parts of your code he can do that and
use it as whatever license you used. Same thing if they somehow
re-implement an API compatble runtime that doesn't rely on gpl code
for instance.

And that obviously applies to whatever lib you use as well. (Actually
if that lib is "standalone" and not tied to GR in anyway, it's
probably not considered a "derivative work" and so it can be any
license you like, doesn't even need to be GPL compatible, but that may
prevent binary distributions though depending on details)

(Of course IANAL ... but I'm pretty sure of what I'm saying at least in the EU).

Cheers,

Sylvain

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

Re: [Discuss-gnuradio] License for libs linked in OOT

[Jan Krämer]

Hey Silvain,

I think I talked to Tom about this some years ago, and he stated that the
GNURadio OOT block code has to be GPLv3 or at least a compatible license.
Because that for sure is a derivative work. But you might be right that it
does not need to be strictly GPLv3 and Tom might have also stated exactly
that and I just don't remember.
But thanks for the answer, it makes my attempts to push for FOSS at work a
lot easier (Not using GPLv3 cause it is considered evil here :/).

Cheers,
Jan

2016-07-07 11:43 GMT+02:00 Sylvain Munaut <246...@gmail.com>:

> > I think the GNURadio OOT block glue has to be GPLv3 in any case and that
> is
> > fine.
>
> Why ?
>
> As long as the license is GPLv3 compatible you can publish it under
> what you like.
> Now of course when re-distributed as binary/complete system, the
> effective license will be GPLv3 because the gplv3 compatibility often
> uses the "sub-licence" clause to be compatible ...
>
> But if someone wants to extract parts of your code he can do that and
> use it as whatever license you used. Same thing if they somehow
> re-implement an API compatble runtime that doesn't rely on gpl code
> for instance.
>
> And that obviously applies to whatever lib you use as well. (Actually
> if that lib is "standalone" and not tied to GR in anyway, it's
> probably not considered a "derivative work" and so it can be any
> license you like, doesn't even need to be GPL compatible, but that may
> prevent binary distributions though depending on details)
>
> (Of course IANAL ... but I'm pretty sure of what I'm saying at least in
> the EU).
>
> Cheers,
>
> Sylvain
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] License for libs linked in OOT

[Michael Dickens]

What Sylvain wrote is correct: if you publish your GR OOT module, then
you have to choose GPLv3 or a compatible FOSS license. I believe that by
default the license is GPLv3, since that's what GR is. See also <
http://www.gnu.org/licenses/license-list.html > for a list of compatible
(and incompatible) licenses. - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] License for libs linked in OOT

[Jan Krämer]

Thanks Michael, now fingers crossed that I am allowed to publish the code
under one of those licenses.

Cheers,
Jan

2016-07-07 12:18 GMT+02:00 Michael Dickens :

> What Sylvain wrote is correct: if you publish your GR OOT module, then you
> have to choose GPLv3 or a compatible FOSS license. I believe that by
> default the license is GPLv3, since that's what GR is. See also <
> http://www.gnu.org/licenses/license-list.html > for a list of compatible
> (and incompatible) licenses. - 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

Re: [Discuss-gnuradio] UHD FW Issue for NI USRP 2943R

[mleech]

You wanted to use the packaged Gnu Radio, which packages UHD 3.9.3, so,
that header show the correct version coming out of the UHD version that
is packaged with the GNu Radio package for windows. 

I asked you to remove the UHD 3.9.4 package that you'd installed
separately, because it was in conflict with the Gnu Radio install. 

On 2016-07-07 09:55, Sanat Kumar Mishra wrote:

> Hello,
> 
> Any uüdate on the below issue??
> 
> Now the link is not getting establisged to flash the images.
> 
> Regards,
> Sanat
> 
> Zitat von Sanat Kumar Mishra :
> 
> Hi again,
> 
> So this means that usrp_x310_fpga_HGS.lvbitx icludes both FW and FPGA image?
> 
> and we also still see the error of  "Win32; Microsoft Visual C++  version 
> 14.0; Boost_106000; UHD_003.009.003-0-unknown" even I have deleted the 
> standalone UHD 3.9.4

Best Regards,
Sanat

Quoting mle...@ripnet.com:

> X3xx images include both firmware and FPGA cod.e
> 
> On 2016-07-06 12:10, Sanat Kumar Mishra wrote:
> 
>> We have unistalled the UHD 3.9.4 and flashed the image of UHD   available 
>> with the GNUradio which is:
>> 
>> C:\Program Files\GNURadio-3.7\share\uhd\images\usrp_x310_fpga_HGS.lvbitx
>> 
>> my question, does this image include the FW and the FPGA together  as I  
>> have no option for standalone FW for the
>> x310 ?
>> 
>> Thank you for help
>> Sanat.
>> 
>> Quoting mle...@ripnet.com:
>> 
>> The installer that you used to install GNU RADIO *includes* UHD.  You
>> now have newer UHD interspersed with the version that came bundled with
>> your GnuRadio install.
>> 
>> On 2016-07-05 11:33, Sanat Kumar Mishra wrote:
>> 
>> UHD 3.9.36 is the latestv version of USRP Hardware Driver   available.  If I 
>> uninstall it then what do you recomend me to use   because as per  my 
>> understanding I need UHD to communicate with   USRP using GNU Radio.
>> 
>> Quoting mle...@ripnet.com:
>> 
>> The windows installer from that site seems to have been linked against
>> UHD 3.9.3, which is why the mismatch. There was no reason to have
>> separately installed UHD, since UHD is listed as a package that is
>> bundled into the installer.
>> 
>> I would remove the 3.9.4 UHD you have if you plan to use Gnu Radio
>> extensively, and the person who builds these windows releases will, at
>> some point, update the packaged UHD to 3.9.4 (or later).
>> 
>> On 2016-07-05 11:19, Sanat Kumar Mishra wrote:
>> 
>> Hi,
>> 
>> As suggested, I am putting the below mail in the discuss gnuradio list. 
>> I installed gnu radio from
>> http://www.gcndevelopment.com/gnuradio/downloads.htm
>> 64-Bit Any CPU - v3.7.9.2/v1.1.1.
>> 
>> I first Installed GNU radio and then Installed the UHD. Will that might 
>> be a reason for the below mentioned problem??
>> 
>> Best Regards,
>> Sanat
>> 
>> 
>> Not sure why you're getting the communication failtures, but your device
>> appears, from the uhd_usrp_probe output to be functioning correctly.
>> 
>> I suspect that your Gnu Radio installed was linked against UHD 3.9.3,
>> which is why the apparent version mismatch, because clearly, your
>> uhd_usrp_probe is linked against the newer library.
>> 
>> How did you install Gnu Radio?  This part of the discussion should
>> probably be continued on the discuss-gnuradio mailing list.
>> 
>> On 2016-07-05 10:58, Sanat Kumar Mishra wrote:
>> I have got the following results: Please note I am using NI USRP2943R   
>> which is like x310 from specification.
>> 
>> Microsoft Windows [Version 6.1.7601]
>> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
>> 
>> C:\Users\smishra>uhd_usrp_probe --args resource=RIO0
>> Win32; Microsoft Visual C++ version 14.0; Boost_105800;  
>> UHD_003.009.004-release
>> 
>> UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw poke32 - operation timed out
>> 
>> UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw poke32 - operation timed out
>> -- X300 initialization sequence...
>> -- Connecting to niusrpriorpc at localhost:5444...
>> -- Using LVBITX bitfile C:\Program Files  
>> (x86)\UHD\share\uhd\images\usrp_x310_fp
>> ga_HGS.lvbitx...
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Detecting internal GPSDO No GPSDO found
>> -- Initialize Radio0 control...
>> -- Performing register loopback test... pass
>> -- Initialize Radio1 control...
>> -- Performing register loopback test... pass
>> _
>> /
>> |   Device: X-Series Device
>> | _
>> |/
>> |   |   Mboard: X310
>> |   |   revision: 8
>> |   |   revision_compat: 7
>> |   |   product: 30813
>> |   |   mac-addr0: 00:80:2f:25:18:f9
>> |   |   mac-addr1: 00:80:2f:25:18:fa
>> |   |   gateway: 192.168.10.1
>> |   |   ip-addr0: 192.168.10.2
>> |   |   sub

Re: [Discuss-gnuradio] License for libs linked in OOT

[Ben Hilburn]

Hi Jan -

If you have any further questions regarding licenses as they pertain to GNU
Radio, feel free to e-mail me directly. I'm happy to answer questions &
help.

Thanks to Sylvain and MLD for providing great answers!

Cheers,
Ben

On Thu, Jul 7, 2016 at 9:18 AM, Jan Krämer  wrote:

> Thanks Michael, now fingers crossed that I am allowed to publish the code
> under one of those licenses.
>
> Cheers,
> Jan
>
> 2016-07-07 12:18 GMT+02:00 Michael Dickens :
>
>> What Sylvain wrote is correct: if you publish your GR OOT module, then
>> you have to choose GPLv3 or a compatible FOSS license. I believe that by
>> default the license is GPLv3, since that's what GR is. See also <
>> http://www.gnu.org/licenses/license-list.html > for a list of compatible
>> (and incompatible) licenses. - 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

Re: [Discuss-gnuradio] License for libs linked in OOT

[Martin Braun]

Jan,

also, don't forget, code you write is yours. You can even have multiple
licenses for the same code (at least for modules and parts that don't
use GNU Radio or other GPL'd libraries).

Cheers,
Martin

On 07/07/2016 06:18 AM, Jan Krämer wrote:
> Thanks Michael, now fingers crossed that I am allowed to publish the
> code under one of those licenses.
> 
> Cheers,
> Jan
> 
> 2016-07-07 12:18 GMT+02:00 Michael Dickens  >:
> 
> __
> What Sylvain wrote is correct: if you publish your GR OOT module,
> then you have to choose GPLv3 or a compatible FOSS license. I
> believe that by default the license is GPLv3, since that's what GR
> is. See also < http://www.gnu.org/licenses/license-list.html > for a
> list of compatible (and incompatible) licenses. - 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

Re: [Discuss-gnuradio] Getting Time Stamps From an x310 in C++

[Martin Braun]

On 07/06/2016 11:34 PM, Robert Kraml wrote:
> Thank you Martin.
> 
> This one looks like it will involve some research.  If I have time I'll
> pursue it.  In the meantime if anyone has some C++ example code that
> shows how an application might extract time tags, I would be grateful.

The header_payload_demux does literally exactly that. In C++.

M
> 
> -Bob
> 
> On 7/6/2016 5:58 PM, Martin Braun wrote:
>> USRPs will only output timestamps at the beginning of streaming, or when
>> time skips (e.g. after an overrun). You can keep track of time by
>> counting samples in between timestamp tags.
>>
>> See the header_payload_demux block for an example of how to keep track
>> of time. Also, check out the gr-uhd manual for an explanation of the
>> tags it uses, e.g.
>> http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__source.html.
>> M
>>
>> On 07/06/2016 04:27 PM, Robert Kraml wrote:
>>> I have a C++ implemented flow-graph that acquires 3 channels at a sample
>>> rate of 5 MHz.  There are a couple of decimation stages with the
>>> resultant n a number of 250 Hz output channels.  How is the best way to
>>> access the associated time stamps.  I wouldn't need every time stamp,
>>> just perhaps one every second or so and the rest would be interpolated.
>>> Might there be some c++ examples of how this would be best done?
>>>
>>> -Bob
>>>
>>>
>>> ___
>>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install on Ubuntu 16.04

[Martin Braun]

On 07/06/2016 11:53 PM, Dave wrote:
> Thanks Martin.  I have changed my subscription to individual messages.
> 
> I ran the command you mentioned below and attached the result.  I’m not
> sure if I should delete all the entries listed or even why I get all the
> “permission denied” messages.  As you will see I executed the command
> both with and without “sudo”.
> 
> dave@MintJulips:~$ find / -name multi_usrp.hpp
> 
> find: ‘/sys/kernel/debug’: Permission denied
> 
> /usr/include/uhd/usrp/multi_usrp.hpp

Here's the culprit. You still have an old UHD installed. Remove that and
start from scratch.

M


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

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

[Gavin Jacobs]

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

Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install on Ubuntu 16.04

[Dave]

Thanks Martin.

I successfully deleted UHD and I believe successfully installed gnuradio et
el using pybombs.  I then ran setup_env.sh.

However now I cannot seem to connect to the B100.

I ran uhd_find_devices and followed the instructions to download images as
per the transcript that follows.  Was PyBombs supposed to take care of
downloading the images?  If not, it seems the pybombs instructions should
tell one to do so.

In any event per the following transcript it now appears I have a permission
issue to access my USB ports.Any advice as to what to do next?

Thanks,  Dave

Transcript of error follows.

dave@MintJulips:~/pybombsprefix1$ . ./setup_env.sh

dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices
linux; GNU C++ version 5.3.1 20160413; Boost_105800;
UHD_003.010.000.git-0-ef57ffcb


UHD Warning:
Could not locate B100 firmware. Please run:

"/home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py"
No UHD Devices Found
dave@MintJulips:~/pybombsprefix1/bin$
/home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py
Images destination:
/home/dave/pybombsprefix1/share/uhd/images
Downloading images from:
http://files.ettus.com/binaries/images/uhd-images_003.010.git-197-g053111dc.
zip
Downloading images to:
/tmp/tmpi2vldX/uhd-images_003.010.git-197-g053111dc.zip
52600 kB / 52600 kB (100%)

Images successfully installed to:
/home/dave/pybombsprefix1/share/uhd/images
dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices
linux; GNU C++ version 5.3.1 20160413; Boost_105800;
UHD_003.010.000.git-0-ef57ffcb


UHD Error:
USB open failed: insufficient permissions.
See the application notes for your device.
No UHD Devices Found

End of transcript...


-Original Message-
From: Discuss-gnuradio
[mailto:discuss-gnuradio-bounces+davidcbasham=msn@gnu.org] On Behalf Of
Martin Braun
Sent: Thursday, July 07, 2016 10:05 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager
Install on Ubuntu 16.04

On 07/06/2016 11:53 PM, Dave wrote:
> Thanks Martin.  I have changed my subscription to individual messages.
> 
> I ran the command you mentioned below and attached the result.  I'm 
> not sure if I should delete all the entries listed or even why I get 
> all the "permission denied" messages.  As you will see I executed the 
> command both with and without "sudo".
> 
> dave@MintJulips:~$ find / -name multi_usrp.hpp
> 
> find: '/sys/kernel/debug': Permission denied
> 
> /usr/include/uhd/usrp/multi_usrp.hpp

Here's the culprit. You still have an old UHD installed. Remove that and
start from scratch.

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] Issues with Pybombs and Package Manager Install on Ubuntu 16.04

[Derek Kozel]

Hello Dave,

Here are the instructions for setting up USB permissions on Linux.
http://files.ettus.com/manual/page_transport.html#transport_usb_udev

Regards,
Derek

On Thu, Jul 7, 2016 at 2:19 PM, Dave  wrote:

> Thanks Martin.
>
> I successfully deleted UHD and I believe successfully installed gnuradio
> et el using pybombs.  I then ran setup_env.sh.
>
> However now I cannot seem to connect to the B100.
>
> I ran uhd_find_devices and followed the instructions to download images as
> per the transcript that follows.  Was PyBombs supposed to take care of
> downloading the images?  If not, it seems the pybombs instructions should
> tell one to do so.
>
> In any event per the following transcript it now appears I have a
> permission issue to access my USB ports.Any advice as to what to do
> next?
>
> Thanks,  Dave
>
>Transcript of error follows.
>
>   dave@MintJulips:~/pybombsprefix1$ . ./setup_env.sh
>
>   dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices
>
>   linux; GNU C++ version 5.3.1 20160413; Boost_105800;
>   UHD_003.010.000.git-0-ef57ffcb
>
>   UHD Warning:
>
>   Could not locate B100 firmware. Please run:
>
>
>   "/home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py"
>
>   No UHD Devices Found
>
>   dave@MintJulips:~/pybombsprefix1/bin$
>   /home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py
>
>   Images destination:  /home/dave/pybombsprefix1/share/uhd/images
>
>   Downloading images from:
>   
> http://files.ettus.com/binaries/images/uhd-images_003.010.git-197-g053111dc.zip
>
>   Downloading images to:
>   /tmp/tmpi2vldX/uhd-images_003.010.git-197-g053111dc.zip
>
>   52600 kB / 52600 kB (100%)
>
>   Images successfully installed to:
>   /home/dave/pybombsprefix1/share/uhd/images
>
>   dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices
>
>   linux; GNU C++ version 5.3.1 20160413; Boost_105800;
>   UHD_003.010.000.git-0-ef57ffcb
>
>   UHD Error:
>
>   USB open failed: insufficient permissions.
>
>   See the application notes for your device.
>
>   No UHD Devices Found
>
>   End of transcript...
>
> -Original Message-
> From: Discuss-gnuradio [
> mailto:discuss-gnuradio-bounces+davidcbasham=msn@gnu.org
> ] On Behalf Of
> Martin Braun
> Sent: Thursday, July 07, 2016 10:05 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager
> Install on Ubuntu 16.04
>
> On 07/06/2016 11:53 PM, Dave wrote:
>
> > Thanks Martin.  I have changed my subscription to individual messages.
>
> >
>
> > I ran the command you mentioned below and attached the result.  I’m
>
> > not sure if I should delete all the entries listed or even why I get
>
> > all the “permission denied” messages.  As you will see I executed the
>
> > command both with and without “sudo”.
>
> >
>
> > dave@MintJulips:~$ find / -name multi_usrp.hpp
>
> >
>
> > find: ‘/sys/kernel/debug’: Permission denied
>
> >
>
> > /usr/include/uhd/usrp/multi_usrp.hpp
>
> Here's the culprit. You still have an old UHD installed. Remove that and
> start from scratch.
>
> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Process for relinquishing driver control in a flowgraph before starting a new one

[Tim Castiglia]

First I should give some context on my project. What we are trying to build
is a python server that utilizes gnuradio's blocks to get information from
hardware and send it outbound, as well as receiving requests from clients
to the server about configuration of flowgraph. More specifically, right
now, I have:

Oscom Source -->Log Power FFT --> Vector Probe

For simplicity, I am using the RTL-SDR for testing purposes. In the future,
we will be using our own device driver created within the SoapySDR
framework, hence why we are using the oscom block.

The problem starts with the fact that this may not be the only flowgraph we
utilize. The hardware we are using may start pumping out FFT values instead
of IQ values. Which means we would need a flowgraph that looks more like:

Oscom Source --> Vector Probe
(Ignore the fact that this is not possible with the oscom block currently,
we will cross that bridge in the future)

So I need to be able to stop my current running flowgraph, and start a new
one. This is where I run into trouble. I can stop my flowgraph perfectly
fine with:

flowgraph.stop()
flowgraph.wait()
time.sleep(5)

But I would like to keep the variable the same in my python code even when
I change the flowgraph. So I try:

flowgraph = newFlowgraphConstructor()

But this causes a python error at the flowgraph.stop() line: "variable
mentioned before instantiated"

To get around this, I made a resetFlowgraph function:
def resetFlowgraph():
flowgraph = newFlowgraphConstructor()
flowgraph.start()

and call things in this order:
flowgraph.stop()
flowgraph.wait()
time.sleep(5)
resetFlowgraph()

The flowgraph starts successfully, but fails to "claim" the RTL-SDR from
the old flowgraph. I have also tried the same with only my device plugged
in, and a similar problem occurs. Is there a way to force the flowgraph to
relinquish its hold on the hardware? Our python server code needs to
continue running, so I need to be able to do this restart without ending
the program (The idea is to have the server always be running and not be
manned most of the time).

Here's some pseudo code to give you an idea of how the code is structured:

#First I have a premade object generated from gnuradio-companion
#I import that object into my server code
import flowgraphInit from flowgraph
#I can also import my other flowgraph
import newFlowgraphConstructor from flowgraph2

#At global level
flowgraph = flowgraphInit()
flowgraph.start()

class ClientSocketConnection
...#init and other functions
def onMessage(payload):
#Parse message
#If we need to change to a different flowgraph
flowgraph.stop()
flowgraph.wait()
time.sleep(5)
resetFlowgraph()

def resetFlowgraph():
flowgraph = newFlowgraphConstructor()
flowgraph.start()

def main():
#create socket factory so we can allow many connections
#So there is only one flowgraph, but many people can see it and
potentially change it

(I have seen this question asked before here
https://lists.gnu.org/archive/html/discuss-gnuradio/2014-01/msg00411.html
but there was no solution in the thread)

Any help is appreciated!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install on Ubuntu 16.04

[Dave]

Thanks Derek and Martin.

 

I followed the instructions regarding permission access to USB.  I’m not 
positive but I think I had to rerun setup_env.sh as well.   Now 
uhd_find_devices functions as expected.  Thanks you.  I ran the 
uhd_wbfm_receive flow graph.  At first I did not get any audio.  I don’t know 
why but looking in my sound settings, the audio was going to Digital Output 
rather than Headphones output (never did that before).  You will see at the 
bottom of the transcript below  that there are UHD warnings  and an 
“Environment Error” but it is not clear to me if I need to address them.  I 
will do more homework.

 

One more question however, should I run volk_profile or did the pybombs install 
already take care of that?

 

One more comment, it seemed previously I could just type the python script 
names our click on a script in my file manager.  Now I need to precede the 
scripts with ./ and clicking on scripts in the file manager no longer executes 
them.  Again I will do more homework on my own.

 

Thanks again for all your help.


Dave

 

Generating: 
'/home/dave/pybombsprefix1/share/gnuradio/examples/uhd/uhd_wbfm_receive.py'

Executing: /usr/bin/python2 -u 
/home/dave/pybombsprefix1/share/gnuradio/examples/uhd/uhd_wbfm_receive.py

linux; GNU C++ version 5.3.1 20160413; Boost_105800; 
UHD_003.010.000.git-0-ef57ffcb

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

-- 

UHD Warning:

Unable to set the thread priority. Performance may be negatively affected.

Please see the general application notes in the manual for instructions.

EnvironmentError: OSError: error in pthread_setschedparam

gr::log :INFO: audio source - Audio sink arch: alsa

Volk warning: no arch found, returning generic impl

 

 

 

 

 

From: Derek Kozel [mailto:derek.ko...@ettus.com] 
Sent: Thursday, July 07, 2016 2:58 PM
To: Dave
Cc: Martin Braun; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install 
on Ubuntu 16.04

 

Hello Dave,

Here are the instructions for setting up USB permissions on Linux.
http://files.ettus.com/manual/page_transport.html#transport_usb_udev

Regards,

Derek

 

On Thu, Jul 7, 2016 at 2:19 PM, Dave  wrote:

Thanks Martin.

I successfully deleted UHD and I believe successfully installed gnuradio et el 
using pybombs.  I then ran setup_env.sh.

However now I cannot seem to connect to the B100.

I ran uhd_find_devices and followed the instructions to download images as per 
the transcript that follows.  Was PyBombs supposed to take care of downloading 
the images?  If not, it seems the pybombs instructions should tell one to do so.

In any event per the following transcript it now appears I have a permission 
issue to access my USB ports.Any advice as to what to do next?

Thanks,  Dave

Transcript of error follows.

dave@MintJulips:~/pybombsprefix1$ . ./setup_env.sh

dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices

linux; GNU C++ version 5.3.1 20160413; Boost_105800; 
UHD_003.010.000.git-0-ef57ffcb

 

UHD Warning:

Could not locate B100 firmware. Please run:

 "/home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py"

No UHD Devices Found

dave@MintJulips:~/pybombsprefix1/bin$ 
/home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py

Images destination:  /home/dave/pybombsprefix1/share/uhd/images

Downloading images from: 
http://files.ettus.com/binaries/images/uhd-images_003.010.git-197-g053111dc.zip

Downloading images to:   /tmp/tmpi2vldX/uhd-images_003.010.git-197-g053111dc.zip

52600 kB / 52600 kB (100%)

Images successfully installed to: /home/dave/pybombsprefix1/share/uhd/images

dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices

linux; GNU C++ version 5.3.1 20160413; Boost_105800; 
UHD_003.010.000.git-0-ef57ffcb

 

UHD Error:

USB open failed: insufficient permissions.

See the application notes for your device.

No UHD Devices Found

End of transcript...

-Original Message-
From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+davidcbasham=msn@gnu.org] On Behalf Of 
Martin Braun
Sent: Thursday, July 07, 2016 10:05 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install 
on Ubuntu 16.04

On 07/06/2016 11:53 PM, Dave wrote:

> Thanks Martin.  I have changed my subscription to individual messages.

> 

> I ran the command you mentioned below and attached the result.  I’m 

> not sure if I should delete all the entries listed or even why I get 

> all the “permission denied” messages.  As you will see I executed the 

> command both with and without “sudo”.

> 

> dave@MintJulips:~$ find / -name multi_usrp.hpp

> 

> find: ‘/sys/kernel/debug’: Permission denied

> 

> /usr/include/uhd/usrp/

Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager Install on Ubuntu 16.04

[Martin Braun]

Dave,

if you've fixed one issue, please start a new thread for the next issue.
As for your q's:

On 07/07/2016 04:37 PM, Dave wrote:
> One more question however, should I run volk_profile or did the pybombs
> install already take care of that?

pybombs does not run volk_profile for you (it used to do that; we'll
need some clean way to reenable that).

> One more comment, it seemed previously I could just type the python
> script names our click on a script in my file manager.  Now I need to
> precede the scripts with ./ and clicking on scripts in the file manager
> no longer executes them.  Again I will do more homework on my own.

The ./ is necessary for files not in your path. The file manager thing
probably fails because the PyBOMBS environment is not available for the
file manager.

M

> 
>  
> 
> Thanks again for all your help.
> 
> 
> Dave
> 
>  
> 
> Generating:
> '/home/dave/pybombsprefix1/share/gnuradio/examples/uhd/uhd_wbfm_receive.py'
> 
> Executing: /usr/bin/python2 -u
> /home/dave/pybombsprefix1/share/gnuradio/examples/uhd/uhd_wbfm_receive.py
> 
> linux; GNU C++ version 5.3.1 20160413; Boost_105800;
> UHD_003.010.000.git-0-ef57ffcb
> 
> -- 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
> 
> -- 
> 
> UHD Warning:
> 
> Unable to set the thread priority. Performance may be negatively affected.
> 
> Please see the general application notes in the manual for instructions.
> 
> EnvironmentError: OSError: error in pthread_setschedparam
> 
> gr::log :INFO: audio source - Audio sink arch: alsa
> 
> Volk warning: no arch found, returning generic impl
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> *From:*Derek Kozel [mailto:derek.ko...@ettus.com]
> *Sent:* Thursday, July 07, 2016 2:58 PM
> *To:* Dave
> *Cc:* Martin Braun; GNURadio Discussion List
> *Subject:* Re: [Discuss-gnuradio] Issues with Pybombs and Package
> Manager Install on Ubuntu 16.04
> 
>  
> 
> Hello Dave,
> 
> Here are the instructions for setting up USB permissions on Linux.
> http://files.ettus.com/manual/page_transport.html#transport_usb_udev
> 
> Regards,
> 
> Derek
> 
>  
> 
> On Thu, Jul 7, 2016 at 2:19 PM, Dave  > wrote:
> 
> Thanks Martin.
> 
> I successfully deleted UHD and I believe successfully installed gnuradio
> et el using pybombs.  I then ran setup_env.sh.
> 
> However now I cannot seem to connect to the B100.
> 
> I ran uhd_find_devices and followed the instructions to download images
> as per the transcript that follows.  Was PyBombs supposed to take care
> of downloading the images?  If not, it seems the pybombs instructions
> should tell one to do so.
> 
> In any event per the following transcript it now appears I have a
> permission issue to access my USB ports.Any advice as to what to do
> next?
> 
> Thanks,  Dave
> 
> Transcript of error follows.
> 
> dave@MintJulips:~/pybombsprefix1$ . ./setup_env.sh
> 
> dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices
> 
> linux; GNU C++ version 5.3.1 20160413; Boost_105800;
> UHD_003.010.000.git-0-ef57ffcb
> 
>  
> 
> UHD Warning:
> 
> Could not locate B100 firmware. Please run:
> 
>  "/home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py"
> 
> No UHD Devices Found
> 
> dave@MintJulips:~/pybombsprefix1/bin$
> /home/dave/pybombsprefix1/lib/uhd/utils/uhd_images_downloader.py
> 
> Images destination:  /home/dave/pybombsprefix1/share/uhd/images
> 
> Downloading images from:
> http://files.ettus.com/binaries/images/uhd-images_003.010.git-197-g053111dc.zip
> 
> Downloading images to:  
> /tmp/tmpi2vldX/uhd-images_003.010.git-197-g053111dc.zip
> 
> 52600 kB / 52600 kB (100%)
> 
> Images successfully installed to: /home/dave/pybombsprefix1/share/uhd/images
> 
> dave@MintJulips:~/pybombsprefix1/bin$ uhd_find_devices
> 
> linux; GNU C++ version 5.3.1 20160413; Boost_105800;
> UHD_003.010.000.git-0-ef57ffcb
> 
>  
> 
> UHD Error:
> 
> USB open failed: insufficient permissions.
> 
> See the application notes for your device.
> 
> No UHD Devices Found
> 
> End of transcript...
> 
> -Original Message-
> From: Discuss-gnuradio
> [mailto:discuss-gnuradio-bounces+davidcbasham=msn@gnu.org] On Behalf
> Of Martin Braun
> Sent: Thursday, July 07, 2016 10:05 AM
> To: discuss-gnuradio@gnu.org 
> Subject: Re: [Discuss-gnuradio] Issues with Pybombs and Package Manager
> Install on Ubuntu 16.04
> 
> On 07/06/2016 11:53 PM, Dave wrote:
> 
>> Thanks Martin.  I have changed my subscription to individual messages.
> 
>> 
> 
>> I ran the command you mentioned below and attached the result.  I’m 
> 
>> not sure if I should delete all the entries listed or even why I get 
> 
>> all the “permission denied” messages.  As you will see I executed the 
> 
>

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] 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:
>> > 
>> > Content-Type: text/plain; charset="utf-8"
>> >
>> > EDIT:
>> >
>> > After so may trials and searches, I found that the problem resides
>> inside
>> > the file:
>> 
>> >
>> > what could I do?
>>
>>
>> > > I tried to install GNURadio with the given instructions in the link
>> below:
>> > >
>> > > https://github.com/gnieboer/gnuradio_windows_build_scripts
>> > >
>>
>>
>> ___
>> 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] random phase offset constantly changing with octoclock setup

[mleech]

Is this an Octoclock, or Octoclock-G? 

If it's just an Octoclock, then it has no internal clocks, and acts as a
high-quality clock/pps distributor. 

I notice you don't have the external clock inputs connected to anything,
and there's no GPS LOCK indicator. 

On 2016-07-07 17:08, Pavan Yedavalli wrote:

> Hi Marcus,
> 
> I did what you suggested by wrapping the timed commands as follows:
> 
> For the TX side (what you sent me in for_pavan.py):
> 
> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
> now = self.uhd_usrp_source_0.get_time_now()
> start_time = now + uhd.time_spec(.5)
> self.uhd_usrp_source_0.set_command_time(start_time)
> self.uhd_usrp_source_0.set_clock_source("external", 0)
> self.uhd_usrp_source_0.set_time_source("external", 0)
> self.uhd_usrp_source_0.set_clock_source("external", 1)
> self.uhd_usrp_source_0.set_time_source("external", 1)
> self.uhd_usrp_source_0.set_samp_rate(samp_rate)
> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 0)
> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 0)
> self.uhd_usrp_source_0.set_antenna(Antenna_sel, 0)
> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 1)
> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 1)
> self.uhd_usrp_source_0.set_antenna("TX/RX", 1)
> self.uhd_usrp_source_0.clear_command_time()
> 
> And for the RX side (B210_Phase_Viewer.py):
> 
> self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec())
> now = self.uhd_usrp_sink_0.get_time_now()
> start_time = now + uhd.time_spec(.5)
> self.uhd_usrp_sink_0.set_command_time(start_time)
> self.uhd_usrp_sink_0.set_clock_source("external", 0)
> self.uhd_usrp_sink_0.set_time_source("external", 0)
> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 0)
> self.uhd_usrp_sink_0.set_clock_source("external", 1)
> self.uhd_usrp_sink_0.set_time_source("external", 1)
> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 1)
> self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
> self.uhd_usrp_sink_0.set_center_freq(915e6, 0)
> self.uhd_usrp_sink_0.set_gain(1.5, 0)
> self.uhd_usrp_sink_0.set_center_freq(915e6, 1)
> self.uhd_usrp_sink_0.set_gain(1.5, 1)
> self.uhd_usrp_sink_0.clear_command_time()
> 
> However, it still does not work when I have the phase viewer running and stop 
> and restart the for_pavan.py flowgraph. I had a run of three straight where 
> the phase offset was around 11 degrees, but then afterward it started 
> fluctuating again (-140, 45, 81 degrees, etc.). 
> 
> Attached is the front of the Octoclock. I believe the settings are correct, 
> but maybe something is wrong with that. Note that the PPS flashes (but I 
> couldn't capture when it flashed in the picture). Also note that I get the 
> thread priority warning when running each of them, but I don't think that is 
> a problem.
> 
> I am really not sure what the issue is here, sadly. Thanks again for your 
> help and patience.
> 
> On Wed, Jul 6, 2016 at 6:22 PM, Marcus D. Leech  wrote:
> 
> On 07/06/2016 09:04 PM, Pavan Yedavalli wrote: 
> Hi Marcus, 
> 
> Trying the attached code with two of the USRPs transmitting, and with the 
> B210_Phase_Viewer for the other 2 USRPs receiving, still gives me different 
> offsets for every different run call. And by different run call, I'm simply 
> running the flowgraph once, seeing the offset, stopping the graph, and then 
> running it again, seeing the new offset, and so on. I must be doing something 
> wrong here. A you mentioned, since all of them are using the Octoclock, that 
> means that they all are having the same reference and pps, but both receive 
> boards may also not be timed in an aligned fashion for the same reason, 
> right? So the receive side LO offsets could also be causing problems in 
> narrowing down the issue, I'm assuming? Thanks again. Yes, the receive side 
> needs to be as mutually-coherent as possible as well.
> 
> Also, I forgot to mention that you'll need to modify the output of the 
> flow-graph I provided to wrap timed-command stuff around the tuning.
> 
> Same on any RX flow-graph.  That's the only sane we to be able to measure any 
> kind of phase-offset that you can trust.
> 
> If the RX side is a B210, you don't need to do timed commands (and, indeed, 
> they aren't supported for tuning on the B210).  What I'd do is
> leave the RX side running, while you bring the TX side up and down. 
> 
> On Wed, Jul 6, 2016 at 5:47 PM, Marcus D. Leech  wrote:
> 
> On 07/06/2016 02:48 PM, Pavan Yedavalli wrote: 
> I disconnected the MIMO cable and now have all 4 directly connected to the 
> Octoclock, but I get the same results in which the offset changes at every 
> run (using the above code). What about the attached code?
> 
> Keep in mind that you'll have to measure it with something that is also 
> mutually coherent. 
> 
> On Tue, Jul 5, 2016 at 9:11 PM, Marcus D. Leech  wrote:
> 
> On 07/05/2016 11:45 PM, Pavan Yedavalli wrote: 
> Yes, sorry - two of them are actually connected via MIMO cable, 

[Discuss-gnuradio] Implementing timed transmission: UHD API or Stream Tags?

[Lakshay Narula]

Hello,

I am a new GNU Radio user. I am looking to build a system that can transmit
a packet at a pre-defined time with very high accuracy (about 1
nanosecond). Having gone through the mailing list I am aware that timed
transmission is a common task and many people have asked similar questions.
However, I am still a bit confused.

1. I see that there is an example tx_timed_samples that comes with the UHD
source code. This is in C++ and uses the UHD API. Am I right in thinking
that when implemented this way, it has nothing to do with GNU Radio at all?
Is there any "reported accuracy" of this method in terms of difference
between actual and required time of transmission?

2. I also see that it is possible to achieve similar objectives using
tx_time stream tags in GNU Radio. My question is if this method is
equivalent to method 1 in terms of what goes on "under the hood"? If not,
how do these differ, and which method would provide better accuracy in
terms of agreement between actual and required time of transmission. Does
GNU Radio use the UHD API "under the hood"?

Please feel free to point me to resources I can read to get a better
understanding of this architecture and relationship between UHD, GNU Radio,
and USRP.

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

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

[Pavan Yedavalli]

It's an Octoclock-G (https://www.ettus.com/product/details/OctoClock-G is
what I ordered). And yes, that is true about the external clock inputs and
GPS lock. Does that matter if it's an Octoclock-G?

On Thu, Jul 7, 2016 at 7:46 PM,  wrote:

> Is this an Octoclock, or Octoclock-G?
>
> If it's just an Octoclock, then it has no internal clocks, and acts as a
> high-quality clock/pps distributor.
>
> I notice you don't have the external clock inputs connected to anything,
> and there's no GPS LOCK indicator.
>
>
>
>
>
>
>
>
> On 2016-07-07 17:08, Pavan Yedavalli wrote:
>
> Hi Marcus,
>
> I did what you suggested by wrapping the timed commands as follows:
>
> For the TX side (what you sent me in for_pavan.py):
>
> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
> now = self.uhd_usrp_source_0.get_time_now()
> start_time = now + uhd.time_spec(.5)
> self.uhd_usrp_source_0.set_command_time(start_time)
> self.uhd_usrp_source_0.set_clock_source("external", 0)
> self.uhd_usrp_source_0.set_time_source("external", 0)
> self.uhd_usrp_source_0.set_clock_source("external", 1)
> self.uhd_usrp_source_0.set_time_source("external", 1)
> self.uhd_usrp_source_0.set_samp_rate(samp_rate)
> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 0)
> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 0)
> self.uhd_usrp_source_0.set_antenna(Antenna_sel, 0)
> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 1)
> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 1)
> self.uhd_usrp_source_0.set_antenna("TX/RX", 1)
> self.uhd_usrp_source_0.clear_command_time()
>
> And for the RX side (B210_Phase_Viewer.py):
>
> self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec())
> now = self.uhd_usrp_sink_0.get_time_now()
> start_time = now + uhd.time_spec(.5)
> self.uhd_usrp_sink_0.set_command_time(start_time)
> self.uhd_usrp_sink_0.set_clock_source("external", 0)
> self.uhd_usrp_sink_0.set_time_source("external", 0)
> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 0)
> self.uhd_usrp_sink_0.set_clock_source("external", 1)
> self.uhd_usrp_sink_0.set_time_source("external", 1)
> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 1)
> self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
> self.uhd_usrp_sink_0.set_center_freq(915e6, 0)
> self.uhd_usrp_sink_0.set_gain(1.5, 0)
> self.uhd_usrp_sink_0.set_center_freq(915e6, 1)
> self.uhd_usrp_sink_0.set_gain(1.5, 1)
> self.uhd_usrp_sink_0.clear_command_time()
>
>
> However, it still does not work when I have the phase viewer running and
> stop and restart the for_pavan.py flowgraph. I had a run of three straight
> where the phase offset was around 11 degrees, but then afterward it started
> fluctuating again (-140, 45, 81 degrees, etc.).
>
> Attached is the front of the Octoclock. I believe the settings are
> correct, but maybe something is wrong with that. Note that the PPS flashes
> (but I couldn't capture when it flashed in the picture). Also note that I
> get the thread priority warning when running each of them, but I don't
> think that is a problem.
>
> I am really not sure what the issue is here, sadly. Thanks again for your
> help and patience.
>
>
> On Wed, Jul 6, 2016 at 6:22 PM, Marcus D. Leech  wrote:
>
>> On 07/06/2016 09:04 PM, Pavan Yedavalli wrote:
>>
>> Hi Marcus,
>>
>> Trying the attached code with two of the USRPs transmitting, and with the
>> B210_Phase_Viewer for the other 2 USRPs receiving, still gives me different
>> offsets for every different run call. And by different run call, I'm simply
>> running the flowgraph once, seeing the offset, stopping the graph, and then
>> running it again, seeing the new offset, and so on. I must be doing
>> something wrong here. A you mentioned, since all of them are using the
>> Octoclock, that means that they all are having the same reference and pps,
>> but both receive boards may also not be timed in an aligned fashion for the
>> same reason, right? So the receive side LO offsets could also be causing
>> problems in narrowing down the issue, I'm assuming? Thanks again.
>>
>> Yes, the receive side needs to be as mutually-coherent as possible as
>> well.
>>
>> Also, I forgot to mention that you'll need to modify the output of the
>> flow-graph I provided to wrap timed-command stuff around the tuning.
>>
>> Same on any RX flow-graph.  That's the only sane we to be able to measure
>> any kind of phase-offset that you can trust.
>>
>> If the RX side is a B210, you don't need to do timed commands (and,
>> indeed, they aren't supported for tuning on the B210).  What I'd do is
>>   leave the RX side running, while you bring the TX side up and down.
>>
>>
>>
>>
>> On Wed, Jul 6, 2016 at 5:47 PM, Marcus D. Leech 
>> wrote:
>>
>>> On 07/06/2016 02:48 PM, Pava

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

[Nick B]

I'm not super familiar with the octoclock-g, will it produce an output if
the GPS isn't locked?  I see what looks like a disconnected GPS Antenna
connector, which would make it unlikely for the GPS to ever lock.
Nick

On Fri, Jul 8, 2016 at 12:12 AM, Pavan Yedavalli 
wrote:

> It's an Octoclock-G (https://www.ettus.com/product/details/OctoClock-G is
> what I ordered). And yes, that is true about the external clock inputs and
> GPS lock. Does that matter if it's an Octoclock-G?
>
> On Thu, Jul 7, 2016 at 7:46 PM,  wrote:
>
>> Is this an Octoclock, or Octoclock-G?
>>
>> If it's just an Octoclock, then it has no internal clocks, and acts as a
>> high-quality clock/pps distributor.
>>
>> I notice you don't have the external clock inputs connected to anything,
>> and there's no GPS LOCK indicator.
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2016-07-07 17:08, Pavan Yedavalli wrote:
>>
>> Hi Marcus,
>>
>> I did what you suggested by wrapping the timed commands as follows:
>>
>> For the TX side (what you sent me in for_pavan.py):
>>
>> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
>> now = self.uhd_usrp_source_0.get_time_now()
>> start_time = now + uhd.time_spec(.5)
>> self.uhd_usrp_source_0.set_command_time(start_time)
>> self.uhd_usrp_source_0.set_clock_source("external", 0)
>> self.uhd_usrp_source_0.set_time_source("external", 0)
>> self.uhd_usrp_source_0.set_clock_source("external", 1)
>> self.uhd_usrp_source_0.set_time_source("external", 1)
>> self.uhd_usrp_source_0.set_samp_rate(samp_rate)
>> self.uhd_usrp_source_0.set_time_unknown_pps(uhd.time_spec())
>> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 0)
>> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 0)
>> self.uhd_usrp_source_0.set_antenna(Antenna_sel, 0)
>> self.uhd_usrp_source_0.set_center_freq(rx_center_freq, 1)
>> self.uhd_usrp_source_0.set_normalized_gain(rx_gain, 1)
>> self.uhd_usrp_source_0.set_antenna("TX/RX", 1)
>> self.uhd_usrp_source_0.clear_command_time()
>>
>> And for the RX side (B210_Phase_Viewer.py):
>>
>> self.uhd_usrp_sink_0.set_time_unknown_pps(uhd.time_spec())
>> now = self.uhd_usrp_sink_0.get_time_now()
>> start_time = now + uhd.time_spec(.5)
>> self.uhd_usrp_sink_0.set_command_time(start_time)
>> self.uhd_usrp_sink_0.set_clock_source("external", 0)
>> self.uhd_usrp_sink_0.set_time_source("external", 0)
>> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 0)
>> self.uhd_usrp_sink_0.set_clock_source("external", 1)
>> self.uhd_usrp_sink_0.set_time_source("external", 1)
>> self.uhd_usrp_sink_0.set_subdev_spec("A:0", 1)
>> self.uhd_usrp_sink_0.set_samp_rate(samp_rate)
>> self.uhd_usrp_sink_0.set_center_freq(915e6, 0)
>> self.uhd_usrp_sink_0.set_gain(1.5, 0)
>> self.uhd_usrp_sink_0.set_center_freq(915e6, 1)
>> self.uhd_usrp_sink_0.set_gain(1.5, 1)
>> self.uhd_usrp_sink_0.clear_command_time()
>>
>>
>> However, it still does not work when I have the phase viewer running and
>> stop and restart the for_pavan.py flowgraph. I had a run of three straight
>> where the phase offset was around 11 degrees, but then afterward it started
>> fluctuating again (-140, 45, 81 degrees, etc.).
>>
>> Attached is the front of the Octoclock. I believe the settings are
>> correct, but maybe something is wrong with that. Note that the PPS flashes
>> (but I couldn't capture when it flashed in the picture). Also note that I
>> get the thread priority warning when running each of them, but I don't
>> think that is a problem.
>>
>> I am really not sure what the issue is here, sadly. Thanks again for your
>> help and patience.
>>
>>
>> On Wed, Jul 6, 2016 at 6:22 PM, Marcus D. Leech 
>> wrote:
>>
>>> On 07/06/2016 09:04 PM, Pavan Yedavalli wrote:
>>>
>>> Hi Marcus,
>>>
>>> Trying the attached code with two of the USRPs transmitting, and with
>>> the B210_Phase_Viewer for the other 2 USRPs receiving, still gives me
>>> different offsets for every different run call. And by different run call,
>>> I'm simply running the flowgraph once, seeing the offset, stopping the
>>> graph, and then running it again, seeing the new offset, and so on. I must
>>> be doing something wrong here. A you mentioned, since all of them are using
>>> the Octoclock, that means that they all are having the same reference and
>>> pps, but both receive boards may also not be timed in an aligned fashion
>>> for the same reason, right? So the receive side LO offsets could also be
>>> causing problems in narrowing down the issue, I'm assuming? Thanks again.
>>>
>>> Yes, the receive side needs to be as mutually-coherent as possible as
>>> well.
>>>
>>> Also, I forgot to mention that you'll need to modify the output of the
>>> flow-graph I provided to wrap timed-command stuff around the tuning.
>>>
>>> Same on any RX flow-graph.  That's the only sane we to be able 

[Discuss-gnuradio] Please Test N210 Users

[SangHyuk Kim]

Hi,

I have used USRP N210 with CBX40 at 1.18GHz

I got a low performance when two USRP N210 communicate

I used 'benchmark_tx.py' and 'benchmark_rx.py' located at
~/gnuradio/gr-digital/example/ofdm

Commands I used are below each other :

Tx) ./benchmark_tx -f 1.18G -m qpsk --tx-gain=31.5 -W 250
Rx) ./benchmark_rx -f 1.18G -m qpsk -W 250
(other options are default : packet size = 400, fft = 512, occupied toens =
200, etc.)

And I counted how many packets are received at Rx machine

Then I calculated throughput on Rx during 60 sec with below equation :

Throughput[bps] = (# of total packet - # of error packet) * 8 * 400 / 60

I derived about 1 Mbps at Rx and I think it is too poor

Am I something missing ?

So, I ask USRP N210 users to try that and tell me how about yours.

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