[Discuss-gnuradio] Log Level/Format Not Changing With Config File

[Devin Kelly]

I'm having an odd problem with the GR logger - no matter what I do the
logger logs messages at all log levels and ignores my formatting
configuration.  I have another machine with the same configuration that
behaves as I expect.

I'm writing an OOT module and testing it using the same code on two
different RHEL7 machines. I have the same version of GR and log4cpp on both
machines:

$ python -c 'from gnuradio import gr; print gr.version()'
3.7.10.1

$ sudo yum info 'log4cpp*'
Loaded plugins: langpacks, product-id, rhnplugin, search-disabled-repos,
subscription-manager, versionlock
This system is receiving updates from RHN Classic or Red Hat Satellite.
Installed Packages
Name: log4cpp
Arch: x86_64
Version : 1.1.1
Release : 1.el7
Size: 394 k
Repo: installed
>From repo   : epel
Summary : C++ logging library
URL : http://sourceforge.net/projects/log4cpp/
License : LGPLv2+
Description : A library of C++ classes for flexible logging to files,
syslog, IDSA and
: other destinations. It is modeled after the Log for Java
library
: (http://www.log4j.org), staying as close to their API as is
reasonable.

Name: log4cpp-devel
Arch: x86_64
Version : 1.1.1
Release : 1.el7
Size: 206 k
Repo: installed
>From repo   : epel
Summary : Header files, libraries and development man pages  log4cpp
URL : http://sourceforge.net/projects/log4cpp/
License : LGPLv2+
Description : This package contains the header files, static libraries and
development
: man pages for log4cpp. If you like to develop programs using
log4cpp,
: you will need to install log4cpp-devel.


I've used strace to look at all the files my flowgraph opens and the config
files it opens are configured the same way on both machines.  I also try to
change the log level env variable like below without success

export GR_CONF_LOG_LOG_LEVEL=INFO

Here are two sample messages, the first one is correct and the second is not


INFO: sample message
Root :INFO: top_block - sample message


Why is this happening?

Thanks for any help,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Daemonizing a flowgraph

[devin kelly]

Hello,

I have a flowgraph that I made with  GRC and modified.  All I want to do
with the flowgraph is make it run as a daemon.  I understand that if there
are overflows or underflows I'll miss them, that's OK.

I added some basic python code to daemonize my flowgraph:


# Fork once
try:
pid = os.fork()
except OSError:
print 'error forking'

if pid > 0:  # if parent, return
return

os.umask(0)

# Reset the session ID
try:
os.setsid()
except OSError:
sys.exit(1)

# Fork twice, giving up ownership of first parent's SID
try:
pid = os.fork()
except OSError:
print 'error forking'

if pid != 0:  # if parent, return
sys.exit(0)

# Change PWD
try:
os.chdir('/')
except OSError:
return

# Close open files
sys.stdin.close()
sys.stdout.close()
sys.stderr.close()

with open('/dev/null', 'r+') as devnull:
sys.stdin = devnull
sys.stdout = devnull
sys.stderr = devnull

tb = top_block_cls(options)
tb.start()
time.sleep(60.0)
tb.stop()
tb.wait()

When I run this, it works at first (I get my prompt back, you can see me
trying to open the file).  But then the UHD hijacks my stdout/stderr and
resumes as if nothing happened.

$ ./flowgraph.py -t
30

linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.005-0-g32951af2

$ vim flowgraph.py -- X300 initialization
sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio0 control...
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Performing register loopback test... pass

How do I stop the UHD from doing this?

Thanks for any help,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PFB Clock Sync stops producing samples

[devin kelly]

OK, I'll give that block a try.  Are you saying there's a bug in the PFB
Clock Sync block?  That was my suspicion but I'm not sure I understand what
the block is doing well enough to know with certainty.

On Thu, Jun 8, 2017 at 2:29 PM, Andy Walls <a...@silverblocksystems.net>
wrote:

> One minor correction on the settings to use, since it appears the
> PFB_clock_synch block uses a ridiculously over-damped loop filter:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-
> digital/lib/pfb_clock_sync_ccf_impl.cc#L82
>
> So the revised settings guidance to get exactly what the PFB clock synch
> block does is:
> Damping Factor:  Use 2 times whatever you're using now for Filter Size
>
>
> However, that seems silly to me.  I normally use one of:
>
> 0.707 (underdamped, but maximally flat, loop filter),
> 1.0 (critically damped loop filter),
> 1.5 (overdamped loop filter), or
> 2.0 (overdamped loop filter)
>
> for the damping factor.
>
> -Andy
>
> On Thu, 2017-06-08 at 14:08 -0400, Andy Walls wrote:
> > For a block that performs the identical function of the PFB clock synch
> > block with correct tag propagation, use the Symbol Synchronizer Block
> > available in this pull request:
> >
> > https://github.com/gnuradio/gnuradio/pull/1294
> > https://github.com/awalls-cx18/gnuradio/tree/symbol_sync2
> >
> > or this OOT module:
> >
> > https://github.com/awalls-cx18/gr-nwr
> >
> > Use the following settings:
> > Timing Error Detector:   y[n]y'[n] Maximum Likelyhood
> > Samples per Symbol:  whatever you're using now
> > Loop Bandwidth:  whatever you're using now (may need tweaking)
> > Damping Factor:  1.0/math.sqrt(2.0)
> > Maximum Deviation:   whatever you're using now
> > Output Samples/Symbol:   whatever you're using now
> > Interpolating Resampler: Polyphase Filterbank, MF
> > Filterbank Arms: whatever you're using now for Filter Size
> > PFB MF Taps: whatever prototype filter taps you're using now
> >
> >
> > Properly fixing the tag propagation in the PFB_clock_sync block is a
> > major change, which is one reason I wrote the new Symbol Synchronizer
> > blocks.
> >
> > FWIW, I also do think get_tags_in_range() could stand to perform a
> > sanity check, but that won't fix the underlying problem.
> >
> > -Andy
> >
> >
> > >  From:
> > > devin kelly
> > >   Subject:
> > > [Discuss-gnuradio] PFB Clock Sync
> > > stops producing samples
> > >  Date:
> > > Thu, 8 Jun 2017 12:08:12 -0400
> > >
> > > __
> > > I'm having a problem with the Polyphase Clock Sync block.  I believe
> > > what's happening is that the block is calling get_tags_in_range
> > > improperly and then causing an infiite loop in
> > > gnuradio-runtime/lib/buffer.cc, at this point the PFB Clock Sync block
> > > stops emitting samples.
> > >
> > >
> > > The problem occurs in the PFB clock sync block here:
> > > https://github.com/gnuradio/gnuradio/blob/master/gr-
> digital/lib/pfb_clock_sync_ccf_impl.cc#L473
> > >
> > >
> > > The PFB block calls get_tags_in_range where the start sample number is
> > > greater than then end sample number, here's the code in buffer.cc that
> > > may be getting stuck in an infiite loop.
> > >
> > >
> > > The entire file is here:
> > > https://github.com/gnuradio/gnuradio/blob/master/gnuradio-
> runtime/lib/buffer.cc#L354
> >
> > [snip]
> > > When I run into this problem, my code seems to get stuck on itr++ (see
> > > debugger output below).  Though I'm not sure if the itr++ call just
> > > stalls or if itr just never equals itr_end.
> > >
> > >
> > > When the PFB Clock Sync block stalls, I attach with GDB, find the PFB
> > > thread and get a back trace, I then go to the PFB general_work frame
> > > and print the two inputs to get_tags_in_range
> >
> > [snip]
> >
> > >I've also found (separately, using breakpoints) that sometimes count is
> > >negative.  Is that the way it should be?
> >
> > [snip]
> >
> >
> > > I'm not sure if we're putting bad data into the PFB block or if
> > > there's some bug in the PFB block.  Or should there be some checking
> > > in get_tags_in_range that checks if start > end.  What's the best way
> > > to proceed?
> > >
> > >
> > > Thanks,
> > >
> > > Devin
> >
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] PFB Clock Sync stops producing samples

[devin kelly]

I'm having a problem with the Polyphase Clock Sync block.  I believe what's
happening is that the block is calling get_tags_in_range improperly and
then causing an infiite loop in gnuradio-runtime/lib/buffer.cc, at this
point the PFB Clock Sync block stops emitting samples.

The problem occurs in the PFB clock sync block here:
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/pfb_clock_sync_ccf_impl.cc#L473

The PFB block calls get_tags_in_range where the start sample number is
greater than then end sample number, here's the code in buffer.cc that may
be getting stuck in an infiite loop.

The entire file is here:
https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/buffer.cc#L354

  void
  buffer_reader::get_tags_in_range(std::vector ,
   uint64_t abs_start,
   uint64_t abs_end,
   long id)
  {
gr::thread::scoped_lock guard(*mutex());

v.resize(0);
std::multimap::iterator itr =
d_buffer->get_tags_lower_bound(std::min(abs_start, abs_start -
d_attr_delay));
std::multimap::iterator itr_end =
d_buffer->get_tags_upper_bound(std::min(abs_end, abs_end -
d_attr_delay));

uint64_t item_time;
while(itr != itr_end) {
  item_time = (*itr).second.offset + d_attr_delay;
  if((item_time >= abs_start) && (item_time < abs_end)) {
std::vector::iterator id_itr;
id_itr = std::find(itr->second.marked_deleted.begin(),
itr->second.marked_deleted.end(), id);
// If id is not in the vector of marked blocks
if(id_itr == itr->second.marked_deleted.end()) {
  tag_t t = (*itr).second;
  t.offset += d_attr_delay;
  v.push_back(t);
  v.back().marked_deleted.clear();
}
  }
  itr++;
}
  }

When I run into this problem, my code seems to get stuck on itr++ (see
debugger output below).  Though I'm not sure if the itr++ call just stalls
or if itr just never equals itr_end.

When the PFB Clock Sync block stalls, I attach with GDB, find the PFB
thread and get a back trace, I then go to the PFB general_work frame and
print the two inputs to get_tags_in_range

(gdb) bt
#0  0x7f4505db7b30 in local_Rb_tree_increment (__x=0x7f43a801ab90) at
../../../../../src/libstdc++-v3/src/c++98/tree.cc:71
#1  std::_Rb_tree_increment (__x=0x7f43a801ab90) at
../../../../../src/libstdc++-v3/src/c++98/tree.cc:85
#2  0x7f450678ed27 in std::_Rb_tree_iterator::operator++ (this=0x7f43baffc570)
at /usr/include/c++/4.8/bits/stl_tree.h:197
#3  0x7f450678e075 in gr::buffer_reader::get_tags_in_range
(this=0x3050350, v=..., abs_start=2833152, abs_end=2833150, id=81)
at /root/gnuradio/gnuradio-runtime/lib/buffer.cc:367
#4  0x7f4506778c79 in gr::block_detail::get_tags_in_range
(this=0x3211be0, v=..., which_input=0, abs_start=2833152, abs_end=2833150,
id=81) at /root/gnuradio/gnuradio-runtime/lib/block_detail.cc:224
#5  0x7f450676ef92 in gr::block::get_tags_in_range (this=0x30a6800,
v=..., which_input=0, start=2833152, end=2833150)
at /root/gnuradio/gnuradio-runtime/lib/block.cc:252
#6  0x7f44f6bc200c in
gr::digital::pfb_clock_sync_ccf_impl::general_work (this=0x30a6710,
noutput_items=128, ninput_items=...,
input_items=..., output_items=...) at
/root/gnuradio/gr-digital/lib/pfb_clock_sync_ccf_impl.cc:473
#7  0x7f450677fe03 in gr::block_executor::run_one_iteration
(this=0x7f43baffcd20)
at /root/gnuradio/gnuradio-runtime/lib/block_executor.cc:451
#8  0x7f45067d5ffc in gr::tpb_thread_body::tpb_thread_body
(this=0x7f43baffcd20, block=..., max_noutput_items=8192)
at /root/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122
#9  0x7f45067c6df1 in gr::tpb_container::operator() (this=0x317c870) at
/root/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:44
#10 0x7f45067c7406 in
gr::thread::thread_body_wrapper::operator()
(this=0x317c870)
at
/root/gnuradio/gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
#11 0x7f45067c72d9 in
boost::detail::function::void_function_obj_invoker0::invoke (function_obj_ptr=...) at
/usr/include/boost/function/function_template.hpp:153
#12 0x7f450675aa36 in boost::function0::operator()
(this=0x32257b8) at /usr/include/boost/function/function_template.hpp:767
#13 0x7f450675a9e2 in boost::detail::thread_data::run (this=0x3225600)
at /usr/include/boost/thread/detail/thread.hpp:117
#14 0x7f450544ee7a in ?? () from
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
#15 0x7f4508a03184 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#16 0x7f450873037d in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) f 6
#6  0x7f44f6bc200c in
gr::digital::pfb_clock_sync_ccf_impl::general_work (this=0x30a6710,
noutput_items=128, ninput_items=...,
input_items=..., output_items=...) at

[Discuss-gnuradio] PMT: vector of vectors of ints

[devin kelly]

Is there any way to create a vector of vectors of ints with the PMT library?

I'm trying to make a C++ GR block that takes in an NxM matrix.  For GRC all
the types are listed at the link below, none really fit my model.

https://github.com/gnuradio/gnuradio/blob/d4bb541ec1ec93446ecfa53948a1a6f995fffb64/grc/core/Param.py#L303

