[Discuss-gnuradio] [GSoC 17] DAB: updates of the week

[Moritz Luca Schmid]

Hi everyone,

I successfully finished the reception chain for the Main Service Channel 
(MSC) this week!


See details in my latest blog post .


Cheers

Luca

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

[Discuss-gnuradio] Channelizer mapping

[John Ackermann N8UR]

Is there a basic rule for how to assign channel numbers to the PFB 
channelizer output?  I seem to be too dense to figure it out from the 
docs.  I just want to pull the channels out in order of their RF 
frequency, low to high.


I currently have a 7 channel channelizer which seems to work properly 
after I farted around to get this map: [5,6,7,0,1,2,3] using a 
"Channels" value of 8 (note that channel 4 is thrown away).


Now I want to extend the number of channels, and the number may be even 
or odd.  From Tom Rondeu's tutorial, I get the sense that the mapping 
changes based on even or odd channel count.


Is there a basic rule to develop the map for the case of RFch0 = ch0, 
RFch1 = ch1, etc.?


Thanks,
John

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

Re: [Discuss-gnuradio] Custom C++ blocks on E310

[Jessica Iwamoto]

Hi all,

We're trying to implement a fast sweep over a range of frequencies on the E310. 
Currently, I have a Python block that takes in a stream from the USRP Source, 
counts up the number of samples, and after receiving n samples, issues a stream 
command to the USRP Source to receive n more samples. There is currently a 
delay (of a few ms) between when the stream command is issued and when the work 
function of my custom block is called, and we are trying to find ways to 
shorten this delay. We can't use timed commands because they are not supported 
in the E310 and it doesn't look like you can queue up a series of stream 
commands either. We also can't use a custom C++ block because of the issues 
discussed previously in this email thread.

Does anyone have ideas on what to try? Or, could you point me to the relevant 
UHD code, as it is a bit confusing to follow? Also, are there any plans to add 
support for timed commands in the E310 or for a queue of stream commands?

Thank you,
Jessica


From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+jessica.iwamoto=aero@gnu.org] On Behalf Of 
Marcus Müller
Sent: Wednesday, May 24, 2017 12:26 PM
To: discuss-gnuradio@gnu.org; Philip Balister 
Subject: Re: [Discuss-gnuradio] Custom C++ blocks on E310


Hi Jessica,

that's really interesting!

It means that the problem only happens when you use your compiler to build your 
C++ blocks, but not when only using the GNU Radio that's already part of your 
image. Not quite sure what that entails; maybe it means that openembedded 
builds broken SDKs... That shouldn't happen. The other thing I could think of 
would be a slight misconfiguration of the compiler (or the linker). Maybe 
Philip has an idea!

Best regards,

Marcus



On 24.05.2017 20:51, Jessica Iwamoto wrote:
Hi all,

I never found the solution to this problem, but I ended up using a work around 
by writing my custom blocks in Python instead of C++.

Jessica

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+jessica.iwamoto=aero@gnu.org] On Behalf Of 
Jessica Iwamoto
Sent: Monday, May 15, 2017 8:38 AM
To: Ben Hilburn 
Cc: discuss-gnuradio@gnu.org
Subject: [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re: [Discuss-gnuradio] 
Custom C++ blocks on E310

Hi Ben,

Here is some of the backtrace from the error. At the top level, the error 
starts in the msg_connect function and it looks like it gets tripped up reading 
something from memory when checking for a valid message port.

#0  0xb635c67c in fetch_add (order=boost::memory_order_relaxed, v=1,
storage=@0x6: )
at /home /prefix 
/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:100
#1  fetch_add (order=boost::memory_order_relaxed, v=1, this=0x6)
at /home /prefix 
/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/atomic_template.hpp:115
#2  pmt::intrusive_ptr_add_ref (p=0x2)
at /home /prefix /src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:69
#3  0xb63e56e4 in intrusive_ptr (rhs=..., this=0xbeffec7c)
at /home /prefix 
/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/smart_ptr/intrusive_ptr.hpp:92
#4  gr::flowgraph::check_valid_port (this=this@entry=0x10c578, e=...)
at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:162
#5  0xb63e95d0 in gr::flowgraph::connect (this=this@entry=0x10c578, src=...,
dst=...)
at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:503
#6  0xb63f4c84 in gr::hier_block2_detail::msg_connect (
this=this@entry=0x10c528, src=..., srcport=..., dst=..., dstport=...)
at /home /prefix 
/src/gnuradio/gnuradio-runtime/lib/hier_block2_detail.cc:198
#7  0xb63f1b14 in gr::hier_block2::msg_connect (this=this@entry=0x0, src=...,
srcport=..., dst=..., dstport=...)
at /home /prefix /src/gnuradio/gnuradio-runtime/lib/hier_block2.cc:104
#8  0xb5cd6958 in _wrap_top_block_sptr_primitive_msg_connect__SWIG_1 (
args=)
at /home 
/prefix_new/src/gnuradio/build-arm/gnuradio-runtime/swig/runtime_swigPYTHON_wrap.cxx:47551

Thanks,
Jessica

From: Ben Hilburn [mailto:bhilb...@gnuradio.org]
Sent: Friday, May 12, 2017 1:35 PM
To: Jessica Iwamoto mailto:jessica.iwam...@aero.org>>
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Custom C++ blocks on E310

Hey Jessica -

The SIGBUS you are receiving indicates that there is likely some funniness 
happening with memory addressing / access somewhere. Especially since your test 
flowgraph is so simple, using GDB to get a backtrace might point you to the 
offending code pretty quickly. For more details on how to do this, check out 
this page on our Wiki: 
https://wiki.gnuradio.org/index.php/TutorialsDebugging#Expert_debugging_tools

Have you tried this already? If so, can you share the backtrace?

Cheers,
Ben



On Thu, May 11, 2017 at 6:15 PM, Jessica Iwamoto 
mailto:jessica.iwam...@aero.or

Re: [Discuss-gnuradio] usrp_spectrum_sense.py

[GNUBeginner]

Hello Marcus,

Could you please tell me your thoughts about hackrf_sweep code? Does it give
me the metrics that I need?

Thanks



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/usrp-spectrum-sense-py-tp63994p64111.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] [GSoC 2017] gr-bokehgui: Updates on Week 3

[Kartik Patel]

Hello all,

This week, I have completed the Bokeh based Time Sink for float values! For
more details, check out at my blog
!

I have dropped the PR 
to master. Kindly share your suggestions and reviews of the code on Github.

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

Re: [Discuss-gnuradio] Channelizer mapping

[West, Nathan]

It works kind of like an fftshift. The center channel is 0, the lowest
channel is nchannels/2 + 1 or so... I think your mapping could have 4 on
the end to get the whole sequence.

On Fri, Jun 2, 2017 at 11:25 AM, John Ackermann N8UR  wrote:

> Is there a basic rule for how to assign channel numbers to the PFB
> channelizer output?  I seem to be too dense to figure it out from the
> docs.  I just want to pull the channels out in order of their RF frequency,
> low to high.
>
> I currently have a 7 channel channelizer which seems to work properly
> after I farted around to get this map: [5,6,7,0,1,2,3] using a "Channels"
> value of 8 (note that channel 4 is thrown away).
>
> Now I want to extend the number of channels, and the number may be even or
> odd.  From Tom Rondeu's tutorial, I get the sense that the mapping changes
> based on even or odd channel count.
>
> Is there a basic rule to develop the map for the case of RFch0 = ch0,
> RFch1 = ch1, etc.?
>
> Thanks,
> John
>
> ___
> 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] Channelizer mapping

[John Ackermann N8UR]

Thanks.  I got some off-help list (thanks, Noah!) and think I have it 
sussed.  There is a trick, though: if you have an even number of 
channels, one of them will wrap from the right side of the graft to the 
left, and be useless.


So as a practical matter, you might as well design for an odd number, 
and then the channel map to get frequency-order has 0 at the center, 
counting up on the right side from 1 to int(n/2), counting down on the 
left side from n-1 to int(n/2)+1.  So for n = 7 (seven channels):


[ 4,5,6,0,1,2,3 ]

I hope I stated that correctly, if not someone please correct me.

(My earlier example was based on the mistaken assumption that you had to 
"waste" a channel for an odd number, so I had 8 channels, and tossed one 
to get 7.  Backwards.)


John


On 06/02/2017 04:32 PM, West, Nathan wrote:

It works kind of like an fftshift. The center channel is 0, the lowest
channel is nchannels/2 + 1 or so... I think your mapping could have 4 on
the end to get the whole sequence.

On Fri, Jun 2, 2017 at 11:25 AM, John Ackermann N8UR mailto:j...@febo.com>> wrote:

Is there a basic rule for how to assign channel numbers to the PFB
channelizer output?  I seem to be too dense to figure it out from
the docs.  I just want to pull the channels out in order of their RF
frequency, low to high.

I currently have a 7 channel channelizer which seems to work
properly after I farted around to get this map: [5,6,7,0,1,2,3]
using a "Channels" value of 8 (note that channel 4 is thrown away).

Now I want to extend the number of channels, and the number may be
even or odd.  From Tom Rondeu's tutorial, I get the sense that the
mapping changes based on even or odd channel count.

Is there a basic rule to develop the map for the case of RFch0 =
ch0, RFch1 = ch1, etc.?

Thanks,
John

___
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