Re: [Discuss-gnuradio] Setting cmake variable with pyBOMBS

[Martin Braun]

Patrick,

please don't get impatient with the mailing list, most people here are
helping in their free time. Give it a day or two.

In your case, there's no global config, but this might work. Add the
following lines to your config.yml:

```
categories:
  hardware:
vars:
  config_opt: 
```

If that doesn't work, you can still do it on a per-packet basis:
```
packages:
  :
vars:
  config_opt: 
  :
vars:
   config_opt: 

```

Remember all files are in YAML format.

M


On 03/30/2016 05:11 PM, Patrick Sathyanathan wrote:
> Any suggestions ?
>  
> Thanks,
>  
> --Patrick
>  
> 
> From: wp...@hotmail.com
> To: discuss-gnuradio@gnu.org
> Date: Wed, 30 Mar 2016 00:03:10 -0700
> Subject: [Discuss-gnuradio] Setting cmake variable with pyBOMBS
> 
>  Hi,
>  
> I installed gnuradio and gr-osmosdr using the latest pyBOMBS from
> source. However none of the hardware directories got configured with
> -DINSTALL_UDEV_RULES=ON. Is there a pybombs config command that I can
> use to set this cmake option globally ? I do not want to cd into each of
> the build directories and run "cmake -DINSTALL_UDEV_RULES=ON .." and run
> "make" and "sudo make install".
>  
> Thanks for any help,
>  
> --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
> 


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

Re: [Discuss-gnuradio] 802.11 transceiver issue

[Abhinav Jadon]

I ran the volk_profile just after the installation so that is not an issue
i guess. Also, I played around with the parameters of the message strobe (
the period parameter), it did have an effect on the underruns and the async
message buffer overflow warning. Low values of the period parameter
prompted async message overflow warnings and high values of the period
parameter prompted underruns ( a lot of them) .
What I dont understand is if the USRP is in the burst mode, why does the
period parameter change things ? If the USRP is set to sample rate of 20e6,
then it expects period*sample_rate samples to be supplied to it. That
requires to change the length of the message again.
Whats wrong here ?

Regards

Abhinav PS  Jadon
2012122
Electronics and Communication Engineering Undergraduate
IIIT - Delhi
IASc Summer Research Fellow 2015
*E*: jadonabhi...@gmail.com
*M*: +919650936845



On Wed, Mar 30, 2016 at 3:48 AM, Marcus Müller 
wrote:

> Did you run volk_profile? That one tries out all volk kernels, and notes
> down which one works best on your PC, so they'll be used automatically the
> next time. Maybe that increases performance!
>
>
> On 29.03.2016 22:24, Abhinav Jadon wrote:
>
> gcc version is 4.8.4
> cpuinfo output :
> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
> pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
> xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor
> ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic
> movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida
> arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt
>
> Since sse4_2 figures in the list and all the SIMD architectures are
> backward compatible, i think its right to say that sse4_2 is the answer we
> are looking for ?
>
> Also ,
> gnuradio version - '3.7.9.1'
> volk version - is in latest version as I pulled it from github yesterday.
>
> Abhinav PS  Jadon
> 2012122
> Electronics and Communication Engineering Undergraduate
> IIIT - Delhi
> IASc Summer Research Fellow 2015
> *E*: jadonabhi...@gmail.com
> *M*: +919650936845
>
>
>
> On Wed, Mar 30, 2016 at 1:27 AM, Alexander Levedahl <
> alexanderleved...@gmail.com> wrote:
>
>> Abhinav,
>>
>> I am not certain what to make of the asynch message buffer overflowing.
>>
>> The __SSE2_MATH__, __SSE_MATH__, __SSE2__, __SSE__ defines are the SIMD
>> preprocessor defines.  Can you run gcc --version and do cat /proc/cpuinfo |
>> grep flags?  The former will indicate the gcc version number.  The latter
>> will indicate what SIMD instructions the processor actually supports.  Also
>> do you know what version of VOLK and gnuradio you have?
>>
>> On Tue, Mar 29, 2016 at 3:50 PM, Abhinav Jadon <
>> abhinav12...@iiitd.ac.in> wrote:
>>
>>> Hi Alex ,
>>> The output in the console was all 'U's before I disabled the WX/GUI
>>> blocks.
>>> Now, it seems to run fine initially before throwing this message :
>>>
>>> "WARN: asynchronous message buffer overflowing, dropping message"

>>>
>>>
>>>
>>> The output of gcc -dM -E - < /dev/null | grep -e "SE" -e "AVX" was :
>>> #define __USER_LABEL_PREFIX__
>>> #define __SSE2_MATH__ 1
>>> #define __ATOMIC_HLE_RELEASE 131072
>>> #define __SSE_MATH__ 1
>>> #define __SSE2__ 1
>>> #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
>>> #define __SSE__ 1
>>> #define __ATOMIC_SEQ_CST 5
>>> #define __ATOMIC_RELEASE 3
>>>
>>>
>>> I have an idea about what SIMD is, although I could not find any SIMD
>>> preprocessor defines.
>>> Am I missing something here?
>>>
>>> Abhinav PS  Jadon
>>> 2012122
>>> Electronics and Communication Engineering Undergraduate
>>> IIIT - Delhi
>>> IASc Summer Research Fellow 2015
>>> *E*: jadonabhi...@gmail.com
>>> *M*: +919650936845
>>>
>>>
>>>
>>> On Wed, Mar 30, 2016 at 12:42 AM, Alexander Levedahl <
>>> alexanderleved...@gmail.com> wrote:
>>>
 Abhinav,

 When you run the flowgraph, can you look at system monitor?  This will
 give some indication whether the problem is that all the cores are pegged
 or if RAM is filling up.
 A couple of other things to look at:
 1) Is there any text being printed to the console?
 2) What happens if you disable the GUI blocks?  Simple method would be
 to open the flowgraph select the blocks that have GUIs associated with
 them, hit D (for disable) and then run the graph.
 3) Would you happen to know which SIMD instructions it is using?  Run
 gcc -dM -E - < /dev/null | grep -e "SE" -e "AVX"
 The gcc -dM -E will print out the preprocessor defines. The - <
 /dev/null forces gcc to exit immediately.  The "SE" flag filters the
 preprocessor defines for any of the SSEE SIMD instructions; the "AVX" flag
 

Re: [Discuss-gnuradio] Setting cmake variable with pyBOMBS

[Patrick Sathyanathan]

Any suggestions ?
 
Thanks,
 
--Patrick
 
From: wp...@hotmail.com
To: discuss-gnuradio@gnu.org
Date: Wed, 30 Mar 2016 00:03:10 -0700
Subject: [Discuss-gnuradio] Setting cmake variable with pyBOMBS




 Hi,
 
I installed gnuradio and gr-osmosdr using the latest pyBOMBS from source. 
However none of the hardware directories got configured with 
-DINSTALL_UDEV_RULES=ON. Is there a pybombs config command that I can use to 
set this cmake option globally ? I do not want to cd into each of the build 
directories and run "cmake -DINSTALL_UDEV_RULES=ON .." and run "make" and "sudo 
make install".
 
Thanks for any help,
 
--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

[Discuss-gnuradio] UHD clock rate in the usrp e310 - release 4

[Gabriel Pechiarovich]

Hi all,
I've developed a flowgraph wich includes  a qpsk modulator and and audio
encoder, I used to run it in the E310 using the first release (
http://files.ettus.com/e3xx_images/e3xx-release-001/) and now trying to use
the release 4.

The problem is:
in the UHD sink and source the clock rate was set to 8e6 Hz, and it worked
fine, in the release 1, but in the relese 4 the Clock rate wont go lower
than 10e6 Hz, so i cant archive the same results.

Any idea how to force the use of 8MHz as the clock rate using the release4

Thank you very much
Gabriel Pechiarovich Salas
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] topblock.wait() never returns even after i stop() it.

[M. Ranganathan]

More information:

I had a lock(), unlock() pair around the stop - which might have been
causing the problem. i.e.

topblock.lock()
...

topblock.stop()
topblock.unlock()

Now the wait() returns in the loop that was waiting.

It now works for USRP but I'd like to know why this bothered the USRP in
the first place. It seems to work differently with the bladerf (i.e. the
lock, unlock pair did not seem to pose a problem for the bladerf()).

Must be missing something

Thanks,

Ranga.

On Wed, Mar 30, 2016 at 5:53 PM, M. Ranganathan  wrote:

> Hello,
>
> I am trying to reconfigure a flow graph based on a signal. The signal
> handler does a stop on a flow graph but the routine that is running the
> flow graph and waiting on the top block, never returns from the wait on the
> top block of the flow graph. I am using osmosdr + gnuradio even though the
> signal handler stops flow graph using tb.stop().
>
> I am not sure if this is relevant but, strangely, this only happens when I
> am using a USRP as a source. When I use bladerf with the same code it works
> the way I intended (in both situations, I am using osmosdr). Do I need to
> do something to make stop() work as intended?
>
> Thanks in advance for any clues.
>
> Regards,
>
> Ranga.
>
>
>
> --
> M. Ranganathan
>



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

[Discuss-gnuradio] topblock.wait() never returns even after i stop() it.

[M. Ranganathan]

Hello,

I am trying to reconfigure a flow graph based on a signal. The signal
handler does a stop on a flow graph but the routine that is running the
flow graph and waiting on the top block, never returns from the wait on the
top block of the flow graph. I am using osmosdr + gnuradio even though the
signal handler stops flow graph using tb.stop().

I am not sure if this is relevant but, strangely, this only happens when I
am using a USRP as a source. When I use bladerf with the same code it works
the way I intended (in both situations, I am using osmosdr). Do I need to
do something to make stop() work as intended?

Thanks in advance for any clues.

Regards,

Ranga.



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

Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk

[Andy Walls]

Hi Arik,

I just took a quick look at your flowgraph.

Some things jump out at me:

1. You have the modulator set at 2 samples/symbol, but the reality is,
most hardware is not going to transmit at 320 ksps.  The X310 USRP for
example requires a minimum of 500 ksps for Tx, so you might as well just
upsample and get more samples/symbol anyway.

2. You have complex channel models in your flowgraph, but there's not
much point in using them until the basic system with a perfect channel
works properly.  Disable them and save the headaches until you're ready.

3. Power Squelch followed by AGC is going to be a disaster.  AGC will be
at *maximum* gain during most of the squelch periods.  When your signal
shows up and breaks squelch, the AGC going to take time to come down
from that enormous gain.  Get rid of the squelch.  Squelch is for
humans, not modems.

I'll look at it more later tonight.

-Andy

On Tue, 2016-03-29 at 23:48 +, Landsman, Arik wrote:
> Hi Andy, 
> 
> I like the "GMSK 9600" approach you mentioned - certainly will be looking 
> into it. in the meanwhile I attached my flow graph. The debug folder has the 
> input and output files. 
> 
> 0xFC0C3 is the sync word as can be seen in "stream_helloWorld". I use Bless 
> to generate the binaries but any hex editor would work I imagine.  
> 
> changing sps from =2 to =8 changes corr (as expected), so generating corr 
> symbols with a "matched" modulator seems like the way to go.
> 
> changing threshold from 0.3 to say 0.5 forces a tag only on that first ultra 
> high spike (30k or so). but 0.3 has the same spike, just more tags follow 
> (which is encouraging).
> 
> Tried bypassing the channel sim, power squelch, AGC, FLL directly into the 
> corr_est block in case the blocks change the symbols in an unpredictable way 
> - nothing seems to be off. 
> 
> As the ultimate check I usually loop the input file ("packet" if you will) 
> and compare it at the Rx. "Hello World" pops here and there but not often 
> enough to start considering BER testing for now.. costas output flips by 90* 
> sporadically. 
> 
> finally, the gui plots are not in the order of the signal chain but are 
> labeled properly. Hopefully easy to follow. 
> 
> And thanks again!
> 
> Arik 
> 
> 
> 
> From: Andy Walls [a...@silverblocksystems.net]
> Sent: Friday, March 25, 2016 6:45 PM
> To: Landsman, Arik
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
> in qpsk
> 
> On Fri, 2016-03-25 at 22:14 +, Landsman, Arik wrote:
> > Hi Andy,
> >
> > I gave it a few more touches since we last spoke, but to no avail...
> > Costas still flips sporadically on a simulated channel.
> >
> > Generally the corr_est block would show a large spike in |corr|^2 on
> > the very first packet I send (>1600), but on all subsequent loops
> > (same packet) the value diminishes to ~100 with multiple peaks.
> 
> That doesn't seem right.
> 
> 
> > I tried various preamble formats and sizes, including an 8 byte long
> > version to avoid any possible corr with payload. corr^2 certainly
> > changes but results in either multiple peaks at low levels (say 100
> > and 140), or with a huge spike at start as mentioned.
> >
> > I can generate  tags by reducing the threshold to extremely low values
> > (say 0.1, 0.3), which I suppose makes sense with the delta between the
> > first and subsequent spike levels.
> >
> > In either case there are more than one tag generated per packet as the
> > packet loops. Only one preamble per packet, non repeating.
> >
> >
> > matched filter taps - can the corr_est block accept taps in any way?
> 
> No.
> 
> The idea with corr_est is to give it exactly the reference samples that
> you are looking to match against.
> 
> That usually means building them with one of the gnuradio modulator
> blocks *and* discarding the the initial samples which are a transient
> emitted during the initial delay of the gnuradio particular modulator.
> 
> Look at the GRC file I just posted to the list regarding "GMSK 9600
> baud".  I had a modulator build the preamble samples. I had to add in a
> few flush/fill bits at the end of the preamble, which never get emitted
> by the modulator. I had to discard the initial transient emitted by the
> modulator.
> 
> >  I'd like to hold sps=8 at least for the time being, and without a
> > filter there is little correlation between the stream and the
> > reference preamble. sps=2 was too low for timing recovery without a
> > preamble.  what do you generally use? (btw all of the debug above was
> > with sps=2).
> 
> I use sps=10 with low data rate stuff.
> 
> >  I am told I've been loosing sleep over this.. in any case I'll keep
> > trying but in the meanwhile if you had any comments I would deeply
> > appreciate it.
> 
> If you have a flowgraph that you could share that simulates the input,
> I'd would probably be easier for me to see what's wrong about the
> corr_est 

Re: [Discuss-gnuradio] Compiling Documentation with an OOT

[Richard Bell]

I've asked this question a few times now on the mailing list, and each time
I hope a different answer comes through. Each time though it's the answer
Ron gave, which never works for me. I can't figure it out. So I've always
resorted to the xml tags to get documentation into GRC, but for the reasons
Tom just mentioned, would rather not do that. Hoping someday I figure this
out.

Rich

On Wed, Mar 30, 2016 at 7:50 AM, Tom Rondeau  wrote:

>
>
> On Mon, Mar 28, 2016 at 9:25 PM, Tom McDermott  wrote:
>
>> Hi Richard -
>>
>> When you say 'propagate through to GRC'  do you mean 'How to display on
>> the GRC documentation tab in the open block properties window'? (select
>> block,  double-click, or rt-click-properties).
>>
>> I do that by putting text between:
>> 
>> 
>> in the module's XML file (manually pasted text, with some characters not
>> allowed...).
>>
>> -- Tom, N5EG
>>
>
>
> I would recommend against using the  tags in the GRC XML files.
> You're just duplicating text, so if anything is ever updated, you now need
> to remember to update it in two places.
>
> As Ron Economos showed in his response, exporting from his public .h files
> works fine.
>
> This might be a question for Sebastian, who I think has gone through a
> couple of iterations of grabbing those docs strings into GRC.
>
> Tom
>
>
>
>
>> On Mon, Mar 28, 2016 at 5:30 PM, Richard Bell 
>> wrote:
>>
>>> Hi all,
>>>
>>> I would like to know how I get the comments I add to my public header
>>> function to propagate through to the GRC Block documentation tab. Is there
>>> a flag I have to add when I compile the OOT?
>>>
>>> Thanks,
>>> Rich
>>>
>>
>
> ___
> 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 build on 32-bit Slackware-Current system (cmake configuration problems)

[Frederick E. Stevens]

Nathan,

I'll read a little more carefully next time.  My apologies.  I will try 
the sed scripts with cmake 3.5.


Thank you again.

Cheers,


Fred

On 03/30/2016 03:08 PM, West, Nathan wrote:
I'm in the habit of not downloading and extracting tarballs from 
strangers on the internet, so I don't know what Tom's latest issue is, 
but the problem you refer to is an issue revealed by the release of 
cmake 3.5.


cmake 3.5 was released after the latest VOLK and GNU Radio release. 
That bug has since been fixed on the maint and master branches of git 
and will be available in the next release if you're the kind of person 
to like releases. One of the listed sed scripts would also work around 
this problem, so that's not the latest issue Tom is having.


Cheers,
-nathan

On Wed, Mar 30, 2016 at 3:43 PM, Frederick E. Stevens 
> wrote:


Hi,

Just tried building on my machine.  Slackware64-14.1 with cmake
3.5.1 built from Slackware64-current.  I would have tried this on
a 32 bit machine but I don't have any running any more.  What I
found is that cmake 3.5 fails with errors when configuring
gnuradio 3.7.9.1 build.  I modified the gnuradio.SlackBuild so
that ccmake is executed instead of cmake.  That way I could see
what was configured before trying to compile.  With cmake 3.5.1 on
the first configure pass I receive the following error messages:

CMake Error at volk/lib/CMakeLists.txt:134 (list):
   list sub-command REMOVE_ITEM requires list to be present.
 Call Stack (most recent call first):
   volk/lib/CMakeLists.txt:159 (OVERRULE_ARCH)



 CMake Error at volk/lib/CMakeLists.txt:134 (list):
   list sub-command REMOVE_ITEM requires list to be present.
 Call Stack (most recent call first):
   volk/lib/CMakeLists.txt:188 (OVERRULE_ARCH)



 CMake Error at volk/lib/CMakeLists.txt:134 (list):
   list sub-command REMOVE_ITEM requires list to be present.
 Call Stack (most recent call first):
   volk/lib/CMakeLists.txt:258 (OVERRULE_ARCH)

On the second pass:

CMake Error at
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
(CMAKE_PARSE_ARGUMENTS):
   Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
 Call Stack (most recent call first):
   /usr/share/cmake-3.5/Modules/FindPythonLibs.cmake:265
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
   CMakeLists.txt:234 (find_package)

Eventually, I went to cmake 3.4.3 and gnuradio is building right
now.  You might want to check your cmake and go to pre 3.5 to see
if that is the issue that you are having.

Hope this helps,

Cheers,

Fred


On 03/30/2016 11:28 AM, tp...@mklab.ph.rhul.ac.uk
 wrote:

Dear All,
  I am attempting to build Gnuradio on a 32-bit x86
Slackware-current system but without success.  I have tried
several approaches.

o Using the Slackbuilds scripts at
https://slackbuilds.org/repository/14.1/development/gnuradio/
which builds gnuradio-3.7.8.1.
o Using the Slackbuilds scripts to build the current release
gnuradio-3.7.9.1
o Unpacking gnuradio-3.7.9.1 and following the minimal
instructions at
http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide
o Downloading the default branch from git and following the
minimal instructions at
http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide


Firstly I found and fixed/worked-around 3 compiler problems
encountered with gcc 5.3.0;

(1) -lpthread needed to be added to CMAKE_C_FLAGS and/or
CMAKE_CXX_FLAGS.  I added it to both.
(2) This fix "sed -i 's/(intrin.h/(x86intrin.h/g'
../volk/lib/CMakeLists.txt" gets around intrin.h not being
present.
(3) This fix "sed -i
's/.\+Werror=unused\-command-line\-argument.\+//g'
../volk/lib/CMakeLists.txt" gets around this Warning option
not being available.

Then I was able to start the cmake configuration process. 
However I get errors like this,


/usr/bin/python2: can't open file
'/tmp/SBo/gnuradio-3.7.9.1/gen/volk_compile_utils.py': [Errno
2] No such file or directory

This script is present but in the volk sub-directory, ie. in
/tmp/SBo/gnuradio-3.7.9.1/volk/gen/volk_compile_utils.py.

Checking the source tarball, eg.

$ tar -tzvf gnuradio-3.7.9.1.tar.gz | grep volk_compile_utils.py
-rw-rw-r-- root/root  2165 2016-02-07 17:09
gnuradio-3.7.9.1/volk/gen/volk_compile_utils.py

confirms this is where it gets unpacked.

I tried a couple of work-arounds,

(1) Symlinking the volk/* directories into the top-level
directory before the cmake stage and then repeating this
symlinking in the build 

Re: [Discuss-gnuradio] Unable to build on 32-bit Slackware-Current system (cmake configuration problems)

[West, Nathan]

I'm in the habit of not downloading and extracting tarballs from strangers
on the internet, so I don't know what Tom's latest issue is, but the
problem you refer to is an issue revealed by the release of cmake 3.5.

cmake 3.5 was released after the latest VOLK and GNU Radio release. That
bug has since been fixed on the maint and master branches of git and will
be available in the next release if you're the kind of person to like
releases. One of the listed sed scripts would also work around this
problem, so that's not the latest issue Tom is having.

Cheers,
-nathan

On Wed, Mar 30, 2016 at 3:43 PM, Frederick E. Stevens  wrote:

> Hi,
>
> Just tried building on my machine.  Slackware64-14.1 with cmake 3.5.1
> built from Slackware64-current.  I would have tried this on a 32 bit
> machine but I don't have any running any more.  What I found is that cmake
> 3.5 fails with errors when configuring gnuradio 3.7.9.1 build.  I modified
> the gnuradio.SlackBuild so that ccmake is executed instead of cmake.  That
> way I could see what was configured before trying to compile.  With cmake
> 3.5.1 on the first configure pass I receive the following error messages:
>
> CMake Error at volk/lib/CMakeLists.txt:134 (list):
>list sub-command REMOVE_ITEM requires list to be present.
>  Call Stack (most recent call first):
>volk/lib/CMakeLists.txt:159 (OVERRULE_ARCH)
>
>
>
>  CMake Error at volk/lib/CMakeLists.txt:134 (list):
>list sub-command REMOVE_ITEM requires list to be present.
>  Call Stack (most recent call first):
>volk/lib/CMakeLists.txt:188 (OVERRULE_ARCH)
>
>
>
>  CMake Error at volk/lib/CMakeLists.txt:134 (list):
>list sub-command REMOVE_ITEM requires list to be present.
>  Call Stack (most recent call first):
>volk/lib/CMakeLists.txt:258 (OVERRULE_ARCH)
>
> On the second pass:
>
> CMake Error at
> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
> (CMAKE_PARSE_ARGUMENTS):
>Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
>  Call Stack (most recent call first):
>/usr/share/cmake-3.5/Modules/FindPythonLibs.cmake:265
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>CMakeLists.txt:234 (find_package)
>
> Eventually, I went to cmake 3.4.3 and gnuradio is building right now.  You
> might want to check your cmake and go to pre 3.5 to see if that is the
> issue that you are having.
>
> Hope this helps,
>
> Cheers,
>
> Fred
>
>
> On 03/30/2016 11:28 AM, tp...@mklab.ph.rhul.ac.uk wrote:
>
>> Dear All,
>>   I am attempting to build Gnuradio on a 32-bit x86 Slackware-current
>> system but without success.  I have tried several approaches.
>>
>> o Using the Slackbuilds scripts at
>> https://slackbuilds.org/repository/14.1/development/gnuradio/ which
>> builds gnuradio-3.7.8.1.
>> o Using the Slackbuilds scripts to build the current release
>> gnuradio-3.7.9.1
>> o Unpacking gnuradio-3.7.9.1 and following the minimal instructions at
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide
>> o Downloading the default branch from git and following the minimal
>> instructions at
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide
>>
>>
>> Firstly I found and fixed/worked-around 3 compiler problems encountered
>> with gcc 5.3.0;
>>
>> (1) -lpthread needed to be added to CMAKE_C_FLAGS and/or
>> CMAKE_CXX_FLAGS.  I added it to both.
>> (2) This fix "sed -i 's/(intrin.h/(x86intrin.h/g'
>> ../volk/lib/CMakeLists.txt" gets around intrin.h not being present.
>> (3) This fix "sed -i 's/.\+Werror=unused\-command-line\-argument.\+//g'
>> ../volk/lib/CMakeLists.txt" gets around this Warning option not being
>> available.
>>
>> Then I was able to start the cmake configuration process.  However I get
>> errors like this,
>>
>> /usr/bin/python2: can't open file
>> '/tmp/SBo/gnuradio-3.7.9.1/gen/volk_compile_utils.py': [Errno 2] No such
>> file or directory
>>
>> This script is present but in the volk sub-directory, ie. in
>> /tmp/SBo/gnuradio-3.7.9.1/volk/gen/volk_compile_utils.py.
>>
>> Checking the source tarball, eg.
>>
>> $ tar -tzvf gnuradio-3.7.9.1.tar.gz | grep volk_compile_utils.py
>> -rw-rw-r-- root/root  2165 2016-02-07 17:09
>> gnuradio-3.7.9.1/volk/gen/volk_compile_utils.py
>>
>> confirms this is where it gets unpacked.
>>
>> I tried a couple of work-arounds,
>>
>> (1) Symlinking the volk/* directories into the top-level directory before
>> the cmake stage and then repeating this
>> symlinking in the build directory.  Doing this got me some distance (23%)
>> into the make procedure before it failed.  See files
>> gnuradio.SlackBuild.try6 &
>> gnuradio.SlackBuild.try6.log.  Some of these directories already exist in
>> the top level & build directories and so can't be symlinked from below.
>> I can't believe this should be necessary and I presume must be an
>> artifact of something else being amiss...
>>
>> (2) Editing the volk/lib/CMakeLists.txt list before running cmake and
>> following the Wiki BuildGuide.  The following edits/hacks 

Re: [Discuss-gnuradio] Unable to build on 32-bit Slackware-Current system (cmake configuration problems)

[Frederick E. Stevens]

Hi,

Just tried building on my machine.  Slackware64-14.1 with cmake 3.5.1 
built from Slackware64-current.  I would have tried this on a 32 bit 
machine but I don't have any running any more.  What I found is that 
cmake 3.5 fails with errors when configuring gnuradio 3.7.9.1 build.  I 
modified the gnuradio.SlackBuild so that ccmake is executed instead of 
cmake.  That way I could see what was configured before trying to 
compile.  With cmake 3.5.1 on the first configure pass I receive the 
following error messages:


CMake Error at volk/lib/CMakeLists.txt:134 (list):
   list sub-command REMOVE_ITEM requires list to be present.
 Call Stack (most recent call first):
   volk/lib/CMakeLists.txt:159 (OVERRULE_ARCH)



 CMake Error at volk/lib/CMakeLists.txt:134 (list):
   list sub-command REMOVE_ITEM requires list to be present.
 Call Stack (most recent call first):
   volk/lib/CMakeLists.txt:188 (OVERRULE_ARCH)



 CMake Error at volk/lib/CMakeLists.txt:134 (list):
   list sub-command REMOVE_ITEM requires list to be present.
 Call Stack (most recent call first):
   volk/lib/CMakeLists.txt:258 (OVERRULE_ARCH)

On the second pass:

CMake Error at 
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203 
(CMAKE_PARSE_ARGUMENTS):

   Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
 Call Stack (most recent call first):
   /usr/share/cmake-3.5/Modules/FindPythonLibs.cmake:265 
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)

   CMakeLists.txt:234 (find_package)

Eventually, I went to cmake 3.4.3 and gnuradio is building right now.  
You might want to check your cmake and go to pre 3.5 to see if that is 
the issue that you are having.


Hope this helps,

Cheers,

Fred

On 03/30/2016 11:28 AM, tp...@mklab.ph.rhul.ac.uk wrote:

Dear All,
  I am attempting to build Gnuradio on a 32-bit x86 Slackware-current 
system but without success.  I have tried several approaches.

o Using the Slackbuilds scripts at 
https://slackbuilds.org/repository/14.1/development/gnuradio/ which builds 
gnuradio-3.7.8.1.
o Using the Slackbuilds scripts to build the current release gnuradio-3.7.9.1
o Unpacking gnuradio-3.7.9.1 and following the minimal instructions at 
http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide
o Downloading the default branch from git and following the minimal 
instructions at http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide


Firstly I found and fixed/worked-around 3 compiler problems encountered with 
gcc 5.3.0;

(1) -lpthread needed to be added to CMAKE_C_FLAGS and/or CMAKE_CXX_FLAGS.  I 
added it to both.
(2) This fix "sed -i 's/(intrin.h/(x86intrin.h/g' ../volk/lib/CMakeLists.txt" 
gets around intrin.h not being present.
(3) This fix "sed -i 's/.\+Werror=unused\-command-line\-argument.\+//g' 
../volk/lib/CMakeLists.txt" gets around this Warning option not being available.

Then I was able to start the cmake configuration process.  However I get errors 
like this,

/usr/bin/python2: can't open file 
'/tmp/SBo/gnuradio-3.7.9.1/gen/volk_compile_utils.py': [Errno 2] No such file 
or directory

This script is present but in the volk sub-directory, ie. in 
/tmp/SBo/gnuradio-3.7.9.1/volk/gen/volk_compile_utils.py.

Checking the source tarball, eg.

$ tar -tzvf gnuradio-3.7.9.1.tar.gz | grep volk_compile_utils.py
-rw-rw-r-- root/root  2165 2016-02-07 17:09 
gnuradio-3.7.9.1/volk/gen/volk_compile_utils.py

confirms this is where it gets unpacked.

I tried a couple of work-arounds,

(1) Symlinking the volk/* directories into the top-level directory before the 
cmake stage and then repeating this
symlinking in the build directory.  Doing this got me some distance (23%) into the 
make procedure before it failed.  See files gnuradio.SlackBuild.try6 &
gnuradio.SlackBuild.try6.log.  Some of these directories already exist in the top 
level & build directories and so can't be symlinked from below.
I can't believe this should be necessary and I presume must be an artifact of 
something else being amiss...

(2) Editing the volk/lib/CMakeLists.txt list before running cmake and following 
the Wiki BuildGuide.  The following edits/hacks allowed the cmake
to complete but the make failed soon after starting and I gave up at that stage.

sed -i 's/\${CMAKE_SOURCE_DIR}\/gen/${CMAKE_SOURCE_DIR}\/volk\/gen/g' 
../volk/lib/CMakeLists.txt
sed -i 
's/\${CMAKE_SOURCE_DIR}\/lib\/qa_utils\.cc/\${CMAKE_SOURCE_DIR}\/volk\/lib\/qa_utils.cc/g'
  ../volk/apps/CMakeLists.txt

See files tom_build.sh & tom_build.log.  Again I can't believe this should be 
necessary.

Please see http://www.mklab.rhul.ac.uk/~tom/tmp-gnuradio.tar.bz2 for all the 
above mentioned files.


Please help/advise!

Thanks
Tom Crane

I have the following software packages installed,
cmake-3.5.0
boost-1.59.0
cppunit-1.13.2
fftw-3.3.4
python-2.7.11
swig-3.0.7
numpy-1.8.0
doxygen-1.8.9.1
tetex-3.0 (for Latex)
python-cheetah-2.4.4
pygtk-2.24.0
gsl-1.16
qt-4.8.7
qwt-6.1.2
PyQt-4.11.4
wxPython-2.8.12.1
lxml-3.5.0
alsa-lib-1.1.0

Re: [Discuss-gnuradio] events, Friedrichshafen (Germany), Linuxwochen (Vienna)

[Daniel Pocock]

On 30/03/16 21:23, Markus Heller wrote:
> Hi Daniel,
> 
> let me organize something. I guess we'll arrange an informal SDR &
> GNURadio dinner after the SDRA somewhere in the city, with the SDRA
> speakers and all GNURadio folks. Of course it will be open to all open
> source people. 
> 
> I'll let you know as soon as I have news.


I also raised Friedrichshafen on the debain-hams, debian-events-eu and
debian.ch mailing lists (Friedrichsahfen being so close to Zurich),
there may be some interest there.  We may have the resources to run a
Debian/Debian Hams table or maybe just collaborate on a community table
there.

Regards,

Daniel

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

Re: [Discuss-gnuradio] events, Friedrichshafen (Germany), Linuxwochen (Vienna)

[Markus Heller]

Hi Daniel,

let me organize something. I guess we'll arrange an informal SDR &
GNURadio dinner after the SDRA somewhere in the city, with the SDRA
speakers and all GNURadio folks. Of course it will be open to all open
source people. 

I'll let you know as soon as I have news.

br
markus

Am Mittwoch, den 30.03.2016, 21:04 +0200 schrieb Daniel Pocock:
> 
> Hi all,
> 
> Is there any official GNU Radio table at Friedrichshafen[1] (24-26 June)
> or any interest in sharing a community table with any other free
> software projects?
> 
> Does anybody plan to visit Linuxwochen[2] (Vienna, 28 - 30 April) or
> even do a talk there?
> 
> Should things like this go into the calendar linked to from the wiki,
> even if there is no official presence but somebody from the community
> does something at an event?
> 
> Regards,
> 
> Daniel
> 
> 
> 1. http://www.hamradio-friedrichshafen.de/ham-en/
> 2. https://www.linuxwochen.at/
> 
> ___
> 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] events, Friedrichshafen (Germany), Linuxwochen (Vienna)

[Daniel Pocock]

Hi all,

Is there any official GNU Radio table at Friedrichshafen[1] (24-26 June)
or any interest in sharing a community table with any other free
software projects?

Does anybody plan to visit Linuxwochen[2] (Vienna, 28 - 30 April) or
even do a talk there?

Should things like this go into the calendar linked to from the wiki,
even if there is no official presence but somebody from the community
does something at an event?

Regards,

Daniel


1. http://www.hamradio-friedrichshafen.de/ham-en/
2. https://www.linuxwochen.at/

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

[Discuss-gnuradio] Idea for gr-osmosdr/rtlsdr drivers

[mleech]

 

How about a thingy that makes a note of the local high-precision time
when the first samples arrive in the work() function, and then somehow
make that available to higher layers, so that you can get a first-order
approximation of the time skew between the streams? 

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

[Discuss-gnuradio] problem with gr-osmosdr so file

[Jason Matusiak]

My machine was modified at work and my home directory is a new name 
now.  Part of the process went through and scrubbed my home directory 
names in files to point to the new one.  Most things (my X310 script) 
are working fine as-is, but when I try to run an RTL-SDR script, it 
errors out.  I can run rtl-test and rtl-fm and things work fine, so 
permissions did not get hosed there, but when I try to run a GRC script, 
it errors out with:

Executing: /usr/bin/python2 -u /home/jmat/Downloads/testRTL2.py

Traceback (most recent call last):
  File "/home/jmat/Downloads/testRTL2.py", line 29, in 
import osmosdr
  File 
"/home/jmat/target/lib/python2.7/dist-packages/osmosdr/__init__.py", 
line 26, in 

from osmosdr_swig import *
  File 
"/home/jmat/target/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", 
line 28, in 

_osmosdr_swig = swig_import_helper()
  File 
"/home/jmat/target/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", 
line 24, in swig_import_helper

_mod = imp.load_module('_osmosdr_swig', fp, pathname, description)
ImportError: libgnuradio-runtime-3.7.9git.so.0.0.0: cannot open shared 
object file: No such file or directory


Digging into things, if I run (I am using older pybombs still) "pybombs 
verify gr-osmosdr" I get the following error:

jmat@jmat:~/pybombs$ ./pybombs verify gr-osmosdr
Settled on prefix: /home/jmat/target
Initializing environmental variables...
Loading recipes ...
/home/jmat/target
Installing packages:
* gr-iqbal
* bladeRF
* airspy
* gr-osmosdr
Installing from source: gr-iqbal
Building:(100%) 
[==]

Build failed. Re-trying with reduced makewidth and higher verbosity.
make[2]: *** No rule to make target 
`/home/jmat/target/lib/libosmodsp.so', needed by 
`lib/libgnuradio-iqbalance.so'.  Stop.

make[1]: *** [lib/CMakeFiles/gnuradio-iqbalance.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[  0%] [  0%] Built target pygen_apps_9a6dd
Built target iqbalance_swig_swig_doc
[ 15%] Built target pygen_python_e9885
make: *** [all] Error 2
Build failed. See output above for error messages.


I tried blowing away osmosdr and rebuilding, but that doesn't seem to 
help.  What am I missing here?  It objdump on the culprit so, I see:

objdump -x /home/jmat/target/lib/libosmodsp.so.0.0.0
BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to handle 
section `' [0x  1b]

BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: no group info for section
BFD: /home/jmat/target/lib/libosmodsp.so.0.0.0: don't know how to handle 
section `' [0x  2e]

objdump: /home/jmat/target/lib/libosmodsp.so.0.0.0: Bad value

So it looks like a corrupted libosmodsp.so.0.0.0, but why can't I 
rebuild it???


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

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

[Marcus Müller]

Hi Daniel,

shortly answering your questions:
On 30.03.2016 17:50, Daniel Pocock wrote:
> OK, so keeping the mixer cooled will help reduce loss but has nothing
> to do with frequency stability? 
yes; well, the point is that the mixer is really just a multiplier,
built from a nonlinear device, and we use the fact that this
nonlinearity introduces a term that contains the product of the two
input signals, and usually filter out the unwanted original signals, and
wrong intermodulations afterward.

Temperature might change the coefficients of whatever model you use to
describe the nonlinear element;
for example, the current I(U) through a Diode is well-modeled with an
exponential function

$I(U) = I_0 e^{\alpha U}$,

and you can represent $e^x$ as power series

$e^x=\sum_{n = 0}^{\infty} \frac{x^n}{n!} = 1 + x + \frac{x^2}{2!} +
\dots$ ,

and abort that series after the second part. You'll notice the quadratic
component in there; and if $U = \frac x\alpha$ happens to be the sum of
two cosines, so

$x=\frac{\cos(f_1 t)+ \cos(f_2 t)}{\alpha}$ (imagine $f_1$ is the
frequency of your soon to be mixed up signal, and $f_2$ your
oscillator's frequency)

by the binomials, you'd have $x^2=\frac{\cos(f_1 t)^2 + 2\cos(f_1
t)\cos(f_2 t)+\cos(f_2 t)^2}{\alpha^2}$ with the cosine product in the
middle; now $\frac{2\cos(f_1 t)\cos(f_2
t)}{\alpha^2}=\frac{2}{\alpha^2}\cos(f_1 t)\cos(f_2 t)$ is only
sensitive to temperature in $\alpha$, not in either $f_i$, so
temperature will change the amplitude of your modulated output, but not
the frequency (lest temperature changes $\alpha$ so fast that you'd
notice the amplitude change as some frequency component; but we can
safely assume it won't).

For completeness: If you use Euler's formula to break down cosine,
you'll find that

$\cos(f_1t)\cdot\cos(f_2t)=\frac14\left[\cos\left((f_1t)-(f_2t)\right)+\cos\left((f_1t)+(f_2t)\right)\right]=
\frac14\left[\cos\left((f_1-f_2)t\right)+\cos\left((f_1+f_2)t\right)\right]$

which contains the sum of the two frequencies, $f_1+f_2$, which is what
we wanted for upconversion!


Now, the oscillator, on the other hand, does change its frequency
> That is definitely quite a relevant point, where I live at present the
> indoor temperature can often be a lot lower than indoor
Hm, the point of cozyness was more to avoid temperature changes;
basically, that's why OCXOs are used: you can relatively well control
the temperature of an oscillator inside a small oven; first of all,
building a control loop to keep that temperature constant is relatively
easy, because a big-enough oven won't cool down or heat up too quick,
and secondly, physics is cooperating here by the laws of thermodynamics.
>
>> That brings one down to the question whether you have the chance to use
>> the same oscillator for both your SDR device and the upconversion; ...
> For people using low-cost RTL-SDR dongles that might be more than they
> can expect
Well, there are people who use one RTL-SDR's clock for multiple
RTL-SDRs, to keep them frequency aligned, so that's probably possible if
you can solder some kind of amplifier (a FET will possibly do, but watch
out for intermodulation products ;) ) to original oscillator.
>
> For the proper SDR boards (e.g. USRP, BladeRF, HackRF) is this feasible?
USRPs: well, given you have either a USRP that integrates its RF
frontend (B2xx, E3xx), or a daughterboard that can transmit: you could
directly generate a tone for mixing with at arbitrary frequencies within
the frontend's frequency range, and that tone would be derived from the
same frequency reference as the oscillator frequency to convert down in
the receiver.
Some USRPs (mainly, the X3x0) also export their 10MHz reference (but on
those, you could also just use a BasicRX daughterboard that doesn't have
any mixer and just receive from e.g. 50MHz in baseband).

BladeRF: same thing; if you can transmit, you can probably also generate
a tone. I haven't worked with that; if it's not full-duplex capable, you
might have to make some firmware/software modifications to be able to
continously have such a TX tone.

HackRF: definitely not Full-Duplex.

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

Re: [Discuss-gnuradio] gr-radar make problem

[Stefan Wunsch]

Hi,

Sebastian is right, it's most likely a dependency problem. I've tested
the source from git and it compiles fine with following dependencies:

- gnuradio 3.7.9.1
- uhd 3.9.2
- boost 1.60.0

First check boost, old versions don't have the strerror function. If
boost is the problem, I should really fix the cmake so that it checks
the boost version.

Greetings
Stefan

On 03/30/2016 09:57 AM, Mostafa Alizadeh wrote:
> Hi all, 
> 
> I tried to build gr-radar  master
> branch but I got the error:
> 
> 
> /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc: In
> member function ‘void gr::radar::usrp_echotimer_cc_impl::receive()’:
> /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:232:16: 
> error:
> ‘class uhd::rx_streamer’ has no member named ‘issue_stream_cmd’
>d_rx_stream->issue_stream_cmd(stream_cmd);
> ^
> /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:84: 
> error:
> ‘struct uhd::rx_metadata_t’ has no member named ‘strerror’
> throw std::runtime_error(str(boost::format("Receiver error %s") %
> d_metadata_rx.strerror()));
>
> ^
> */home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94:
> error: ‘str’ was not declared in this scope*
> throw std::runtime_error(str(boost::format("Receiver error %s") %
> d_metadata_rx.strerror()));
>
>   ^
> /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94: 
> note:
> suggested alternatives:
> In file included from /usr/include/boost/format.hpp:53:0,
>  from /usr/local/include/gnuradio/logger.h:55,
>  from /usr/local/include/gnuradio/block.h:29,
>  from /usr/local/include/gnuradio/tagged_stream_block.h:27,
>  from
> /home/mostafa/RADAR/gr-radar-master/include/radar/usrp_echotimer_cc.h:25,
>  from
> /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.h:24,
>  from
> /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:26:
> /usr/include/boost/format/free_funcs.hpp:22:38: note:   ‘boost::str’
>  std::basic_string str(const basic_format Alloc>& f) {
>   ^
> /usr/include/boost/format/free_funcs.hpp:22:38: note:   *‘boost::str’*
> make[2]: ***
> [lib/CMakeFiles/gnuradio-radar.dir/usrp_echotimer_cc_impl.cc.o] Error 1
> make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2
> make: *** [all] Error 2
> 
> 
> *This is due to "boost::str" which is not declared! *
> 
> What could I do? 
> 
> 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

[Discuss-gnuradio] GRCon16 links

[madengr]

I see a link here:

http://gnuradio.org/grcon-2016/

Is registration open?  It says it starts today 3/30/16, but no link.

Thanks,
Lou




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GRCon16-links-tp59207.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] gr-radar make problem

[Sebastian Müller]

Hi Mostafa,

have you checked your BOOST version? gr-radar needs 1.60.0 or higher.
Also, see https://github.com/kit-cel/gr-radar/issues/10 for more info.

Regards,
Sebastian
Am 30. März 2016 bei 09:57:22, Mostafa Alizadeh (m.alizade...@gmail.com) 
schrieb:

Hi all, 

I tried to build gr-radar master branch but I got the error:


/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc: In member 
function ‘void gr::radar::usrp_echotimer_cc_impl::receive()’:
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:232:16: 
error: ‘class uhd::rx_streamer’ has no member named ‘issue_stream_cmd’
   d_rx_stream->issue_stream_cmd(stream_cmd);
                ^
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:84: 
error: ‘struct uhd::rx_metadata_t’ has no member named ‘strerror’
    throw std::runtime_error(str(boost::format("Receiver error %s") % 
d_metadata_rx.strerror()));
                                                                                
    ^
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94: 
error: ‘str’ was not declared in this scope
    throw std::runtime_error(str(boost::format("Receiver error %s") % 
d_metadata_rx.strerror()));
                                                                                
              ^
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94: note: 
suggested alternatives:
In file included from /usr/include/boost/format.hpp:53:0,
                 from /usr/local/include/gnuradio/logger.h:55,
                 from /usr/local/include/gnuradio/block.h:29,
                 from /usr/local/include/gnuradio/tagged_stream_block.h:27,
                 from 
/home/mostafa/RADAR/gr-radar-master/include/radar/usrp_echotimer_cc.h:25,
                 from 
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.h:24,
                 from 
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:26:
/usr/include/boost/format/free_funcs.hpp:22:38: note:   ‘boost::str’
     std::basic_string str(const basic_format& f) 
{
                                      ^
/usr/include/boost/format/free_funcs.hpp:22:38: note:   ‘boost::str’
make[2]: *** [lib/CMakeFiles/gnuradio-radar.dir/usrp_echotimer_cc_impl.cc.o] 
Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2
make: *** [all] Error 2


This is due to "boost::str" which is not declared! 

What could I do? 

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

[Discuss-gnuradio] Unable to build on 32-bit Slackware-Current system (cmake configuration problems)

[TPCgr]

Dear All,
 I am attempting to build Gnuradio on a 32-bit x86 Slackware-current system 
but without success.  I have tried several approaches.

o Using the Slackbuilds scripts at 
https://slackbuilds.org/repository/14.1/development/gnuradio/ which builds 
gnuradio-3.7.8.1.
o Using the Slackbuilds scripts to build the current release gnuradio-3.7.9.1
o Unpacking gnuradio-3.7.9.1 and following the minimal instructions at 
http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide
o Downloading the default branch from git and following the minimal 
instructions at http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide


Firstly I found and fixed/worked-around 3 compiler problems encountered with 
gcc 5.3.0;  

(1) -lpthread needed to be added to CMAKE_C_FLAGS and/or CMAKE_CXX_FLAGS.  I 
added it to both.
(2) This fix "sed -i 's/(intrin.h/(x86intrin.h/g' ../volk/lib/CMakeLists.txt" 
gets around intrin.h not being present.
(3) This fix "sed -i 's/.\+Werror=unused\-command-line\-argument.\+//g' 
../volk/lib/CMakeLists.txt" gets around this Warning option not being available.

Then I was able to start the cmake configuration process.  However I get errors 
like this,

/usr/bin/python2: can't open file 
'/tmp/SBo/gnuradio-3.7.9.1/gen/volk_compile_utils.py': [Errno 2] No such file 
or directory

This script is present but in the volk sub-directory, ie. in 
/tmp/SBo/gnuradio-3.7.9.1/volk/gen/volk_compile_utils.py.

Checking the source tarball, eg.

$ tar -tzvf gnuradio-3.7.9.1.tar.gz | grep volk_compile_utils.py
-rw-rw-r-- root/root  2165 2016-02-07 17:09 
gnuradio-3.7.9.1/volk/gen/volk_compile_utils.py

confirms this is where it gets unpacked.

I tried a couple of work-arounds,

(1) Symlinking the volk/* directories into the top-level directory before the 
cmake stage and then repeating this
symlinking in the build directory.  Doing this got me some distance (23%) into 
the make procedure before it failed.  See files gnuradio.SlackBuild.try6 & 
gnuradio.SlackBuild.try6.log.  Some of these directories already exist in the 
top level & build directories and so can't be symlinked from below.
I can't believe this should be necessary and I presume must be an artifact of 
something else being amiss...

(2) Editing the volk/lib/CMakeLists.txt list before running cmake and following 
the Wiki BuildGuide.  The following edits/hacks allowed the cmake 
to complete but the make failed soon after starting and I gave up at that stage.

sed -i 's/\${CMAKE_SOURCE_DIR}\/gen/${CMAKE_SOURCE_DIR}\/volk\/gen/g' 
../volk/lib/CMakeLists.txt
sed -i 
's/\${CMAKE_SOURCE_DIR}\/lib\/qa_utils\.cc/\${CMAKE_SOURCE_DIR}\/volk\/lib\/qa_utils.cc/g'
  ../volk/apps/CMakeLists.txt

See files tom_build.sh & tom_build.log.  Again I can't believe this should be 
necessary.  

Please see http://www.mklab.rhul.ac.uk/~tom/tmp-gnuradio.tar.bz2 for all the 
above mentioned files.


Please help/advise!

Thanks
Tom Crane

I have the following software packages installed,
cmake-3.5.0
boost-1.59.0
cppunit-1.13.2
fftw-3.3.4
python-2.7.11
swig-3.0.7
numpy-1.8.0
doxygen-1.8.9.1
tetex-3.0 (for Latex)
python-cheetah-2.4.4
pygtk-2.24.0
gsl-1.16
qt-4.8.7
qwt-6.1.2
PyQt-4.11.4
wxPython-2.8.12.1
lxml-3.5.0
alsa-lib-1.1.0
jack-audio-connection-kit-0.124.1
portaudio-V19
alsa-oss-1.0.28
sdl-1.2.15
gcc-5.3.0
gcc-g++-5.3.0
make-4.1

Build host CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz

-- 
Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England. 
Email:  T.Crane at rhul dot ac dot uk
Fax:+44 (0) 1784 472794

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

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

[madengr]

If you can synthesize the LO for the upconverter using the RTL XO as a
reference, the drift may tend to cancel.  I say "may" as this is a trick
used in dual or triple down conversion chains.  If you can alternate between
low and high sided IFs, then the drifts will move in the opposite directions
(but not the same amount).  Though with the complexity of doing that, might
as well just lock everything it to a 10 MHz reference.

Maybe just periodically calibrate to WWV.
 
Lou


Daniel Pocock wrote
> Has anybody been using any of the upconverters for SDR and has anybody
> made any comparison of them?





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/comparing-SDR-upconverters-thermal-stability-tp59194p59204.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

[mleech]

 

Tsys is essentially irrelevant for HF receivers, since Tambient is much,
much higher (thousands of K) than even some really-poor RF engineering
scenarios. 

At HF, galactic background can be very high--1e4K or more. 

On 2016-03-30 10:30, Marcus Müller wrote: 

> Hi Daniel,
> 
> haven't made experience with any of these upconverters; but:
> 
> The really temperature-sensitive aspect of an upconverter is probably
> the oscillator, not the mixer. So the trick might really be keeping
> your upconverter in the same environment as your SDR receiver (assuming
> both don't have overly well temperature-compensated or oven-controlled
> oscillators), as that will just as much limit your frequency accuracy.
> 
> Mixer circuits do exhibit conversion loss that tends to get worse with
> rising temperature, but that'll not distort your signal much.
> 
> The core question here is whether you'll deterioriate your system
> performance if you keep your upverter far from your antenna; my guess is
> that you'd have an LNA close to the antenna, anyway, so keeping the
> upverter's oscillator warm and cozy near your SDR device won't be that
> complicated, probably.
> 
> That brings one down to the question whether you have the chance to use
> the same oscillator for both your SDR device and the upconversion; that
> way, you'd only have to worry about one device drifting under any
> circumstance. Does your device give you the chance to couple out a clock
> or maybe transmit a sine?
> 
> Best regards,
> Marcus
> 
> On 30.03.2016 09:18, Daniel Pocock wrote:
> 
>> Hi all, Has anybody been using any of the upconverters for SDR and has 
>> anybody made any comparison of them? I've seen some comments suggesting that 
>> many of the low cost models have poor thermal stability[1], has anybody seen 
>> problems with this in practice for receiving modes like SSB on amateur HF 
>> bands? If this is an issue, is anybody aware of alternative models that are 
>> more robust? Regards, Daniel 1. 
>> http://www.rtl-sdr.com/review-of-the-spyverter-upconverter/#comment-79953 
>> [1] ___ Discuss-gnuradio mailing 
>> list Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
 

Links:
--
[1]
http://www.rtl-sdr.com/review-of-the-spyverter-upconverter/#comment-79953
[2] 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] comparing SDR upconverters, thermal stability

[Daniel Pocock]

On 30/03/16 16:49, mle...@ripnet.com wrote:
> All of them use reasonably good crystals or crystal XOs.  Certainly a
> lot better than the RTLSDRs most of these were intended for.
> 
> I assume that you're talking about frequency stability, rather than gain
> stability?
> 


Yes, frequency stability.  SSB voice signals in the HF spectrum may be
around 3000 Hz wide

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

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

[Daniel Pocock]

On 30/03/16 16:30, Marcus Müller wrote:
> Hi Daniel,
> 
> haven't made experience with any of these upconverters; but:
> 
> The really temperature-sensitive aspect of an upconverter is probably
> the oscillator, not the mixer. So the trick might really be  keeping
> your upconverter in the same environment as your SDR receiver (assuming
> both don't have overly well temperature-compensated or oven-controlled
> oscillators), as that will just as much limit your frequency accuracy.
> 
> Mixer circuits do exhibit conversion loss that tends to get worse with
> rising temperature, but that'll not distort your signal much.
> 

OK, so keeping the mixer cooled will help reduce loss but has nothing to
do with frequency stability?


> The core question here is whether you'll deterioriate your system
> performance if you keep your upverter far from your antenna; my guess is
> that you'd have an LNA close to the antenna, anyway, so keeping the
> upverter's oscillator warm and cozy near your SDR device won't be that
> complicated, probably.
> 

That is definitely quite a relevant point, where I live at present the
indoor temperature can often be a lot lower than indoor

> That brings one down to the question whether you have the chance to use
> the same oscillator for both your SDR device and the upconversion; that
> way, you'd only have to worry about one device drifting under any
> circumstance. Does your device give you the chance to couple out a clock
> or maybe transmit a sine?
> 

For people using low-cost RTL-SDR dongles that might be more than they
can expect

For the proper SDR boards (e.g. USRP, BladeRF, HackRF) is this feasible?

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

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

[mleech]

 

I know that some of them, like the HAMITUP, use a socket for the XO,
which one could easily replace with a TCXO. Check with the
 manufacturers about the XO spec they use. 

On 2016-03-30 11:43, Daniel Pocock wrote: 

> On 30/03/16 16:49, mle...@ripnet.com wrote:
> 
>> All of them use reasonably good crystals or crystal XOs. Certainly a lot 
>> better than the RTLSDRs most of these were intended for. I assume that 
>> you're talking about frequency stability, rather than gain stability?
> 
> Yes, frequency stability. SSB voice signals in the HF spectrum may be
> around 3000 Hz wide
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1]
 

Links:
--
[1] 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] Compiling Documentation with an OOT

[Tom Rondeau]

On Mon, Mar 28, 2016 at 9:25 PM, Tom McDermott  wrote:

> Hi Richard -
>
> When you say 'propagate through to GRC'  do you mean 'How to display on
> the GRC documentation tab in the open block properties window'? (select
> block,  double-click, or rt-click-properties).
>
> I do that by putting text between:
> 
> 
> in the module's XML file (manually pasted text, with some characters not
> allowed...).
>
> -- Tom, N5EG
>


I would recommend against using the  tags in the GRC XML files. You're
just duplicating text, so if anything is ever updated, you now need to
remember to update it in two places.

As Ron Economos showed in his response, exporting from his public .h files
works fine.

This might be a question for Sebastian, who I think has gone through a
couple of iterations of grabbing those docs strings into GRC.

Tom




> On Mon, Mar 28, 2016 at 5:30 PM, Richard Bell 
> wrote:
>
>> Hi all,
>>
>> I would like to know how I get the comments I add to my public header
>> function to propagate through to the GRC Block documentation tab. Is there
>> a flag I have to add when I compile the OOT?
>>
>> Thanks,
>> Rich
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

[mleech]

 

All of them use reasonably good crystals or crystal XOs. Certainly a lot
better than the RTLSDRs most of these were intended for. 

I assume that you're talking about frequency stability, rather than gain
stability? 

On 2016-03-30 03:18, Daniel Pocock wrote: 

> Hi all,
> 
> Has anybody been using any of the upconverters for SDR and has anybody
> made any comparison of them?
> 
> I've seen some comments suggesting that many of the low cost models have
> poor thermal stability[1], has anybody seen problems with this in
> practice for receiving modes like SSB on amateur HF bands?
> 
> If this is an issue, is anybody aware of alternative models that are
> more robust?
> 
> Regards,
> 
> Daniel
> 
> 1. http://www.rtl-sdr.com/review-of-the-spyverter-upconverter/#comment-79953 
> [1]
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [2]
 

Links:
--
[1]
http://www.rtl-sdr.com/review-of-the-spyverter-upconverter/#comment-79953
[2] 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] comparing SDR upconverters, thermal stability

[Marcus Müller]

Hi Daniel,

haven't made experience with any of these upconverters; but:

The really temperature-sensitive aspect of an upconverter is probably
the oscillator, not the mixer. So the trick might really be  keeping
your upconverter in the same environment as your SDR receiver (assuming
both don't have overly well temperature-compensated or oven-controlled
oscillators), as that will just as much limit your frequency accuracy.

Mixer circuits do exhibit conversion loss that tends to get worse with
rising temperature, but that'll not distort your signal much.

The core question here is whether you'll deterioriate your system
performance if you keep your upverter far from your antenna; my guess is
that you'd have an LNA close to the antenna, anyway, so keeping the
upverter's oscillator warm and cozy near your SDR device won't be that
complicated, probably.

That brings one down to the question whether you have the chance to use
the same oscillator for both your SDR device and the upconversion; that
way, you'd only have to worry about one device drifting under any
circumstance. Does your device give you the chance to couple out a clock
or maybe transmit a sine?

Best regards,
Marcus


On 30.03.2016 09:18, Daniel Pocock wrote:
>
> Hi all,
>
> Has anybody been using any of the upconverters for SDR and has anybody
> made any comparison of them?
>
> I've seen some comments suggesting that many of the low cost models have
> poor thermal stability[1], has anybody seen problems with this in
> practice for receiving modes like SSB on amateur HF bands?
>
> If this is an issue, is anybody aware of alternative models that are
> more robust?
>
> Regards,
>
> Daniel
>
>
> 1. http://www.rtl-sdr.com/review-of-the-spyverter-upconverter/#comment-79953
>
>
> ___
> 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] Rx overflow problem related with sample rate

[SangHyuk Kim]

Dear Marcus,

Thanks for your help.

I'm tried to understand your advices about interrupt coalescing and I
changed interrupt coalescing options

My default setting like below:

Coalesce parameters for eth0:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 20
rx-frames: 5
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 72
tx-frames: 53
tx-usecs-irq: 0
tx-frames-irq: 5

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

I controlled rx-usecs(0 ~ 1000) and rx-frames(0~1000), but I can't change
adaptive-rx or pkt-rate-low(high).

Rx-usecs and rx-frames doesn't help to solve overflow problem.

Did I miss something when control interrupt coalescing ?

What parameters do I have to set ?

Thanks.

2016-03-29 20:52 GMT+09:00 Marcus Müller :

> Hi SangHyuk,
>
> On 29.03.2016 13:45, SangHyuk Kim wrote:
>
> Hi,
>
> I found two phenomenons when USRP N210 are on receiving mode (but, no
> received data)
>
>
>
> i) When I capture eth0 packets using wireshark, USRP send buffer to host
> continuously. Maybe it is to sampling process.
>
> Of course. How else would the samples from the USRP come to your PC, where
> you put them into GNU Radio??
>
> I think that host cannot read these buffer quickly, so overflow is
> occurred (at high samp_rate).
>
> Yes!
>
>But, I don't know why host cannot consume these packet quickly (My PC
> CPU : 2.7GHz x 4)
>
> If that is too slow or fast enough depends completely on the application
> you're running. To be honest, 2.7GHz isn't *that* much, if your network
> card doesn't support reducing the number of interrupts sent. Play with
> "interrupt coalescing".
>
>
> ii) If I use samp_rate 25M, CPU utilization is over 300% (But, Tx mode is
> very stable, CPU utilization is under 10% at 25 MSps)
>I'm using native Ubuntu 14.04 OS, I can't understand these...
>
> Again, CPU usage depends on what you do with the signal, and I don't know
> what "TX mode" is for you.
>
> Best regards,
> Marcus
>
>
>
> Please give me a guide
>
> Thanks.
>
> 2016-03-29 12:50 GMT+09:00 SangHyuk Kim :
>
>> Hi,
>>
>> I tried to change recv_buffer_size, but I can't find where I input buffer
>> size.
>>
>> What is the default recv_buffer_size ?
>>
>> And why Tx is ok at BW 25MHz but Rx is not at same bandwidth ?
>>
>> Thanks
>>
>> 2016-03-28 10:06 GMT+09:00 Marcus D. Leech < 
>> mle...@ripnet.com>:
>>
>>> On 03/27/2016 09:01 PM, SangHyuk Kim wrote:
>>>
>>> Hi,
>>>
>>> My Ethernet controller info.
>>>
>>> Ethernet controller: Broadcom Corporation NetXtreme BCM57762 Gigabit
>>> Ethernet PCIe
>>> Subsystem: Apple Inc. Device 00f6
>>> Physical Slot: 9
>>> Flags: bus master, fast devsel, latency 0, IRQ 19
>>> Memory at acb0 (64-bit, prefetchable) [size=64K]
>>> Memory at acb1 (64-bit, prefetchable) [size=64K]
>>> Expansion ROM at a0a0 [disabled] [size=64K]
>>> Capabilities: 
>>> Kernel driver in use: tg3
>>>
>>> And I changed rmem_max and wmem_max but, it was not effect.
>>>
>>> How can I change recv_buffer_size ??
>>>
>>> Thanks
>>>
>>> Just specify it in the device arguments.
>>>
>>> recv_buffer_size=
>>>
>>> In your device arguments
>>>
>>>
>>>
>>>
>>> 2016-03-28 0:37 GMT+09:00 Marcus D. Leech < 
>>> mle...@ripnet.com>:
>>>
 On 03/27/2016 05:53 AM, tom x wrote:

 Hi,

 >I think my PC can handle this sample rate
 Have you tried other rates? What's the highest sample rate before
 overflow occurs?

 >How can I handle this problem ?
 Maybe a power squelch block? You can filter out signals that don't meet
 a db threshold before they reach your PC.

 
 https://gnuradio.org/doc/doxygen/classgr_1_1analog_1_1pwr__squelch__cc.html

 That's not how Gnu Radio works.The blocks run on your PC.

 However the power squelch I believe interrupts the sample stream, so
 that if you're writing to disk, the average write rate to the disk
   is lowered in this case, depending on the dynamics of the amplitude
 of your signals, since you'll only be writing "good stuff".

 If you're getting 'D', this may be your ethernet controller--what type
 do you have?  The 82579LM is notorious for dropping data.
   Also, make certain that your network buffering is configured
 correctly.  See the notes here:

 http://files.ettus.com/manual/page_transport.html#transport_udp_linux




 On Sun, Mar 27, 2016 at 10:56 AM, SangHyuk Kim < 
 tkdgur7...@gmail.com> wrote:

> Hi,
>
> I'm using USRP N210 with CBX daughter board on native Ubuntu 14.04
>
> When I open fft_uhd with sample rate about 25 MSps, it spits out of
> "D"(overfow)
>
> As I know, USRP N210 

[Discuss-gnuradio] gr-radar make problem

[Mostafa Alizadeh]

Hi all,

I tried to build gr-radar  master
branch but I got the error:


/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc: In
member function ‘void gr::radar::usrp_echotimer_cc_impl::receive()’:
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:232:16:
error: ‘class uhd::rx_streamer’ has no member named ‘issue_stream_cmd’
   d_rx_stream->issue_stream_cmd(stream_cmd);
^
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:84:
error: ‘struct uhd::rx_metadata_t’ has no member named ‘strerror’
throw std::runtime_error(str(boost::format("Receiver error %s") %
d_metadata_rx.strerror()));

^
*/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94:
error: ‘str’ was not declared in this scope*
throw std::runtime_error(str(boost::format("Receiver error %s") %
d_metadata_rx.strerror()));

  ^
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:245:94:
note: suggested alternatives:
In file included from /usr/include/boost/format.hpp:53:0,
 from /usr/local/include/gnuradio/logger.h:55,
 from /usr/local/include/gnuradio/block.h:29,
 from /usr/local/include/gnuradio/tagged_stream_block.h:27,
 from
/home/mostafa/RADAR/gr-radar-master/include/radar/usrp_echotimer_cc.h:25,
 from
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.h:24,
 from
/home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc:26:
/usr/include/boost/format/free_funcs.hpp:22:38: note:   ‘boost::str’
 std::basic_string str(const basic_format& f) {
  ^
/usr/include/boost/format/free_funcs.hpp:22:38: note:   *‘boost::str’*
make[2]: ***
[lib/CMakeFiles/gnuradio-radar.dir/usrp_echotimer_cc_impl.cc.o] Error 1
make[1]: *** [lib/CMakeFiles/gnuradio-radar.dir/all] Error 2
make: *** [all] Error 2


*This is due to "boost::str" which is not declared! *

What could I do?

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] comparing SDR upconverters, thermal stability

[Daniel Pocock]

Hi all,

Has anybody been using any of the upconverters for SDR and has anybody
made any comparison of them?

I've seen some comments suggesting that many of the low cost models have
poor thermal stability[1], has anybody seen problems with this in
practice for receiving modes like SSB on amateur HF bands?

If this is an issue, is anybody aware of alternative models that are
more robust?

Regards,

Daniel


1. http://www.rtl-sdr.com/review-of-the-spyverter-upconverter/#comment-79953


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

[Discuss-gnuradio] Setting cmake variable with pyBOMBS

[Patrick Sathyanathan]

 Hi,
 
I installed gnuradio and gr-osmosdr using the latest pyBOMBS from source. 
However none of the hardware directories got configured with 
-DINSTALL_UDEV_RULES=ON. Is there a pybombs config command that I can use to 
set this cmake option globally ? I do not want to cd into each of the build 
directories and run "cmake -DINSTALL_UDEV_RULES=ON .." and run "make" and "sudo 
make install".
 
Thanks for any help,
 
--Patrick
  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] implementation of tdma using USRPs

[Henning Bredenberg]

Thanks for your answer, Derek.

I got an attenuator between them.
Maybe i can ask in a different direction: I got problems with the  
virtual interfaces provided by tunnel.py. Do I really need them?
In GRC there are the adresses of the USRPs inside the  
USRP-source/sink-block, not any virtual interface adresses.
Maybe u can tell me, whether i should focus on gnuradio itself or try  
to implement my project in GRC with creating blocks for my requirements?


Regards,
Henning


Quoting Derek Kozel :


Hello Henning,

I don't have advice on TDMA in GNU Radio, but want to step in and make sure
that you have attenuation between the two B200's. The recommended maximum
receive power on the B200 is -15 dBm and the transmit power is up to 10
dBm. It sounds like you probably do have attenuation and aren't overdriving
the ADCs given that you have a successful data link, but as a note to
others reading the thread in the future 20 to 30 dB of attenuation is
recommended as a safety measure to guard against accidental damage.

Regards,
Derek

On Tue, Mar 29, 2016 at 1:52 AM, Henning Bredenberg <
henning.bredenb...@tuhh.de> wrote:


Hi all,

I'm using GNU-Radio for some weeks now and i try to implement a little
project. This list already helped me to get into it. Thanks for that.

First step of my project now is to implement a simple tdma-frame using two
USRPs B200 connected via a coax cable. The first 20ms of a 80ms-frame are
assigned for me.
I used the tunnel.py, which builds a TAP-device. I got that working so far
and so i configured two virtual ethernet interfaces (gr0 and gr1) which i
can ping successfully. The aim is now to use this virtual interfaces to
emulate the occuring delays of my communication system in grc. Therefor i
tried to use the tdma_engine.py of pre-cog (grextras included) but some
issues occured due to the change from 3.6 to 3.7. I read about it in the
archives but it was all pretty outdated.
Are there any newer templates to implement a tdma structure? Or is it
advisable to use tdma_engine.py?

best regards,
Henning




___
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