What are my options for passing a matrix into the block?

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

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

 = d_filters[d_filtnum]->filter(&
> in[count+d_out_idx]);
> in pfb_clock_sync_ccf.cc isn't all that suspicious, let's harass GDB for a
> moment.
>
> 1. since you're in stack frame #0 by default, can you see whether you can
> `print number` from the gdb shell? It's possible that GCC optimized that
> variable away, so try `print bPtr`, too.
> 2. From 1. we know whether this happens on the first loop iteration or a
> subsequent one; that will show in which direction we'd look for bugs
> 3. `frame 1` brings us into the context of the fir_filter_ccf::filter
> function. `print al` and `print d_ntaps`, please!
> 4. We're getting a bit fancy here with gdb, but whatever :) `print
> d_aligned_taps[al]`
>
> Hope this gives us a push forward!
>
> Greetings,
> Marcus
>
>
>
> On 12/06/2016 07:24 PM, devin kelly wrote:
>
> I changed my volk_config like so
>
> volk_32fc_32f_dot_prod_32fc generic generic
>
> And I still get a segfault:
>
> gdb python core.8035
>
>  .
>
> Program terminated with signal 11, Segmentation fault.
> #0  0x7f116379277f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860,
> num_points=45) at /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> 83  *realpt += ((*aPtr++) * (*bPtr));
> Missing separate debuginfos, use: debuginfo-install
> python-2.7.5-48.el7.x86_64
> (gdb) bt
> #0  0x7f116379277f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at
> /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> #1  0x7f11474f in 
> gr::filter::kernel::fir_filter_ccf::filter(std::complex
> const*) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> filter-3.7.10.1.so.0.0.0
> #2  0x7f1150356b41 in 
> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
> std::vector<int, std::allocator >&, std::vector std::allocator >&, std::vector<void*, std::allocator<void*>
> >&) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> digital-3.7.10.1.so.0.0.0
> #3  0x7f1163d14d80 in gr::block_executor::run_one_iteration() ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #4  0x7f1163d56090 in gr::tpb_thread_body::tpb_
> thread_body(boost::shared_ptr, int) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #5  0x7f1163d49791 in boost::detail::function::void_
> function_obj_invoker0<gr::thread::thread_body_wrapper,
> void>::invoke(boost::detail::function::function_buffer&) ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #6  0x7f1163cfae60 in boost::detail::thread_data<boost::function0
> >::run() ()
> at /local_disk/spectrum_challenge/lib64/libgnuradio-
> runtime-3.7.10.1.so.0.0.0
> #7  0x7f11627f927a in thread_proxy () at /lib64/libboost_thread-mt.so.
> 1.53.0
> #8  0x7f117e4d8dc5 in start_thread () at /lib64/libpthread.so.0
> #9  0x7f117dafe73d in clone () at /lib64/libc.so.6
> (gdb) f 0
> #0  0x7f116379277f in volk_32fc_32f_dot_prod_32fc_generic
> (result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at
> /local_disk/spectrum_challenge_src/volk/kernels/
> volk/volk_32fc_32f_dot_prod_32fc.h:83
> 83  *realpt += ((*aPtr++) * (*bPtr));
> (gdb) info locals
> res = {0, 0}
> realpt = 0x7f114680f570
> imagpt = 0x7f114680f574
> aPtr = 0x7f1126cac684
> bPtr = 0x56ea860
> number = 0
> (gdb) print realpt
> $1 = (float *) 0x7f114680f570
> (gdb) print *realpt
> $2 = 0
> (gdb) print aPtr
> $3 = (const float *) 0x7f1126cac684
> (gdb) print *aPtr
> Cannot access memory at address 0x7f1126cac684
> (gdb) print bPtr
> $4 = (const float *) 0x56ea860
> (gdb) print *bPtr
> $5 = 0.000685208186
>
>
> The fault happens here:
>
> https://github.com/gnuradio/volk/blob/master/kernels/volk/
> volk_32fc_32f_dot_prod_32fc.h#L83
>
>
> Since aPtr is just
>
> const float* aPtr = (float*)input;
>
> Maybe the issue is with pfb_clock_sync_ccf_impl?  I'm not sure.
>
> Devin
>
> On Tue, Dec 6, 2016 at 1:06 PM, devin kelly <dwwke...@gmail.com> wrote:
>
>> It's a bit of both.  The segfault usually happens on packet between
>> packets 2 and 3 (I send one packet per second on my transmitter) but
>> sometimes will happen a few packets later.  It also always segfaults, I've
>> gotten it to segfault about 20 times or so.
>>
>> On Tue, Dec 6, 2016 at 12:24 PM, West, Nathan <
>> n...@ostatema

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

I changed my volk_config like so

volk_32fc_32f_dot_prod_32fc generic generic

And I still get a segfault:

gdb python core.8035

 .

Program terminated with signal 11, Segmentation fault.
#0  0x7f116379277f in volk_32fc_32f_dot_prod_32fc_generic
(result=0x56de260, input=0x7f1126cac680, taps=0x56ea860,
num_points=45) at
/local_disk/spectrum_challenge_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:83
83  *realpt += ((*aPtr++) * (*bPtr));
Missing separate debuginfos, use: debuginfo-install
python-2.7.5-48.el7.x86_64
(gdb) bt
#0  0x7f116379277f in volk_32fc_32f_dot_prod_32fc_generic
(result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at
/local_disk/spectrum_challenge_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:83
#1  0x7f11474f in
gr::filter::kernel::fir_filter_ccf::filter(std::complex const*) ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0
#2  0x7f1150356b41 in
gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vector<int,
std::allocator >&, std::vector >&, std::vector<void*, std::allocator<void*> >&) ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-digital-3.7.10.1.so.0.0.0
#3  0x7f1163d14d80 in gr::block_executor::run_one_iteration() ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#4  0x7f1163d56090 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#5  0x7f1163d49791 in
boost::detail::function::void_function_obj_invoker0<gr::thread::thread_body_wrapper,
void>::invoke(boost::detail::function::function_buffer&) ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#6  0x7f1163cfae60 in boost::detail::thread_data<boost::function0
>::run() ()
at
/local_disk/spectrum_challenge/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#7  0x7f11627f927a in thread_proxy () at
/lib64/libboost_thread-mt.so.1.53.0
#8  0x7f117e4d8dc5 in start_thread () at /lib64/libpthread.so.0
#9  0x7f117dafe73d in clone () at /lib64/libc.so.6
(gdb) f 0
#0  0x7f116379277f in volk_32fc_32f_dot_prod_32fc_generic
(result=0x56de260, input=0x7f1126cac680, taps=0x56ea860, num_points=45) at
/local_disk/spectrum_challenge_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:83
83  *realpt += ((*aPtr++) * (*bPtr));
(gdb) info locals
res = {0, 0}
realpt = 0x7f114680f570
imagpt = 0x7f114680f574
aPtr = 0x7f1126cac684
bPtr = 0x56ea860
number = 0
(gdb) print realpt
$1 = (float *) 0x7f114680f570
(gdb) print *realpt
$2 = 0
(gdb) print aPtr
$3 = (const float *) 0x7f1126cac684
(gdb) print *aPtr
Cannot access memory at address 0x7f1126cac684
(gdb) print bPtr
$4 = (const float *) 0x56ea860
(gdb) print *bPtr
$5 = 0.000685208186


The fault happens here:

https://github.com/gnuradio/volk/blob/master/kernels/volk/volk_32fc_32f_dot_prod_32fc.h#L83


Since aPtr is just

const float* aPtr = (float*)input;

Maybe the issue is with pfb_clock_sync_ccf_impl?  I'm not sure.

Devin

On Tue, Dec 6, 2016 at 1:06 PM, devin kelly <dwwke...@gmail.com> wrote:

> It's a bit of both.  The segfault usually happens on packet between
> packets 2 and 3 (I send one packet per second on my transmitter) but
> sometimes will happen a few packets later.  It also always segfaults, I've
> gotten it to segfault about 20 times or so.
>
> On Tue, Dec 6, 2016 at 12:24 PM, West, Nathan <n...@ostatemail.okstate.edu
> > wrote:
>
>> Honestly, my money would be on GCC 4.8.5 being less buggy than 6.2, but
>> that's a separate topic.
>>
>> You can configure VOLK to not use this protokernel and there's some
>> documentation on how to do it here: http://gnuradio.org/doc/
>> doxygen/volk_guide.html#volk_tuning
>>
>> This is fairly concerning though... are you able to consistently trigger
>> a segfault or is it a seemingly random event that you can't trigger?
>>
>> On Tue, Dec 6, 2016 at 11:48 AM, devin kelly <dwwke...@gmail.com> wrote:
>>
>>> OK, I tried a brand new GR/Volk install and still had the same problem.
>>> So no problem with re-linking Volk to GR.  Could this be an issue with Volk
>>> on GCC 4.8.5?  The newest GCC is 6.2 so 4.8.5 is pretty old, though the
>>> newest for Red Hat 7.  Is there any way to reconfigure volk to not use
>>> volk_32fc_32f_dot_prod_32fc_a_avx?
>>>
>>> Here's volk-config-info:
>>>
>>> $ volk-config-info --all --prefix --cc --cflags --avail-machines
>>> --machine --alignment --malloc
>>> /local_disk/spectrum_challenge
>>> cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> This is free software see the source for

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

It's a bit of both.  The segfault usually happens on packet between packets
2 and 3 (I send one packet per second on my transmitter) but sometimes will
happen a few packets later.  It also always segfaults, I've gotten it to
segfault about 20 times or so.

On Tue, Dec 6, 2016 at 12:24 PM, West, Nathan <n...@ostatemail.okstate.edu>
wrote:

> Honestly, my money would be on GCC 4.8.5 being less buggy than 6.2, but
> that's a separate topic.
>
> You can configure VOLK to not use this protokernel and there's some
> documentation on how to do it here: http://gnuradio.org/doc/
> doxygen/volk_guide.html#volk_tuning
>
> This is fairly concerning though... are you able to consistently trigger a
> segfault or is it a seemingly random event that you can't trigger?
>
> On Tue, Dec 6, 2016 at 11:48 AM, devin kelly <dwwke...@gmail.com> wrote:
>
>> OK, I tried a brand new GR/Volk install and still had the same problem.
>> So no problem with re-linking Volk to GR.  Could this be an issue with Volk
>> on GCC 4.8.5?  The newest GCC is 6.2 so 4.8.5 is pretty old, though the
>> newest for Red Hat 7.  Is there any way to reconfigure volk to not use
>> volk_32fc_32f_dot_prod_32fc_a_avx?
>>
>> Here's volk-config-info:
>>
>> $ volk-config-info --all --prefix --cc --cflags --avail-machines
>> --machine --alignment --malloc
>> /local_disk/spectrum_challenge
>> cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> This is free software see the source for copying conditions.  There is NO
>> warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> /usr/bin/cc:::  -Wall
>> /usr/bin/c++:::  -Wall
>> generic_orc:::GNU:::-g  -Wall
>> sse2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2
>> sse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>> ssse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
>> sse4_a_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>> -msse4a -mpopcnt
>> sse4_1_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>> -mssse3 -msse4.1
>> sse4_2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
>> -mssse3 -msse4.1 -msse4.2 -mpopcnt
>> avx_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
>> -msse4.1 -msse4.2 -mpopcnt -mavx
>> avx2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
>> -msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2
>> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc
>> ;sse4_a_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_
>> 64_mmx_orc;avx2_64_mmx_orc;
>> generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc
>> ;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc;
>> avx2_64_mmx_orc
>> Alignment in bytes: 32
>> Used malloc implementation: posix_memalign
>>
>>
>> Thanks again for any help,
>> Devin
>>
>>
>> On Fri, Dec 2, 2016 at 10:04 AM, Marcus Müller <marcus.muel...@ettus.com>
>> wrote:
>>
>>> Oh, that's pretty interesting! Well, no misconfiguration should
>>> segfault, so I'm a bit stumped at the moment.
>>>
>>> On 12/01/2016 06:14 PM, devin kelly wrote:
>>>
>>> Marcus,
>>>
>>> Thanks for taking the time.  It is possible I re-installed a new version
>>> of VOLK.  I'll try a fresh build and see what that gets me.
>>>
>>> I also should have mentioned that the filter works OK for a while then
>>> segfaults.  A couple of packets always pass through the clock sync block
>>> I'm using before I get the segfault.  Finally, the segfault occurs in the
>>> polyphase clock sync block, do you think I could have mis-configured the
>>> block in some way that will get me this error?  I think the PF clock sync
>>> block is pretty popular so if there's a bug in that block that's causing
>>> this I'd be surprised.
>>>
>>> Devin
>>>
>>> On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller <marcus.muel...@ettus.com
>>> > wrote:
>>>
>>>> Hi Devin,
>>>>
>>>> I don't think it's a kernel problem – all your calculations happen in
>>>> userland, and the kernel has not much to say with respect to the
>>>> instructions used.
>>>>
>>>> The most common reason for this kind of misbehaviour is in fact a
>>>> problem with how the application (in this case, your GNU Radio
>>>> application's block) calls into the library function (in this case the VOLK
>>>> dot produc

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

OK, I tried a brand new GR/Volk install and still had the same problem.  So
no problem with re-linking Volk to GR.  Could this be an issue with Volk on
GCC 4.8.5?  The newest GCC is 6.2 so 4.8.5 is pretty old, though the newest
for Red Hat 7.  Is there any way to reconfigure volk to not use
volk_32fc_32f_dot_prod_32fc_a_avx?

Here's volk-config-info:

$ volk-config-info --all --prefix --cc --cflags --avail-machines --machine
--alignment --malloc
/local_disk/spectrum_challenge
cc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software see the source for copying conditions.  There is NO
warranty not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
/usr/bin/cc:::  -Wall
/usr/bin/c++:::  -Wall
generic_orc:::GNU:::-g  -Wall
sse2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2
sse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3
ssse3_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
sse4_a_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -msse4a
-mpopcnt
sse4_1_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1
sse4_2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1 -msse4.2 -mpopcnt
avx_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1 -msse4.2 -mpopcnt -mavx
avx2_64_mmx_orc:::GNU:::-g  -Wall -m64 -mmmx -msse -msse2 -msse3 -mssse3
-msse4.1 -msse4.2 -mpopcnt -mavx -mfma -mavx2
generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc;sse4_a_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc;
generic_orc;sse2_64_mmx_orc;sse3_64_mmx_orc;ssse3_64_mmx_orc;sse4_1_64_mmx_orc;sse4_2_64_mmx_orc;avx_64_mmx_orc;avx2_64_mmx_orc;
avx2_64_mmx_orc
Alignment in bytes: 32
Used malloc implementation: posix_memalign


Thanks again for any help,
Devin


On Fri, Dec 2, 2016 at 10:04 AM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Oh, that's pretty interesting! Well, no misconfiguration should segfault,
> so I'm a bit stumped at the moment.
>
> On 12/01/2016 06:14 PM, devin kelly wrote:
>
> Marcus,
>
> Thanks for taking the time.  It is possible I re-installed a new version
> of VOLK.  I'll try a fresh build and see what that gets me.
>
> I also should have mentioned that the filter works OK for a while then
> segfaults.  A couple of packets always pass through the clock sync block
> I'm using before I get the segfault.  Finally, the segfault occurs in the
> polyphase clock sync block, do you think I could have mis-configured the
> block in some way that will get me this error?  I think the PF clock sync
> block is pretty popular so if there's a bug in that block that's causing
> this I'd be surprised.
>
> Devin
>
> On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller <marcus.muel...@ettus.com>
> wrote:
>
>> Hi Devin,
>>
>> I don't think it's a kernel problem – all your calculations happen in
>> userland, and the kernel has not much to say with respect to the
>> instructions used.
>>
>> The most common reason for this kind of misbehaviour is in fact a problem
>> with how the application (in this case, your GNU Radio application's block)
>> calls into the library function (in this case the VOLK dot product).
>>
>> Is it possible that for some reason, GNU Radio used a previous version of
>> VOLK when you linked it, and then the new version of VOLK was installed?
>>
>> Best regards,
>>
>> Marcus
>>
>> On 12/01/2016 05:23 PM, devin kelly wrote:
>>
>> Hello,
>>
>> I'm having a problem with the above VOLK function segfaulting.  I don't
>> think I'm passing any incorrect values to VOLK.  My problem could be that
>> I'm on RHEL7 with (obviously) an older kernel:
>>
>> $ uname -a
>> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55
>> EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>>
>> I'm on VOLK 1.3 and GR 3.7.10.1.
>>
>> it segfaults here:
>> https://github.com/gnuradio/volk/blob/maint/kernels/volk/vol
>> k_32fc_32f_dot_prod_32fc.h#L119
>> It looks like aPtr (0x7fea5c3014c0) is somehow not valid.  GR passes this
>> pointer to VOLK so maybe it's a GR problem?
>>
>> I've copied the output of a GDB session and my CPU info below.
>>
>> Thanks for any help,
>> Devin
>>
>>
>>
>> Program terminated with signal 11, Segmentation fault.
>> #0  0x7fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at
>> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
>> 835   return *(__m256 *)__P;
>> Missing separate debuginfos, use: debuginfo-install
>> python-2.7.5-48.el7.x86_64
>> (gdb) bt
>> #0  0x7fea7b1bd8

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

Marcus,

Thanks for taking the time.  It is possible I re-installed a new version of
VOLK.  I'll try a fresh build and see what that gets me.

I also should have mentioned that the filter works OK for a while then
segfaults.  A couple of packets always pass through the clock sync block
I'm using before I get the segfault.  Finally, the segfault occurs in the
polyphase clock sync block, do you think I could have mis-configured the
block in some way that will get me this error?  I think the PF clock sync
block is pretty popular so if there's a bug in that block that's causing
this I'd be surprised.

Devin

On Thu, Dec 1, 2016 at 11:47 AM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Hi Devin,
>
> I don't think it's a kernel problem – all your calculations happen in
> userland, and the kernel has not much to say with respect to the
> instructions used.
>
> The most common reason for this kind of misbehaviour is in fact a problem
> with how the application (in this case, your GNU Radio application's block)
> calls into the library function (in this case the VOLK dot product).
>
> Is it possible that for some reason, GNU Radio used a previous version of
> VOLK when you linked it, and then the new version of VOLK was installed?
>
> Best regards,
>
> Marcus
>
> On 12/01/2016 05:23 PM, devin kelly wrote:
>
> Hello,
>
> I'm having a problem with the above VOLK function segfaulting.  I don't
> think I'm passing any incorrect values to VOLK.  My problem could be that
> I'm on RHEL7 with (obviously) an older kernel:
>
> $ uname -a
> Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55
> EST 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> I'm on VOLK 1.3 and GR 3.7.10.1.
>
> it segfaults here:
> https://github.com/gnuradio/volk/blob/maint/kernels/volk/vol
> k_32fc_32f_dot_prod_32fc.h#L119
> It looks like aPtr (0x7fea5c3014c0) is somehow not valid.  GR passes this
> pointer to VOLK so maybe it's a GR problem?
>
> I've copied the output of a GDB session and my CPU info below.
>
> Thanks for any help,
> Devin
>
>
>
> Program terminated with signal 11, Segmentation fault.
> #0  0x7fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
> 835   return *(__m256 *)__P;
> Missing separate debuginfos, use: debuginfo-install
> python-2.7.5-48.el7.x86_64
> (gdb) bt
> #0  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
> (__P=0x7fea5c3014c0) at /usr/lib/gcc/x86_64-redhat-lin
> ux/4.8.5/include/avxintrin.h:835
> #1  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
> (result=0x3665160, input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_
> dot_prod_32fc.h:119
> #2  0x7fea6661d88f in gr::filter::kernel::fir_filter
> _ccf::filter(std::complex const*) () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0
> #3  0x7fea66c01d01 in 
> gr::digital::pfb_clock_sync_ccf_impl::general_work(int,
> std::vector<int, std::allocator >&, std::vector std::allocator >&, std::vector<void*, std::allocator<void*>
> >&) ()
> at /local_disk/gr_3.7.10.1/lib64/libgnuradio-digital-3.7.10.1.so.0.0.0
> #4  0x7fea7b73fe10 in gr::block_executor::run_one_iteration() () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #5  0x7fea7b781120 in gr::tpb_thread_body::tpb_threa
> d_body(boost::shared_ptr, int) () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #6  0x7fea7b774821 in boost::detail::function::void_
> function_obj_invoker0<gr::thread::thread_body_wrapper,
> void>::invoke(boost::detail::function::function_buffer&) () at
> /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
> #7  0x7fea7b725ef0 in boost::detail::thread_data<boost::function0
> >::run() () at /local_disk/gr_3.7.10.1/lib64/
> libgnuradio-runtime-3.7.10.1.so.0.0.0
> #8  0x7fea7a22427a in thread_proxy () at /lib64/libboost_thread-mt.so.1
> .53.0
> #9  0x7fea960f3dc5 in start_thread () at /lib64/libpthread.so.0
> #10 0x7fea9571973d in clone () at /lib64/libc.so.6
> (gdb) print __P
> $1 = (const float *) 0x7fea5c3014c0
> (gdb) print *__P
> Cannot access memory at address 0x7fea5c3014c0
> (gdb) print *(__m256 *)__P
> Cannot access memory at address 0x7fea5c3014c0
> (gdb) f 1
> #1  volk_32fc_32f_dot_prod_32fc_a_avx (result=0x3665160,
> input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
> /local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_
> dot_prod_32fc.h:119
> 119 a0Val = _mm256_load_ps(aPtr);
> (gdb) info locals
> number = 0
> sixteenthPoints 

[Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

[devin kelly]

Hello,

I'm having a problem with the above VOLK function segfaulting.  I don't
think I'm passing any incorrect values to VOLK.  My problem could be that
I'm on RHEL7 with (obviously) an older kernel:

$ uname -a
Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55
EST 2016 x86_64 x86_64 x86_64 GNU/Linux

I'm on VOLK 1.3 and GR 3.7.10.1.

it segfaults here:
https://github.com/gnuradio/volk/blob/maint/kernels/volk/volk_32fc_32f_dot_prod_32fc.h#L119
It looks like aPtr (0x7fea5c3014c0) is somehow not valid.  GR passes this
pointer to VOLK so maybe it's a GR problem?

I've copied the output of a GDB session and my CPU info below.

Thanks for any help,
Devin



Program terminated with signal 11, Segmentation fault.
#0  0x7fea7b1bd8b7 in _mm256_load_ps (__P=0x7fea5c3014c0) at
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
835   return *(__m256 *)__P;
Missing separate debuginfos, use: debuginfo-install
python-2.7.5-48.el7.x86_64
(gdb) bt
#0  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
(__P=0x7fea5c3014c0) at
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
#1  0x7fea7b1bd8b7 in volk_32fc_32f_dot_prod_32fc_a_avx
(result=0x3665160, input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
/local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:119
#2  0x7fea6661d88f in
gr::filter::kernel::fir_filter_ccf::filter(std::complex const*) ()
at /local_disk/gr_3.7.10.1/lib64/libgnuradio-filter-3.7.10.1.so.0.0.0
#3  0x7fea66c01d01 in
gr::digital::pfb_clock_sync_ccf_impl::general_work(int, std::vector&, std::vector >&, std::vector >&) ()
at /local_disk/gr_3.7.10.1/lib64/libgnuradio-digital-3.7.10.1.so.0.0.0
#4  0x7fea7b73fe10 in gr::block_executor::run_one_iteration() () at
/local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#5  0x7fea7b781120 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) ()
at /local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#6  0x7fea7b774821 in
boost::detail::function::void_function_obj_invoker0::invoke(boost::detail::function::function_buffer&) () at
/local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#7  0x7fea7b725ef0 in boost::detail::thread_data::run() () at
/local_disk/gr_3.7.10.1/lib64/libgnuradio-runtime-3.7.10.1.so.0.0.0
#8  0x7fea7a22427a in thread_proxy () at
/lib64/libboost_thread-mt.so.1.53.0
#9  0x7fea960f3dc5 in start_thread () at /lib64/libpthread.so.0
#10 0x7fea9571973d in clone () at /lib64/libc.so.6
(gdb) print __P
$1 = (const float *) 0x7fea5c3014c0
(gdb) print *__P
Cannot access memory at address 0x7fea5c3014c0
(gdb) print *(__m256 *)__P
Cannot access memory at address 0x7fea5c3014c0
(gdb) f 1
#1  volk_32fc_32f_dot_prod_32fc_a_avx (result=0x3665160,
input=0x7fea5c3014c0, taps=0x3671a00, num_points=47) at
/local_disk/gr_3.7.10.1_src/volk/kernels/volk/volk_32fc_32f_dot_prod_32fc.h:119
119 a0Val = _mm256_load_ps(aPtr);
(gdb) info locals
number = 0
sixteenthPoints = 2
res = {-1.30492652e+29, 0.0779444203}
realpt = 0x7fea57ffde50
imagpt = 0x7fea57ffde54
aPtr = 0x7fea5c3014c0
bPtr = 0x3671a00
a0Val = {-0.656753004, -0.658071458, -0.760932922, -0.762304127,
-0.869615495, -0.869560063, -0.887507021, -0.885902643}
a1Val = {-0.744178772, -0.742508531, -0.437728733, -0.437706977,
-0.0328192525, -0.0346645005, 0.376206338, 0.374125361}
a2Val = {0.711783648, 0.711464763, 0.931477308, 0.933318734, 1.01744843,
1.01973152, 0.954917312, 0.955377996}
a3Val = {0.734342158, 0.732418418, 0.374049634, 0.371605545, -0.0585254543,
-0.0588675328, -0.461206883, -0.458686352}
b0Val = {0.0023738991, 0.0023738991, -0.00534401694, -0.00534401694,
0.00242348039, 0.00242348039, 0.00727195293, 0.00727195293}
b1Val = {-0.0158917159, -0.0158917159, 0.00614725193, 0.00614725193,
0.0485430211, 0.0485430211, -0.22138992, -0.22138992}
b2Val = {0, 0, 0.22138992, 0.22138992, -0.0485430211, -0.0485430211,
-0.00614725193, -0.00614725193}
b3Val = {0.0158917159, 0.0158917159, -0.00727195293, -0.00727195293,
-0.00242348039, -0.00242348039, 0.00534401694, 0.00534401694}
x0Val = {0.0023738991, -0.00534401694, 0.00242348039, 0.00727195293,
-0.0158917159, 0.00614725193, 0.0485430211, -0.22138992}
x1Val = {0, 0.22138992, -0.0485430211, -0.00614725193, 0.0158917159,
-0.00727195293, -0.00242348039, 0.00534401694}
x0loVal = {0.0023738991, 0.0023738991, -0.00534401694, -0.00534401694,
-0.0158917159, -0.0158917159, 0.00614725193, 0.00614725193}
x0hiVal = {0.00242348039, 0.00242348039, 0.00727195293, 0.00727195293,
0.0485430211, 0.0485430211, -0.22138992, -0.22138992}
x1loVal = {0, 0, 0.22138992, 0.22138992, 0.0158917159, 0.0158917159,
-0.00727195293, -0.00727195293}
x1hiVal = {-0.0485430211, -0.0485430211, -0.00614725193, -0.00614725193,
-0.00242348039, -0.00242348039, 0.00534401694, 0.00534401694}
c0Val = {-0.00155906542, 

[Discuss-gnuradio] CMake Linking Problem

[devin kelly]

Hello,

I've created my own GR module with GR mod tool.  I added two files

   include/my_mod/crc.h
   lib/crc.cc

And I can use the functions (crc32 for example) in those files perfectly
fine within classes that wind up in libgnuradio-my_mod.so.  However, I
can't use the functions in crc.h/crc.cc in external applications that link
to libgnuradio-my_mod.so.

The correct symbols exist in libgnuradio-my_mod.so however the symbols are
local, not global.

$ readelf -a lib/libgnuradio-my_mod.so | grep crc32
   192: 00228440  1024 OBJECT  LOCAL  DEFAULT   24 crc32_tab
   426: f3f052 FUNCLOCAL  DEFAULT   11 _Z5crc32jPKvm

How can I expose crc32 to the outside world?  Do I have to make the change
in one of my CMakeLists.txt files or one of the source files?  The function
(crc32) isn't a static.

Thanks for any help,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting values from external program.

[devin kelly]

Jeon,

If you're just trying to get the results from 'hcitool clock', I'd look at
the source code for hcitool and just copy that code.  You'll probably have
to add some extra #includes and link to a few extra libraries.  This way
you won't get any extra latency that's added when you create new processes.

You can start looking here:

http://git.kernel.org/cgit/bluetooth/bluez.git/tree/tools/hcitool.c

Hope this helps,
Devin

On Sat, Oct 15, 2016 at 9:26 AM, Jeon  wrote:

> Thank you, Marcus.
>
> I've implemented code to get MAC address(hcitool dev) in a black class
> constructor.
>
> On the other hand, implementing code to get device's clock (hcitool clock)
> in start() did not work well, maybe due to my little knowledge. Anyway,
> since I have to get clocks repeatedly, I think it's good to implement in
> [general_]work().
>
> Ah, my aim is to build a system that takes Bluetooth device's MAC address
> and clock, and calculates frequency hopping sequence. And finally I want to
> make GNU Radio react to the calculated hop sequence. (Not only sticking on
> simulation).
>
> I'll post again if further progress.
>
> Regards,
> Jeon.
>
> On Wed, Oct 12, 2016 at 9:36 PM, Marcus Müller 
> wrote:
>
>> Hi Jeon,
>>
>> Your use case is not what you'd use controlport for; I think you've got
>> it right: use modtool to create a sync block, but set its number of in- and
>> outputs to zero; override the start() method to spawn a new thread that
>> contains a function which has a loop that executes the external command,
>> publishes a message, and repeat.
>>
>> Anyway, your requirement:
>>
>> > One condition is, I need to retrieve contents from "hcitool clock" as
>> fast as the system (GNU Radio) can.
>>
>> conflicts with the idea of message passing – message passing doesn't
>> allow backpressure, so you'll just flood the message receiver's message
>> input, and that would be useless.
>>
>> What do you want to do with that data? If it's something that makes sense
>> to be understood as stream of samples, go for the classical GNU Radio
>> source block and write the data to the output stream.
>>
>>
>> Best regards,
>>
>> Marcus
>> On 12.10.2016 14:16, Jeon wrote:
>>
>> Just get to the point.
>>
>> I have a Bluetooth dongle connected to my PC. I can read a MAC address
>> and internal clock value by typing `hcitool dev` and `hcitool clock` in
>> command line. You can see demo in link below:
>>
>> http://i.imgur.com/hbQcBQq.png
>>
>> What I want is to make GNU Radio get those values/contents.
>>
>> Currently, I've planned to make a source block expressed in pseudocode:
>>
>> work(args) {
>> file_pointer = popen("hcitool dev"); // or "hcitool clock"
>> buf = read(fp);
>> val = some_char_array_manipulation(buf);
>> publish_message(val);
>> pclose(file_pointer);
>> }
>>
>> Recently, I found that ControlPort can bridge GNU Radio and other
>> programs. Well, however, I am new to ControlPort (just used for
>> PerfMonitor) and seems more complicated than the pseudocode above.
>>
>> Which would you recommend? One condition is, I need to retrieve contents
>> from "hcitool clock" as fast as the system (GNU Radio) can.
>>
>> Regards,
>> Jeon.
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: Correlation Estimator in 3.7.10

[devin kelly]

Steven,

I've had the exact same problem as you - my flowgraphs from 3.7.9 worked
well but now I'm getting a lot of false detections from this block.

Is this really how this block is supposed to perform?  We just have to use
trial and error to find the right threshold?

Thanks For Any Help,
Devin


On Tue, Sep 27, 2016 at 11:37 AM, Steven Knudsen  wrote:

> Alright, after some more thought I believe I understand what is going on.
>
> By looking at the cross-correlation power for the current input samples,
> the threshold can be calculated as a desired false alarm rate. An
> “arbitrary” threshold can be set independently of the received signal power.
>
> Unfortunately, for the test_corr_est.grc example, you just can’t set the
> threshold high enough to avoid false alarms. I tried the CE block with up
> to 0.99 for the threshold and it was still a mess, though much better.
>
> That said, for my own application/flowgraph, setting the CE block
> threshold to 0. appears to work. I can set as “low” as 0.999, but
> that’s it.
>
> This makes me wonder why bother to have a threshold parameter at all?
> Maybe just set the calculated d_pfa value to 10 or something and be done
> with it. Of course, we all hate magic numbers, and so doing would introduce
> a second number to the algorithm (the first is a multiplier of 4 in the
> peak thresholding logic).
>
> Thanks for your patience…
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
> www.linkedin.com/in/knudstevenknudsen
>
> *Von einem gewissen Punkt an gibt es keine Rückkehr mehr. Dieser Punkt ist
> zu erreichen. - Franz Kafka*
>
> Begin forwarded message:
>
> *From: *Steven Knudsen 
> *Subject: **Correlation Estimator in 3.7.10*
> *Date: *September 27, 2016 at 07:40:17 MDT
> *To: *GNURadio Discussion List 
> *Cc: *Knud 
>
> Hi All,
>
> I am pretty confused with some of the changes to the corr_est_cc_impl.cc
> threshold detection algorithm.
>
> Previously, in _set_threshold(), the zero-offset autocorrelation of the
> reference symbols was computed and scaled by the desired relative threshold
> when the correlation estimator is instantiated to provide a fixed (constant
> for the run) threshold (d_thresh). That makes sense to me and appeared to
> work pretty well.
>
> Now, in _set_threshold(), a  is calculated as d_pfa = -logf(1.0f -
> threshold) . In the work function, the detection threshold is calculated
> anew on each invocation as the mean value of the square of the current
> correlation of the reference symbols with the input symbols, scaled by
> d_pfa.
>
> How can the threshold for detecting the peak of the correlation against
> the reference symbols be a function of the input symbols? I know that using
> an absolute threshold based on only the reference symbols may be a problem
> because you can’t know the magnitude of the received input symbols, but I
> think that’s why there is a block callback for set_threshold().
>
> The net result is that when one runs the correlation estimator, a bunch of
> peaks are output in the vicinity of the sync sequence in the input stream.
> The test_corr_est.grc example in gr-digital shows this well.
>
> I checked the commit history and the only relevant comment is “Works with
> arbitrary scaling”. This suggests that the changes are meant to include
> in the threshold the effect of arbitrary input signal power, which does
> make some sense. Again, I thought that was why there was a callback, but
> even that is clunky and I could be wrong.
>
> Anyway, all I know is that the correlation estimator used to work really
> well for me and is now, in my applications, broken badly. Maybe I’m not
> setting it up correctly, but AFAIK the block parameters are the same.
>
> Thanks for your consideration of this question,
>
> steven
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
> www.linkedin.com/in/knudstevenknudsen
>
>
> *All the wires are cut, my friendsLive beyond the severed ends.  Louis
> MacNeice*
>
>
>
> ___
> 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] remove_item_tag()

[devin kelly]

Hello,

I'm interested in editing stream tags.  So far my approach is to read the
tag I'm interested in, copy the value, remove the tag, edit the tag value
and then add the new tag with add_item_tag.

In looking at the GR documentation, the function remove_item_tag says that
the function will be deprecated as of GR 3.8.  What will replace this
function, or what should my GR 3.8 approach be?

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

Re: [Discuss-gnuradio] Using USRP Clock for Timers

[devin kelly]

A different approach makes sense.  What I need this for is doing some book
keeping when certain frame/slots occur.  Since I have a TDMA system, I need
to make sure the metadata (e.g. tx_time tag) I apply to my packets is in
sync with the radio time.  Additionally, the receive time is important to
me (for estimating time of flight - which I do by transmitting the tx_time
in packet payload and subtracting it from rx_time).  So given these two
constraints I figured it would be easiest for me just to use one clock for
everything.

The other approaches I can think of are

1) Sync the PC clock (like I mentioned before)
2) Estimate the clock difference using something like get_time_last_pps()
in a loop (like in new version of query_gpsdo_sensors) and pass around that
offset.

I'm not sure what advantages and disadvantages are to 1) and with 2) it
seems a little cumbersome but do-able.  By the way, I've used the global
block registry for accessing the USRP clock before and that was pretty easy
to use (is is available in Python?).  Is there some other approach I'm
missing?

Devin

On Wed, Jun 8, 2016 at 4:30 PM, Marcus Müller <marcus.muel...@ettus.com>
wrote:

> Hi Devin,
>
> this won't work out for the simple reason that timed commands happen in
> the FPGA on the USRP, and C++ happens in your PC, and the coupling between
> both is loose at best – there's always some random latency bus (network,
> USB,…) between the USRP and the host, and hence, these two clocks never
> agree on how fast time progresses, or how late it actually is.
>
> Now, in my experience, things like these work out if one approaches them
> differently; could you hence explain what you need to be called, and why
> that has to happen at a specific "radio time" (as opposed to "CPU time")?
>
> Best regards,
> Marcus
>
>
> On 08.06.2016 22:22, devin kelly wrote:
>
> Hello,
>
> For my applications the MAC layer of my waveform requires me to implement
> a few timers (e.g. for slot and frame times, etc).
>
> What I'd like to do is exclusively use the USRP clock for these timers.
> I've tried mixing the system clock and the USRP clock before (see a few
> messages on this list from a few months ago) and I couldn't get the
> accuracy I needed.
>
> Is there any way to setup a callback using the USRP clock. Sort of like a
> UHD timed_command except instead of changing the gain, frequency, etc. I
> want to call some C++ function.
>
> Also, I think I could try to sync my PC clock with the USRP clock but it
> seems using "Unknown PPS" or "Don't Sync" are usually recommended but I
> don't understand why.
>
> Thanks,
> Devin
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Using USRP Clock for Timers

[devin kelly]

Hello,

For my applications the MAC layer of my waveform requires me to implement a
few timers (e.g. for slot and frame times, etc).

What I'd like to do is exclusively use the USRP clock for these timers.
I've tried mixing the system clock and the USRP clock before (see a few
messages on this list from a few months ago) and I couldn't get the
accuracy I needed.

Is there any way to setup a callback using the USRP clock. Sort of like a
UHD timed_command except instead of changing the gain, frequency, etc. I
want to call some C++ function.

Also, I think I could try to sync my PC clock with the USRP clock but it
seems using "Unknown PPS" or "Don't Sync" are usually recommended but I
don't understand why.

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

Re: [Discuss-gnuradio] Scrambler - Descrambler

[devin kelly]

Ah, thanks for that, I tried looking for a block that does this and figured
it would be called something like "drop ..." or "discard ...".

This does work but it has it's one problem: My tagged stream to PDU block
has to wait for all the bytes specified by the length_tag to come in before
it forms the PDU.  This means a packet will be delayed until the packet
after it comes in.

For example, if I have a 120 bit (15 byte) packet and I drop the first byte
that comes that comes out of the descrambler I now have the tagged stream
to PDU block receiving 14 bytes and waiting for the descrambler to emit
that last byte (since my packet_len is still 15).  The descrambler will
only emit the last byte when the next packet shows up.

On Tue, Mar 22, 2016 at 1:34 PM, Richard Bell <richard.be...@gmail.com>
wrote:

> I've always used a "skip head" block after the descrambler to remove these
> erroneous items that come out. "skip head" will drop whatever number of
> items on the floor you tell it to and there after pass everything.
>
> Rich
>
> On Tue, Mar 22, 2016 at 10:24 AM, devin kelly <dwwke...@gmail.com> wrote:
>
>> Hi Sean,
>>
>> Thanks for taking the time.  You're definitely right about setting the
>> parameters for the scrambler/descrambler, it seems like I can get my
>> descrambled signal to look pretty close to my original signal or I can
>> totally screw it up by changing the parameters.  What I don't know is
>> whether I can get the output of my descrambler to match the input of my
>> scrambler.
>>
>> With mask = 0x61 and seed = 0x7f I get (the first message is the input to
>> my scrambler and the second is the output):
>>
>> length = 6
>>
>> * MESSAGE DEBUG PRINT PDU VERBOSE *
>> ()
>> pdu_length = 14
>> contents =
>> : d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47 30
>> ***
>> * MESSAGE DEBUG PRINT PDU VERBOSE *
>> ()
>> pdu_length = 14
>> contents =
>> : 00 68 91 f3 6a 10 fc 74 9c 50 27 0c c6 23
>> ***
>>
>>
>> length = 7
>>
>> * MESSAGE DEBUG PRINT PDU VERBOSE *
>> ()
>> pdu_length = 14
>> contents =
>> : d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47 30
>> ***
>> * MESSAGE DEBUG PRINT PDU VERBOSE *
>> ()
>> pdu_length = 14
>> contents =
>> : 06 d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47
>> ***
>>
>> Neither of these messages are what I expect but length = 7 is pretty
>> close.  Does anyone know if it's possible to configure the scrambler and
>> de-scrambler so the message I get out of my descrambler is exactly the same
>> message I put into my scrambler?
>>
>> Thanks,
>> Devin
>>
>> On Tue, Mar 22, 2016 at 11:45 AM, Sean Nowlan <nowl...@gmail.com> wrote:
>>
>>> Devin,
>>>
>>> I haven't used the multiplicative scrambler/descrambler, although I've
>>> used the additive scrambler. Both blocks use the same underlying LFSR
>>> implementation. I noticed that there is some sensitivity in how the LFSR
>>> parameters are specified. Judging by the parameters in your flowgraph,
>>> you're using the polynomial: 0x61 --> 0b111 --> x^6 + x^5 + 1, which is
>>> listed as an example in
>>> gnuradio/gr-digital/include/gnuradio/digital/lfsr.h. This suggests a
>>> degree=6 polynomial. However, according to [1] there is an implied 1 at the
>>> highest order bit, so this is in fact a degree=7 polynomial: x^7 +  x^6 +
>>> x^5 + 1. Also in [1] it mentions that "length" is not the shift register
>>> length but the length of the bit shift when a new bit enters the shift
>>> register. Hence, length should be length=(degree - 1).
>>>
>>> I would modify your scrambler/descrambler parameters to be the following:
>>>
>>> Mask: 0x61 (degree=7)
>>> Seed: 0x7f
>>> Length: 6
>>>
>>> Perhaps the junk you're seeing can be explained by the LFSR
>>> configuration.
>>>
>>> Note that I figured this out by trying to get a compatible LFSR
>>> implementation for the CCITT polynomial x^9 + x^5 + 1, which has an LFSR
>>> specification:
>>>
>>> Mask: 0x21 (degree=9)
>>> Seed: 0x1ff
>>> Length: 8
>>>
>>> [1] https://www.mail-archive.com/patch-gnuradio@gnu.org/msg00180.html
>>> [2] http://cache.nxp.com/files/rf_if/doc/app_note/AN5070.pdf
>>>
>>>
>>> On Mon, Mar 21, 2016 at 2:40 PM, devin k

Re: [Discuss-gnuradio] Scrambler - Descrambler

[devin kelly]

Hi Sean,

Thanks for taking the time.  You're definitely right about setting the
parameters for the scrambler/descrambler, it seems like I can get my
descrambled signal to look pretty close to my original signal or I can
totally screw it up by changing the parameters.  What I don't know is
whether I can get the output of my descrambler to match the input of my
scrambler.

With mask = 0x61 and seed = 0x7f I get (the first message is the input to
my scrambler and the second is the output):

length = 6

* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 14
contents =
: d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47 30
***
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 14
contents =
: 00 68 91 f3 6a 10 fc 74 9c 50 27 0c c6 23
***


length = 7

* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 14
contents =
: d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47 30
***
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 14
contents =
: 06 d0 22 e7 d5 20 f8 e9 38 a1 4e 18 8c 47
***

Neither of these messages are what I expect but length = 7 is pretty
close.  Does anyone know if it's possible to configure the scrambler and
de-scrambler so the message I get out of my descrambler is exactly the same
message I put into my scrambler?

Thanks,
Devin

On Tue, Mar 22, 2016 at 11:45 AM, Sean Nowlan <nowl...@gmail.com> wrote:

> Devin,
>
> I haven't used the multiplicative scrambler/descrambler, although I've
> used the additive scrambler. Both blocks use the same underlying LFSR
> implementation. I noticed that there is some sensitivity in how the LFSR
> parameters are specified. Judging by the parameters in your flowgraph,
> you're using the polynomial: 0x61 --> 0b111 --> x^6 + x^5 + 1, which is
> listed as an example in
> gnuradio/gr-digital/include/gnuradio/digital/lfsr.h. This suggests a
> degree=6 polynomial. However, according to [1] there is an implied 1 at the
> highest order bit, so this is in fact a degree=7 polynomial: x^7 +  x^6 +
> x^5 + 1. Also in [1] it mentions that "length" is not the shift register
> length but the length of the bit shift when a new bit enters the shift
> register. Hence, length should be length=(degree - 1).
>
> I would modify your scrambler/descrambler parameters to be the following:
>
> Mask: 0x61 (degree=7)
> Seed: 0x7f
> Length: 6
>
> Perhaps the junk you're seeing can be explained by the LFSR configuration.
>
> Note that I figured this out by trying to get a compatible LFSR
> implementation for the CCITT polynomial x^9 + x^5 + 1, which has an LFSR
> specification:
>
> Mask: 0x21 (degree=9)
> Seed: 0x1ff
> Length: 8
>
> [1] https://www.mail-archive.com/patch-gnuradio@gnu.org/msg00180.html
> [2] http://cache.nxp.com/files/rf_if/doc/app_note/AN5070.pdf
>
>
> On Mon, Mar 21, 2016 at 2:40 PM, devin kelly <dwwke...@gmail.com> wrote:
>
>> Hello,
>>
>> I'm a little confused on how to use the scrambler and descrambler, it
>> looks like the descrambler always preprends a byte to my stream.  When I
>> run this flowgraph I get this from the message ports (the first message is
>> the original message, the second message is from the descrambler):
>>
>> * MESSAGE DEBUG PRINT PDU VERBOSE *
>> ()
>> pdu_length = 10
>> contents =
>> : d0 22 e7 d5 20 f8 e9 38 a1 4e
>> ***
>> * MESSAGE DEBUG PRINT PDU VERBOSE *
>> ()
>> pdu_length = 10
>> contents =
>> : 06 d0 22 e7 d5 20 f8 e9 38 a1
>> ***
>>
>>
>> I'm not totally sure what do about this, I've tried adding a delay block
>> but that screws up my packet_len tags.
>>
>> Here's the original work function:
>>
>> {
>> const unsigned char *in = (const unsigned char*)input_items[0];
>> unsigned char *out = (unsigned char*)output_items[0];
>>
>> for(int i = 0; i < noutput_items; i++) {
>> out[i] = d_lfsr.next_bit_descramble(in[i]);
>> }
>>
>> return noutput_items;
>> }
>>
>> I've also tried this work function (my approach here is to ignore the
>> first byte out of the descrambler and then put junk into the last byte
>> which would then be ignored on the next call to work() and yes I realize
>> this isn't a general solution)
>>
>> {
>> const unsigned char *in = (const unsigned char*)input_items[0];
>> unsigned char *out = (unsigned char*)output_items[0];
>>
>>   unsigned char junk;
>>   for(int i = 0; i < noutput_items + 8; i++) {
>>   if (i < 8) {
>> junk = d_lfsr.next_bit_descr

[Discuss-gnuradio] Scrambler - Descrambler

[devin kelly]

Hello,

I'm a little confused on how to use the scrambler and descrambler, it looks
like the descrambler always preprends a byte to my stream.  When I run this
flowgraph I get this from the message ports (the first message is the
original message, the second message is from the descrambler):

* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 10
contents =
: d0 22 e7 d5 20 f8 e9 38 a1 4e
***
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 10
contents =
: 06 d0 22 e7 d5 20 f8 e9 38 a1
***


I'm not totally sure what do about this, I've tried adding a delay block
but that screws up my packet_len tags.

Here's the original work function:

{
const unsigned char *in = (const unsigned char*)input_items[0];
unsigned char *out = (unsigned char*)output_items[0];

for(int i = 0; i < noutput_items; i++) {
out[i] = d_lfsr.next_bit_descramble(in[i]);
}

return noutput_items;
}

I've also tried this work function (my approach here is to ignore the first
byte out of the descrambler and then put junk into the last byte which
would then be ignored on the next call to work() and yes I realize this
isn't a general solution)

{
const unsigned char *in = (const unsigned char*)input_items[0];
unsigned char *out = (unsigned char*)output_items[0];

  unsigned char junk;
  for(int i = 0; i < noutput_items + 8; i++) {
  if (i < 8) {
junk = d_lfsr.next_bit_descramble(in[i]);
  } else if (i > noutput_items) {
out[i - 8] = d_lfsr.next_bit_descramble(0xff);
  } else {
out[i - 8] = d_lfsr.next_bit_descramble(in[i]);
  }
  }

return noutput_items;
}

I run the flowgraph and now my last byte is junk (argh!)


***
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 10
contents =
: d0 22 e7 d5 20 f8 e9 38 a1 4e
***
* MESSAGE DEBUG PRINT PDU VERBOSE *
()
pdu_length = 10
contents =
: d0 22 e7 d5 20 f8 e9 38 a1 3d

Does anyone have any advice on how to use to the scrambler and
descrambler?  Would writing my own message blocks that use the LFSR be a
better approach?

Thanks for any help,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Calling start() in gr.sync_block

[devin kelly]

Hello,

I have a block that's like the message strobe - it has one output message
port and no other connections.

For whatever reason GR isn't calling the start() function on my block when
I call top_block.start().  I've written a few other blocks that do this
without any problem but this I can't figure out.


Here's part of my class:

class app_strobe(gr.sync_block):
"""
"""
def __init__(self,
 filename,
 node_id,
 iterations='all',
 repeat=False,
 interval=0.1):
gr.sync_block.__init__(self,
   name="app_strobe",
   in_sig=None,
   out_sig=None)

 self.message_port_register_out(PDUS)

def start(self):

super(gr.sync_block, self).start()
print 'starting'

self.timer = threading.Timer(self.interval, self.callback)
self.timer.start()

Here's my unit test for the block:

def test_001(self):

self.tb = gr.top_block()

self.app_out = swarm_app_strobe("events.csv", 1)
self.app_in = gr.message_debug()

self.tb.msg_connect(self.app_out,
"pdus",
self.app_in,
"store")

self.tb.start()
sleep(5)
self.tb.stop()
self.tb.wait()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[devin kelly]

Thanks for the help, I don't think I could have figured this out on my own.

This is because I'm on RHEL7 (argh!).  My libfftw.so doesn't contain any
references to AVX. For me there are a couple of options for fixing this:

1) Use Nathan's branch.
2) Rebuild fftw with AVX support
3) Rebuild GR and Volk without AVX.

I tried 2) first and noticed this in the spec file that was in the source
RPM I was trying to rebuild:

%ifarch %{ix86} x86_64
# Enable SSE2 support for x86 and x86_64
# (no avx as it is claimed to drastically slower)
for((i=0;i<2;i++)); do
 prec_flags[i]+=" --enable-sse2"
done
%endif

Is the spec file author right?  Now I'm a little confused about the
approach I should take.  I'll probably just go with 1) in the mean time.

Thanks again Nathan,
Devin

On Wed, Mar 9, 2016 at 1:06 AM, West, Nathan <n...@ostatemail.okstate.edu>
wrote:

> The a and c vectors come from gr:fft objects' internal buffers. These are
> internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc).
> fftwf_malloc is obviously not generating buffers with proper alignment so
> you're seeing a 50% (per buffer) that this segfaults. I'll note that this
> is also only an issue with fftwf buffers when fftwf isn't built with AVX
> support (and therefore nothing in fftwf requires  a 32-byte aligned buffer).
>
> Andy Walls (thanks!) pointed out on IRC that we had a similar issue years
> ago with a QT sink.
>
> I have a branch that should fix this (
> https://github.com/n-west/gnuradio/tree/fft-avx-alignment). I also
> suggest you look in to getting a version of fftwf built with AVX. I don't
> know if there's a good way to tell, but if I run readelf -a on my
> libfftw3.so I see some functions with avx in the name.
>
> Cheers,
> nw
>
>
> On Tue, Mar 8, 2016 at 1:31 PM, devin kelly <dwwke...@gmail.com> wrote:
>
>> OK, here's my C program:
>>
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> int main() {
>>
>> size_t alignment = volk_get_alignment();
>>
>> uint8_t* ptr;
>>
>> ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
>> printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr,
>> *ptr);
>> volk_free((void*)ptr);
>> ptr = NULL;
>>
>>
>> return 0;
>> }
>>
>>
>> Compile:
>>
>> $ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib
>>
>> It's output:
>>
>> $ ./volk_test
>> Using Volk machine: avx2_64_mmx_orc
>> alignment = 32, ptr = 151b040, *ptr = 00
>>
>> Also, I've attached the output from the preprocessor, this command:
>>
>> $ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
>> -DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
>> -g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
>> -I/local_disk/gr_3.7.9_src/volk/include
>> -I/local_disk/gr_3.7.9_src/volk/kernels
>> -I/local_disk/gr_3.7.9_src/volk/build_debug/lib
>> -I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
>> volk_malloc_preprocessed   -c
>> /local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c
>>
>> I just found the compiler step from from doing 'VERBOSE=1 make' then
>> changed the output and added -E.  I attached volk_malloc_preprocessed as
>> well.
>>
>> It looks like this is my volk_malloc():
>>
>>
>> void *volk_malloc(size_t size, size_t alignment)
>> {
>>   void *ptr;
>>
>>
>>
>>
>>   if (alignment == 1)
>> return malloc(size);
>>
>>   int err = posix_memalign(, alignment, size);
>>   if(err == 0) {
>> return ptr;
>>   }
>>   else {
>> fprintf(stderr,
>> "VOLK: Error allocating memory "
>> "(posix_memalign: error %d: %s)\n", err, strerror(err));
>> return ((void *)0);
>>   }
>> }
>>
>>
>>
>> Devin
>>
>>
>>
>> On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan <
>> n...@ostatemail.okstate.edu> wrote:
>>
>>>
>>> On Tue, Mar 8, 2016 at 10:58 AM, devin kelly <dwwke...@gmail.com> wrote:
>>>
>>>> Calling 'info variables' (or args or locals) the last few frames didn't
>>>> give me any real info so I built a copy of GR/Volk with debug symbols.  I
>>>> ran the FG again, this time from GDB, here's my back trace.  In this
>>>> backtrace you can see the arguments passed in each call.  I have an
>>>> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>>>

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[devin kelly]

OK, here's my C program:

#include 
#include 
#include 
#include 

int main() {

size_t alignment = volk_get_alignment();

uint8_t* ptr;

ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr, *ptr);
volk_free((void*)ptr);
ptr = NULL;


return 0;
}


Compile:

$ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib

It's output:

$ ./volk_test
Using Volk machine: avx2_64_mmx_orc
alignment = 32, ptr = 151b040, *ptr = 00

Also, I've attached the output from the preprocessor, this command:

$ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
-DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
-g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
-I/local_disk/gr_3.7.9_src/volk/include
-I/local_disk/gr_3.7.9_src/volk/kernels
-I/local_disk/gr_3.7.9_src/volk/build_debug/lib
-I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
volk_malloc_preprocessed   -c
/local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c

I just found the compiler step from from doing 'VERBOSE=1 make' then
changed the output and added -E.  I attached volk_malloc_preprocessed as
well.

It looks like this is my volk_malloc():


void *volk_malloc(size_t size, size_t alignment)
{
  void *ptr;




  if (alignment == 1)
return malloc(size);

  int err = posix_memalign(, alignment, size);
  if(err == 0) {
return ptr;
  }
  else {
fprintf(stderr,
"VOLK: Error allocating memory "
"(posix_memalign: error %d: %s)\n", err, strerror(err));
return ((void *)0);
  }
}



Devin



On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan <n...@ostatemail.okstate.edu>
wrote:

>
> On Tue, Mar 8, 2016 at 10:58 AM, devin kelly <dwwke...@gmail.com> wrote:
>
>> Calling 'info variables' (or args or locals) the last few frames didn't
>> give me any real info so I built a copy of GR/Volk with debug symbols.  I
>> ran the FG again, this time from GDB, here's my back trace.  In this
>> backtrace you can see the arguments passed in each call.  I have an
>> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>>
>
> Excellent. Thanks for going through that extra step. It really helps.
>
>
>>
>> Here's are the links for the relevant code:
>>
>>
>> https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
>>
>> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323
>>
>> https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_cc_impl.cc#L214
>>
>> Could the problem be that nitems is 257 and num_points is 512?  Or should
>> nitems really be 256 and not 257?
>>
>
> I don't think so. I'm not familiar with the details of the fft_filter
> implementations, but usually these things will take in some history if they
> don't have enough points to operate on (in this case 512).
>
> The much more worrying thing is your vector addresses.
>
>
>>
>> Thanks,
>> Devin
>>
>> (gdb) bt
>> #0  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
>> (__P=0x3b051b0)
>> at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
>> #1  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
>> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
>>
>
> 0x3b1f770 % 32 = 16 (bad)
> 0x3b051b0 % 32 = 16 (bad)
> 0x3b240e0 % 32 = 0 (good)
>
> Unfortunately it looks like volk_get_alignment is returning the wrong
> thing or there's a bug in volk_malloc. Can you tell us what
> volk_get_alignment returns? The easiest thing is probably to write a simple
> C program that prints out the result (hmm, I should add that to
> volk-config-info). I'd also like to know which volk_malloc implementation
> you're using. Unfortunately I don't think we have an easy way to discover
> that (hmm, something else that should be added to volk-config-info). I
> think the best way might be to look at volk_malloc.c intermediate files
> after the preprocessor has done its work.
>
> If you want to move on while we figure this out then you can edit
> ~/.volk/volk_config and replace the avx2_fma with sse3 on the line that has
> this kernel name on it.
>
>
>> at
>> /local_disk/gr_3.7.9_src/volk/kernels/volk/volk_32fc_x2_multiply_32fc.h:242
>> #2  0x7fffdc945a75 in __volk_32fc_x2_multiply_32fc_a
>> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
>> at /local_disk/gr_3.7.9_src/volk/build_debug/lib/volk.c:7010
>> #3  0x7fffd3f8e360 in gr::f

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[devin kelly]

Here's a simpler FG that I can use to reproduce this error.  Hopefully it
actually works for someone else.

Devin

On Tue, Mar 8, 2016 at 10:58 AM, devin kelly <dwwke...@gmail.com> wrote:

> Calling 'info variables' (or args or locals) the last few frames didn't
> give me any real info so I built a copy of GR/Volk with debug symbols.  I
> ran the FG again, this time from GDB, here's my back trace.  In this
> backtrace you can see the arguments passed in each call.  I have an
> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>
> Here's are the links for the relevant code:
>
>
> https://github.com/gnuradio/volk/blob/f0b722392950bf7ede7b32f5ff60019bce7a8592/kernels/volk/volk_32fc_x2_multiply_32fc.h#L232
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-filter/lib/fft_filter.cc#L323
>
> https://github.com/gnuradio/gnuradio/blob/222e0003f9797a1b92d64855bd2b93f0d9099f93/gr-digital/lib/corr_est_cc_impl.cc#L214
>
> Could the problem be that nitems is 257 and num_points is 512?  Or should
> nitems really be 256 and not 257?
>
> Thanks,
> Devin
>
> (gdb) bt
> #0  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
> (__P=0x3b051b0)
> at /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
> #1  0x7fffdcaccb57 in volk_32fc_x2_multiply_32fc_a_avx2_fma
> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
> at
> /local_disk/gr_3.7.9_src/volk/kernels/volk/volk_32fc_x2_multiply_32fc.h:242
> #2  0x7fffdc945a75 in __volk_32fc_x2_multiply_32fc_a
> (cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
> at /local_disk/gr_3.7.9_src/volk/build_debug/lib/volk.c:7010
> #3  0x7fffd3f8e360 in gr::filter::kernel::fft_filter_ccc::filter(int,
> std::complex const*, std::complex*) (this=0x3b02f40,
> nitems=nitems@entry=257, input=input@entry=0x7fffc9cc7000,
> output=output@entry=0x3b36460)
> at /local_disk/gr_3.7.9_src/gnuradio/gr-filter/lib/fft_filter.cc:323
> #4  0x7fffd42910df in gr::digital::corr_est_cc_impl::work(int,
> std::vector >&, std::vector<void*,
> std::allocator<void*> >&) (this=0x3b01560, noutput_items=257,
> input_items=..., output_items=std::vector of length 1, capacity 1 = {...})
> at
> /local_disk/gr_3.7.9_src/gnuradio/gr-digital/lib/corr_est_cc_impl.cc:237
> #5  0x7fffdd064907 in gr::sync_block::general_work(int,
> std::vector<int, std::allocator >&, std::vector std::allocator >&, std::vector<void*, std::allocator<void*>
> >&) (this=0x3b015b8, noutput_items=, ninput_items=...,
> input_items=..., output_items=...) at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/sync_block.cc:66
> #6  0x7fffdd02f70f in gr::block_executor::run_one_iteration()
> (this=this@entry=0x7fff83ffedb0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/block_executor.cc:438
> #7  0x7fffdd06da8a in
> gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int)
> (this=0x7fff83ffedb0, block=..., max_noutput_items=) at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/tpb_thread_body.cc:122
> #8  0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0<gr::thread::thread_body_wrapper,
> void>::invoke(boost::detail::function::function_buffer&) (this=0x3bc3ec0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/lib/scheduler_tpb.cc:44
> #9  0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0<gr::thread::thread_body_wrapper,
> void>::invoke(boost::detail::function::function_buffer&) (this=0x3bc3ec0)
> at
> /local_disk/gr_3.7.9_src/gnuradio/gnuradio-runtime/include/gnuradio/thread/thread_body_wrapper.h:51
> #10 0x7fffdd062761 in
> boost::detail::function::void_function_obj_invoker0<gr::thread::thread_body_wrapper,
> void>::invoke(boost::detail::function::function_buffer&)
> (function_obj_ptr=...) at
> /usr/include/boost/function/function_template.hpp:153
> #11 0x7fffdd016cd0 in
> boost::detail::thread_data<boost::function0 >::run() (this= out>)
> at /usr/include/boost/function/function_template.hpp:767
> #12 0x7fffdd016cd0 in
> boost::detail::thread_data<boost::function0 >::run() (this= out>)
> at /usr/include/boost/thread/detail/thread.hpp:117
> #13 0x7fffdbe4f24a in thread_proxy () at
> /lib64/libboost_thread-mt.so.1.53.0
> #14 0x77800dc5 in start_thread () at /lib64/libpthread.so.0
> #15 0x76e2528d in clone () at /lib64/libc.so.6
>
> Here are the locals on the last few frames:
>
> (gdb) f 0
> #0  0x7fffdcaccb57 in _mm256_load_ps (__P=0x3b051b0) at
> /usr/lib/gcc/x86_64-redhat-linux/4.8.5/include/avxintrin.h:835
>

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[devin kelly]

-3.64918089,
-4.92134571, -1.06491208}
yl = {4.14784345e-43, 0, 1.26116862e-44, 0, -4.87442367e+17,
4.59163468e-41, -4.87439343e+17, 4.59163468e-41}
yh = {-1674752, 4.59163468e-41, 0, 0, -1.50397414e-36, 4.59163468e-41,
-3.31452625e+17, 4.59163468e-41}
tmp2 = {6.72623263e-44, 1.2751816e-43, 2.24207754e-44, 0, 7.17464814e-43,
0, -3.31440427e+17, 4.59163468e-41}
z = {0.794147611, 0, 0.263988227, 0, -0.380019426, 0, -0.953325868, 0}
number = 0
quarterPoints = 128
c = 0x3b1f770
a = 0x3b051b0
b = 0x3b240e0
(gdb) f 2
#2  0x7fffdc945a75 in __volk_32fc_x2_multiply_32fc_a
(cVector=0x3b1f770, aVector=0x3b051b0, bVector=0x3b240e0, num_points=512)
at /local_disk/gr_3.7.9_src/volk/build_debug/lib/volk.c:7010
7010volk_32fc_x2_multiply_32fc_a(cVector, aVector, bVector,
num_points);
(gdb) info locals
No locals.
(gdb) f 3
#3  0x7fffd3f8e360 in gr::filter::kernel::fft_filter_ccc::filter
(this=0x3b02f40, nitems=nitems@entry=257,
input=input@entry=0x7fffc9cc7000, output=output@entry=0x3b36460) at
/local_disk/gr_3.7.9_src/gnuradio/gr-filter/lib/fft_filter.cc:323
323   volk_32fc_x2_multiply_32fc_a(c, a, b, d_fftsize);
(gdb) info locals
a = 
b = 
c = 
i = 0
dec_ctr = 0
j = 
ninput_items = 257

My volk profile results:

$  volk_profile -R 32fc_x2_multiply
Using Volk machine: avx2_64_mmx_orc
RUN_VOLK_TESTS: volk_32fc_x2_multiply_32fc(131071,1987)
u_avx2_fma completed in 220ms
u_avx completed in 220ms
u_sse3 completed in 240ms
generic completed in 2810ms
a_avx2_fma completed in 200ms
a_avx completed in 220ms
a_sse3 completed in 230ms
a_generic completed in 2810ms
u_orc completed in 280ms
Best aligned arch: a_avx2_fma
Best unaligned arch: u_avx2_fma
RUN_VOLK_TESTS: volk_32fc_x2_multiply_conjugate_32fc(131071,1987)
u_avx completed in 230ms
u_sse3 completed in 230ms
generic completed in 2790ms
a_avx completed in 220ms
a_sse3 completed in 230ms
a_generic completed in 2800ms
Best aligned arch: a_avx
Best unaligned arch: u_avx
Writing "/home/devin/.volk/volk_config"...




On Mon, Mar 7, 2016 at 10:38 PM, West, Nathan <n...@ostatemail.okstate.edu>
wrote:

> On Mon, Mar 7, 2016 at 10:18 PM, West, Nathan <n...@ostatemail.okstate.edu
> > wrote:
>
>> On Mon, Mar 7, 2016 at 2:32 PM, devin kelly <dwwke...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I've built a flowgraph (grc, python attached) that usually (but not
>>> always) produces a segfaults in volk_32fc_x2_multiply_32fc_a_avx2_fma.  The
>>> segfault occurs in the FFT filter in correlation estimator block.  I'm not
>>> sure if it's the Volk code that's causing the segfault or the GR code
>>> calling it or what I'm putting into GR.  I've got a back trace below if
>>> that helps.
>>>
>>> Also, at the tag gate in my flowgraph I would usually have a USRP
>>> transmitter and a USRP receiver in a before the Correlation Estimate in a
>>> separate flowgraph but since I can re-create the segfault in the flowgraph
>>> I simplified.
>>>
>>> I'm using GR 3.7.9, Volk 1.2.1 and UHD 3.9.2 (though I don't call any
>>> UHD code here).
>>>
>>> Thanks for any help,
>>> Devin
>>>
>>> $ gdb /usr/bin/python core.13408
>>> GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
>>> Copyright (C) 2013 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <
>>> http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.  Type "show
>>> copying"
>>> and "show warranty" for details.
>>> This GDB was configured as "x86_64-redhat-linux-gnu".
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>...
>>> Reading symbols from /usr/bin/python2.7...Reading symbols from
>>> /usr/bin/python2.7...(no debugging symbols found)...done.
>>> (no debugging symbols found)...done.
>>>
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>> Core was generated by `python2 ./segfault_test.py'.
>>> Program terminated with signal 11, Segmentation fault.
>>> #0  0x7f11a4d064c0 in volk_32fc_x2_multiply_32fc_a_avx2_fma () from
>>> /local_disk/gr_3.7.9/lib/libvolk.so.1.2.1
>>> Missing separate debuginfos, use: debuginfo-install
>>> python-2.7.5-34.el7.x86_64
>>> (gdb) bt
>>> #0  0x7f11a4d064c0 in volk_32fc_x2_multiply_32fc_a_avx2_fma () at
>>> /local_disk/gr_3.7.9/lib/libvolk.so.1.2.1
>>> #1  0x7f119c1d0006 in
>>> gr::filter::kernel::fft_filter_ccc::f

[Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[devin kelly]

Hello,

I've built a flowgraph (grc, python attached) that usually (but not always)
produces a segfaults in volk_32fc_x2_multiply_32fc_a_avx2_fma.  The
segfault occurs in the FFT filter in correlation estimator block.  I'm not
sure if it's the Volk code that's causing the segfault or the GR code
calling it or what I'm putting into GR.  I've got a back trace below if
that helps.

Also, at the tag gate in my flowgraph I would usually have a USRP
transmitter and a USRP receiver in a before the Correlation Estimate in a
separate flowgraph but since I can re-create the segfault in the flowgraph
I simplified.

I'm using GR 3.7.9, Volk 1.2.1 and UHD 3.9.2 (though I don't call any UHD
code here).

Thanks for any help,
Devin

$ gdb /usr/bin/python core.13408
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python2.7...Reading symbols from
/usr/bin/python2.7...(no debugging symbols found)...done.
(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 13431]
[New LWP 13432]
[New LWP 13408]
[New LWP 13417]
[New LWP 13424]
[New LWP 13418]
[New LWP 13419]
[New LWP 13425]
[New LWP 13426]
[New LWP 13423]
[New LWP 13421]
[New LWP 13429]
[New LWP 13428]
[New LWP 13434]
[New LWP 13430]
[New LWP 13427]
[New LWP 13433]
[New LWP 13420]
[New LWP 13422]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `python2 ./segfault_test.py'.
Program terminated with signal 11, Segmentation fault.
#0  0x7f11a4d064c0 in volk_32fc_x2_multiply_32fc_a_avx2_fma () from
/local_disk/gr_3.7.9/lib/libvolk.so.1.2.1
Missing separate debuginfos, use: debuginfo-install
python-2.7.5-34.el7.x86_64
(gdb) bt
#0  0x7f11a4d064c0 in volk_32fc_x2_multiply_32fc_a_avx2_fma () at
/local_disk/gr_3.7.9/lib/libvolk.so.1.2.1
#1  0x7f119c1d0006 in gr::filter::kernel::fft_filter_ccc::filter(int,
std::complex const*, std::complex*) ()
at /local_disk/gr_3.7.9/lib64/libgnuradio-filter-3.7.9.so.0.0.0
#2  0x7f119c4d724f in gr::digital::corr_est_cc_impl::work(int,
std::vector >&, std::vector<void*,
std::allocator<void*> >&) () at
/local_disk/gr_3.7.9/lib64/libgnuradio-digital-3.7.9.so.0.0.0
#3  0x7f11a52b1f57 in gr::sync_block::general_work(int,
std::vector<int, std::allocator >&, std::vector >&, std::vector<void*, std::allocator<void*>
>&) () at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
#4  0x7f11a527a6bd in gr::block_executor::run_one_iteration() () at
/local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
#5  0x7f11a52baf60 in
gr::tpb_thread_body::tpb_thread_body(boost::shared_ptr, int) ()
at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
#6  0x7f11a52aebc1 in
boost::detail::function::void_function_obj_invoker0<gr::thread::thread_body_wrapper,
void>::invoke(boost::detail::function::function_buffer&) () at
/local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
#7  0x7f11a5260910 in boost::detail::thread_data<boost::function0
>::run() ()
at /local_disk/gr_3.7.9/lib64/libgnuradio-runtime-3.7.9.so.0.0.0
#8  0x7f11a40b824a in thread_proxy () at
/lib64/libboost_thread-mt.so.1.53.0
#9  0x7f11bfa38dc5 in start_thread () at /lib64/libpthread.so.0
#10 0x7f11bf05d28d in clone () at /lib64/libc.so.6
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: segfault_test
# Author: Devin Kelly
# Generated: Mon Mar  7 14:21:06 2016
##

if __name__ == '__main__':
import ctypes
import sys
if sys.platform.startswith('linux'):
try:
x11 = ctypes.cdll.LoadLibrary('libX11.so')
x11.XInitThreads()
except:
print "Warning: failed to XInitThreads()"

from PyQt4 import Qt
from gnuradio import blocks
from gnuradio import digital
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import qtgui
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from gnuradio.qtgui import Range, RangeWidget
from optparse import OptionParser
import pmt
import sip
import sys


class segfault_test(gr.top_block, Qt.QWidget):

def __init__(self):
gr.top_block.__init__(self, "segfault_test")
Qt.QWidget.__init__(s

[Discuss-gnuradio] Bursty Flowgraph Problem

[devin kelly]

Hello,

I have a flowgraph where I make some random PDUs, prepend an access code
and preamable (Do I need both?).  I modulate and demodulate, find the
packet with Correlate Access Code, separate the header and payload, and
then print the message with Message Debug.

My problem is with the modulator and demodulator, when I include them my
receiver stops printing out messages.  When I disable Constellation
Modulator and Constellation Receiver (i.e. connect the "transmit" virtual
source to the "receive" virtual source) the receiver works fine.

I can't seem to figure this out, I've tried multiple modulators and
demodulators, what am I missing?   I am doing something wrong with the
matched filter?

I've attached the GRC file, if anyone could take the time to take a look
I'd appreciate it.

Devin


burst_test.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] PDU Message Structure

[devin kelly]

Hello,

I have a block that emits pmt::dict messages.  I'd like to connect it to a
PDU to Tagged Stream block.

My problem is that a dict isn't a pair and I run into this error:

https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/pdu_to_tagged_stream_impl.cc#L63

If I place the dict in a pair, I won't get that error but I do get another
error telling me my data needs to be a uniform vector.

The dict has multiple data types in it so I'm not sure what the best way to
proceed is.  What's a good way to (a good way to GR I mean) structure my
messages?  Make them pairs where the first part is metadata and the second
is a uniform vector?

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

Re: [Discuss-gnuradio] USRP's not Communicating

[devin kelly]

Ah sorry I wasn't specific.  This was from years ago, the numbers I used
were just meant to be an example, not accurate.

On Tue, Aug 25, 2015 at 10:25 PM, Marcus D. Leech mle...@ripnet.com wrote:

 On 08/25/2015 10:17 PM, devin kelly wrote:

 You can have each USRP on the same computer or not, that shouldn't matter.

 I've done this test with some USRP2's and I remember what we did was
 transmit a CW tone from one to another and measure a frequency offset
 (maybe 10s of kHz?).  Basically, transmit a tone at some known frequency
 (like 200 MHz) and measure the received frequency (maybe something like
 200.02 MHz) and then add the 0.02 into you center frequency for this test.

 You can also just synchronize the USRPs with a 10MHz reference and 1PPS.

 Devin

 The USRP2 uses a 2.5PPM master on-board clock, so at 200Mhz tuned
 frequency, the max it can be off is about 500Hz.  For narrowband
 transmission,
   that may be too much, but I'd be very surprised to see 20kHz offset with
 a 200MHz carrier.




 On Tue, Aug 25, 2015 at 5:14 PM, John Garrick li...@ruby-forum.com
 wrote:

 Hello,

 I want to transmit the data between two USRP's and make them communicate
 with each other. But I guess the packets are not being received
 properly.
 I am connected the two USRP's to the same laptop and trying it. Is that
 applicable? I mean, will it work if I do that? Or should I connect to
 two computers and perform that? I have been receiving this error.

 linux; GNU C++ version 4.8.4; Boost_105500;
 UHD_003.009.git-144-g407e3086

 Using Volk machine: avx_64_mmx
 -- Opening a USRP1 device...
 -- Using FPGA clock rate of 64.00MHz...

 No gain specified.
 Setting gain to 56.25 (from [0.00, 112.50])

 UHD Warning:
 The hardware does not support the requested RX sample rate:
 Target sample rate: 0.05 MSps
 Actual sample rate: 0.25 MSps

 Symbol Rate: 25000.00
 Requested sps:   2.00
 Given sample rate:   25.00
 Actual sps for rate: 10.00

 Requested sample rate: 5.00
 Actual sample rate: 25.00
 ok = False  pktno = 53034  n_rcvd =1  n_right =0
 ok = False  pktno =   24  n_rcvd =2  n_right =0
 ok = False  pktno =   35  n_rcvd =3  n_right =0
 ok = False  pktno =   44  n_rcvd =4  n_right =0
 ok = False  pktno =   46  n_rcvd =5  n_right =0
 ok = False  pktno =   46  n_rcvd =6  n_right =0
 ok = False  pktno = 3872  n_rcvd =7  n_right =0
 ok = False  pktno = 12304  n_rcvd =8  n_right =0
 ok = False  pktno =   49  n_rcvd =9  n_right =0
 ok = False  pktno =   50  n_rcvd =   10  n_right =0
 ok = False  pktno =   54  n_rcvd =   11  n_right =0
 ok = False  pktno =  200  n_rcvd =   12  n_right =0
 ok = False  pktno =   63  n_rcvd =   13  n_right =0

 Please suggest. Thank you

 Regards,
 Ravi

 --
 Posted via http://www.ruby-forum.com/.

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




 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio



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


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

Re: [Discuss-gnuradio] USRP's not Communicating

[devin kelly]

You can have each USRP on the same computer or not, that shouldn't matter.

I've done this test with some USRP2's and I remember what we did was
transmit a CW tone from one to another and measure a frequency offset
(maybe 10s of kHz?).  Basically, transmit a tone at some known frequency
(like 200 MHz) and measure the received frequency (maybe something like
200.02 MHz) and then add the 0.02 into you center frequency for this test.

You can also just synchronize the USRPs with a 10MHz reference and 1PPS.

Devin

On Tue, Aug 25, 2015 at 5:14 PM, John Garrick li...@ruby-forum.com wrote:

 Hello,

 I want to transmit the data between two USRP's and make them communicate
 with each other. But I guess the packets are not being received
 properly.
 I am connected the two USRP's to the same laptop and trying it. Is that
 applicable? I mean, will it work if I do that? Or should I connect to
 two computers and perform that? I have been receiving this error.

 linux; GNU C++ version 4.8.4; Boost_105500;
 UHD_003.009.git-144-g407e3086

 Using Volk machine: avx_64_mmx
 -- Opening a USRP1 device...
 -- Using FPGA clock rate of 64.00MHz...

 No gain specified.
 Setting gain to 56.25 (from [0.00, 112.50])

 UHD Warning:
 The hardware does not support the requested RX sample rate:
 Target sample rate: 0.05 MSps
 Actual sample rate: 0.25 MSps

 Symbol Rate: 25000.00
 Requested sps:   2.00
 Given sample rate:   25.00
 Actual sps for rate: 10.00

 Requested sample rate: 5.00
 Actual sample rate: 25.00
 ok = False  pktno = 53034  n_rcvd =1  n_right =0
 ok = False  pktno =   24  n_rcvd =2  n_right =0
 ok = False  pktno =   35  n_rcvd =3  n_right =0
 ok = False  pktno =   44  n_rcvd =4  n_right =0
 ok = False  pktno =   46  n_rcvd =5  n_right =0
 ok = False  pktno =   46  n_rcvd =6  n_right =0
 ok = False  pktno = 3872  n_rcvd =7  n_right =0
 ok = False  pktno = 12304  n_rcvd =8  n_right =0
 ok = False  pktno =   49  n_rcvd =9  n_right =0
 ok = False  pktno =   50  n_rcvd =   10  n_right =0
 ok = False  pktno =   54  n_rcvd =   11  n_right =0
 ok = False  pktno =  200  n_rcvd =   12  n_right =0
 ok = False  pktno =   63  n_rcvd =   13  n_right =0

 Please suggest. Thank you

 Regards,
 Ravi

 --
 Posted via http://www.ruby-forum.com/.

 ___
 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] Padding burtsy blocks

[devin kelly]

I have a flowgraph that I'm trying to develop in simulation first before
deploying to some sort of hardware like a USRP.  The flowgraph begins with
a ZMQ Pull Source and then I have all my signal processing blocks
afterwards (eventually there would be a UHD Sink).  The ZMQ block only
produces samples when it receives a message so when it doesn't receive
samples the flowgraph doesn't run.

If the work function for any block is only called when there are samples in
the input buffer I don't see how adding any blocks after my ZMQ Pull Source
could help.  So that leaves making my own ZMQ Pull Source that emits zeros
when it has no other message.  Do I have any other options?  If I add a
this feature would be useful to merge back into GR or is this not really an
intended use case for GR?

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

Re: [Discuss-gnuradio] Enveloping a transmit amplifier

[devin kelly]

For anyone interested I took this to the USRP Users list and got the issue
resolved.

The gist of it was that none of the GPIO code got moved into any of the
releases until UHD 3.9.

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-August/015455.html

On Wed, Aug 19, 2015 at 2:44 PM, devin kelly dwwke...@gmail.com wrote:

 I tried this out and I'm having some problems.  I'm on GR 3.7.8 and UHD
 3.8.5, both the newest as far as I know.

 What I did was make a flowgraph with a signal generator source and a UHD
 sink in GRC.   It works before I made any modifications.  There are a few
 lines in top_block.py that set the sample rate, antenna, etc.  At the end
 of them I added this:

 self.uhd_usrp_sink_0.set_gpio_attr(TXA, ATR_TX, 1, 0x10, 0)


 It should set pin 4 high whenever I transmit (right?).  I run my flowgraph
 and get this traceback:

 Traceback (most recent call last):
   File top_block.py, line 76, in module
 tb = top_block()
   File top_block.py, line 55, in __init__
 self.uhd_usrp_sink_0.set_gpio_attr(TXA, ATR_TX, 1, 0x10, 0)
   File
 /usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py, line
 4539, in set_gpio_attr
 return _uhd_swig.usrp_sink_sptr_set_gpio_attr(self, bank, attr, value,
 mask, mboard)
 RuntimeError: LookupError: Path not found in tree:
 /mboards/0/dboards/A/iface


 I know I'm using the right banks because I can do this command:

 $ python -c 'from gnuradio import uhd; usrp =
 uhd.multi_usrp_sink(serial=removed, uhd.io_type.COMPLEX_FLOAT32, 1);
 print usrp.get_gpio_banks(0)'


 and get

 ('RXA', 'TXA')

 I also run this command:

 uhd_usrp_probe --args='serial=removed' --tree | grep -i iface

 and get nothing.  Without piping into grep I get 177 lines that all seem
 to make sense to me.

 Is that command I'm using correct or is there some other issue?

 Thanks,
 Devin

 On Wed, Aug 19, 2015 at 8:09 AM, devin kelly dwwke...@gmail.com wrote:

 Marcus,

 Thanks for the advice, this seems to do exactly what I'm looking for.  My
 only question is that I've been under the impression that the UHD doesn't
 yet support GPIO for the B210.  I did recently upgrade to 3.8.5 though so
 maybe things have changed?

 Devin

 On Wed, Aug 19, 2015 at 5:43 AM, Marcus Müller marcus.muel...@ettus.com
 wrote:

 Hi Devin,

 You wanted to ramp up/down the external PA: Use the GPIO pins, and the
 ATR registers [1] or timed commands issued over the message bus [2] to
 change their state

 Best regards,
 Marcus

 [1] http://files.ettus.com/manual/page_gpio_api.html#xgpio_fpanel_atr
 [2] http://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
 On 08/18/2015 09:17 PM, devin kelly wrote:

 Hello,
 0
 I'm transmitting a fairly bursty, irregularly timed signal.  I attach a
 stream tag to the sample that has the start of the burst (tx_sob).  I also
 have a PA that I can turn on and off that's inbetween my USRP B210 and
 antenna.

 I'd like to be able to turn the PA on and off synchronously, say 50 ms
 before tx_sob is to be transmitted.

 Is there any way to do this?  I'm thinking I could add a new tag that's
 50 ms before my transmission but then how would I synchronously turn on the
 PA?  Is there something like a callback function I can use?  Does the UHD
 or the UHD block have this functionality?

 Thanks for any help,
 Devin


 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio



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




 --
 http://alum.wpi.edu/~dkelly/




 --
 http://alum.wpi.edu/~dkelly/

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

Re: [Discuss-gnuradio] Help with building GNU Radio for Android

[devin kelly]

I found the section of code the python NDK is complaining about:

#ifndef LONG_BIT
#define LONG_BIT (8 * SIZEOF_LONG)
#endif

#if LONG_BIT != 8 * SIZEOF_LONG
/* 04-Oct-2000 LONG_BIT is apparently (mis)defined as 64 on some recent
 * 32-bit platforms using gcc.  We try to catch that here at compile-time
 * rather than waiting for integer multiplication to trigger bogus
 * overflows.
 */
#error LONG_BIT definition appears wrong for platform (bad gcc/glibc
config?).
#endif


So it looks like maybe SIZEOF_LONG is what's really not properly defined.
I then found this python mailing list post:

https://mail.python.org/pipermail/python-bugs-list/2004-November/026111.html

The first poster says that this will limit python to only using glibc
systems, which makes total sense here given that Android uses bionic not
glibc.  What I don't understand is that bionic seems to define LONG_BIT,
SIZEOF_LONG etc correctly:

https://github.com/android/platform_bionic/blob/d717b1a3e55db9b7625a46bec950e856cc107951/libc/include/sys/limits.h

So what's it complaining about?

Devin

On Thu, Aug 20, 2015 at 10:43 AM, Tom Rondeau t...@trondeau.com wrote:

 On Mon, Aug 17, 2015 at 7:28 PM, Schuyler St. Leger 
 schuyler.st.le...@gmail.com wrote:

 I am trying to build GNU Radio for Android and am having issues with the
 build process.

 I first tried building GNU Radio for Android on Mac OS X 10.10.4. I was
 able to follow the directions successfully until I had to build gr-grand.
 When I tried to build gr-grand I got this error (see error 1). I have tried
 searching for this error, but have not found any useful information from my
 search. I am not sure if this is an error with the build procedure, or if
 it is an error with the Android NDK and Python.



 We'll have to spend some time looking into this. Most of use working on
 the Android stuff are using Linux -- generally Ubuntu, either 14.04 or
 15.04 (I use both versions, depending on which machine I'm on). This could
 be a conflict with the installed Python and the one in the SDK, or possibly
 just a bug in the SDK.

 Although, now that I think about it, there's no reason to SWIG gr-grand.
 You'll never use that in Python on Android; we only use the c++ library
 out, and specifically the static libgnuradio-grand.a library.

 Maybe try adding the flag -DENABLE_PYTHON=False to the cmake line?



 I then tried building GNU Radio for Android in a Ubuntu 14.04 64 bit VM,
 but when trying to stage Boost (./b2) I get this output from Boost (see
 error 2) and get an error about -march=armv7-m not being a supported
 compiler flag when Boost starts compiling. I have tried adding the
 toolset=gcc-android to Boost but this did not fix the problem (I had to
 do this on Mac to get Boost to use the configuration in the user-config.jam
 file).


 Are you sure you want armv7-m? Most of what we're using is armv7-a. But
 you might just try armv7 instead to use a more generic v7 architecture.
 Take a look at the gcc man page for a list of supported machines. This
 might be something you'll need to play around with.



 I would like help getting this working, as I really want to get GNU Radio
 working on Android for me.

 Schuyler St. Leger

 Error 1:
 [ 80%] Building CXX object
 swig/CMakeFiles/_grand_swig.dir/grand_swigPYTHON_wrap.cxx.o
 In file included from
 /opt/android-toolchain/include/python2.7/Python.h:58:0,
  from
 /opt/grandroid/gr-grand/build/swig/grand_swigPYTHON_wrap.cxx:167:
 /opt/android-toolchain/include/python2.7/pyport.h:1029:2: error: #error
 LONG_BIT definition appears wrong for platform (bad gcc/glibc config?).
  #error LONG_BIT definition appears wrong for platform (bad gcc/glibc
 config?).
   ^
 make[2]: ***
 [swig/CMakeFiles/_grand_swig.dir/grand_swigPYTHON_wrap.cxx.o] Error 1
 make[1]: *** [swig/CMakeFiles/_grand_swig.dir/all] Error 2
 make: *** [all] Error 2

 Error 2:
 Performing configuration checks

 - 32-bit   : no
 - 64-bit   : no
 - arm  : no
 - mips1: no
 - power: no
 - sparc: no
 - x86  : no
 - combined : no
 - has_icu builds   : no
 - lockfree boost::atomic_flag : no


 Yeah, when this is right, you should see 'yes' for 32-bit and arm.

 FYI, I should be getting a 64-bit ARM soon and will see what changes are
 necessary there.

 And if any of this helps and you do get it working, we should try to
 update the Android wiki page accordingly, either by fixing some of the
 instructions or with some side notes for these problems.

 Tom



 ___
 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] Enveloping a transmit amplifier

[devin kelly]

Marcus,

Thanks for the advice, this seems to do exactly what I'm looking for.  My
only question is that I've been under the impression that the UHD doesn't
yet support GPIO for the B210.  I did recently upgrade to 3.8.5 though so
maybe things have changed?

Devin

On Wed, Aug 19, 2015 at 5:43 AM, Marcus Müller marcus.muel...@ettus.com
wrote:

 Hi Devin,

 You wanted to ramp up/down the external PA: Use the GPIO pins, and the ATR
 registers [1] or timed commands issued over the message bus [2] to change
 their state

 Best regards,
 Marcus

 [1] http://files.ettus.com/manual/page_gpio_api.html#xgpio_fpanel_atr
 [2] http://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
 On 08/18/2015 09:17 PM, devin kelly wrote:

 Hello,
 0
 I'm transmitting a fairly bursty, irregularly timed signal.  I attach a
 stream tag to the sample that has the start of the burst (tx_sob).  I also
 have a PA that I can turn on and off that's inbetween my USRP B210 and
 antenna.

 I'd like to be able to turn the PA on and off synchronously, say 50 ms
 before tx_sob is to be transmitted.

 Is there any way to do this?  I'm thinking I could add a new tag that's 50
 ms before my transmission but then how would I synchronously turn on the
 PA?  Is there something like a callback function I can use?  Does the UHD
 or the UHD block have this functionality?

 Thanks for any help,
 Devin


 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio



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




-- 
http://alum.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Enveloping a transmit amplifier

[devin kelly]

I tried this out and I'm having some problems.  I'm on GR 3.7.8 and UHD
3.8.5, both the newest as far as I know.

What I did was make a flowgraph with a signal generator source and a UHD
sink in GRC.   It works before I made any modifications.  There are a few
lines in top_block.py that set the sample rate, antenna, etc.  At the end
of them I added this:

self.uhd_usrp_sink_0.set_gpio_attr(TXA, ATR_TX, 1, 0x10, 0)


It should set pin 4 high whenever I transmit (right?).  I run my flowgraph
and get this traceback:

Traceback (most recent call last):
  File top_block.py, line 76, in module
tb = top_block()
  File top_block.py, line 55, in __init__
self.uhd_usrp_sink_0.set_gpio_attr(TXA, ATR_TX, 1, 0x10, 0)
  File /usr/local/lib64/python2.7/site-packages/gnuradio/uhd/uhd_swig.py,
line 4539, in set_gpio_attr
return _uhd_swig.usrp_sink_sptr_set_gpio_attr(self, bank, attr, value,
mask, mboard)
RuntimeError: LookupError: Path not found in tree:
/mboards/0/dboards/A/iface


I know I'm using the right banks because I can do this command:

$ python -c 'from gnuradio import uhd; usrp =
uhd.multi_usrp_sink(serial=removed, uhd.io_type.COMPLEX_FLOAT32, 1);
print usrp.get_gpio_banks(0)'


and get

('RXA', 'TXA')

I also run this command:

uhd_usrp_probe --args='serial=removed' --tree | grep -i iface

and get nothing.  Without piping into grep I get 177 lines that all seem to
make sense to me.

Is that command I'm using correct or is there some other issue?

Thanks,
Devin

On Wed, Aug 19, 2015 at 8:09 AM, devin kelly dwwke...@gmail.com wrote:

 Marcus,

 Thanks for the advice, this seems to do exactly what I'm looking for.  My
 only question is that I've been under the impression that the UHD doesn't
 yet support GPIO for the B210.  I did recently upgrade to 3.8.5 though so
 maybe things have changed?

 Devin

 On Wed, Aug 19, 2015 at 5:43 AM, Marcus Müller marcus.muel...@ettus.com
 wrote:

 Hi Devin,

 You wanted to ramp up/down the external PA: Use the GPIO pins, and the
 ATR registers [1] or timed commands issued over the message bus [2] to
 change their state

 Best regards,
 Marcus

 [1] http://files.ettus.com/manual/page_gpio_api.html#xgpio_fpanel_atr
 [2] http://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
 On 08/18/2015 09:17 PM, devin kelly wrote:

 Hello,
 0
 I'm transmitting a fairly bursty, irregularly timed signal.  I attach a
 stream tag to the sample that has the start of the burst (tx_sob).  I also
 have a PA that I can turn on and off that's inbetween my USRP B210 and
 antenna.

 I'd like to be able to turn the PA on and off synchronously, say 50 ms
 before tx_sob is to be transmitted.

 Is there any way to do this?  I'm thinking I could add a new tag that's
 50 ms before my transmission but then how would I synchronously turn on the
 PA?  Is there something like a callback function I can use?  Does the UHD
 or the UHD block have this functionality?

 Thanks for any help,
 Devin


 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio



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




 --
 http://alum.wpi.edu/~dkelly/




-- 
http://alum.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Enveloping a transmit amplifier

[devin kelly]

Hello,

I'm transmitting a fairly bursty, irregularly timed signal.  I attach a
stream tag to the sample that has the start of the burst (tx_sob).  I also
have a PA that I can turn on and off that's inbetween my USRP B210 and
antenna.

I'd like to be able to turn the PA on and off synchronously, say 50 ms
before tx_sob is to be transmitted.

Is there any way to do this?  I'm thinking I could add a new tag that's 50
ms before my transmission but then how would I synchronously turn on the
PA?  Is there something like a callback function I can use?  Does the UHD
or the UHD block have this functionality?

Thanks for any help,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ZeroC ICE Choice for ControlPort

[devin kelly]

Tom,

Thanks for the detailed reply, I appreciate it.


On Mon, Nov 19, 2012 at 11:02 AM, Tom Rondeau t...@trondeau.com wrote:

 On Mon, Nov 19, 2012 at 10:51 AM, Tim Newman tim.new...@gmail.com wrote:
  Which version of Ice does the controlport branch currently depend on?
  I only ask because I think only Ubuntu 12.04 and 11.10 have Ice 3.4.2,
  whereas older Ubuntu versions come with the Ice 3.3.x versions and
  there are significant API changes between the two, so the apt-get
  install may only be supported on 12.04 and 11.10.
 
  Tim

 Oh, that's a good point. Everything was developed against 3.4.2, so I
 expect there would be issues with the 3.3 release. The FindICE.cmake
 file specifically checks for Ice-3.4, too, so older installations
 won't even be tried.

 Tom


  On Mon, Nov 19, 2012 at 10:25 AM, Tom Rondeau t...@trondeau.com wrote:
  On Mon, Nov 19, 2012 at 10:05 AM, Philip Balister phi...@balister.org
 wrote:
  On 11/18/2012 06:38 PM, devin kelly wrote:
 
  I just read about the release of
 
  ControlPort
 http://www.trondeau.com/home/2012/11/18/public-release-of-controlport.html
 ,
 
  (which I'm excited about) just wondering why use ZeroC ICE?
 
  Thanks for any explanation
 
 
  This is a start:
 
  http://www.zeroc.com/iceVsCorba.html
 
  Philip
 
  Devin,
 
  Yes, the comparisons between ICE and CORBA are definitely one reason.
  We wanted the benefits of CORBA without all of its drawbacks, and ICE
  is the logical choice. Also, it's easy to install and pretty easy to
  learn how to use. It's available in most systems, like being able to
  'apt-get install zeroc-ice' in Ubuntu and Debian.
 
  Now, we could ask why we want something as complex as this for
  ControlPort? ICE is pretty good at supporting other languages
  (specifically for our needs both C++ and Python). We want it to be
  robust, which takes a lot of thought and overhead. ICE has already
  done that for us. One of the subtle but useful things that ICE does is
  pass exceptions over the connection. So if one side throws an
  exception (like say the running application crashes or is terminated),
  the other side can gracefully shut down, free up resources, and exit.
 
  It also provides mechanisms for authentication and encryption. We're
  still working out details of how to make use of this, but it should be
  pretty clear that this is something we want. For instance, we actually
  have privilege levels for each variable that's exported. The intent is
  that when connecting, the authentication mechanism would use your
  credentials to determine what your privilege level is and only allow
  you access to those parameters (for example, maybe you can 'get' all
  the variables but you need special permission to be able to 'set'
  them). Again, as these things are already designed into ICE, we don't
  have to worry about how it's done; just how to use it.
 
  But finally, I'll say this. If you look at the code, you'll see that a
  lot of it is abstracted away from ICE. We've  tried to make it so that
  we could replace it with other solutions if people want to or
  something better comes along. You'll see some comments for XMLRPC and
  Erlang in the code. We could also potentially use CORBA here, too, if
  someone is crazy for CORBA. The main problem with this last bit is
  that we haven't architected any other layers besides ICE, so it's
  possible that a lot of our decisions are fundamentally rooted in ICE's
  way of doing things. It's probably not unworkable, but I bring this up
  because  it's likely that 'just' dropping in a new middleware might
  not be 'just' that easy. Still, the intent is there.
 
  Tom
 
  ___
  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




-- 
http://alum.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ZeroC ICE Choice for ControlPort

[devin kelly]

I just read about the release of
ControlPorthttp://www.trondeau.com/home/2012/11/18/public-release-of-controlport.html,
(which I'm excited about) just wondering why use ZeroC ICE?

Thanks for any explanation

Devin

-- 
http://alum.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to speed up spectrum sensing?

[devin kelly]

Well if you're sensing a 40 MHz band you have to retune.  The largest band
you can sense without retuning is about 25 MHz.

Also I would try higher FFT sizes, like 1024, 2048, or 4096.  Watch your CPU
load when you run your script, your processor probably isn't slowing you
down even with large FFT sizes.

I highly suggest you look at tune delay and dwell delay, manipulating those
can really speed up your sensing times.  The tune delay you can only set to
be so low without corrupting your data.  However, the dwell delay you can
set to be as low as one sweep, it all depends on how much averaging you want
to do.  Look at the code where it deals with the delay times.

Also, just how fast do you need this to be?  You should be able to do
thousands of sweeps in less than a second if I remember correctly.

Devin

On Thu, May 26, 2011 at 8:59 PM, Yang yyl@gmail.com wrote:

  Thank you for replying.

 I have already tried different fft size (256, 128, 32, etc) but as you said
 it did not change my sensing time. I also change my decimation but no luck
 too.

 I intend to sense a broad band, say, 20M or 40M. But it seems this script
 costs too much time working. Should I retune or not? Because if I do not it
 only sense a very narrow band.
 --
 Yang
 Sent with Sparrow http://www.sparrowmailapp.com

 On 2011年5月27日星期五 at 上午4:15, devin kelly wrote:

 Changing the fft size won't change your sensing time that much unless the
 machine you're using is really slow or the fft size is outrageous.  What fft
 sizes are you using?

 What will affect your sensing time more is the sampling/decimation rate you
 sent, the tune delay, and the dwell delay.  Be careful when changing the
 tune delay, if it is too short your data will be corrupted.

 Look at the usrp_spectrum_sense.py code and try this:

 $ python usrp_spectrum_sense.py --help


 Also, since you're only trying to look at a narrow band,
 usrp_spectrum_sense.py isn't for you. This script is really for looking at
 different bands and different times, but you really only need to look at one
 band.  Basically, you never need to retune and a lot of that script does is
 retune.

 Devin

 On Sat, May 14, 2011 at 8:11 AM, Alexander Chemeris 
 alexander.cheme...@gmail.com wrote:

 On Fri, May 13, 2011 at 14:25, Tom Rondeau trondeau1...@gmail.com wrote:
  On Fri, May 13, 2011 at 11:12 AM, Yang yyl@gmail.com wrote:
 
  Hi all,
  I am working on the implementation of dynamic spectrum access with
  gnuradio and usrp2. I modified usrp_spectrum_sense for usrp2 to do the
  sensing job. However, I find the sensing speed is intolerably slow,
 which is
  about 1s for 1MHz.
 
  Yang,
  Considering that the USRP2 can sample 25 MHz, you should be able to
 capture
  that bandwidth instantaneously.

 Note, that while USRP2 can sample 25MHz, you probably can't receive
 that much in your PC. I'm working with USRP N210 and having troubles
 with receiving even 16 MSPS.

 --
 Regards,
 Alexander Chemeris.

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




 --
 http://users.wpi.edu/~dkelly/
  ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





-- 
http://users.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Store data with usrp_spectrum_sense.py

[devin kelly]

I did a project similar to this. Look at this structure

m = parse_msg(tb.msgq.delete_head())

There is a field called data (I think) that contains the magnitude of the
sweep.  You record m.data to a file (like a csv, hdf5, or binary file).
 Keep in mind that you have to do the equivalent of fftshift.

Hope that helps.

On Sat, May 21, 2011 at 2:04 PM, Miguel Angel Sanz Rodriguez 
mikys...@hotmail.com wrote:

  Hi everyone,
 I am new in GNUradio and I want to sense the spectrum of Wifi from 2.4G to
 2.5 G with a USRP.
 I have been reading through a lot of discussions in the forum but I have
 not been able to store any data using usrp_spectrum_sense.py. I want to
 analyze this data with matlab, but I dont get any suitable file after
 running spectrum sense. I know that I have to modify the script, but I dont
 know how. I am quite bad at programming, so I would appreciate so much a way
 to find the solution(it must be very easy, but I am usless in programming)
 Thanks in advance for your help

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




-- 
http://users.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to speed up spectrum sensing?

[devin kelly]

Changing the fft size won't change your sensing time that much unless the
machine you're using is really slow or the fft size is outrageous.  What fft
sizes are you using?

What will affect your sensing time more is the sampling/decimation rate you
sent, the tune delay, and the dwell delay.  Be careful when changing the
tune delay, if it is too short your data will be corrupted.

Look at the usrp_spectrum_sense.py code and try this:

$ python usrp_spectrum_sense.py --help


Also, since you're only trying to look at a narrow band,
usrp_spectrum_sense.py isn't for you. This script is really for looking at
different bands and different times, but you really only need to look at one
band.  Basically, you never need to retune and a lot of that script does is
retune.

Devin

On Sat, May 14, 2011 at 8:11 AM, Alexander Chemeris 
alexander.cheme...@gmail.com wrote:

 On Fri, May 13, 2011 at 14:25, Tom Rondeau trondeau1...@gmail.com wrote:
  On Fri, May 13, 2011 at 11:12 AM, Yang yyl@gmail.com wrote:
 
  Hi all,
  I am working on the implementation of dynamic spectrum access with
  gnuradio and usrp2. I modified usrp_spectrum_sense for usrp2 to do the
  sensing job. However, I find the sensing speed is intolerably slow,
 which is
  about 1s for 1MHz.
 
  Yang,
  Considering that the USRP2 can sample 25 MHz, you should be able to
 capture
  that bandwidth instantaneously.

 Note, that while USRP2 can sample 25MHz, you probably can't receive
 that much in your PC. I'm working with USRP N210 and having troubles
 with receiving even 16 MSPS.

 --
 Regards,
 Alexander Chemeris.

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




-- 
http://users.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 Spectrum Sensing Help, (variant for FunCube Dongle?)

[devin kelly]

On Fri, Mar 18, 2011 at 4:29 PM, Moeller moelle...@gmx.de wrote:

 On 18.03.2011 18:10, devin kelly wrote:
  I have two problems with my data though.  In the file attached is some TV
 spectrum (left half) and noise (right half).
  My first question is this: why isn't the spectrum for the TV signal flat,
 it seems to bob up and down.  Note that each segment is from a different
  FFT, that is each FFT produces that oval shape.  At first I thought this
 had something to do with the window I was using but I've tried hamming,
  blackman-harris, and rectangular windows and they all have this effect.

 Why should it be flat? On the transmission side OFDM is quite flat.
 Typically (NLOS conditions) you will receive multiple paths and they
 interfere.
 The frequency selective fading effect is very strong for wide-band
 signals like DVB-T.
 NB signals like GSM assume the flat fading model, by contrast.

 I suppose flat is the wrong word.  If you look at the image I provided in
the first email you'll find that all the FFT outputs have this hump shape to
them.


  My second question is why isn't the transition between TV spectrum and
 noise more smooth? It looks like it could be smooth but the gain seems to
 jump
  for an FFT right after 566 MHz and then settle down again.  I thought
 this might be the AGC but I've tried different attack/decay rates, different
  reference levels, etc with the agc2_cc block but the problem remains.

 Can you switch off the AGC? AGC can destroy the whole spectrum measurement.
 Single spikes could be spurious mixing products from the receiver itself.


I've only started using the AGC block very recently.   I started using
because I wanted some way to control the AGC.  This makes me think of the
question, is the AGC on by default?  That is, if I don't have an AGC block
will the AGC be doing anything?  Also, in the first two or three ICs in the
WBX there is a digitally controlled attenuator and an LNA, those are part of
the AGC correct?


 A global filtering shape is expected from the analog RF filters.
 Of course, on the borders of FFT blocks you have incorrect transitions,
 depending on the shape within the reception bandwidth.
 I assume this could be compensated by scaling the FFT values.


This is going to be the next thing I try.


 To get the spectrum more smooth, you have to capture longer signals
 within the blocks of measurement bandwidth, for averaging the PSD estimate.

  Any help with either of these questions would be appreciated,
  Devin

 Do you want to publish the program? I think it would be very interesting
 for the examples section of Gnuradio. Surely, you will get support from
 the Gnuradio community to improve the sensing function.

 Btw, did anybody try to write a spectrum sensor with the Funcube USB
 dongle?
 This would be a low-cost alternative. The measurement bandwidth is not
 high,
 but it can scan a broad range of the spectrum.
 Possibly, after switching off AGC, compensating within the meas. bandwidth
 and compensating the global filter shape, the result could be quite useful.
 (if there are not too many spurious frequency components within the
 receiver itself)

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


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

[Discuss-gnuradio] USRP2 Spectrum Sensing Help

[devin kelly]

Hello,

I've created a spectrum sensor with the USRP2, my python script uses the
same idea as usrp_spectrum_sense.py found in gnuradio.  That is, it tunes,
takes an FFT, records, retunes, etc.

I have two problems with my data though.  In the file attached is some TV
spectrum (left half) and noise (right half).

My first question is this: why isn't the spectrum for the TV signal flat, it
seems to bob up and down.  Note that each segment is from a different FFT,
that is each FFT produces that oval shape.  At first I thought this had
something to do with the window I was using but I've tried hamming,
blackman-harris, and rectangular windows and they all have this effect.

My second question is why isn't the transition between TV spectrum and noise
more smooth? It looks like it could be smooth but the gain seems to jump for
an FFT right after 566 MHz and then settle down again.  I thought this might
be the AGC but I've tried different attack/decay rates, different reference
levels, etc with the agc2_cc block but the problem remains.

Any help with either of these questions would be appreciated,
Devin
attachment: tv-spectrum.png___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 Spectrum Sensing Help

[devin kelly]

Thanks Jason, Marcus,

I forgot to mention I'm using the WBX, not the TVRX.  I'm using the UHD as
well.

The flowgraph

uhd_single_source - agc2 - streamToVector - fft_vcc - cmplexToMagitude
- binStatistics

I added the agc2 block recently, I have similar problems without it.

Usually I'm interested in sweeping from 50 MHz to 2.2 GHz, but this scan was
from 558 MHz to 568 MHz.  The FFT size I use is usually 512 or 1024.  I
believe the decimation rate here is 256, but both problems persist no matter
the decimation/sampling rate I select.

On Fri, Mar 18, 2011 at 1:43 PM, Jason Abele ja...@ettus.com wrote:

 On Fri, Mar 18, 2011 at 10:10 AM, devin kelly dwwke...@gmail.com wrote:
  Hello,
 
  I've created a spectrum sensor with the USRP2, my python script uses the
  same idea as usrp_spectrum_sense.py found in gnuradio.  That is, it
 tunes,
  takes an FFT, records, retunes, etc.

 Could you post a flowgraph or tell us what frequencies you are tuning
 sweeping across, what step size, any averaging you use, sample rate or
 decimation, etc.

  I have two problems with my data though.  In the file attached is some TV
  spectrum (left half) and noise (right half).
 
  My first question is this: why isn't the spectrum for the TV signal flat,
 it
  seems to bob up and down.  Note that each segment is from a different
 FFT,
  that is each FFT produces that oval shape.  At first I thought this had
  something to do with the window I was using but I've tried hamming,
  blackman-harris, and rectangular windows and they all have this effect.

 The TVRX has a 6MHz bandpass filter, which will add shape to the
 spectrum you sense and even if you pick a smaller than 6Msps sample
 rate, you will still have several effects to consider:

 * Aliasing of energy inside the 6MHz bandpass
 * Probably 75% of the 6MHz is the flat region
 * TVRX has finite tuning steps, so you may be causing the USRP2 DDC to
 push your IF against the edge of the TVRX bandpass

  My second question is why isn't the transition between TV spectrum and
 noise
  more smooth? It looks like it could be smooth but the gain seems to jump
 for
  an FFT right after 566 MHz and then settle down again.  I thought this
 might
  be the AGC but I've tried different attack/decay rates, different
 reference
  levels, etc with the agc2_cc block but the problem remains.
 

 I am not familiar with the agc2 block, but I would recommend against
 using AGC until you are confident you have handled the bandpass nature
 of TVRX properly

  Any help with either of these questions would be appreciated,

 If you are using UHD, you might consider using the uhd::tune_result_t
 returned by set_center_freq() to make sure you are staying centered in
 the bandpass filter


 When I do a sweep from 558MHz to 568MHz with my decimation rate of 256 I
get these results from tune_result_t.  Note this isn't all the results, but
I think you can get the idea from these.

Target Inter Frequency  567277343.75  Actual Inter Frequency  567277167.277
Target DSP Frequency  -128.777472496  Actual DSP Frequency  -128.778629005
Target Inter Frequency  567472656.25  Actual Inter Frequency  567472527.473
Target DSP Frequency  -81.0821123123  Actual DSP Frequency  -81.0716301203
Target Inter Frequency  567667968.75  Actual Inter Frequency  567667887.668
Target DSP Frequency  -33.3867521286  Actual DSP Frequency  -33.3879143
Target Inter Frequency  567863281.25  Actual Inter Frequency  567863247.863
Target DSP Frequency  -1511.94291818  Actual DSP Frequency  -1511.9323507
Target Inter Frequency  568058593.75  Actual Inter Frequency  568057081.807
Target DSP Frequency  -891.903235674  Actual DSP Frequency  -891.904346645
Target Inter Frequency  558097656.25  Actual Inter Frequency  558096764.347

The DSP frequency is all over the place, from -30 to -1500, why is it always
negative?

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

Re: [Discuss-gnuradio] Possible WBX Board Failure

[devin kelly]

So I checked all the pins in this daughtercard and they all look fine.
Could it be anything else?

Thanks any help,
Devin





Also, here is the output of uhd_usrp_probe

$ sudo uhd_usrp_probe --args=addr=192.168.10.2
linux; GNU C++ version 4.4.5; Boost_104000; UHD_002.20110126204618.b83454d

Current recv sock buff size: 5000 bytes
mboard0 MIMO master

Warning:
Unknown transceiver board ID combination...
RX dboard ID: WBX (0x0053)
TX dboard ID: Unknown (0x)
  _
 /
|   Device: USRP2/N Series device
| _
|/
|   |   Mboard: USRP2-REV3 mboard
|   |   rev: 768
|   |   mac-addr: 00:50:c2:85:30:52
|   |   ip-addr: 255.255.255.255
|   |   serial: 82
|   |   name: dk-usrp2
|   | _
|   |/
|   |   |   RX DSP: USRP2-REV3 ddc0
|   |   |   Codec Rate: 100.00 Msps
|   | _
|   |/
|   |   |   TX DSP: USRP2-REV3 duc0
|   |   |   Codec Rate: 100.00 Msps
|   | _
|   |/
|   |   |   RX Dboard: USRP2-REV3 dboard (rx unit)
|   |   | _
|   |   |/
|   |   |   |   RX Subdev: Unknown - WBX (0x0053)
|   |   |   |   Antennas:
|   |   |   |   Freq range: 0.000 to 0.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: C
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: USRP2-REV3 adc - ltc2284
|   |   |   |   Gain Elements: None
|   | _
|   |/
|   |   |   TX Dboard: USRP2-REV3 dboard (tx unit)
|   |   | _
|   |   |/
|   |   |   |   TX Subdev: Unknown - Unknown (0x)
|   |   |   |   Antennas:
|   |   |   |   Freq range: 0.000 to 0.000 Mhz
|   |   |   |   Gain Elements: None
|   |   |   |   Connection Type: C
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: USRP2-REV3 dac - ad9777
|   |   |   |   Gain Elements: None



On Thu, Mar 10, 2011 at 2:18 PM, Marcus D. Leech mle...@ripnet.com wrote:

 On 03%2F10%2F2011 03%2F10%2F201103/10/2011 02:10 PM, Josh Blum wrote:


 On 03%2F10%2F2011 03%2F10%2F201103/10/2011 10:58 AM, devin kelly
 wrote:

 Hello,

 When using a particular WBX daughtercard I get this message from my
 script:

 Current recv sock buff size: 6000 bytes
 mboard0 MIMO master

 Warning:
 Unknown transceiver board ID combination...
 RX dboard ID: WBX (0x0053)
 TX dboard ID: Unknown (0x)

 This is usually a sign that the board is not mounted correctly. Re-mount
 the WBX and try again.

 -Josh


  He says that he tried it on multiple USRP motherboards, so it's unlikely
 to be, per se, a mounting issue.  But I'd
  check for a bent pin on the daughtercard connector.




 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium
 http://www.sbrac.org




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




-- 
http://users.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Possible WBX Board Failure

[devin kelly]

Looks like that didn't work for me...

Burn

sudo ./usrp_burn_db_eeprom --id=0x0052 --unit=TX --args=addr=192.168.10.2
linux; GNU C++ version 4.4.5; Boost_104000; UHD_002.20110126204618.b83454d

Current recv sock buff size: 5000 bytes
mboard0 MIMO master

Warning:
Unknown transceiver board ID combination...
RX dboard ID: WBX (0x0053)
TX dboard ID: Unknown (0x)
Setting dbid on TX:0 dboard...
  New dbid: WBX (0x0052)
  Done

Readback

sudo ./usrp_burn_db_eeprom --unit=TX --args=addr=192.168.10.2
linux; GNU C++ version 4.4.5; Boost_104000; UHD_002.20110126204618.b83454d

Current recv sock buff size: 5000 bytes
mboard0 MIMO master

Warning:
Unknown transceiver board ID combination...
RX dboard ID: WBX (0x0053)
TX dboard ID: Unknown (0x)
Getting dbid on TX:0 dboard...
  Current dbid: Unknown (0x)
  Done

The output of uhd_usrp_probe is the same afterwards as well.  Also, screwing
in all the screws didn't help either :(

Is there anything else I can try, or the eeprom on this board fried?

Again, thanks for any help,
Devin

On Fri, Mar 11, 2011 at 11:56 AM, Josh Blum j...@ettus.com wrote:


  Also, here is the output of uhd_usrp_probe
 
  $ sudo uhd_usrp_probe --args=addr=192.168.10.2
  linux; GNU C++ version 4.4.5; Boost_104000;
 UHD_002.20110126204618.b83454d
 
  Current recv sock buff size: 5000 bytes
  mboard0 MIMO master
 
  Warning:
  Unknown transceiver board ID combination...
  RX dboard ID: WBX (0x0053)
  TX dboard ID: Unknown (0x)

 The wrong ID is being read from the eeprom. Usually, this is an issue
 with mounting. On the off chance that the eeprom got
 corrupted/blanked/shocked, you can manually burn an ID in with the
 following tool:

 cd prefix/share/uhd/utils
 ./usrp_burn_db_eeprom --id=0x0052 --unit=TX

 See if that helps,
 -Josh

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

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

[Discuss-gnuradio] Possible WBX Board Failure

[devin kelly]

Hello,

When using a particular WBX daughtercard I get this message from my script:

Current recv sock buff size: 6000 bytes
mboard0 MIMO master

Warning:
Unknown transceiver board ID combination...
RX dboard ID: WBX (0x0053)
TX dboard ID: Unknown (0x)
Traceback (most recent call last):
  File usrp_spectrum_sense.py, line 366, in module
tb = my_top_block()
  File usrp_spectrum_sense.py, line 153, in __init__
self.u.set_antenna(self.antenna)
  File /usr/local/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py,
line 1488, in set_antenna
return _uhd_swig.uhd_usrp_source_sptr_set_antenna(self, *args, **kwargs)
RuntimeError: assertion failed: val.asstd::string() == std::string()
  in virtual void unknown_rx::rx_set(const wax::obj, const wax::obj)
  at /opt/uhd/host/lib/usrp/dboard/db_unknown.cpp:176

The first two lines are normal... but the rest is not.  I've tried to use
different machines, different USRP2s, different SD cards (all burned with
the same firmware though) and I always get this message.  The only reason
why I can think for this happening is a broken WBX board... Can anyone think
of any other reason this?

For reference, the WBX serial number is 741, in case there is something
wrong with that batch of WBXs.

Thanks for any help,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd_find_devices error

[Devin Kelly]

Thanks Josh, that makes sense.  But what about accessing the USRP1?

uhd_find_devices --args=type=usrp1

Can't find any UHD devices.

Thanks for the help.
Devin

On Tue, 2010-11-23 at 18:53 -0800, Josh Blum wrote:
 When you specify the address it works, the other methods do not. This is 
 likely due to a firewall blocking broadcast packet:
 
 http://www.ettus.com/uhd_docs/manual/html/usrp_nxxx.html#debugging-networking-problems
 
 -Josh
 
 On 11/23/2010 03:00 PM, devin kelly wrote:
  Hello,
 
  I have a strange problem with uhd_find_devices.  I can do
 
  [dkelly uhd]+master$ uhd_find_devices --args=addr=192.168.10.2
  linux; GNU C++ version 4.4.5; Boost_104000; UHD_20101122.202304.0c147c9
 
  --
  -- UHD Device 0
  --
  Device Address:
  type: usrp2
  addr: 192.168.10.2
  name: dk-usrp2
  serial: 00:50:c2:85:30:52
 
  fine, as you can see.   But everything else I try fails.  Note I have a
  USRP1 too here.
 
  [dkelly uhd]+master$ sudo uhd_find_devices --args=type=usrp2
  linux; GNU C++ version 4.4.5; Boost_104000; UHD_20101122.202304.0c147c9
 
  No UHD Devices Found
 
 [dkelly uhd]+master$ sudo uhd_find_devices --args=type=usrp1
  linux; GNU C++ version 4.4.5; Boost_104000; UHD_20101122.202304.0c147c9
 
  No UHD Devices Found
  [dkelly uhd]+master$ sudo uhd_find_devices --args=serial=12345
  linux; GNU C++ version 4.4.5; Boost_104000; UHD_20101122.202304.0c147c9
 
  No UHD Devices Found
 
  I've noticed when when I use the addr argument that I see in wireshark that
  exactly 180 packets are communicated between my pc andthe usrp2.  I don't
  see any packets on either interface for any other argument.
 
  Here is my ifconfig:
  eth3Link encap:Ethernet  HWaddr 00:22:3f:f6:36:40
 inet6 addr: fe80::222:3fff:fef6:3640/64 Scope:Link
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 RX packets:17375493 errors:0 dropped:0 overruns:0 frame:0
 TX packets:6397200 errors:0 dropped:0 overruns:0 carrier:0
 collisions:0 txqueuelen:1000
 RX bytes:4261877192 (4.2 GB)  TX bytes:499316331 (499.3 MB)
 Interrupt:16 Base address:0x6700
 
  eth3:0 Link encap:Ethernet  HWaddr 00:22:3f:f6:36:40
 inet addr:192.168.10.1  Bcast:0.0.0.0  Mask:255.255.255.0
 UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 Interrupt:16 Base address:0x6700
 
  Does anyone have any ideas for for why only the addr argument works?  I'd
  like to use my USRP1 with the UHD.
 
  Also, while I'm here, do I have to update anything (like reflashing the
  eeprom) on my USRP1 for it to work with the UHD?
 
  Thanks for any help,
  Devin
 
 
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
http://users.wpi.edu/~dkelly


signature.asc
Description: This is a digitally signed message part
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Stopping the UHD

[devin kelly]

Hello,

I'm having a problem, where I want to receive data from a specified
amount of time/samples and then stop.  I'm using a USRP2 with the UHD.
 So far, everything works fine, except for when I try to stop.  My
script exits ok, but the usrp2 keeps sending data over the ethernet
bus.  The 'C' led is remains illuminated as well, indicating that the
usrp2 is still receiving.

My code looks like this

self.ipAddr = '192.168.10.2'
self.bufSize = '60e6'
self.u = uhd.single_usrp_source('addr=' + self.ipAddr + ',
recv_buff_size=' + self.bufSize, uhd.io_type_t.COMPLEX_FLOAT32)

 ...

if tb.u.stop() is False:
   print 'tb.u.stop() failed'
if tb.stop() is False:
   print 'tb.stop() failed'
sys.exit()

tb.u.stop() and tb.stop() both return true.  Is there something else I
need to do stop my usrp2?  So far the only way I've found to stop it
is to do a hard reset.


Also, I've looked over the next branch and the gnu radio mailing list,
but I haven't really found anything.
Thanks for any help!
Devin

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

[Discuss-gnuradio] WBX: Failed to set center frequency

[devin kelly]

Hello,

I'm doing some spectrum sensing with the WBX and the USRP2, I'm using
the usrp_spectrum_sense script.  I do my scans over the whole range of
the WBX, from 50 MHz to 2.2GHz.  When I do a scan, sometimes I'll get
an error message Failed to set center frequency: FFF  At first, I
thought I had either my tune_delay or dwell_delay value set too low.
I tried increasing both incrementally to 500ms each.  This helped a
little, but there are certainly still failures.

Usually it will fail 0-8 times per scan.  I've noticed to that a lot
of the same frequencies will fail, but it's never consistent.

I've also noticed some unexplained peaks that occur near the
frequencies that fail.  There are certainly more of these peaks when I
have more failures.  So far, I've been testing in a controlled
envoironment with either the input terminated or using a tone
generated by a signal generator.

Has anyone else run into this problem?  I don't think it could be the
tune/dwell delays, 500ms is really high delay time.  Is there an
optimal tune/dwell delay for the WBX?  No values I've tried have fully
solved my problem though.  Could either the tune/dwell delay times be
frequency dependent?

Thanks For Any Help,
Devin

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

[Discuss-gnuradio] usrp_spectrum_sense and gr_bin_statistics_f

[devin kelly]

Hello,

I've been looking into how usrp_spectrum_sense works and I have a
question about my understanding of how it works.

The basic idea is that is that you tune, take FFT(s?), then retune,
etc.  This is done with the fft block and the stats block.  My
questions are:

1) What is input_items conceptually?  I think it is a vector of
pointers to different fft sweeps, but I could be wrong.

2) So, is this code taking several FFTs then the for loop and
accrue_stats finds the maximum magnitude of each of the FFT bins.  Is
that right?

3) Could I change dwell_time to change the number of FFTs that are taken?

4) If I wanted to do some averaging (instead of find the max
magnitude) could I would have to edit accrue_stats

Here's all the relevant code from
gnuradio-core/src/lib/general/gr_bin_statistics_f.cc

  const float *input = (const float *) input_items[0];
  size_t vlen = d_max.size();

  int n = 0;
  int t;

while (n  noutput_items){
  switch (d_state)

   ...

         case ST_DWELL_DELAY:
   t = std::min(noutput_items - n, int(d_delay));
   for (int i = 0; i  t; i++){
   accrue_stats(input[n * vlen]);
   n++;
    }
   d_delay -= t;
   assert(d_delay = 0);
   if (d_delay == 0){
  leave_dwell_delay();
  enter_tune_delay();
      }
      break;

...

  void
  gr_bin_statistics_f::accrue_stats(const float *input)
  {
for (size_t i = 0; i  vlen(); i++){
  d_max[i] = std::max(d_max[i], input[i]);// compute per bin maxima
}
  }



Thanks for any help,
Devin

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

Re: [Discuss-gnuradio] DQPSK Transmitter and Receiver

[devin kelly]

Hello everyone,


Tom, thanks for that, that was a good start for me, but I'm still am having
the problems.


This is how I make my modulator for dqpsk, the way I make the modulator for
dbpsk is mostly the same.  Tom, at first I thought you meant I might need to
change the samples_per_symbol paramter.  I did this, on the transmitter and
receiver, with no results.  I'm pretty sure you were talking about something
else,


Here are my modulators.  All I'm doing is switching between them.

modulator = gnuradio.blks2impl.dbpsk.dbpsk_mod(

samples_per_symbol=2,

excess_bw=0.35,

gray_code=True,

verbose=False,

log=False)



modulator = gnuradio.blks2impl.dqpsk.dqpsk_mod(

samples_per_symbol=4,

 excess_bw=0.35,

 gray_code=True,

 verbose=False,

 log=False)


Here is my transmitter.

class tx_top_block(gr.top_block):

def __init__(self, mod):
gr.top_block.__init__(self)

modulator=mod

self.packet_modulator = blks2.mod_pkts(
modulator,
access_code=None,
msgq_limit=4,
pad_for_usrp=True,
use_whitener_offset=False
)

usrp2_sink = usrp2.sink_32fc(network_interface)
usrp2_sink.set_interp(interpolation)
usrp2_sink.set_center_freq(center_freq)
usrp2_sink.set_gain(usrp2_sink.gain_max())

self.connect(self.packet_modulator, usrp2_sink)


def main_loop(self):
packet_size= 1000
max_num_packets= 10
repeat_packets = True

try:
data = Hello, World!\n
data = data + (packet_size-len(data))*' '  # pad rest of packet

self.start()
print Started Transmitter
while True:
for pkt_num in xrange(0,max_num_packets):
self.packet_modulator.send_pkt(data, False)
if not repeat_packets:
break
self.packet_modulator.send_pkt('', True)  # Tell the source to
block if it is done transmitting
self.wait()   # Wait for radio to
finish.

except KeyboardInterrupt:
pass

print \n\nExiting.


Thanks For Any Help,
Devin

On Mon, Apr 26, 2010 at 10:35 AM, Tom Rondeau trondeau1...@gmail.comwrote:

 On Mon, Apr 26, 2010 at 1:30 AM, devin kelly dwwke...@gmail.com wrote:
  Hello Everyone,
  I've made a basic DBPSK transmitter and receiver.  I can receive ASCII
  strings fine and the spectrum looks exactly as it should.
  However, if I swap the DBPSK modulator/demodulator for the DQPSK
  modulator/demodulator, my system breaks.   I can no longer receive the
 same
  strings and the spectrum looks very strange.  It's much wider and
 triangular
  shaped.
  Same goes for the D8PSK system and the D16PSK system I recently was
 asking
  about.
  I believe marcin_w asked a similar question a few days ago and I haven't
  seen a reply yet (am I wrong?)  My question is, should I be doing
 something
  different?  Do I need to add in some extra block when I switch from DBPSK
 to
  DQPSK?  While searching old posts, I found some people talking about
 DQPSK
  not working correctly, but that was about a year ago.
  Any help would be greatly appreciated.
  Devin


 Well, you haven't really told us what you are doing (code-wise), so
 it's hard to tell...

 Have you compared your code to the dbpsk/dbpsk2 and dqpsk/dqpsk2
 blocks in the source code? That might give you a hint.

 My best (blind) guess is that you are feeding the modulator the wrong
 number of bits per sample. You have to send a dbspk a chunk size of 1
 bit / byte while the dqpsk takes 2 bits/byte chunks.

 Tom




-- 
http://users.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RSSI estimation

[devin kelly]

Hello Bin,

My group considered doing this about 4-5 months ago.  Things may have
changed now, but at that time it was not possible (or at least not straight
forward to me) to get the gain from the AGC.

From my understanding, the AGC (automatic gain control) makes getting RSSI
readings difficult because your signal is getting amplified before it gets
sampled.  So if you don't know the gain the AGC sets (which varies with
time) it's hard to do RSSI.

Devin

On Tue, Apr 27, 2010 at 12:04 PM, bin zan zanbin2...@gmail.com wrote:

 Hello,
Anyone know if it is correct to roughly estimate RSSI information
 from I/Q values. For example is it correct to say RSSI of a message is equal
 to 10log10(I^2-Q^2). Otherwise, what is the correct way to obtain RSSI value
 in gnuradio?

 Thanks,
 Bin
 Winlab

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


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

[Discuss-gnuradio] DQPSK Transmitter and Receiver

[devin kelly]

Hello Everyone,

I've made a basic DBPSK transmitter and receiver.  I can receive ASCII
strings fine and the spectrum looks exactly as it should.

However, if I swap the DBPSK modulator/demodulator for the DQPSK
modulator/demodulator, my system breaks.   I can no longer receive the same
strings and the spectrum looks very strange.  It's much wider and triangular
shaped.

Same goes for the D8PSK system and the D16PSK system I recently was asking
about.

I believe marcin_w asked a similar question a few days ago and I haven't
seen a reply yet (am I wrong?)  My question is, should I be doing something
different?  Do I need to add in some extra block when I switch from DBPSK to
DQPSK?  While searching old posts, I found some people talking about DQPSK
not working correctly, but that was about a year ago.

Any help would be greatly appreciated.
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Adding a python block

[devin kelly]

Hello everyone,

I took the d8psk.py modulator and tweaked it a little to make a d16psk.py
modulator.  I have (both of them) in

gnuradio/gnuradio-core/src/python/gnuradio/blks2impl

I ran
$sudo make install
$make check

Yet my script still gets an error on this line

modulator = gnuradio.blks2impl.d16psk.d16psk_mod(.)

I import like this

import gnuradio.blks2impl

The error says

Traceback (most recent call last):
  File tx.py, line 94, in module
modulator = d16psk.d16psk_mod( # continued on next
line...
NameError: name 'd16psk' is not defined

I know the script works as it works when I copy d16psk.py to my the same
directory and change the import line.  What do I have to do to install this
block I wrote?

Thanks for any help,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Ettus Research News

[devin kelly]

I have questions about the UHD.  What license will be applied to it?  Will
the sources be provided or binary only? (I suspect sources, but want to be
sure)  And will the UHD be taking the place of libusrp2.so?

Also, more general, from the perspective of the user (me) what will change?
 From the announcement it seems that not much will change for the user.

Thanks for your help and congratulations,
Devin

On Fri, Feb 5, 2010 at 12:01 PM, Matt Ettus m...@ettus.com wrote:



 Ettus Research LLC was founded in 2004 to produce high quality, low cost
 software radio systems, and bring these capabilities to everyone.  In the
 last five and a half years this company, which started in a garage, has
 shipped thousands of products to users in over 67 countries.  Those products
 have been used for everything from mapping the earth, moon and stars to
 tracking wildlife, from teaching signal processing to obtaining a PhD., by
 everyone from individual hobbyists to huge research teams, for communicating
 across a desk, under water, under ground, across town, and around the world.

 Today, as the next step in the growth of our company, we are very proud to
 announce that Ettus Research has been acquired by National Instruments
 Corporation (NI, http://www.ni.com).  NI was founded in 1976 to transform
 the way engineers and scientists around the world design, prototype, and
 deploy systems for test, control, and embedded design applications.

 Below you will find answers to some questions you may have about this
 change.


 What does this mean for Ettus Research LLC and its products?

For the most part, things will stay the same.  We will continue to
 operate separately from, but as a wholly-owned subsidiary of National
 Instruments.  Our web address, email, phone, and postal addresses will all
 stay the same.  All sales will continue to be direct.  The additional
 resources the acquisition provides us will help us to serve you better and
 faster.

The USRP family of hardware for software radio will continue to be
 our main product line, and it will continue to be actively developed and
 improved.  We have several exciting new products we are working on for
 release later this year.  We are also working on a new Universal Hardware
 Driver or UHD, which will completely encapsulate everything needed to
 control all of our hardware in a single driver.  This will enable software
 developers to use USRP hardware without having to worry about the low level
 details of daughterboard control, kernel drivers, or other factors.  The UHD
 will be cross-platform, allowing use on Linux, Windows, and Mac OS X.

 What does this mean for GNU Radio?

Ettus Research will continue to support and contribute to GNU Radio,
 and the combination of GNU Radio software and USRP hardware will remain our
 core focus.  The additional resources that a large company like NI can
 provide will allow us to focus even more energy on improving the overall
 capabilities of the system.  Two of the core GNU Radio developers, Matt
 Ettus and Josh Blum, are employed by Ettus Research.

In the future we will also likely be providing GNU Radio drivers for
 additional hardware from National Instruments.


 What does this mean for LabVIEW?

The Universal Hardware Driver will allow us to produce high-quality,
 officially supported LabVIEW drivers for all of our hardware.  We hope to
 have those drivers available in the coming months.


 What does this mean for those using Simulink, OSSIE, OpenBTS, SCARI, or
 other software with their USRP hardware?

Ettus Research is fully committed to enabling the use of USRP
 hardware with any and every software platform for SDR.  The UHD will ease
 both the technical and the licensing hurdles which have made this somewhat
 difficult in the past.  We will be actively seeking input from the key
 representatives of those communities in order to ensure that the UHD API
 will fulfill their needs.


 Will USRP hardware be sold through National Instruments?

In the short term, no, all sales will continue to be directly
 through Ettus Research, but in the longer term we may offer some or all
 products through NI's worldwide sales network as well.


 In summary, we will continue to bring you high quality, low cost devices
 for software radio systems, to enable you, our users, to create exciting,
 groundbreaking radio communication systems.

 If you have any questions, please don't hesitate to ask.  Thank you for
 your time and your support.

 Matt Ettus
 President, Ettus Research LLC
 m...@ettus.com




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

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

[Discuss-gnuradio] Undefined Symbol with python2.6

[devin kelly]

Hello,

I just installed the latest GR from the git master branch.  I use Ubuntu
9.10, boost 1.38, and python2.6, and the USRP2.  The install seemed to go
fine.  However, I if try to run any of the python modules I get this error:

I do this:
sudo python streaming_fft.py -e eth1 -f 2.4G
./rx_streaming_samples -s -e eth1 -f 2.4e+09 -d 16  -o /proc/self/fd/1 |
./stdin_int32_fft.py  -f 2.4e+09 -d 16
Traceback (most recent call last):
  File ./stdin_int32_fft.py, line 23, in module
from gnuradio import gr, gru
  File /usr/lib/python2.6/dist-packages/gnuradio/gr/__init__.py, line 43,
in module
from gnuradio_swig_python import *
  File
/usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_python.py, line
23, in module
from gnuradio_swig_py_runtime import *
  File
/usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_runtime.py,
line 6, in module
import _gnuradio_swig_py_runtime
ImportError: libboost_thread-mt.so.1.35.0: cannot open shared object file:
No such file or directory
/proc/self/fd/1: Broken pipe

So I just made a symlik in /usr/lib from boostthread1.38 to boostthread1.35
This is probably a bad idea (see below)  But why is boostthread1.35
required?  Should I reinstall boost1.35 and then GR?


With the boostthread1.35 - boostthread1.38 symlink I just get a different
error:

$ sudo python streaming_fft.py -e eth1 -f 2.4G
./rx_streaming_samples -s -e eth1 -f 2.4e+09 -d 16  -o /proc/self/fd/1 |
./stdin_int32_fft.py  -f 2.4e+09 -d 16
Traceback (most recent call last):
  File ./stdin_int32_fft.py, line 23, in module
from gnuradio import gr, gru
  File /usr/lib/python2.6/dist-packages/gnuradio/gr/__init__.py, line 43,
in module
from gnuradio_swig_python import *
  File
/usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_python.py, line
24, in module
from gnuradio_swig_py_general import *
  File
/usr/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_general.py,
line 6, in module
import _gnuradio_swig_py_general
ImportError:
/usr/lib/python2.6/dist-packages/gnuradio/gr/_gnuradio_swig_py_general.so:
undefined symbol: _Z12gr_make_headji
/proc/self/fd/1: Broken pipe

I doesn't matter which python script I run or what flags I use, I get this
error message.  I searched for the undefined symbol, Z12gr_make_headji, and
found 0 results.  No one seems to have this problem thatI can find.

Also, when I try to run grc I get this a window that says this:
Cannot import gnuradio. Are your PYTHONPATH and LD_LIBRARY_PATH set
correctly?
With this title: /usr/lib/python2.6/dist-packages/gnuradio/g (the rest is
cut off)

My gnuradio core library seems to be located in the right place:
$ locate gnuradio-core.so
/usr/local/lib/libgnuradio-core.so
/usr/local/lib/libgnuradio-core.so.0
/usr/local/lib/libgnuradio-core.so.0.0.0
(is the 0.0.0 wrong?)


I had had some problems installing before, but I think the most recent
install worked.  When I run make check all tests pass.

If anyone can help I'd really appreciate it,
Devin
-- 
http://users.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Time of Arrival Hooks

[devin kelly]

Hello everyone,

I'm doing a project with the USRP2 that where I need to know the Time of
Arrival(TOA) of the waveforms.  This is for a geolocation application.

My understanding as of now is that the hooks to get TOA are there in the
USRP2, but the firmware does not provide access to them at this point.  Is
this correct?

If the firmware can provide TOA, how can I get that information??

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

Re: [Discuss-gnuradio] New Ethernet MAC for USRP2

[devin kelly]

So what does this update actually do?  Does it add UDP onto the network
stack?  What about VRT?  I know VRT and UDP are being implemented
independently, but around the same time.  How does this update fit in with
adopting those two protocols?

Thanks
Devin

On Fri, Oct 2, 2009 at 1:23 PM, Ben Hilburn bhilb...@gmail.com wrote:

  And this is the first time for me using git.
  After I use 'git fetch' to get the repository, what's next to get the
  following command working?

 For future reference, 'git fetch' simply pulls the list of changesets.
  In order to apply them to your current branch, you need to use 'git
 merge'.

 Alternatively, doing a 'git pull' does it all for you - this is
 generally the easier route unless you want to hand-select/view the
 changesets before applying them.

 Cheers,
 Ben

 
  git branch --track new_eth origin/new_eth
  git checkout new_eth
 
  Hanwen
 
  2009/10/1 Matt Ettus m...@ettus.com
 
 
  I am in the process of replacing the old GigE MAC logic for the USRP2
 with
  a much cleaner design.  This is the first step in allowing for a bunch
 of
  big improvements.  I would greatly appreciate it if people with USRP2s
 would
  try this new version.  Instructions on how to get it are here:
 
  http://gnuradio.org/trac/wiki/NewEthMAC
 
  Please report both success or problems with it.
 
  Thanks,
  Matt
 
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 


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

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

[Discuss-gnuradio] UDP VRT Status

[devin kelly]

Hello

I am interested in the firmware update for the USRP2 that will give the
USRP2 capability for handling UDP network layer and VRT application layer
protocols.  Will both of these update occur with the same firmware update?
If not, is there any estimate for when the latter update will occur?

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

[Discuss-gnuradio] VRT and UDP

[devin kelly]

What is the situation with VRT and UDP?  Has what's going into the VRT
context packets been finalized?  If so, where should I look for this
information?  I've been looking in Eric Blossom's branch, it looks like he
is doing most of the VRT development, is this right?

Who is doing the UDP development and how far along is it?

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

Re: [Discuss-gnuradio] USRP2 Sockets

[devin kelly]

So, just to help me understand, let's say that running as root wasn't a
problem.  Like, if you didn't have to be root to open a raw socket.

Would that mean that the open_usrp2_socket() function would just look like
this

usrp2::open_usrp2_socket() {

int fd = socket(PF_PACKET, SOCK_RAW, htons(0xBEEF);
return fd;
}

and you wouldn't need the helper program, usrp2_socket_opener.cc?  But, you
would still need the read_fd(...) and write_fd(...) functions right?

Thanks again for the help.
Devin

On Wed, Apr 15, 2009 at 4:41 PM, Eric Blossom e...@comsec.com wrote:

 On Wed, Apr 15, 2009 at 04:20:20PM -0400, devin kelly wrote:
  I've been looking over the GNU Radio code and I can't seem to figure what
 is
  being done in /usrp2/host/lib/open_usrp2_socket.cc file.  Specifically,
  lines 97 through to 128.
 
  What I think is happening is that a pair of connected sockets is created
  (97) then a process is forked (102).  So, the child process has it's own
  pair of sockets?  Are sockfd[0] in each process connected?  That would
  explain why sockfd[1] is closed (114) immediately after the fork, but it
  would not explain the need for socketpair to begin with.
 
  So, my questions are: why is socketpair needed?  What is the fork doing?
  And, why is the socket closed right after the fork?
 
  Any help is appreciated.
  Devin


 This code allows us to open a SOCK_RAW socket without being root by
 using a setuid-root helper program, usrp2_socket_opener.  The setuid
 program opens the socket on our behalf and passes it back to us
 through the socket pair using the socket capability feature.

 Look at the code for the helper program, usrp2_socket_opener.c
 and read the man pages for each system call to see what's going on.

 Eric




-- 
http://users.wpi.edu/~dkelly/ http://users.wpi.edu/%7Edkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP2 Sockets

[devin kelly]

I've been looking over the GNU Radio code and I can't seem to figure what is
being done in /usrp2/host/lib/open_usrp2_socket.cc file.  Specifically,
lines 97 through to 128.

What I think is happening is that a pair of connected sockets is created
(97) then a process is forked (102).  So, the child process has it's own
pair of sockets?  Are sockfd[0] in each process connected?  That would
explain why sockfd[1] is closed (114) immediately after the fork, but it
would not explain the need for socketpair to begin with.

So, my questions are: why is socketpair needed?  What is the fork doing?
And, why is the socket closed right after the fork?

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

[Discuss-gnuradio] GNU Radio Packets

[devin kelly]

Hello,

I am trying to figure out how information is sent between a PC and the
USRP.  So far I can tell they are all customized packets, i.e. raw sockets
are used, which is why you need to be root.  But I've been having trouble
figuring out what the header information is.  Does anyone know?  If there is
a GNU Radio plugin for Wireshark (formerly Ethereal) that would be a great
tool.  Also, does the USRP (or USRP2) support UDP at all?  I doesn't look
like it to me, but I'd like to be sure.  And if not, why no support for UDP?

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

Re: [Discuss-gnuradio] GNU Radio Packets

[devin kelly]

Thanks for the help.

How close is GNU radio to implementing VITA49/UDP?  Is the release weeks
away, months away, or more?  What version number do you think that will be?

Thanks again,
Devin

On Thu, Mar 26, 2009 at 10:47 AM, Johnathan Corgan 
jcor...@corganenterprises.com wrote:

 2009/3/26 devin kelly dwwke...@gmail.com:

  I am trying to figure out how information is sent between a PC and the
  USRP.  So far I can tell they are all customized packets, i.e. raw
 sockets
  are used, which is why you need to be root.

 The USRP2 currently uses Ethernet frames of type 0xBEEF to communicate
 sample data and control frames with the host PC.

  But I've been having trouble
  figuring out what the header information is.

 The wire format is described here:


 http://gnuradio.org/trac/browser/gnuradio/trunk/usrp2/firmware/include/usrp2_eth_packet.h


  If there is
  a GNU Radio plugin for Wireshark (formerly Ethereal) that would be a
 great
  tool.

 That would be a welcome addition to the project.

  Also, does the USRP (or USRP2) support UDP at all?

 It currently does not.  However, after release 3.2, we are rewriting
 the USRP2 transport format to use the VITA49 digital IF standard,
 encapsulated in UDP.

 Johnathan




-- 
http://users.wpi.edu/~dkelly/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio