Re: [Discuss-gnuradio] Log Power FFT Block

[CEL]

Hi Alejandro,

um, this is the mailing list you are looking for.
Ask this here; don't ask to ask in private :)

Best regards,
Marcus

On Sat, 2018-05-05 at 14:44 +0200, ALEJANDRO RAMIRO MUNOZ wrote:
> Hey all!
> 
> Someone has experience working with this block in GNU Radio?
> I'd like to ask him/her some questions!
> 
> Really thank you in advance,
> Regards!
> 
> ___
> 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 DDC and GNURadio Bandwidth Problem

[CEL]

Hi Ali,

just like the console will tell you, 25 kS/s is simply impossible with
an X310; instead, the minimum possible rate was used.

You should probably just configure your X310 to get you e.g. 500 kS/s,
and then resample in digital domain. If you're hesitant to design your
own decimating filter, use the "rational resampler" block and configure
it to decimate by (500/25)=20.

Best regards,
Marcus

On Mon, 2018-05-14 at 10:18 +0300, Ali wrote:
> Hi to all,
> 
> I am using GNURadio to control an X310. I want to get IQ samples for only 25 
> kHz bandwidth. 
> 
> When I wrote 25 kHz to the bandwidth line in UHD-Source block in GNURadio, I 
> still see the signals at 50 kHz or 75 kHz away from the center. My sampling 
> rate is 195312 Hz. When checked in MATLAB, the signals are there. It looks 
> like I cannot control the bandwidth with GNURadio.
> 
> I suspected that there is not any DDC filter for this bandwidth. If it is so, 
> what is the minimum bandwidth for USRPs? Are the bandwidths that I can use 
> discrete? I am confused.
> 
> Thanks in advance,
> Ali
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] grc companion color theme Kubuntu 18.04

[CEL]

Hi Murray,

> background color … transparent

I wasn't aware of that, but I'd call it a bug in Kubuntu (or, the way
Kubuntu configures their KDE to configure GTK to show tooltips).

What do you mean with "toggle visibility button"?

Cheers,
Marcus


On Mon, 2018-05-14 at 12:56 +0100, Murray Thomson wrote:
> Hi,
> 
> I've installed grc companion (3.7.12.0 from pybombs) in Kubuntu 18.04 and the 
> background color of the tooltips is transparent, which makes it difficult to 
> read.  I addition to this, the toggle visibility icon is not found. Could 
> anyone point me in the right direction to edit this please?
> 
> Cheers,
> Murray
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP Output to Spectrum Analyzer

[CEL]

Hello Yeo Jin Kuang Alvin,

that's probably because your Spectrum Analyzer has a sweep rate, and
you get something like a reduced probability of seeing the sweep at
all.
I think it's very likely you should read a tutorial on what a spectrum
analyzer is, and what the various settings on it mean, until you can
expect to observe a sweep with it (hint: it's near impossible to see a
sweep as a sweep with a SA, unless that sweep is very slow).

Best regards,
Marcus

On Wed, 2018-05-09 at 09:24 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hello,
>  
> I managed to get the waveform! Was due some misconfigurations with the RBW 
> and VBW on the Spectrum Analyzer.
>  
> However, may I know why is the waveform bandwidth reduced by a lot. I tried 
> to send a chirp with a bandwidth of 1MHz but when I transmit out, I got 50kHz 
> of BW. Is it due to some loss when transmitting?
>  
> Thank you in advanced!
>  
> From: Discuss-gnuradio 
> [mailto:discuss-gnuradio-bounces+yjinkuan=dso.org...@gnu.org] On Behalf Of 
> Ron Economos
> Sent: Wednesday, 9 May 2018 3:28 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] USRP Output to Spectrum Analyzer
>  
> Here's what I get from the flow graph below.
> 
> 
> 
> 
> 
> Ron
> 
> On 05/08/2018 10:28 PM, Yeo Jin Kuang Alvin (IA) wrote:
> > Hi all,
> >  
> > Theoretically, in frequency domain, the spectrum for SQUARE wave should be 
> > a SINC  and for the spectrum of RAMP wave should be decreasing with every 
> > odd harmonics. A question that I want to ask is, will I get to see these 
> > frequency spectrum in the Spectrum Analyzer after being transmitted out 
> > from the USRP B210? As I have tried to send a Square and a Ramp wave using 
> > GNU Radio Companion, I see the waveform I want in GNU Radio plot, but I 
> > don’t see any nice expected waveforms in the Spectrum Analyzer.
> >  
> > Is it because of the IQ Modulation in the AD9361 of the USRP B210 that 
> > causes me not seeing the expected results? Or is it because of some 
> > configurations not done properly? Hope to get a reply soon!
> >  
> > Thank you in advance!
> >  
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RTP block / Opus vocoder

[CEL]

Well, I think you and Ron basically recommend the same functionality,
but Ron is hesitant to reinvent the wheel:

For local transport, UDP between your flowgraph and VLC works just
fine. Also fine would be simply using a named pipe (FIFO, as in `man
mkfifo`, if you're on something vaguely resembling UNIX) and a simple
file sink (or source).

Then, use VLC to receive those UDP packets containing raw samples, and
encode them with Opus, and encapsulate them with RTP. (In the opposite
direction, use VLC to receive an RTP stream, decompress the audio to
raw audio samples, and send them via UDP to your flow graph)

That would alleviate the need to have all this in a block, and test it
yourself.

Best regards,
Marcus

On Wed, 2018-05-09 at 12:30 +0200, Albin Stigö wrote:
> >  RTP is encapsulated in UDP. If you send an RTP stream to the GNU Radio UDP 
> > block, you will get an RTP stream.
> 
> Exactly. But do you know if there already is a project to handle RTP 
> bookkeeping..? Otherwise I will start one. RTP is very application specific 
> but I'm looking to implement raw audio and opus. I'll try to make it modular 
> so that others can be built on top.
> 
> --Albin
> 
> 
> On Wed, May 9, 2018, 10:38 Ron Economos  wrote:
> > RTP is encapsulated in UDP. If you send an RTP stream to the GNU Radio 
> > UDP block, you will get an RTP stream.
> > 
> > VLC is just a suggestion. It can send RTP containing Opus.
> > 
> > Ron
> > 
> > On 05/09/2018 01:10 AM, Albin Stigö wrote:
> > > Well RTP provides important functionality when streaming over the
> > > internet. Especially time stamping and sequence numbering which allows
> > > to reassemble out of order data (UDP provides no such guarantee) and
> > > adjustment for clock drift which, among other things, allows you to
> > > keep the receiver buffer smaller for "real time" tuning.
> > >
> > > RTP also provides a "telemetry" channel over RTCP for network statistics.
> > >
> > > Not sure why you assume I will use VLC?
> > >
> > > Of course if you are just streaming over a LAN raw UDP might be ok
> > > since the risk of out of order packets is essentially zero.
> > >
> > >
> > > --Albin
> > >
> > >
> > > On Wed, May 9, 2018 at 9:35 AM, Ron Economos  wrote:
> > >> RTP runs over UDP. Why would you need a block? Just let VLC do all the 
> > >> dirty
> > >> work.
> > >>
> > >> Ron
> > >>
> > >>
> > >> On 05/08/2018 11:59 PM, Albin Stigö wrote:
> > >>> Hi all,
> > >>>
> > >>> Is there an RTP (real time protocol) streaming block? I know about the
> > >>> UDP block but I want RTP/RTCP.
> > >>>
> > >>> If not I will start writing one... Just don't want to start a new
> > >>> project if there already is one.
> > >>>
> > >>> Also, what happened to Opus in the gr-vocoder? Thinking about writing
> > >>> an opus block as well.
> > >>>
> > >>> The goal is streaming opus encoding audio from gnuradio from remote
> > >>> locations.
> > >>>
> > >>>
> > >>> --Albin
> > >>>
> > >> ___
> > >> Discuss-gnuradio mailing list
> > >> Discuss-gnuradio@gnu.org
> > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting gnuradio to compile with zeromq

[CEL]

Hi Brad,

changing the pythonpath shouldn't change the path in which CMake looks
for include files and libraries, at all.

Can you check whether your /usr/include has some zmq.hpp ?
Debian just throws that C++ wrapper for C zeromq into the zeromq-devel
package (without any documentation which version they use ... g),
but other distros don't, and you might need to manually add that header
to your system's include path. It's a single, isolated header file, so
you can just download it from github and add it.

Best regards,
Marcus

On Wed, 2018-05-09 at 12:00 -0400, Brad Hein wrote:
> 
> I'm unable to get the gnuradio cmake process to recognize that I have zeromq 
> installed. Every time I run cmake it ends up with gr-zeromq disabled. I tried 
> installing zeromq and zeromq-devel version 4 (yum install zeromq zeromq-dev) 
> but that didn't help. I also tried uninstalling the default version 4 and 
> installing the zeromq and zeromq-dev version 3 packages, still cmake wouldn't 
> detect zeromq. 
> 
> OS: CentOS 7.4 with all updates. X86_64 VM.
> 
> gnuradio: latest code, master branch. current comit: 
> * 82d0a6b -(4 weeks ago) gr-newmod: Pylint fixes in python scripts . Swapnil 
> Negi (HEAD, origin/master, origin/HEAD, master)
> 
> 
> One thing I noticed is that gnuradio defaults my install prefix to /usr/local 
> (/usr/local/lib64 for example) which leads to me having to set my pythonpath 
> manually... maybe nothing... but I wonder if the cmake process is looking 
> under /usr/local/lib64 for the zeromq libraries instead of /usr/lib64? not 
> sure. 
> 
> I've done some googling but I'm coming up empty handed in terms of getting 
> gnuradio to compile with zeromq. 
> 
> I'm on the gnuradio master branch. 
> 
> -- Configuring gr-zeromq support...
> --   Dependency Boost_FOUND = 1
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> --   Dependency ZEROMQ_FOUND = FALSE
> CMake Error at cmake/Modules/GrComponent.cmake:75 (message):
>   user force-enabled gr-zeromq but configuration checked failed
> Call Stack (most recent call first):
>   gr-zeromq/CMakeLists.txt:32 (GR_REGISTER_COMPONENT)
> 
> -- Configuring incomplete, errors occurred!
> See also "/home/brad/gr/gnuradio/build/CMakeFiles/CMakeOutput.log".
> See also "/home/brad/gr/gnuradio/build/CMakeFiles/CMakeError.log".
> 
> 
> Looking through the cmake error log file mentioned above there are strangely 
> no references to zeromq. 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Raspberry Pi 3 / Error: selected processor does not support ARM mode

[CEL]

Hi Brad,

to jump in and clarify what Phil probably could've said in a lot fewer
words, but for didn't ;) :

Philip is an OpenEmbedded Guru of ancient fame. Basically, OpenEmbedded
is a system to build your own linux distros, by defining what
compilers, libraries, and tools to include in the base image.
It's what whoever built the Linux system in your car entertainment box,
your industrial control or USRP E310 might have been using to get Linux
and their software running on the boxes they're selling.

The idea is that you build yourself a full system image and tooling,
including an SDK that you can use to cross-compile software for the
target system (in your case, the pi), on your workstation.

A BSP is a board support package, and contains what is necessary to
know how build a correctly working kernel and base system. The meta-
raspberrypi thing is essentially the base system, atop of which you can
add packages (such as GNU Radio) to be compiled exactly for your
hardware.

Best regards,
Marcus

On Tue, 2018-05-08 at 23:58 -0400, Brad Hein wrote:
> I don't follow... but I look forward to reading your blog post when it is 
> available. 
> 
> On Tue, May 8, 2018 at 6:37 PM, Philip Balister  wrote:
> > On 05/08/2018 04:13 PM, Brad Hein wrote:
> > > Hi Philip,
> > > 
> > > How do I go a out trying an alternative as you suggest?
> > 
> > I have a note to do a blog post on building an aarch64 image with
> > OpenEmbedded, but paying work is interfering. It is fairly straight
> > forward the meta-raspberrypi  bsp is very good.
> > 
> > Philip
> > 
> > > 
> > > Thanks!
> > > 
> > > [Sent from mobile device]
> > > 
> > > On Tue, May 8, 2018, 6:07 PM Philip Balister  wrote:
> > > 
> > >> I'm not that familiar wit Raspian, but my impression is that it is
> > >> binary compatible with the original Pi, which has no neon support. The
> > >> volk code didn't handle this gracefully until recently.
> > >>
> > >> That said, The Pi 3 does support neon and better. For the Pi-3, I'd use
> > >> something built to take advantage of the better processor.
> > >>
> > >> Philip
> > >>
> > >>
> > >> On 05/08/2018 11:08 AM, Brad Hein wrote:
> > >>> On a new Raspberry Pi 3, running Raspbian, all apt-get package updates
> > >>> loaded, I'm encountering an error compiling gnuradio (branch: master). I
> > >>> made one modification from the default source code, and that is the
> > >> neonasm
> > >>> patch to fix a different compile error with a missing instruction on the
> > >>> Pi.
> > >>>
> > >>> Has anybody encountered the ARM mode error mentioned below or know what 
> > >>> I
> > >>> can do to push past it?
> > >>>
> > >>>
> > >>> $ git diff HEAD~1
> > >>> diff --git
> > >>> a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
> > >>> b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
> > >>> index e4002b8..37dcd75 100644
> > >>> --- a/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
> > >>> +++ b/kernels/volk/asm/neon/volk_32f_x2_dot_prod_32f_a_neonasm_opts.s
> > >>> @@ -43,7 +43,12 @@ volk_32f_x2_dot_prod_32f_a_neonasm_opts:
> > >>>   vadd.f32   s15, s15, s13
> > >>>   vadd.f32   s15, s15, s14
> > >>>   bls.done  @ if vector is multiple of 16 then finish
> > >>> - sbfx   r11, r1, #2, #1 @ check alignment
> > >>> +@ BH
> > >>>
> > >> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00234.html
> > >>> +@ sbfx   r11, r1, #2, #1 @ check alignment
> > >>> + mov  r11,#0
> > >>> + tst  r1,#4
> > >>> + movner11,#15
> > >>> +# BH END OF PATCH
> > >>>   rsbr9, r8, r3
> > >>>   andr11, r11, #3
> > >>>   movr6, r1
> > >>>
> > >>>
> > >>>
> > >>> $ cat /etc/debian_version
> > >>> 8.0
> > >>>
> > >>>
> > >>> $ uname -a
> > >>> Linux redwave 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l
> > >>> GNU/Linux
> > >>>
> > >>> $ gnuradio branch: master (82d0a6b)
> > >>> * 82d0a6b -(4 weeks ago) gr-newmod: Pylint fixes in python scripts .
> > >>> Swapnil Negi (HEAD, origin/master, origin/HEAD, master)
> > >>>
> > >>>
> > >>>
> > >>> Error output follows:
> > >>>
> > >>> [  0%] Building C object
> > >>> volk/lib/CMakeFiles/volk_obj.dir/volk_machine_neon_hardfp_orc.c.o
> > >>> In file included from
> > >>> /home/pi/gr/gnuradio/build/volk/lib/volk_machine_neon_hardfp_orc.c:130:0:
> > >>> /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_multiply_32fc.h:
> > >> In
> > >>> function ‘volk_32fc_s32fc_multiply_32fc_neon’:
> > >>>
> > >> /home/pi/gr/gnuradio/volk/kernels/volk/volk_32fc_s32fc_multiply_32fc.h:282:16:
> > >>> warning: unused variable ‘cPtr’ [-Wunused-variable]
> > >>>  lv_32fc_t* cPtr = cVector;
> > >>> ^
> > >>> /tmp/ccWuy8Qj.s: Assembler messages:
> > >>> /tmp/ccWuy8Qj.s:7707: Error: selected processor does not support ARM 
> > >>> mode
> > >>> `rbit r4,r4'
> > >>> /tmp/ccWuy8Qj.s:7718: Error: selected processor does 

Re: [Discuss-gnuradio] signal cancellation example using GRC and USRP B210

[CEL]

Dear Inkyu,

there's no guarantee that the phases of both TX are exactly identical.
In fact, you should expect an unknown offset.

Also, you'll notice that your two antennas are at two different
positions in the room. You're accidentally building a beamforming
system! So, these nulls will not be everywhere in the room, but only in
a specific direction in the far field of the TX antenna. And with a
carrier frequency of nearly 6 GHz, a wavelength in air is

c/f ≈ (3·10⁸ m/s) / (6·10⁹ 1/s) = 0.05 m = 50 cm

and half that distance from a (single) transmit antenna would be the
distance at which two received signals would be exactly of opposite
phase.

So, I'm not sure what you want to demonstrate, but unless it's
beamforming, you're probably not doing it right :) Which is no shame,
but it would be interesting to hear what it is that you want to
achieve.

Best regards,

Marcus

On Fri, 2018-04-27 at 20:44 +0800, Inkyu Bang wrote:
> Hi, all !!
> 
> I am trying to make a simple example of signal cancellation using GRC.
> However, I did not get any good results.
> 
> Here is my setting
> 
> Plan: sending two sine wave with different phases and receiving canceled 
> signal (only noise)
> Center frequency: 5.89GHz (I am using the antenna supporting this center 
> frequency)
> Sampling rate: 5MHz
> Frequency of sine wave: 1kHz
> 
> USRP: B210
> Tx GRC flow graph: signal source block + USRP sink (two channels)
> Rx GRC flow graph: USRP sink + QT GUI time sink
> 
> When I send two sine signals, I used two RF chains in the same USRP.
> I received those signals at the other USRP.
> 
> I expected to see canceled signals (i.e., only noise level power in time 
> domain) 
> but still, I see sine wave signal.
> 
> I thought frequency offset in the receiving USRP is applied to both sine 
> waves.
> 
> Do I need to consider frequency offset first?
> Could anyone help me to solve this problem?
> 
> Thank you.
> Regards,
> 
> Inkyu
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fundamental question on Sampling rate

[CEL]

Hi Mehtap
On Fri, 2018-04-27 at 15:57 +0300, mehtap özkan wrote:
> Based on your calculations, I have decided to get a LIMESDR-PCIe.
> The sampling rate will be 122,88 MSPS which will give  61.44 MHz I and 61.44 
> MHz Q.
I think it is the other way around: The Sampling rates are 61.44 MHz on
I and Q simultaneously. The 122,88 MS/s is just a cumulative rate.

> That will be enough to demodulate a 50 MHz wide QPSK modulated signal.

Probably!
> I am not sure if I can decimate the  122,88 MSPS by 2 and still being able to 
> correctly demodulate the signal.

No, you can't. See the sampling theorem.

Best regards,
Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with USRP receiver Gain

[CEL]

Dear Prabhat,

the B210 doesn't support 120 dB of gain. 
Ask uhd_uspr_probe about minimum and maximum gain, or simply don't use
"absolute gain" setting in the USRP block, but "relative" gain, and use
0 for minimum, and 1 for maximum gain.

Risking that I repeat what I said before: RSSI is a signal-specific,
not universally defined number that often has a lot to do with rough
guesswork, or, in the case of LTE, it's defined in the standard, but
none of these definitions look like what you do in the flow graph.

If you're computing digital power, just call it power. No need to use a
badly defined term for it.

Also, don't use WX GUI. Use Qt. WX is about to get deleted from GNU
Radio.

Best regards,
Marcus

On Fri, 2018-04-27 at 16:34 +0530, Prabhat Kumar Rai wrote:
> Hello,
> 
> I am receiving RSSI with USRP B210 and I have some doubt regarding that :
> Also, I am attaching grc file and python file for reference.
> 
> 1- I am saving my received data to a file_sink and trying to compute
> power(RSSI) from that by using python code, kindly see attached python
> file.
> At the output, I am getting -20dB if there is no signal source and
> 20dB when there is a signal source (which is not possible).
> 
> 2- Change in gain in USRP_SOURCE block leads to change in the output
> value so I am using maximum as 120 dB. Is that possible or any gain is
> fine?
> 
> Is there any error in python code or in grc file?
> 
> Any help is really appreciated.
> 
> Thanks,
> Prabhat
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tx Burst for Chirp signals

[CEL]

Hi!

So, you're continuously generating data to send, so it continuously
sends data – it works as you've designed it. Maybe you want to somehow
add "tx_time" tags every "packet length" samples?
Also, make sure that one packet really contains one chirp. In your
previous flow graph, that wasn't the case, so make sure the packet
length corresponds to the number of samples per chirp.

Best regards,
Marcus

On Thu, 2018-05-10 at 09:20 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi, 
> 
> Thanks Marcus! Corrected it and thanks for the info!
> 
> 1)  I would like to transmit burst signals of the chirp
> generated  from the flowgraph attached. I tried using the “stream to
> Tagged stream” way, but when I ran the GNU Radio Companion, it’s
> being  transmitted continuously. Nothing seems to be happening. Am I
> doing  something wrong and is there a better way for burst
> transmission?
> 
> Does anyone know this?
> 
> Thanks in advanced!
> 
> -Original Message-
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> Sent: Thursday, 10 May 2018 5:06 PM
> To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> 
> Hi!
> 
> your receiver low pass filter is incorrectly parameterized, probably
> (sampling rate isn't 32 MS/s). And so is the rest of your flow graph
> –
> your USRP is using a sampling rate of 2 MS/s, but you act as if it's
> running at 32 MS/s. Start with 2 MS/s and make it work with that –
> then
> later scale up (the processing load of 32 MS/s is harder than you
> probably think).
> Remember that GNU Radio is pure DSP, so all the axis labels on your
> visualizations are just that – labels, interpreting relative
> frequencies (i.e. frequencies divided by the sampling rate) by
> multiplying them with the value you entered in bandwidth. The
> "physical
> meaning" of your signal is defined by the sampling rate of your
> physical device.
> Thus, you want to use the same sampling rate everywhere in your flow
> graph. These things mean! something.
> 
> Best regards,
> Marcus
> 
> On Thu, 2018-05-10 at 08:31 +, Yeo Jin Kuang Alvin (IA) wrote:
> > Hi everyone,
> >  
> > There are two questions that I would like to ask.
> >  
> > 1)  I would like to transmit burst signals of the chirp
> > generated
> > from the flowgraph attached. I tried using the “stream to Tagged
> > stream” way, but when I ran the GNU Radio Companion, it’s being
> > transmitted continuously. Nothing seems to be happening. Am I doing
> > something wrong and is there a better way for burst transmission?
> >  
> > 2)  I noticed something with the sampling rates of the blocks.
> > When I use the same sampling rate for all the blocks, I get
> > underflow
> > “UUU”. However, when I changed all the block’s sampling rate to
> > 32MHz
> > and leave the USRP Sink and Source to 2MHz, no underflow is seen
> > but
> > there is still overflow (seen in the attached screenshot).
> >  
> > What is the difference between the USRP’s sampling rate compared to
> > the other block’s sampling rate?
> >  
> > Thank you in advanced!
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tx Burst for Chirp signals

[CEL]

Hi!

your receiver low pass filter is incorrectly parameterized, probably
(sampling rate isn't 32 MS/s). And so is the rest of your flow graph –
your USRP is using a sampling rate of 2 MS/s, but you act as if it's
running at 32 MS/s. Start with 2 MS/s and make it work with that – then
later scale up (the processing load of 32 MS/s is harder than you
probably think).
Remember that GNU Radio is pure DSP, so all the axis labels on your
visualizations are just that – labels, interpreting relative
frequencies (i.e. frequencies divided by the sampling rate) by
multiplying them with the value you entered in bandwidth. The "physical
meaning" of your signal is defined by the sampling rate of your
physical device.
Thus, you want to use the same sampling rate everywhere in your flow
graph. These things mean! something.

Best regards,
Marcus

On Thu, 2018-05-10 at 08:31 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi everyone,
>  
> There are two questions that I would like to ask.
>  
> 1)  I would like to transmit burst signals of the chirp generated
> from the flowgraph attached. I tried using the “stream to Tagged
> stream” way, but when I ran the GNU Radio Companion, it’s being
> transmitted continuously. Nothing seems to be happening. Am I doing
> something wrong and is there a better way for burst transmission?
>  
> 2)  I noticed something with the sampling rates of the blocks.
> When I use the same sampling rate for all the blocks, I get underflow
> “UUU”. However, when I changed all the block’s sampling rate to 32MHz
> and leave the USRP Sink and Source to 2MHz, no underflow is seen but
> there is still overflow (seen in the attached screenshot).
>  
> What is the difference between the USRP’s sampling rate compared to
> the other block’s sampling rate?
>  
> Thank you in advanced!
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tx Burst for Chirp signals

[CEL]

sure, but it's not the way I'd recommend for perfectly periodic
transmissions and I'm almost certain this will just lead us further
down your XY problem: https://xyproblem.info

Can you maybe explain in detail what you need chirps for, why you need
them at this low repitition rate, what the purpose of all this is? We
might be better at helping you that way.

thank you,
Marcus

On Thu, 2018-05-10 at 09:58 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi,
> 
> Thank you again. Are there any examples or guides I can refer to
> regarding the tx_time tags? Will this allow me to transmit every few
> seconds?
> 
> Thank you in advanced!
> 
> -Original Message-----
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> Sent: Thursday, 10 May 2018 5:34 PM
> To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> 
> Hi!
> 
> So, you're continuously generating data to send, so it continuously
> sends data – it works as you've designed it. Maybe you want to
> somehow
> add "tx_time" tags every "packet length" samples?
> Also, make sure that one packet really contains one chirp. In your
> previous flow graph, that wasn't the case, so make sure the packet
> length corresponds to the number of samples per chirp.
> 
> Best regards,
> Marcus
> 
> On Thu, 2018-05-10 at 09:20 +, Yeo Jin Kuang Alvin (IA) wrote:
> > Hi, 
> > 
> > Thanks Marcus! Corrected it and thanks for the info!
> > 
> > 1)  I would like to transmit burst signals of the chirp
> > generated  from the flowgraph attached. I tried using the “stream
> > to
> > Tagged stream” way, but when I ran the GNU Radio Companion, it’s
> > being  transmitted continuously. Nothing seems to be happening. Am
> > I
> > doing  something wrong and is there a better way for burst
> > transmission?
> > 
> > Does anyone know this?
> > 
> > Thanks in advanced!
> > 
> > -Original Message-
> > From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> > Sent: Thursday, 10 May 2018 5:06 PM
> > To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> > 
> > Hi!
> > 
> > your receiver low pass filter is incorrectly parameterized,
> > probably
> > (sampling rate isn't 32 MS/s). And so is the rest of your flow
> > graph
> > –
> > your USRP is using a sampling rate of 2 MS/s, but you act as if
> > it's
> > running at 32 MS/s. Start with 2 MS/s and make it work with that –
> > then
> > later scale up (the processing load of 32 MS/s is harder than you
> > probably think).
> > Remember that GNU Radio is pure DSP, so all the axis labels on your
> > visualizations are just that – labels, interpreting relative
> > frequencies (i.e. frequencies divided by the sampling rate) by
> > multiplying them with the value you entered in bandwidth. The
> > "physical
> > meaning" of your signal is defined by the sampling rate of your
> > physical device.
> > Thus, you want to use the same sampling rate everywhere in your
> > flow
> > graph. These things mean! something.
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2018-05-10 at 08:31 +, Yeo Jin Kuang Alvin (IA) wrote:
> > > Hi everyone,
> > >  
> > > There are two questions that I would like to ask.
> > >  
> > > 1)  I would like to transmit burst signals of the chirp
> > > generated
> > > from the flowgraph attached. I tried using the “stream to Tagged
> > > stream” way, but when I ran the GNU Radio Companion, it’s being
> > > transmitted continuously. Nothing seems to be happening. Am I
> > > doing
> > > something wrong and is there a better way for burst transmission?
> > >  
> > > 2)  I noticed something with the sampling rates of the
> > > blocks.
> > > When I use the same sampling rate for all the blocks, I get
> > > underflow
> > > “UUU”. However, when I changed all the block’s sampling rate to
> > > 32MHz
> > > and leave the USRP Sink and Source to 2MHz, no underflow is seen
> > > but
> > > there is still overflow (seen in the attached screenshot).
> > >  
> > > What is the difference between the USRP’s sampling rate compared
> > > to
> > > the other block’s sampling rate?
> > >  
> > > Thank you in advanced!
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Audio File transmission using Qpsk modulation

[CEL]

No, 15 kHz is not "very minimum", it's impossible. Your console will
contain information that the UHD picked a different, higher, sampling
rate.

Your "I picked 15 kS/s to get a clear audio file" doesn't make much
sense; this is not how digital communications work!

I'm afraid you'll have to be way more careful when designing an RF
transceiver. Maybe you'd want to read up on complex baseband,
constellations, pulse shaping, symbol synchronization and resamplers,
so that you understand what's happening in your flow graph.

Best regards,
Marcus

On Thu, 2018-05-10 at 17:29 -0400, JONNY LEYIKUN wrote:
> HI  Jeff Long
> 
> Yaah 15K is very minimum to use in USRP sink  
> I use 15K sample rate in order to get clear  Audio File. but I also
> use large sample rate in USRP sink but the result is more or less the
> same
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnuradio + ZeroMQ = win!

[CEL]

Hi Brad!

Thanks for sharing your success! It's always valuable to hear what
works for people :)

Best regards,
Marcus

On Sat, 2018-05-12 at 09:01 -0400, Brad Hein wrote:
> Just a follow up to some of the issues I reported recently with the
> Socket PDU blocks.. Switching to ZeroMQ (ZMQ) based source and sink
> blocks for flowgraph-to-flowgraph communications has eliminated all
> of the issues I was encountering. Thanks to those who suggested
> trying zmq. 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Audio File transmission using Qpsk modulation

[CEL]

There's no "exact block" to solve your problem.
You have a specific task, and you'll have to design a specific
solution. We can't do that for you, as much a we'd like to.

Best regards,
Marcus

On Sat, 2018-05-12 at 18:10 +0200, JONNY LEYIKUN wrote:
> Thanks for the feedback!  Mr muller 
> To be honest am new for this software but I tried my best to figure
> out this problem.if you can please send me the exact block 
> 
> 
> 
> On Sat, 12 May 2018, 12:11 Müller, Marcus (CEL), <muel...@kit.edu>
> wrote:
> > No, 15 kHz is not "very minimum", it's impossible. Your console
> > will
> > contain information that the UHD picked a different, higher,
> > sampling
> > rate.
> > 
> > Your "I picked 15 kS/s to get a clear audio file" doesn't make much
> > sense; this is not how digital communications work!
> > 
> > I'm afraid you'll have to be way more careful when designing an RF
> > transceiver. Maybe you'd want to read up on complex baseband,
> > constellations, pulse shaping, symbol synchronization and
> > resamplers,
> > so that you understand what's happening in your flow graph.
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2018-05-10 at 17:29 -0400, JONNY LEYIKUN wrote:
> > > HI  Jeff Long
> > > 
> > > Yaah 15K is very minimum to use in USRP sink  
> > > I use 15K sample rate in order to get clear  Audio File. but I
> > also
> > > use large sample rate in USRP sink but the result is more or less
> > the
> > > same
> > > ___
> > > 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] Tx Burst for Chirp signals

[CEL]

Could you be a little more specific, please, than "receive, digitize
and re-transmit"? For what purpose? Why a chirp? Can you please give us
the bigger picture, here? What's the thing you need to build?

Best regards,
Marcus
On Fri, 2018-05-11 at 02:03 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hello,
> 
> I am currently trying to work on the USRP B210 to act as a
> transceiver. Basically, what I am tasked to do is to receive,
> digitize, modulate and re-transmit. So what I am planning to do now
> is to create a chirp signal in the USRP B210 and transmit back to
> itself to the RX port. As a result, I have to send a pulse and stop
> for a moment while it is receiving and then transmit again.
> 
> Thank you in advanced!
> 
> -Original Message-
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> Sent: Thursday, 10 May 2018 9:09 PM
> To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> 
> sure, but it's not the way I'd recommend for perfectly periodic
> transmissions and I'm almost certain this will just lead us further
> down your XY problem: https://xyproblem.info
> 
> Can you maybe explain in detail what you need chirps for, why you
> need
> them at this low repitition rate, what the purpose of all this is? We
> might be better at helping you that way.
> 
> thank you,
> Marcus
> 
> On Thu, 2018-05-10 at 09:58 +, Yeo Jin Kuang Alvin (IA) wrote:
> > Hi,
> > 
> > Thank you again. Are there any examples or guides I can refer to
> > regarding the tx_time tags? Will this allow me to transmit every
> > few
> > seconds?
> > 
> > Thank you in advanced!
> > 
> > -Original Message-
> > From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> > Sent: Thursday, 10 May 2018 5:34 PM
> > To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> > 
> > Hi!
> > 
> > So, you're continuously generating data to send, so it continuously
> > sends data – it works as you've designed it. Maybe you want to
> > somehow
> > add "tx_time" tags every "packet length" samples?
> > Also, make sure that one packet really contains one chirp. In your
> > previous flow graph, that wasn't the case, so make sure the packet
> > length corresponds to the number of samples per chirp.
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2018-05-10 at 09:20 +, Yeo Jin Kuang Alvin (IA) wrote:
> > > Hi, 
> > > 
> > > Thanks Marcus! Corrected it and thanks for the info!
> > > 
> > > 1)  I would like to transmit burst signals of the chirp
> > > generated  from the flowgraph attached. I tried using the “stream
> > > to
> > > Tagged stream” way, but when I ran the GNU Radio Companion, it’s
> > > being  transmitted continuously. Nothing seems to be happening.
> > > Am
> > > I
> > > doing  something wrong and is there a better way for burst
> > > transmission?
> > > 
> > > Does anyone know this?
> > > 
> > > Thanks in advanced!
> > > 
> > > -Original Message-
> > > From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> > > Sent: Thursday, 10 May 2018 5:06 PM
> > > To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> > > Subject: Re: [Discuss-gnuradio] Tx Burst for Chirp signals
> > > 
> > > Hi!
> > > 
> > > your receiver low pass filter is incorrectly parameterized,
> > > probably
> > > (sampling rate isn't 32 MS/s). And so is the rest of your flow
> > > graph
> > > –
> > > your USRP is using a sampling rate of 2 MS/s, but you act as if
> > > it's
> > > running at 32 MS/s. Start with 2 MS/s and make it work with that
> > > –
> > > then
> > > later scale up (the processing load of 32 MS/s is harder than you
> > > probably think).
> > > Remember that GNU Radio is pure DSP, so all the axis labels on
> > > your
> > > visualizations are just that – labels, interpreting relative
> > > frequencies (i.e. frequencies divided by the sampling rate) by
> > > multiplying them with the value you entered in bandwidth. The
> > > "physical
> > > meaning" of your signal is defined by the sampling rate of your
> > > physical device.
> > > Thus, you want to use the same sampling rate everywhere in your
> > > flow
> > > graph. These things mean! something.
> > > 
> > &

Re: [Discuss-gnuradio] An analog RF question

[CEL]

Hi Marcus,

> Use digipots to set the R values, and use a fixed value for C, or
perhaps selectable C as well (probably only two or three values).

friends of mine tried to do variable attenuation for powerline
communication frontends using digipots, and: these can be very
frequency-selective, even below 10 MHz. Maybe they were just using the
wrong components.

> Or, a small number (4?) of selectable L-C-R low-pass filters, and fix the 
> sample rates to a small number.

That sounds like a nice choice, given the existence of highspeed analog
switches (which have gotten really affordable due to USB2, PCIe and
USB3).

I wonder if one could build an active filter with a (video?) opamp and
make components in the feedback branches exchangeable, assuming the
contribution of the analog switch compared to the effective component
values at the frequencies of interest are negligible. Then again, this
pretty much sounds like a non-integrated digipot, doesn't it?

Best regards,
Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Changing delay block value over time

[CEL]

No.

Best regards,
Marcus
On Thu, 2018-05-24 at 09:22 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi all,
>  
> Am I able to change the value of the delay block automatically in GRC over 
> time when the flowgraph is running?
>  
> Thank you in advanced!
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] random number problem

[CEL]

Hi! 

Don't use random.h's `random()` in GNU Radio. It's not thread-safe and
mustn't be used in multithreaded applications, and GNU Radio is
inherently multithreaded.

> So I tried to use srand(time(0))

That is **explicitly** a way to get a different sequence every time, so
this is very counter-productive. Have you read `srand`'s and `time`'s
manual pages at all?

Since you're probably using a C++ compiler that has C++11 support,
simply use 

#include  // NOT random.h
 
int main()
{
int seed = 42; // constant that defines the sequence we're getting
std::mt19937 rng(seed); //default mersenne_twister_engine 
std::uniform_real_distribution<> uni(0.0, 1.0);
for (int n = 0; n < 10; ++n) {
double uniform_number = uni(rng);
}
}

Best regards,
Marcus

#On Thu, 2018-05-24 at 18:17 +0900, 김무연 wrote:
>  Hi all!
> Could I ask something?
> I want to generate random numbers
> So when I make a block, I included random.h and I used random() function
> But every time it produces the same output
> And I want to use this blocks twice in the gnuradio
> So I tried to use srand(time(0))
> But it didn't work
> My question is this are there any method to do the same role of 
> srand(time(0)) when I create a block in gnuradio?
> Thanks 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Changing delay block value over time

[CEL]

I'd recommend that, yes :) But then again, the delay block you're
referring to only allows for full samples in delay; maybe you much
rather want an adjustable interpolator? What is the purpose of all this
(kind of a recurring theme, me asking *why* people want to do
something, so that we can help them)?

Best regards,
Marcus

On Thu, 2018-05-24 at 10:00 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi all,
> 
> Is there a way to implement control of delays over time? Type out own code?
> 
> Thank you in advanced!
> 
> -Original Message-
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> Sent: Thursday, 24 May 2018 5:58 PM
> To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Changing delay block value over time
> 
> No.
> 
> Best regards,
> Marcus
> On Thu, 2018-05-24 at 09:22 +, Yeo Jin Kuang Alvin (IA) wrote:
> > Hi all,
> >  
> > Am I able to change the value of the delay block automatically in GRC over 
> > time when the flowgraph is running?
> >  
> > Thank you in advanced!
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio master and UHD RFNOC Version Issue

[CEL]

Hi John, 
GNU Radio versioning  is totally independent from UHD versioning, and
that's what's defining the compatibility with the FPGA image.
So, you need to install the UHD that fits your FPGA image (or use an
FPGA image that fits your installed UHD).

Best regards,
Marcus
On Thu, 2018-05-24 at 13:21 -0600, John Medrano wrote:
> Recently we built GNURadio and UHD from source on a Fedora 28. Since we use 
> RFNOC we were compiling GNURadio version v3.7.10.2, and using rfnoc-devel 
> branch from UHD.
> 
> Building on Fedora 28 we received compiling errors when we were building 
> v3.7.10.2. So we decided to build the master branch instead. 
> 
> The problem is that the master branch is not compatible with UHD firmware for 
> RFNOC. Expecting firmware version 85 and found version 83.
> 
> Is the current UHD RFNOC branch in github compatible with master branch of 
> GNURadio?
> 
> What is latest version of GNURadio that we can use? Can we compile in Fedora 
> 28?
> 
> Please advise,
> 
> Thank you,
> John
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio master and UHD RFNOC Version Issue

[CEL]

Hi John,
On Fri, 2018-05-25 at 06:39 -0600, John Medrano wrote:
> Thank you for the response. 
> 
> The issue that we have is that the latest UHD RFNOC version is not compatible 
> with latest version of GNU Radio.

That's simply not true. UHD, to GNU Radio, is just a library.

> 
> So I must either compile older version in with newer compiler, 

the compiler version has little to nothing to do with this, luckily :)

> or downgrade to a version that is compatible with UHD RFNOC.

You need to use a UHD version that supports what you need (RFNoC); "UHD
RFNOC" is not a thing. RFNoC is an architectural aspect of the FPGA
designs running on some USRPs. So, you need an _UHD_ version that comes
with compatibility for these.

>  Upgrading UHD to latest version will not allow us to use RFNOC. I may be 
> wrong, but that is my understanding. 

You'll probably need to manually build UHD, anyway.
After that, you need to build GNU Radio against that UHD version.

Best regards,
Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio master and UHD RFNOC Version Issue

[CEL]

Hi John,

no need to apologize; we're all learners of some kind!
So, let me annotate your terminology below, so that we are on the same
page :)

On Fri, 2018-05-25 at 07:20 -0600, John Medrano wrote:
> Hello,
> 
> I apologize for my terminology, it is causing some confusion. 
> 
> If you download the source from https://github.com/EttusResearch/uhd. You can 
> compile this version and it should work fine with latest version of GNU Radio

Nope – that's the wrong way around. UHD is a library used /by/ GNU
Radio, so after building UHD, you need to build GNU Radio, to use that
specific version of UHD.


> But this version is missing additional modules that are available in branch 
> rfnoc-devel. I inspected /host/lib/rfnoc for both the master and rfnoc-devel 
> branches; there are several modules from rfnoc-devel branch such as sig_gen 
> that are not available in master branch. That is what I am referring to as 
> RFNOC UHD. I would like to continue using rfnoc-devel branch, and hence the 
> issue that I am having. Since the version we were instructed that works with 
> that branch, no longer compiles in latest version of Fedora. That version 
> being v3.7.10.2.

So, as Derek said, for RFNOC features, you might have to build your own
UHD (and consequently, your own GNU Radio afterwards) with specific
flags.


> When we build source, we typically install all dependencies and it the 
> proceeds to build with no issue. But in this latest version of Fedora, we 
> received compilation errors while trying to build v3.7.10.2.

To be 100 % certain I'm getting you correct here: when building UHD
3.7.10.2 on Fedora28, you're getting compile errors?

> Since latest version of GNU Radio built with no issue, I suspected that 
> changes had been made to correct for newer version.

Again, building UHD (and installing it) has to happen before GNU Radio,
and build errors in one are unrelated to the other, unless the GNU
Radio compile error especially states that "hey, we've got some
function that we expect, but the UHD headers don't declare that".

> 
> Where in the source code, do they check the version of UHD for compatibility?

Yes. GNU Radio checks, at runtime, whether the UHD library used when
building GNU Radio is the same as is being loaded at run time. Because:
these have to match.

The error you're experiencing, however, has nothing to do with that.
It's a **firmware** version mismatch.
GNU Radio doesn't know, care or directly interact with the firmware
running on your USRP at all.

That's UHD checking whether the USRP runs the right firmware. 

This all has nothing to do with GNU Radio!


> This will help me to look back at and see which GNU Radio versions are 
> compatible with the rfnoc-devel branch.

Please stop saying that.
GNU Radio has no relation to RFNoC.

Best regards,
Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Changing delay block value over time

[CEL]

Hi!

So, I guess, full sample delay is far too coarse for your application,
right? 

Best regards,
Marcus
On Fri, 2018-05-25 at 00:46 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi,
> 
> I need to simulate propagation delay, for example, having a plane fly past 
> and have to collect data for 5 secs which means I need to calculate the slant 
> range over time. In order for me to get the propagation delay 2R/c. As a 
> result, I need to change the delays for 5  secs.
> 
> Thank you in advanced!
> 
> -Original Message-----
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> Sent: Thursday, 24 May 2018 7:15 PM
> To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Changing delay block value over time
> 
> I'd recommend that, yes :) But then again, the delay block you're
> referring to only allows for full samples in delay; maybe you much
> rather want an adjustable interpolator? What is the purpose of all this
> (kind of a recurring theme, me asking *why* people want to do
> something, so that we can help them)?
> 
> Best regards,
> Marcus
> 
> On Thu, 2018-05-24 at 10:00 +, Yeo Jin Kuang Alvin (IA) wrote:
> > Hi all,
> > 
> > Is there a way to implement control of delays over time? Type out own code?
> > 
> > Thank you in advanced!
> > 
> > -Original Message-
> > From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> > Sent: Thursday, 24 May 2018 5:58 PM
> > To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Changing delay block value over time
> > 
> > No.
> > 
> > Best regards,
> > Marcus
> > On Thu, 2018-05-24 at 09:22 +, Yeo Jin Kuang Alvin (IA) wrote:
> > > Hi all,
> > >  
> > > Am I able to change the value of the delay block automatically in GRC 
> > > over time when the flowgraph is running?
> > >  
> > > Thank you in advanced!
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Changing delay block value over time

[CEL]

By the way, a physical hint:

what you get when a plane approaches or leaves from you is a phase of
the wave that /changes linearly over time/, if you think about it.

A linearly over time changing phase is a frequency.

What you want to model is probably Doppler frequency shift in addition
to a time shift. 

The way to do that is not a simple delay.

Best regards,
Marcus


On Fri, 2018-05-25 at 00:46 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi,
> 
> I need to simulate propagation delay, for example, having a plane fly past 
> and have to collect data for 5 secs which means I need to calculate the slant 
> range over time. In order for me to get the propagation delay 2R/c. As a 
> result, I need to change the delays for 5  secs.
> 
> Thank you in advanced!
> 
> -Original Message-----
> From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> Sent: Thursday, 24 May 2018 7:15 PM
> To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Changing delay block value over time
> 
> I'd recommend that, yes :) But then again, the delay block you're
> referring to only allows for full samples in delay; maybe you much
> rather want an adjustable interpolator? What is the purpose of all this
> (kind of a recurring theme, me asking *why* people want to do
> something, so that we can help them)?
> 
> Best regards,
> Marcus
> 
> On Thu, 2018-05-24 at 10:00 +, Yeo Jin Kuang Alvin (IA) wrote:
> > Hi all,
> > 
> > Is there a way to implement control of delays over time? Type out own code?
> > 
> > Thank you in advanced!
> > 
> > -Original Message-
> > From: Müller, Marcus (CEL) [mailto:muel...@kit.edu] 
> > Sent: Thursday, 24 May 2018 5:58 PM
> > To: Yeo Jin Kuang Alvin (IA); discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Changing delay block value over time
> > 
> > No.
> > 
> > Best regards,
> > Marcus
> > On Thu, 2018-05-24 at 09:22 +, Yeo Jin Kuang Alvin (IA) wrote:
> > > Hi all,
> > >  
> > > Am I able to change the value of the delay block automatically in GRC 
> > > over time when the flowgraph is running?
> > >  
> > > Thank you in advanced!
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] a single source module to generate a random sequence with a pre-ample in the front

[CEL]

Hi Linda,

Why should the Ettus website contain GNU Radio examples?
Also, why should this specific example exist? 
Anyway, all you need is the "vector insert" block.

Best regards,
Marcus
On Fri, 2018-05-25 at 21:05 -0400, Linda20071 wrote:
> There is an example on ettus website that uses a single source module
> to generate a random sequence with a preamble in the front (on the
> same field in this module's properties dialogue box). I think this is
> an example to show preamble synchronization. I simply couldn't find
> the website with this example / flowgraph on ettus website. Could
> somebody kindly point out where it is?
> 
> Thank you. 
> ___
> 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] Incorrect quantizations when converting from float to char

[CEL]

If possible, please track progress on
https://github.com/gnuradio/volk/issues/188

On Sat, 2018-06-09 at 15:30 +, Müller, Marcus (CEL) wrote:
> Hi Paul,
> 
> hm, OK, considering the actual conversion is done in VOLK, can you
> tell
> us
> 
> * whether ~/.volk/volk_config exists (and if so, its contents
> regarding
> volk_32f_s32f_convert_8i )
> * what the output of `volk-config-info --machine` is?
> 
> Thanks,
> Marcus
> 
> On Sat, 2018-06-09 at 17:13 +0200, Paul Boven wrote:
> > Hi everyone,
> > 
> > I'm trying to perform 2 bit sampling of an RF signal. In one
> > approach, 
> > I'm using a float->char block, and noticed that around zero, a
> > number
> > of 
> > float inputs become quantized in a bin that's one off from the
> > correct 
> > value. The ones that are wrong are always off by one, with their 
> > quantization error always in the direction of zero.
> > 
> > The problem can be demonstrated with a really simple flowchart,
> > using 
> > the following blocks:
> > 
> > * Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0,
> > Output 
> > type: Float)
> > * Throttle
> > The throttle is then connected to two blocks:
> > * A file-sink (Type Float) and a
> > * 'Float to Char' block.
> > * The float to char block is again connected to a File Sink, now of
> > type 
> > Char.
> > 
> > As an example, I've plotted all the samples that quantized as
> > zero. 
> > These should fall in the range [-0.5:0.5], but occasionally we also
> > get 
> > hits that lie within [-1:1]. These mishaps are rare (about one in
> > 2000). 
> > It also shows that they only occur at multiples of 8192 samples,
> > and 
> > zooming in reveals that they always happen shortly before the next 
> > multiple of 8192, not after.
> > 
> > For other values than 0, the same applies, but the misquantizations
> > are 
> > only in one direction, ending up in a lower bin if the input is 
> > positive, or in a higher bin if the input is negative. Again, the 
> > misquantizations only occur in half the bin: For a value of 1, the
> > float 
> > value should be in [0.5:1.5], but occasionally a value in [1.5:2]
> > also 
> > ends up being quantized as 1.
> > 
> > This seems to me a bug that is somehow related to internal block 
> > boundaries, but I'm not familiar enough with the internals of
> > GnuRadio 
> > to figure out just what's going wrong.
> > 
> > The problem does NOT occur when converting to Short or Int.
> > 
> > This is using GnuRadio 3.7.11 (as packaged with Ubuntu 18.04).
> > 
> > Regards, Paul Boven.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > 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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine (was: Re: Incorrect quantizations when converting from float to char)

[CEL]

Hi Paul,

yes, this seems to be the case where the "naive" C implementation
behaves differently from all the SIMD ones: 

As far as I know – but I'm desparately looking for any standards
document that specifies that – doing a 

int8_t val = (int8_t) 8.8f;

will always lead to 8, whereas

int8_t val = (int8_t) -8.8f;

would always lead to -8.

Now, for the conversion operations used in the SIMD kernels, it depends
on specific flags being set in FPU-control registers (MXCSR, it seems).
U. Noone set these to give identical results as the native C
conversion above, so if I set the tolerance in the kernel unit test to
0 instead of 1 (which it always should have been), I get a whole lot of
failures. Great.

Normally, we'd stick with the what the generic version of a kernel
gives us.

I'd do that here, too. But: that would lead to a non-rounding
behaviour... I'm breaking someone's porcelain here, no matter what I
do.

Any ideas?

Best regards,
Marcus

On Sat, 2018-06-09 at 18:24 +0200, Paul Boven wrote:
> Hi Marcus,
> 
> Just reran the test after editing volk_config, and the result is 
> somewhat surprising:
> 
> Every float in [-1:1] now converts to zero. Every float in [1:2] now 
> converts to 1. Whereas it should be [-0.5:0.5] and [0.5:1.5].
> 
> It seems that most of the time, the u_sse2 converter is used, but at
> the 
> end of each multiple of 8192 bytes, a few are done with the
> 'generic' 
> converter - that would match perfectly with the observed behaviour.
> 
> It was also pointed out to me (on irc, unfortunately no longer in my 
> history) that it is strange that for some acceleration types, there
> is a 
> cast to int16_t instead of int8_t at the end of the routine, e.g.:
> 
> https://github.com/gnuradio/volk/blob/master/kernels/volk/volk_32f_s3
> 2f_convert_8i.h#L200
> 
> I had not really looked into that before because having run the 
> volk_profile seemed to make no difference.
> 
> Regards, Paul Boven.
> 
> On 06/09/2018 06:08 PM, Müller, Marcus (CEL) wrote:
> > I can reproduce these, but do the errors disappear for you if you
> > replace "u_sse2 u_sse2" with "generic generic" on that line?
> > 
> > 
> > Best regards,
> > Marcus
> > On Sat, 2018-06-09 at 18:04 +0200, Paul Boven wrote:
> > > Hi Marcus,
> > > 
> > > This machine did not yet have a volk_config when I ran these
> > > tests.
> > > 
> > > I have since run volk_profile and rebooted, and the Float->Char
> > > quantization bug still occurs.
> > > 
> > > $ volk-config-info --machine
> > > avx2_64_mmx_orc
> > > 
> > > $ grep volk_32f_s32f_convert_8i .volk/volk_config
> > > volk_32f_s32f_convert_8i u_sse2 u_sse2
> > > 
> > > Regards, Paul Boven.
> > > 
> > > On 06/09/2018 05:30 PM, Müller, Marcus (CEL) wrote:
> > > > Hi Paul,
> > > > 
> > > > hm, OK, considering the actual conversion is done in VOLK, can
> > > > you
> > > > tell
> > > > us
> > > > 
> > > > * whether ~/.volk/volk_config exists (and if so, its contents
> > > > regarding
> > > > volk_32f_s32f_convert_8i )
> > > > * what the output of `volk-config-info --machine` is?
> > > > 
> > > > Thanks,
> > > > Marcus
> > > > 
> > > > On Sat, 2018-06-09 at 17:13 +0200, Paul Boven wrote:
> > > > > Hi everyone,
> > > > > 
> > > > > I'm trying to perform 2 bit sampling of an RF signal. In one
> > > > > approach,
> > > > > I'm using a float->char block, and noticed that around zero,
> > > > > a
> > > > > number
> > > > > of
> > > > > float inputs become quantized in a bin that's one off from
> > > > > the
> > > > > correct
> > > > > value. The ones that are wrong are always off by one, with
> > > > > their
> > > > > quantization error always in the direction of zero.
> > > > > 
> > > > > The problem can be demonstrated with a really simple
> > > > > flowchart,
> > > > > using
> > > > > the following blocks:
> > > > > 
> > > > > * Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0,
> > > > > Output
> > > > > type: Float)
> > > > > * Throttle
> > > > > The throttle is then connected to two blocks:
> > > > > * A file-sink (Type Float) and a
> > > > > * 'Float to Char' block.
> > > &

Re: [Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine

[CEL]

Hi Paul,

I agree with everything you say. Float to char should behave *exactly*
like float to int and short. Will fix it in that way. Will also have a
truncating version, maybe. I've just added 3 lines of code to the
current implementation to demonstrate it's trivial to change the
rounding mode. X87 FPUs are darn mighty things.

This brings me to another aspect: As far as I can tell from this height
is that VOLK code absolutely neglects to configure the FPU to a known
state. If the calling thread decides to do a   

_MM_SET_ROUNDING_MODE(_MM_ROUND_TOWARD_ZERO);

before calling volk_32f_s32f_convert_8i, all the kernels behave like
the truncate-to-0 generic kernel. That can't be what we want, nor is it
documented.

So, that's a bigger issue with VOLK: on one hand, we'd want to set that
SIMD FPU control register (MXCSR) on every entry into a volk kernel
that uses rounding, under- or overflowing SIMD intrinsics to have
defined behaviour. Since we are nice programmers, we don't want to have
surprising side effects, so we'd restore it to its original state on
exit... I see pipeline flush and performance bottleneck right there,
but it's IA64 calling convention to save and restore as callee. 

Best regards,
Marcus
On Sat, 2018-06-09 at 20:18 +0200, Paul Boven wrote:
> Hi Marcus,
> 
> I would prefer that when going from float to int, every 'bin' should 
> have equal size. So I can think of two ways to do that:
> 
> 1) zero corresponds to [-0.5 : 0.4999]
> 
> or
> 
> 2) zero corresponds to [0.0 : 0.99]
> 
> whereas the 'generic' optimization does
> 
> 3) zero corresponds to [-1 to 0.99]
> 
> The second was actually the behaviour I was expecting, and I was 
> pleasantly surprised when GnuRadio seemed to do the first - but then 
> occasionally it doesn't.
> 
> I just did a quick test in python3, and there, the range of int(x)
> for 
> zero runs [-0.99 : 0.99], so I'm expecting most programming 
> languages to behave that way.
> 
> So, I guess a programmer would expect the behaviour as in the third 
> case. Someone who is converting radio signals might want either the 
> first or second case, as otherwise you end up with some interesting 
> non-linearities.
> 
> The gnuplot helpfile states: " The `int(x)` function returns the
> integer 
> part of its argument, truncated toward zero."
> 
> But gnuplot also provides functions like 'floor(x)' and ceil(x).
> 
> So the real question is still, do we want the behaviour of int(x),
> or 
> the behaviour that an analog to digital converter would have?
> 
> Finally, I'd say we want the behaviour to be the same for Int, Short
> and 
> Char. So I ran a few more tests.
> 
> With Volk enabled, Float to Int, Short and Char treat [-0.5 :
> 0.49] 
> as zero, with the occasional glitch for Char.
> 
> volk_32f_s32f_convert_16i a_avx u_avx
> volk_32f_s32f_convert_32i a_avx u_sse2
> 
> With these conversions for Int and Short also switched to 'generic 
> generic', I get the same results:
> 
> Short zero: [-0.5 : 0.49]
> Int zero:   [-0.5 : 0.49]
> 
> So, assuming I carried out these tests correctly, the odd one out
> seems 
> to be the generic case for float to char conversion.
> 
> Note that Volk in the 16 bit and 32 bit case uses a function called 
> 'rintf' in the conversions. From its manpage:
> 
> "(...) round  their argument  to  an integer value in floating-point 
> format".
> 
> So I say this boils down to a bug in the 'generic' float to char
> case.
> 
> This is not a fix to make lightly, because somebody is going to have 
> their flowchart break because of this. Then again, in the current 
> situation the outcome depends on which optimizations your machine 
> happens to have available, so that's also quite bad.
> 
> Possibly there is also an optimization opportunity of never using 
> 'generic' even at the block edge when acceleration is available by 
> choosing the right size of blocks, but that's probably a small gain.
> 
> Regards, Paul Boven.
> 
> 
> 
> On 06/09/2018 07:18 PM, Müller, Marcus (CEL) wrote:
> > Hi Paul,
> > 
> > yes, this seems to be the case where the "naive" C implementation
> > behaves differently from all the SIMD ones:
> > 
> > As far as I know – but I'm desparately looking for any standards
> > document that specifies that – doing a
> > 
> > int8_t val = (int8_t) 8.8f;
> > 
> > will always lead to 8, whereas
> > 
> > int8_t val = (int8_t) -8.8f;
> > 
> > would always lead to -8.
> > 
> > Now, for the conversion operations used in the SIMD kernels, it
> > depends
> > on specific flags being set in FPU-control registers (MXCSR, it
> > 

Re: [Discuss-gnuradio] Incorrect quantizations when converting from float to char

[CEL]

I can reproduce these, but do the errors disappear for you if you
replace "u_sse2 u_sse2" with "generic generic" on that line?


Best regards,
Marcus
On Sat, 2018-06-09 at 18:04 +0200, Paul Boven wrote:
> Hi Marcus,
> 
> This machine did not yet have a volk_config when I ran these tests.
> 
> I have since run volk_profile and rebooted, and the Float->Char 
> quantization bug still occurs.
> 
> $ volk-config-info --machine
> avx2_64_mmx_orc
> 
> $ grep volk_32f_s32f_convert_8i .volk/volk_config
> volk_32f_s32f_convert_8i u_sse2 u_sse2
> 
> Regards, Paul Boven.
> 
> On 06/09/2018 05:30 PM, Müller, Marcus (CEL) wrote:
> > Hi Paul,
> > 
> > hm, OK, considering the actual conversion is done in VOLK, can you
> > tell
> > us
> > 
> > * whether ~/.volk/volk_config exists (and if so, its contents
> > regarding
> > volk_32f_s32f_convert_8i )
> > * what the output of `volk-config-info --machine` is?
> > 
> > Thanks,
> > Marcus
> > 
> > On Sat, 2018-06-09 at 17:13 +0200, Paul Boven wrote:
> > > Hi everyone,
> > > 
> > > I'm trying to perform 2 bit sampling of an RF signal. In one
> > > approach,
> > > I'm using a float->char block, and noticed that around zero, a
> > > number
> > > of
> > > float inputs become quantized in a bin that's one off from the
> > > correct
> > > value. The ones that are wrong are always off by one, with their
> > > quantization error always in the direction of zero.
> > > 
> > > The problem can be demonstrated with a really simple flowchart,
> > > using
> > > the following blocks:
> > > 
> > > * Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0,
> > > Output
> > > type: Float)
> > > * Throttle
> > > The throttle is then connected to two blocks:
> > > * A file-sink (Type Float) and a
> > > * 'Float to Char' block.
> > > * The float to char block is again connected to a File Sink, now
> > > of
> > > type
> > > Char.
> > > 
> > > As an example, I've plotted all the samples that quantized as
> > > zero.
> > > These should fall in the range [-0.5:0.5], but occasionally we
> > > also
> > > get
> > > hits that lie within [-1:1]. These mishaps are rare (about one in
> > > 2000).
> > > It also shows that they only occur at multiples of 8192 samples,
> > > and
> > > zooming in reveals that they always happen shortly before the
> > > next
> > > multiple of 8192, not after.
> > > 
> > > For other values than 0, the same applies, but the
> > > misquantizations
> > > are
> > > only in one direction, ending up in a lower bin if the input is
> > > positive, or in a higher bin if the input is negative. Again, the
> > > misquantizations only occur in half the bin: For a value of 1,
> > > the
> > > float
> > > value should be in [0.5:1.5], but occasionally a value in [1.5:2]
> > > also
> > > ends up being quantized as 1.
> > > 
> > > This seems to me a bug that is somehow related to internal block
> > > boundaries, but I'm not familiar enough with the internals of
> > > GnuRadio
> > > to figure out just what's going wrong.
> > > 
> > > The problem does NOT occur when converting to Short or Int.
> > > 
> > > This is using GnuRadio 3.7.11 (as packaged with Ubuntu 18.04).
> > > 
> > > Regards, Paul Boven.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bug in fmdet_cf_imp.cc

[CEL]

Hello Eugene,

Thanks! I.. uh. wat?! There's a lot of interesting things in the code
of that block. d_8 being a constant with value 8 not being the largest
surprise; I see that this should be a derivative-approximating filter,
right, which inherently needs to have high-pass characteristics, and
honestly, odd symmetry would be good, so yeah, without knowing what
exactly I'm looking at here, it seems this is the right thing to do.
Can you point me at the source for the Taylor series (it looks like
one) you're citing in your last email?

Taking a step back, Sdot is really just the result of a FIR filter
applied to the input signal, isn't it? So, let's add that to the list
of things to actually use VOLK on to speed things up.

Best regards,
Marcus

On Fri, 2018-06-08 at 18:48 +, Eugene Grayver wrote:
> Hello,
>  
> There is a bug in the FM demod.  Unbelievably (almost), I reported a
> bug in the same line a couple of years ago.  At that time I also
> goofed (should have not retyped it).  The equation is STILL wrong!
>  
> Sdot = d_scl * (-S0+d_8*S1-d_8*S2+S4);
>  
> Should be
>  
> Sdot = d_scl * (-S0+d_8*S1-d_8*S3+S4);
>  
>  
> 
>  
> It is crazy that the basic FM demo works at all.
>  
>  
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Sr. Eng. Spec.
> Tel: 310.336.1274
> 
>  
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Incorrect quantizations when converting from float to char

[CEL]

Hi Paul,

hm, OK, considering the actual conversion is done in VOLK, can you tell
us

* whether ~/.volk/volk_config exists (and if so, its contents regarding
volk_32f_s32f_convert_8i )
* what the output of `volk-config-info --machine` is?

Thanks,
Marcus

On Sat, 2018-06-09 at 17:13 +0200, Paul Boven wrote:
> Hi everyone,
> 
> I'm trying to perform 2 bit sampling of an RF signal. In one
> approach, 
> I'm using a float->char block, and noticed that around zero, a number
> of 
> float inputs become quantized in a bin that's one off from the
> correct 
> value. The ones that are wrong are always off by one, with their 
> quantization error always in the direction of zero.
> 
> The problem can be demonstrated with a really simple flowchart,
> using 
> the following blocks:
> 
> * Noise Source (Noise Type: Gaussian, Amplitude: 1, Seed: 0, Output 
> type: Float)
> * Throttle
> The throttle is then connected to two blocks:
> * A file-sink (Type Float) and a
> * 'Float to Char' block.
> * The float to char block is again connected to a File Sink, now of
> type 
> Char.
> 
> As an example, I've plotted all the samples that quantized as zero. 
> These should fall in the range [-0.5:0.5], but occasionally we also
> get 
> hits that lie within [-1:1]. These mishaps are rare (about one in
> 2000). 
> It also shows that they only occur at multiples of 8192 samples, and 
> zooming in reveals that they always happen shortly before the next 
> multiple of 8192, not after.
> 
> For other values than 0, the same applies, but the misquantizations
> are 
> only in one direction, ending up in a lower bin if the input is 
> positive, or in a higher bin if the input is negative. Again, the 
> misquantizations only occur in half the bin: For a value of 1, the
> float 
> value should be in [0.5:1.5], but occasionally a value in [1.5:2]
> also 
> ends up being quantized as 1.
> 
> This seems to me a bug that is somehow related to internal block 
> boundaries, but I'm not familiar enough with the internals of
> GnuRadio 
> to figure out just what's going wrong.
> 
> The problem does NOT occur when converting to Short or Int.
> 
> This is using GnuRadio 3.7.11 (as packaged with Ubuntu 18.04).
> 
> Regards, Paul Boven.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] volk float32->int8 kernel and thus float_to_char block round or floor, depending on VOLK machine

[CEL]

Oh wait, it gets better: while the float->int16 does indeed use rintf,
float->int32 doesn't… now we don't have a majority situation pro-
rounding anymore… argh.
On Sat, 2018-06-09 at 19:24 +, Müller, Marcus (CEL) wrote:
> Hi Paul,
> 
> I agree with everything you say. Float to char should behave
> *exactly*
> like float to int and short. Will fix it in that way. Will also have
> a
> truncating version, maybe. I've just added 3 lines of code to the
> current implementation to demonstrate it's trivial to change the
> rounding mode. X87 FPUs are darn mighty things.
> 
> This brings me to another aspect: As far as I can tell from this
> height
> is that VOLK code absolutely neglects to configure the FPU to a known
> state. If the calling thread decides to do a   
> 
> _MM_SET_ROUNDING_MODE(_MM_ROUND_TOWARD_ZERO);
> 
> before calling volk_32f_s32f_convert_8i, all the kernels behave like
> the truncate-to-0 generic kernel. That can't be what we want, nor is
> it
> documented.
> 
> So, that's a bigger issue with VOLK: on one hand, we'd want to set
> that
> SIMD FPU control register (MXCSR) on every entry into a volk kernel
> that uses rounding, under- or overflowing SIMD intrinsics to have
> defined behaviour. Since we are nice programmers, we don't want to
> have
> surprising side effects, so we'd restore it to its original state on
> exit... I see pipeline flush and performance bottleneck right there,
> but it's IA64 calling convention to save and restore as callee. 
> 
> Best regards,
> Marcus
> On Sat, 2018-06-09 at 20:18 +0200, Paul Boven wrote:
> > Hi Marcus,
> > 
> > I would prefer that when going from float to int, every 'bin'
> > should 
> > have equal size. So I can think of two ways to do that:
> > 
> > 1) zero corresponds to [-0.5 : 0.4999]
> > 
> > or
> > 
> > 2) zero corresponds to [0.0 : 0.99]
> > 
> > whereas the 'generic' optimization does
> > 
> > 3) zero corresponds to [-1 to 0.99]
> > 
> > The second was actually the behaviour I was expecting, and I was 
> > pleasantly surprised when GnuRadio seemed to do the first - but
> > then 
> > occasionally it doesn't.
> > 
> > I just did a quick test in python3, and there, the range of int(x)
> > for 
> > zero runs [-0.99 : 0.99], so I'm expecting most
> > programming 
> > languages to behave that way.
> > 
> > So, I guess a programmer would expect the behaviour as in the
> > third 
> > case. Someone who is converting radio signals might want either
> > the 
> > first or second case, as otherwise you end up with some
> > interesting 
> > non-linearities.
> > 
> > The gnuplot helpfile states: " The `int(x)` function returns the
> > integer 
> > part of its argument, truncated toward zero."
> > 
> > But gnuplot also provides functions like 'floor(x)' and ceil(x).
> > 
> > So the real question is still, do we want the behaviour of int(x),
> > or 
> > the behaviour that an analog to digital converter would have?
> > 
> > Finally, I'd say we want the behaviour to be the same for Int,
> > Short
> > and 
> > Char. So I ran a few more tests.
> > 
> > With Volk enabled, Float to Int, Short and Char treat [-0.5 :
> > 0.49] 
> > as zero, with the occasional glitch for Char.
> > 
> > volk_32f_s32f_convert_16i a_avx u_avx
> > volk_32f_s32f_convert_32i a_avx u_sse2
> > 
> > With these conversions for Int and Short also switched to 'generic 
> > generic', I get the same results:
> > 
> > Short zero: [-0.5 : 0.49]
> > Int zero:   [-0.5 : 0.49]
> > 
> > So, assuming I carried out these tests correctly, the odd one out
> > seems 
> > to be the generic case for float to char conversion.
> > 
> > Note that Volk in the 16 bit and 32 bit case uses a function
> > called 
> > 'rintf' in the conversions. From its manpage:
> > 
> > "(...) round  their argument  to  an integer value in floating-
> > point 
> > format".
> > 
> > So I say this boils down to a bug in the 'generic' float to char
> > case.
> > 
> > This is not a fix to make lightly, because somebody is going to
> > have 
> > their flowchart break because of this. Then again, in the current 
> > situation the outcome depends on which optimizations your machine 
> > happens to have available, so that's also quite bad.
> > 
> > Possibly there is also an optimization opportunity of never using 
> > 'generic' even at the block edge when accelerat

Re: [Discuss-gnuradio] GR-UHD Compatibility Issue

[CEL]

As Marcus said, 3.0.4 is somewhere between "ancient" and "archaic". Is
there a specific reason you consider that version?

On Tue, 2018-06-12 at 03:01 -0400, Marcus D. Leech wrote:
> On 06/12/2018 02:49 AM, Luis Felipe Albarracin Sanchez wrote:
> > Hello to all,
> > 
> > i just did, what the stable version 3.0.4 from the repository:
> > 
> > https://www.gnuradio.org/releases/gnuradio/
> > 
> > And then i opened the package and red the "install"  text which
> > said:
> > 
> > The simplest way to compile this package is:
> > 
> >   1. `cd' to the directory containing the package's source code and
> > type
> >  `./configure' to configure the package for your system. If
> > you're
> >  using `csh' on an old version of System V, you might need to
> > type
> >  `sh ./configure' instead to prevent `csh' from trying to
> > execute
> >  `configure' itself.
> > 
> >  Running `configure' takes awhile.  While running, it prints
> > some
> >  messages telling which features it is checking for.
> > 
> >   2. Type `make' to compile the package.
> > 
> > Thanks again,
> > 
> > Any idea of what the problem could be?
> > 
> > Kind regards.
> > 
> 
> You're trying to install a version of Gnu Radio that is 11 years old
> is 
> the main problem.
> 
> 
> Try starting here:
> 
> https://wiki.gnuradio.org/index.php/InstallingGR
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GR-UHD Compatibility Issue

[CEL]

The most recent one :)
At this time, that's 3.7.13.2, but we haven't rolled a tar ball for
that yet – shame on me. You can get the current stable one always via
git, using the maint-3.7 branch, or from github's release page (though
the tarballs there might not be bit-identical to what we'll shortly
release under https://www.gnuradio.org/releases/gnuradio/) on 
https://github.com/gnuradio/gnuradio/releases .

Best regards,
Marcus

On Tue, 2018-06-12 at 10:14 +0200, Luis Felipe Albarracin Sanchez
wrote:
> Hello all,
> 
> I am sorry i just look at the stable versions available at that one
> was one of the closest to the top.
> 
> I will checkout the others.
> 
> Is there any stable Version you would recommend?
> 
> Kind regards.
> 
> On Tue, Jun 12, 2018 at 10:06 AM, Müller, Marcus (CEL)  du> wrote:
> > As Marcus said, 3.0.4 is somewhere between "ancient" and "archaic".
> > Is
> > there a specific reason you consider that version?
> > 
> > On Tue, 2018-06-12 at 03:01 -0400, Marcus D. Leech wrote:
> > > On 06/12/2018 02:49 AM, Luis Felipe Albarracin Sanchez wrote:
> > > > Hello to all,
> > > > 
> > > > i just did, what the stable version 3.0.4 from the repository:
> > > > 
> > > > https://www.gnuradio.org/releases/gnuradio/
> > > > 
> > > > And then i opened the package and red the "install"  text which
> > > > said:
> > > > 
> > > > The simplest way to compile this package is:
> > > > 
> > > >   1. `cd' to the directory containing the package's source code
> > and
> > > > type
> > > >  `./configure' to configure the package for your system. If
> > > > you're
> > > >  using `csh' on an old version of System V, you might need
> > to
> > > > type
> > > >  `sh ./configure' instead to prevent `csh' from trying to
> > > > execute
> > > >  `configure' itself.
> > > > 
> > > >  Running `configure' takes awhile.  While running, it
> > prints
> > > > some
> > > >  messages telling which features it is checking for.
> > > > 
> > > >   2. Type `make' to compile the package.
> > > > 
> > > > Thanks again,
> > > > 
> > > > Any idea of what the problem could be?
> > > > 
> > > > Kind regards.
> > > > 
> > > 
> > > You're trying to install a version of Gnu Radio that is 11 years
> > old
> > > is 
> > > the main problem.
> > > 
> > > 
> > > Try starting here:
> > > 
> > > https://wiki.gnuradio.org/index.php/InstallingGR
> > > 
> > > 
> > > 
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Visualising data with GNURadio

[CEL]

Hi Jaco,

this is really a reasonable thing to want, but to be honest, GNU
Radio's visualizations are very much oriented along the streaming
nature of GNU Radio – and scrollback doesn't fit all to well.

I recommend https://github.com/miek/inspectrum , which is relatively
new, and relatively cool :)

Other than that, there was a quite interesting email thread about this
in 2014 [1] with scores of ideas and tool recommendations!

Best regards,
Marcus

[1] https://lists.gnu.org/archive/html/discuss-gnuradio/2014-07/msg0021
1.html
On Fri, 2018-06-08 at 18:07 +0200, Jaco Versfeld wrote:
> Good day,
> 
> The short story:
> 
> I have data sets (quite large) in .wav format.  I want to perform
> basic signal processing as well as more complex algorithms on blocks
> of the data and then display the output.  It would be great if one
> could "scroll" through the data.  Are there any blocks that can do
> that?
> 
> 
> Slightly longer story:
> 
> I am busy with passive acoustic monitoring of cetaceans.  Data is
> collected by hydrophones and stored in .wav files.  These files tend
> to be very large.  I want to analyse these signals, and view blocks
> of the data stream.  I successfully created a flowgraph where I
> filtered the data, and then displayed both the time and frequency
> domain graphs.  Because of some basic prior work with SDRs, I love
> the GNURadio environment.   However, if one could view a block of the
> data at a time and then scroll/proceed to the next block, it would be
> really great to do post-analysis.
> 
> Kind regards,
> Jaco 
> 
> ___
> 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] make maint-3.7 fails

[CEL]

Hi Tom,

got a bit of worries about this one:

On Fri, 2018-06-08 at 09:17 -0700, Tom McDermott wrote:
> modified:   volk (new commits)

Which basically means that the Volk submodule isn't in the state the
main module's branch expects it to be, and that's exactly what's going
wrong there.

Best guess: git `submodule update` should fix this. Afterwards, `git
status` should not contain any info about the submodule containing any
changes.

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

Re: [Discuss-gnuradio] Memory Blocks & Struct Variable

[CEL]

Sorry, I replied with an empty mail just now, confusion of keys. I
added more coffee to solve the issue with the author.

Steve,

assuming your set_mag() is in C++: if you have control over the
set_mag() method, write it so that it accepts vectors, for example.
Then, you can just use Python lists or tuples.

Does that help?

Best regards,
Marcus

On Thu, 2018-06-07 at 08:45 +0300, shachar J. brown wrote:
> Hi Everyone,
> 
> I'm sure someone has encountered one of the following questions. Please help 
> me figure this out:
> At certain points in my flow graph I have different scenarios, each demanding 
> a set of different parameters. I now ended up having large tables (1-2 K) of 
> possible variable I would like to insert into the grc. Inserting such a huge 
> table as a 2D array into a variable sounds like a pain in the neck. any more 
> useful ways to store memory in the grc?
> As a result of the above, I tried playing a bit with the "Struct Variable". 
> sadly, I couldn't figure out how to use the "set_variable()" method 
> correctly. say it's name is mag, and it has two fields: a,b. I tried 
> set_mag(1,2), or set_mag.a(1), or set_mag(struct({'a': 1, 'b': 2})). None 
> worked...
> Thanks a lot!
> Steve
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Memory Blocks & Struct Variable

[CEL]

On Thu, 2018-06-07 at 08:45 +0300, shachar J. brown wrote:
> Hi Everyone,
> 
> I'm sure someone has encountered one of the following questions. Please help 
> me figure this out:
> At certain points in my flow graph I have different scenarios, each demanding 
> a set of different parameters. I now ended up having large tables (1-2 K) of 
> possible variable I would like to insert into the grc. Inserting such a huge 
> table as a 2D array into a variable sounds like a pain in the neck. any more 
> useful ways to store memory in the grc?
> As a result of the above, I tried playing a bit with the "Struct Variable". 
> sadly, I couldn't figure out how to use the "set_variable()" method 
> correctly. say it's name is mag, and it has two fields: a,b. I tried 
> set_mag(1,2), or set_mag.a(1), or set_mag(struct({'a': 1, 'b': 2})). None 
> worked...
> Thanks a lot!
> Steve
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A few questions regarding gr-ieeee802-11

[CEL]

Hi Tal,

3.7 is the maint-3.7 branch, master works towards 3.8, and a milestone
of that will be when next is merged into it. You can expect a 3.8
release when next is merged, and all the serious kinks that came with
it are contained enough for us to risk a release :)

Best regards,
Marcus

On Fri, 2018-06-08 at 14:03 +0200, Tal Peer wrote:
> Hi Bastian,
> 
> Thanks for the clarification about the matched filter -- I basically got the 
> scaling part wrong. Now everything makes sense. 
> About the next into master merge: I understand that currently master is the 
> 3.7 branch and next the 3.8 branch (or is it?), so can we expect a 3.8 
> release when the merge happens?
> 
> Cheers,
> Tal
> 
> On Fri, Jun 8, 2018 at 12:48 PM, Bastian Bloessl  wrote:
> > Hi,
> > 
> > On 06/08/2018 10:18 AM, Tal Peer wrote:
> > > 1. In the Sync Long block, the input is put through a matched filter 
> > > defined by the long training sequence in time domain. I'm probably 
> > > overseeing something here, but  I would expect this sequence to be the 
> > > same as the sequence given in table I-6 of the standard (well, a part of 
> > > it at least, since it repeats 2.5 times). Now, I understand the LONG 
> > > vector is generated using the create_long.R script and not knowing any R 
> > > I tried to reproduce this in MATLAB. However, after some experiments I 
> > > figured that in order to reproduce the same sequence I have to run in 
> > > MATLAB (a is the freq. domain sequence):
> > > 
> > > fliplr(fft(ifftshift(a)/sqrt(52)))
> > > 
> > > where from the R script I would actually expect (as we're transforming 
> > > the sequence from frequency to time domain and also conjugating it to 
> > > create a matched filter):
> > > 
> > > fliplr(conj(ifft(fftshift(a)/sqrt(52
> > > 
> >  
> > I'm not sure if I understand you correctly. It sounds like you think the 
> > steps in the R-script are reasonable, but you fail to reproduce it in 
> > MATLAB. I don't have MATLAB, so I cannot test it, but maybe you forgot an 
> > 'i' and were using the fft instead of the ifft.
> > 
> > I've done it again in Python and it results in exactly the steps that you 
> > seem to expect.
> > 
> > To reproduce the sequence in the standard:
> > 
> > 
> > import numpy as np
> > 
> > # frequency domain
> > fd = np.array([0]*6 + [1, 1, -1, -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 1, 1, -1, 
> > -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 0, 1, -1, -1, 1, 1, -1, 1, -1, 1, -1, -1, 
> > -1, -1, -1, 1, 1, -1, -1, 1, -1, 1, -1, 1, 1, 1, 1] + [0]*5)
> > 
> > # time domain
> > td = np.fft.ifft(np.fft.ifftshift(fd/64**.5), norm="ortho")
> > 
> > sync_long = np.append(td[32:], [td, td])
> > # sequence in standard considers windowing
> > sync_long[0] = sync_long[0] / 2
> > 
> > # Standard, Appendix I
> > sync_long
> > 
> > 
> > 
> > 
> > To reproduce the sequence in the code:
> > 
> > 
> > 
> > # taps for matched filter (I used a different/weird scaling)
> > m = np.fft.ifft(np.fft.ifftshift(fd), norm="ortho") * (64.0/52)**.5
> > m = np.conj(m)
> > m = m[::-1] # reverse for d_fir kernel (which reverses again)
> > # sequence in sync_long block
> > m
> > 
> > 
> > 
> > 
> > 
> > 
> > > I think I might be missing something here and would be glad if someone 
> > > could shed some light on this.
> > > 
> > > 2. As seen in the provided examples, the (Random) Periodic Message Source 
> > > from gr-foo is useful for simulations. However, due to a bug in GR 3.7, 
> > > flowgraphs using it won't stop automatically. I'm aware that this has 
> > > already been fixed by this PR: 
> > > https://github.com/gnuradio/gnuradio/pull/797 . However, I would like to 
> > > be able to use a vanilla GR 3.7 and the fix was applied to the next 
> > > branch due to API change. Are there any known workarounds not requiring 
> > > patching?
> > > 
> >  
> > No, you'll have to use `next` or wait some more time until next is merged 
> > in master. Marcus is working on thatn (see PR 
> > https://github.com/gnuradio/gnuradio/pull/1809)
> > 
> > Best,
> > Bastian
> > 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP Digital Modulation - Loopeback Constellation

[CEL]

Hi Luis,

I hope you're using an attenuator with a cable or antennas in your
feedback, not to risk damaging your receiver!

What you need to do to get a similar constellation is the whole dance
that is taught in your average digital communication basics lecture:

Synchronization in time, and phase (and theoretically frequency, but
when it's really only a loopback, that's not an issue, since they will
be identical), an equalizer if your channel leads to ISI, and
potentially phase tracking, as well as usually some sort of pulse
shaping filter etc.

Best regards,
Marcus

On Thu, 2018-06-14 at 10:59 +0200, Luis Felipe Albarracin Sanchez
wrote:
> Hello all,
> 
> I am trying to do a Loopback with an USRP B210, ad i have the following 
> flowgraph:
> 
> 
> 
> 
> 
> For mi test i need to obtain a similar constellation once i received the 
> signal, but i am getting:
> 
> 
> 
> 
> My question is, are there any blocks missing or what else i need to do, to 
> obtain a similar constellation in the Rx side?
> 
> Once again, thank you very much.
> 
> Kind regards.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP Digital Modulation - Loopeback Constellation

[CEL]

Hi Luis,
On Thu, 2018-06-14 at 12:29 +0200, Luis Felipe Albarracin Sanchez
wrote:
> Hello Marcus,
> 
> Thanks for the response,
> 
> I am not using an attenuator, because i font have one , i am only with my 
> cable, but i have meassured the Power before connecting to the RX in my USRP, 
> so it wont be bigger than the threshold of the USRP.

That's a dangerous game – you rely on never inadvertedly setting a high
RX or TX gain.

> 
> Thanks for the info, is there any guide where i can look all of the blocks 
> for Sync, phase tracking and shape filtering  implemented in a loopback for 
> 16QAM and other digital modulations (Flowgraphs examples)?

https://tutorials.gnuradio.org has a PSK example if you read from
chapter 1 to 7 :)

Best regards,
Marcus


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP Digital Modulation - Loopeback Constellation

[CEL]

Well, you asked for "and other modulations", so I gave you one where
phase synchronization is possible with simple control loops.

Synchronization of 16QAM is... nontrivial. I've just discussed this
with my favourite officemate.

In practical systems, it's very likely that you'd simply send a
preamble, and use that to estimate your phase. Then, do a decision-
feedback phase tracking, and/or insert pilot symbols periodically to
keep track of your channel. Preambles have the advantage of
singlehandedly also solve the pi/2 ambiguity.

Regarding symbol timing recovery: puuuh, that's where things get
interesting. Gardner might be a viable method, as it's basically
looking at the ACF of your pulse shaping; same goes for the symbol
recovery through polyphase derivative estimation.

I might be seduced to admit for a quick prototype I'd be lazy and treat
16 QAM for all synchronization purposes as a QPSK with an SNR no better
than √5 and deal with that bad SNR through very low loopback filter
bandwidths, but that can only work if your channel isn't changing
faster. But afterwards, even if this does work out (I'm not sure it
would), I'd still have a pi/2 phase ambiguity that I'd have to resolve
using other methods, so:

Probably start with a preamble, and oversample that by 4 to 16. Try to
do a phase and timing recovery based on the known pulse shape.

Best regards,
Marcus

On Thu, 2018-06-14 at 13:09 +0200, Luis Felipe Albarracin Sanchez
wrote:
> Hello Marcus, and all,
> 
> Thanks for the response,
> 
> I am reading the PSK example you told me, nevertheless y am not so sure it 
> applies also for 16QAM...i understand that Costas Loop, does not work with 16 
> QAM.
> 
> Is there any flowgrpah for a complete 16QAM modulator/demodulator?
> 
> Kind regards.
> 
> On Thu, Jun 14, 2018 at 12:46 PM, Müller, Marcus (CEL)  
> wrote:
> > Hi Luis,
> > On Thu, 2018-06-14 at 12:29 +0200, Luis Felipe Albarracin Sanchez
> > wrote:
> > > Hello Marcus,
> > > 
> > > Thanks for the response,
> > > 
> > > I am not using an attenuator, because i font have one , i am only with my 
> > > cable, but i have meassured the Power before connecting to the RX in my 
> > > USRP, so it wont be bigger than the threshold of the USRP.
> > 
> > That's a dangerous game – you rely on never inadvertedly setting a high
> > RX or TX gain.
> > 
> > > 
> > > Thanks for the info, is there any guide where i can look all of the 
> > > blocks for Sync, phase tracking and shape filtering  implemented in a 
> > > loopback for 16QAM and other digital modulations (Flowgraphs examples)?
> > 
> > https://tutorials.gnuradio.org has a PSK example if you read from
> > chapter 1 to 7 :)
> > 
> > Best regards,
> > Marcus
> 
> 
> 

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Faster FPGA clock rates

[CEL]

Dear Maria,

no, GNU Radio is a pure software framework; it doesn't directly talk to
any hardware, but has a gr-uhd component which uses UHD, Ettus' own
driver, to talk to your USRP.

Anyway, you can't simply reprogram the FPGA to give you higher clock
rates. 61.44 MHz is physically the most that the interface on the radio
chip on the B210 can do. There's zero way around that.

To answer your question "which programming language would I need to
modify an Ettus USRP's FPGA image": None, you would need to learn
*hardware description languages*, especially Verilog. If you haven't
worked with those before, it will be quite different from programming
Python or C++ or Matlab. But again, an FPGA modification couldn't do
anything here.

Best regards,
Marcus

On Thu, 2018-06-14 at 11:30 +0200, Maria wrote:
> Hi all,
> 
> I would like to know whether GNU radio can be used to program the FPGA 
> of the USRP and hence assist with faster clock rates. I am using the 
> USRP B210 and the maximum clock rate seems to be 61.44 MHz so I wanted 
> to know if it is possible to increase that rate by programming on the 
> FPGA and if that programming can be done through the GNU radio platform. 
> If so, could you please let me know which programming language would I 
> need? Python, C++? Existing libraries on GNU radio?
> 
> Thank you very much in advance!
> 
> Cheers!
> 
> Maria
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unable to see GSM signals in USRP Spectrum Scanner (FFT)

[CEL]

Hi Amrit,

Well, usrp_spectrum_sense is a hopping observer, and GSM is a hopping
system: your probability of intercept is rather low.

Your probability of intercept is in fact, really zero, if your phone
doesn't do GSM (2G), but uses 3G (UMTS) or 4G (LTE): these use other
frequencies altogether. So, make sure your phone really does do GSM.

You also don't even have to look at the GSM900 uplink at all:
Telefonica (which Aldi resells) doesn't use that band at all.

The spectrum sense application is really badly suited for this kind of
task, as it hops: Instead, simply look at the whole band at once. A
simple GNU Radio Companion flow graph connecting the USRP source (samp
rate = total uplink bandwidth) to a Qt GUI Frequency Sink would make
more sense.

A word of secondary advice: If you're planning to experiment with 2G
networks of your own, or doing something about the basic properties of
microwave propagation and so on, observing spectrum of GSM is a
worthwhile thing to do. Just be warned that it will be increasingly
hard to find GSM signals "in the wild": T-Mobile will switch off GSM
end-of-2020, and thus, up to then, all phones that can do both LTE and
GSM will be instructed to use LTE whenever possible. Since there won't
be much Machine-to-Machine GSM-only  (which I assume are the primary
users that won't be able to switch) user equipment in cities, you'll
see that increasingly many phones don't use GSM anymore at all – even
if the network still exists; the calculation is very simple: The amount
of spectrum necessary to let a single user do a GSM phone call is worth
MB/s for a lot of LTE users. Thus, everybody not using GSM is desirable
for network operators.

Best regards,
Marcus

On Mon, 2018-06-18 at 11:25 +0200, Amrit Zoad wrote:
> Greetings everyone,
> 
> I hope everyone is having a good day.
> 
> I have installed GNURadio 3.7 and I wanted to see the GSM signals of my phone 
> (when I call someone) with the application "USRP Spectrum Scanner (FFT)". 
> But, I was unable to see any fluctiations in the spectrum from 890 MHz to 915 
> MHz & 1710 MHz to 1785 MHz. My location is in Germany and I own a sim card of 
> Aldi Talk (MEDIONmobile).
> 
> Then I tried with my phone's Bluetooth 5.0 and I could see the frequency 
> hopping from 2.4 GHz to 2.44 GHz along with the light Wi-Fi signals in the 
> spectrum.
> 
> I have the Etttus Research USRP B210 with Bandwidth of 56 MHz (of the 
> front-end filter) and thus I am setting the sampling rate to 40 MHz. The 
> antenna also works from 850 MHz to 6.5 GHz. so no problem with that as well.
> 
> What could be reason for me not able to see my phone's GSM signals in the 
> spectrum scanner?
> Your help would be very valuable.
> 
> Best regards,
> Amrit Zoad 
> +49 177 8474550
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio Help

[CEL]

I don't understand what you mean with "do the FFT and then transfer […]
to the host machine": GNU Radio runs on the host machine, so whatever
processing you do already happens on the host machine.

Assuming this is just a small problem in expression, and you're doing
all this on the same machine:
Well, you'll need to send messages to the USRP source to re-tune with
timed commands, and to "sort" the samples coming out of the source by
the timestamp they have so that you know which FFT-length vectors
belong to which frequency (and drop the samples that were taken while
you were re-tuning). Note that the capability to tune on timed commands
is not given in all USRPs to the same degree at all.

It's a relatively complex application that you're planning. There's an
old GNU Radio example that does exactly that, but was written long
before timed commands were introduced, and is hence incredibly
inefficient (has to throw away most of the samples, because it never
knows when exactly tuning has happpened). I wouldn't recommend using it
for this reason, but it still works, and that without much custom
blocks (but with ugly and slow python code that noone would write
similarly today). It's in gnuradio/gr-uhd/examples/python and is called
usrp_spectrum_sense. Again, this is basically obsolete technologically,
but it still works. Please don't write the 400th thesis about this
piece of software!

Best regards,
Marcus

On Wed, 2018-06-13 at 17:42 +0300, Ivan Zahartchuk wrote:
> I need to rebuild the frequency, do fft and then transfer the whole array 
> from 70 to 6GHz to the host machine. I do not quite imagine how you can do 
> this with standard blocks in gnuradio.
> 
> 
> 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
> > Dear Ivan,
> > 
> > you don't pass data to a block yourself. 
> > 
> > You write a block that does a clearly-limited signal processing job,
> > and use GNU Radio to connect that to other blocks:
> > 
> > https://tutorials.gnuradio.org
> > 
> > In your case, instantiating a USRP source in your block makes
> > absolutely no sense, for example. You'd build a flow graph containing
> > the USRP source, and your custom-written block, and you'd connect these
> > two.
> > 
> > It's sadly not really clear what you want to achieve, so I'm afraid I'm
> > not able to help you here.
> > 
> > Generally, GNU Radio pretty much takes the idea of "draw a block
> > diagram of what you want to achieve with your signal processing", and
> > directly translates it to "using existing blocks and writing new ones,
> > and letting GNU Radio take care of how the data gets around".
> > 
> > Also, wideband signal processing and implementing a sync_block in
> > Python... do not work well together.
> > 
> > So, I think you might really be a bit confused about the architecture
> > of GNU Radio – I really hope the tutorials explain that better than I
> > could.
> > 
> > Best regards,
> > Marcus
> > 
> > On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
> > > Hello. I'm trying to write a block in gnuradio for broadband reception.
> > >  The main problem at the moment is to transfer data to the fft block. 
> > > I'm new to python and so it's hard for me to figure this out.import numpy 
> > > as np
> > > 
> > > I need an array of data to pass to the gnuradio.fft.fft.vcc block
> > > 
> > > from gnuradio import gr
> > > from gnuradio import uhd
> > > from gnuradio import fft
> > > 
> > > class blk(gr.sync_block):  # other base classes are basic_block, 
> > > decim_block, interp_block
> > > """Embedded Python Block example - a simple multiply const"""
> > > 
> > > def __init__(self, 
> > > gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):  # only 
> > > default arguments here
> > > """arguments to this function show up as parameters in GRC"""
> > > gr.sync_block.__init__(
> > > self,
> > > name='Python Block',   # will show up in GRC
> > > in_sig=None,
> > > out_sig=[np.complex64,np.complex64]
> > > )
> > > # if an attribute with the same name as a parameter is found,
> > > # a callback is registered (properties work, too).
> > > self.gain = gain
> > > self.start_freq=start_freq
> > > self.stop_freq=stop_freq
> > > self.samp_rate=samp_rate
> > > self.uhd_usrp_source_0 = uhd.us

Re: [Discuss-gnuradio] GNURadio Help

[CEL]

Dear Ivan,

you don't pass data to a block yourself. 

You write a block that does a clearly-limited signal processing job,
and use GNU Radio to connect that to other blocks:

https://tutorials.gnuradio.org

In your case, instantiating a USRP source in your block makes
absolutely no sense, for example. You'd build a flow graph containing
the USRP source, and your custom-written block, and you'd connect these
two.

It's sadly not really clear what you want to achieve, so I'm afraid I'm
not able to help you here.

Generally, GNU Radio pretty much takes the idea of "draw a block
diagram of what you want to achieve with your signal processing", and
directly translates it to "using existing blocks and writing new ones,
and letting GNU Radio take care of how the data gets around".

Also, wideband signal processing and implementing a sync_block in
Python... do not work well together.

So, I think you might really be a bit confused about the architecture
of GNU Radio – I really hope the tutorials explain that better than I
could.

Best regards,
Marcus

On Wed, 2018-06-13 at 17:16 +0300, Ivan Zahartchuk wrote:
> Hello. I'm trying to write a block in gnuradio for broadband reception.
>  The main problem at the moment is to transfer data to the fft block. 
> I'm new to python and so it's hard for me to figure this out.import numpy as 
> np
> 
> I need an array of data to pass to the gnuradio.fft.fft.vcc block
> 
> from gnuradio import gr
> from gnuradio import uhd
> from gnuradio import fft
> 
> class blk(gr.sync_block):  # other base classes are basic_block, decim_block, 
> interp_block
> """Embedded Python Block example - a simple multiply const"""
> 
> def __init__(self, 
> gain=1.0,start_freq=70e6,stop_freq=6000e6,samp_rate=30e6):  # only default 
> arguments here
> """arguments to this function show up as parameters in GRC"""
> gr.sync_block.__init__(
> self,
> name='Python Block',   # will show up in GRC
> in_sig=None,
> out_sig=[np.complex64,np.complex64]
> )
> # if an attribute with the same name as a parameter is found,
> # a callback is registered (properties work, too).
> self.gain = gain
> self.start_freq=start_freq
> self.stop_freq=stop_freq
> self.samp_rate=samp_rate
> self.uhd_usrp_source_0 = uhd.usrp_source(",".join(("", "")),
>  uhd.stream_args(
>  cpu_format="fc32",
>  otw_format="sc16",
>  chanels=range(1),
>  ),
>  )
> 
> 
> self.uhd_usrp_source_0.set_clock_rate(30e6, uhd.ALL_MBOARDS)
> self.uhd_usrp_source_0.set_samp_rate(self.samp_rate)
> self.uhd_usrp_source_0.set_gain(self.gain, 0)
> self.uhd_usrp_source_0.set_antenna("RX2", 0)
> self.uhd_usrp_source_0.set_bandwidth(30e6, 0)
> self.range_freq=(self.stop_freq-self.start_freq)/self.samp_rate
> 
> def work(self, input_items, output_items):
> """example: multiply with constant"""
> for i in np.range(self.range_freq):
> 
> self.uhd_usrp_source_0.set_center_freq(self.start_freq+self.samp_rate*i)
> data=np.array(self.uhd_usrp_source_0.finite_acquisition(8192))
> output_items[0][:] = input_items[0] * self.example_param
> return len(output_items[0])
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio Help

[CEL]

Ivan,

the E310 is a very special USRP as it not only requires you to
understand radio, software, digital signal processing and development,
but also embedded hardware development and efficiently also FPGA
design. Are you *sure* you want to start with that? Without meaning to
cause any offense, this is a bigger project than you realize that
you're about to take on.
None of the things I explained before will work, because the E310's CPU
is simply too weak to get 30 MS/s out of the digital logic, let alone
do any processing on them.

This, by the way also answers John's question: Ivan's got to do the
processing in the radio, as the host computer is the E310's ARM CPU and
that can't even handle the memory bandwidth of 30 MS/s at 32 bit per
sample, but needs it to be broken down to a much smaller amount of
data. Also, since the E310 is one of the USRPs that cannot do tuned
commands, throwing away data in the FPGA before it even reaches the FFT
(which also has to happen in the FPGA) is kind of a necessity.

So, if you don't want to dive right into FPGA developement (and I
strongly recommend you don't!), you'll need to reduce your expectations
to doing maybe 1 MHz at once, because that's what your CPU will be able
to process in software with an FFT of any significant size.

So, the closest to what you want exists in the shape of RFNoC Fosphor
architecture: It sends FFT'ed, magnitude-squared, logarithmized, even
practically color-mapped values and thus can achieve good bandwidth
even on an E310. Adding the tuning and frequency coordination logic
would, on the other hand, really require a lot of work in the FPGA, and
it'll have nothing to do with GNU Radio.

If you want my personal opinion: Start with a different device.
Learning about GNU Radio, DSP, SDR is hard enough. Don't add FPGAs,
embedded devices and mandatory RFNoC to it for a start.

Best regards,
Marcus

On Wed, 2018-06-13 at 09:11 -0600, John Medrano wrote:
> This is much more doable. 
> 
> May I ask why you want to buffer all the data in the radio?
> 
> On Wed, Jun 13, 2018 at 9:06 AM, Ivan Zahartchuk  wrote:
> > I want to process not 6GHz but 30 MHz at a time. Ie I read 30 MHz at a 
> > frequency of 400 MHz (for example) then I do 30 MHz FFT and write them to 
> > the buffer. And so up to 6GHz. Then when the buffer is full, I transfer the 
> > data to the host machine (I use the USRP E310 board) to display the data.
> > In fact, it should be such a broadband spectrum analyzer not in real time.
> > 
> > 2018-06-13 17:57 GMT+03:00 John Medrano :
> > > Hello.
> > > 
> > > If I understand what you are saying correctly, you would like to process 
> > > wide band data. And you mention 70 MHz to 6 GHz. 
> > > 
> > > Even with RFNOC there is a limitation on the amount of data you can 
> > > process simultaneously, and that is about 200 MHz. There is no way 
> > > possible to simultaneously process a 6GHz band with one host and radio. 
> > > You would need an array of radios. 
> > > 
> > > Please provide more details on design requirements, it hard to understand 
> > > what you are trying to accomplish. 
> > > 
> > > On Wed, Jun 13, 2018 at 8:46 AM, Ivan Zahartchuk  
> > > wrote:
> > > > In the future, I would also like to use the RFNoC
> > > > 
> > > > 2018-06-13 17:42 GMT+03:00 Ivan Zahartchuk :
> > > > > I need to rebuild the frequency, do fft and then transfer the whole 
> > > > > array from 70 to 6GHz to the host machine. I do not quite imagine how 
> > > > > you can do this with standard blocks in gnuradio.
> > > > > 
> > > > > 
> > > > > 2018-06-13 17:32 GMT+03:00 Müller, Marcus (CEL) :
> > > > > > Dear Ivan,
> > > > > > 
> > > > > > you don't pass data to a block yourself. 
> > > > > > 
> > > > > > You write a block that does a clearly-limited signal processing job,
> > > > > > and use GNU Radio to connect that to other blocks:
> > > > > > 
> > > > > > https://tutorials.gnuradio.org
> > > > > > 
> > > > > > In your case, instantiating a USRP source in your block makes
> > > > > > absolutely no sense, for example. You'd build a flow graph 
> > > > > > containing
> > > > > > the USRP source, and your custom-written block, and you'd connect 
> > > > > > these
> > > > > > two.
> > > > > > 
> > > > > > It's sadly not really clear what you want to achieve, so I'm afraid 
> > > > > > I'm
> > > > > > not able t

Re: [Discuss-gnuradio] GNU Radio not installing: Build Failed

[CEL]

Hello Jason and Derek!

What Derek wrote very much sums up what is going on in my head; I
should probably write that down.

So, knowing fully this is everything but an official announcement, 3.8
will need C++11. Just wanted to confirm that.

On the way to 3.8, we'll thus need to "weed out" the systems that we
still support. For example, I'm pretty sure Ubuntu 14.04 will fall off
the wagon. I know there's quite a few users on that, but that's why we
keep the maint-3.7 branch alive: If you're stuck on a 4 year old
desktop/convenience operating system¹, you might simply not need or
want the newest features (and API breakage) that in the meantime
appeared on the master branch. We still don't want to abandon you in
the dark, and thus we backport patches to maint-3.7.

That clearly says something about stability of dependencies on maint-
3.7: We simply won't add any new dependencies, be it a newer version of
a language standard, or an update of a library that we link to. That's
why it's called "maint-something", we do the maintenance, we don't add
new things that might break what you're already doing.

So what about stability of dependencies on the master branch?
The ugly truth is that, as long as we don't formally release anything,
we should be able to do whatever we like on master. It should compile
at every commit, but it's not the end of the world if at some point,
something obscure breaks on master that we didn't notice. It's
unreleased developer code.

Now, that's not really fair to say, though, because 3.7 has been around
forever, and we've got a lot of users who'd normally want to use a
released version building master, just because we haven't been
productive enough at releasing versions in the last years.
Thus, for the time being, we'll announce when we do something on master
that we expect things to break.
Going forward after the release: If you don't want the development
version's quirks (those including random dependency changes, API
changes, ABI changes, disappearing features, appearing features, and
surprise gerbils), I'd advise you to stick with a release and its
maint-MAJOR.MINOR branch.

I hope that answers the demand of users (stability and new features)
and developers (ability to improve and extend without having to care
about dependencies that are partially literally a decade old, looking
at Ubuntu 14.04 there) with an equilibrium that makes new features
appear, without breaking old functionality.

I think this is an issue only because we've been handling master and
maint differently. If you're used to the old GNU Radio dev model,
you'll find that "master" today works much more like "next" used to
work let's say mid-2016. "maint-3.7" is a new (old) concept, which we
hope will make the released versions even more reliable than they used
to be, whilst not stopping developers to just work on the main
development branch (that being master). (If you're still on "maint" and
wondering why nothing happened: that branch is dead.)

So, if you're on an old system, and you don't need the features that
are not in the 3.7, please do consider using maint-3.7 instead of
master. The moment we release 3.8, we'll also start a maint-3.8 branch.
That, by the way, doesn't mean we let maint-3.7 die anytime soon. As
far as feasible, patches to master (and maint-3.8) would continue to be
backported to maint-3.7.

Best regards,
Marcus


¹ CentOS 7 takes a bit of a special role in there, in my opinion, as it
tends to be a server system where you really have good reason not to
update; if it turns out that there's too many dependency problems with
GR 3.8 on it, we'll come up with a "golden way" of getting a working
subenvironment for maint-3.8 to build (even if in a reduced feature
set). If we can come back to you, Jason, there on how to decide what
priorities to set, and maybe for some real-world testing or even
solutions, that'd be valuable.
Basically, the same would apply to Ubuntu server, but I'll be honest
here: CentOS' "maintenance support time" simply puts Canonical to
shame, and Ubuntu LTS early phase of support is about as well-
maintained as CentOS late "maintenance support time", so, personally,
while I think it might be a valid choice for desktop systems that
really can stand an update every two years, I don't think I need to
support Canonical reselling the same desktop-oriented fork of debian as
a server platform. But, due to *excellent* maintenance work on Debian,
thanks to Mait, it's very likely you'll have an easy time getting
recent GNU Radio packages even for older Ubuntu releases.

On Fri, 2018-06-08 at 16:15 +0100, Derek Kozel wrote:
> Hi Jason,
> 
> Centos 7 is being specifically looked at for 3.8 as it will define
> the minimum version of most dependencies. We don't yet have a CentOS
> 7 regression test VM, but it is something to consider. We will be
> enforcing the C++11 requirement in CMake which I believe is
> sufficient to make all this work on Centos, but it would be great to
> get your eyes 

Re: [Discuss-gnuradio] Channel Coding

[CEL]

Hello Dewan!

On Mon, 2018-05-28 at 16:09 -0400, Dewan Arif wrote:
> 1. In FEC_extended_encoder, What is the Encoder Objective ??  How to put the 
> value in Encoder Objective ??

Small typo: it's "encoder object", not "objective" :) 
What you want there is to put the ID of a "Encoder Definition" (there's
 different choices if you search for "Encoder Definition" in the block
list.

GNU Radio comes with an example for all these! It's called
fecapi_encoders.grc and typically can be found in
/usr/[local/]share/gnuradio/examples/fec ; not quite sure where it gets
installed under OS X, but I think you'll be able to find that file on
your computer :)
> 
> 2. I have attached the flowgraph, I'm not receiving the same amount of data. 
> what block should I use to correct it ??

Don't use the "packet encoder" block *at all*. It is deprecated!!! It
simply doesn't work reliably, and drops data occasionally (this has
bitten myself).

You'll find a much nicer example in
/usr/[local/]share/gnuradio/examples/digital/packet/packet_loopback_hie
r.grc

Best regards,
Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] debugging for gnuradio DSP programming

[CEL]

Hi Linda,

for debugging *programmatic* things (i.e. crashes, program doesn't
calculate what I think it should), you'd use a debugger:

https://wiki.gnuradio.org/index.php/TutorialsDebugging
https://wiki.gnuradio.org/index.php/TutorialsGDB

for debugging *algorithmic* things (i.e. I don't know why my receiver
doesn't get the bits that I sent), well: That's mostly wireless comms
engineering, and you would apply your domain-specific knowledge to
that.

Both aspects of debugging take experience, but you usually get better
pretty quickly once you get started. Of course, especially the second
one, is something that an education in communications technology does
help a lot with – I don't know what you "are" by trade, but throw in
whatever you've learned: It's often that we need to transform problems
to forms of problems that we've learned to solve. :)

The universal approach that works best for me is this:

1. Get pen, paper and a coffee (or whatever drink floats your boat)

2. Make a very rough block diagram of what you're implementing

3. Verify that this block diagram matches what you've actually built by
making sure every step in your system does what you think it does, at
least according to documentation or source code (this is an important
step)

4. (MOST important step) Explicitly write down:
 a) What should be happening
 b) What is happening instead
 c) A list of suspicions you already have to later work through, cross
out and amend

5. Build a simplified system that reproduces b). In GNU Radio, that
typically means taking the signal that leads to the problem, and write
it to a file sink, to be able to replay *exactly the same thing* later
on and work on things until the issue is fixed.

6. Find the *simplest possible* test input that would allow you to test
whether the first element in your (simplified) system works. Implement
that test by repeating step 4 on it: think about what it should be
putting out, and check that it does.
This can take the form of a unit test, or simply of hooking up a Qt
time sink to the output of that first block, or as writing things to a
file and opening that file with python and doing some statistics on it
or … . Writing a unit test of course is the coolest way: that way, you
can later (even automatically) check that you have no functional
regressions, and you document for yourself/superiors/clients that
you've dealt with that class of problems.

7. If first element does what it should, move on to the output of the
second, repeat step 6

8. If you're stuck, try rubber-ducking the problem: explain the problem
to someone not familiar with the overall problem (for example, a rubber
ducky). This is an excellent method for two reasons:

 * You get to describe what you're doing, what you're expecting and
   what isn't happening in a way that forces you to explain it to
   someone who doesn't have the same knowledge of the problem as you –
   thereby forcing you to change your perspective on the problem, which
   very often leads to new (successful) approaches
 * For that explanation to not be totally insufficient¹ nor take
   hours², you train recognizing all the factors someone else (and
   you!!) would need to understand the problem, and usually these
   factors are what you need to control in order to further narrow
   down the problem. Also, in case you later discuss your problem with
   someone that you hope can actually contribute their experience,
   you've already done the narrowing down, and know what context you
   give, so that people don't have to repeatedly ask you for context to
   get the bigger picture. That's way more efficient.

9. Always, always take notes, somewhere; honestly, if they're readable
to yourself, that's a bonus, but not necessary. That way, you notice
when you're about to try something overly complicated, and you notice
when you do something stupid, and it decreases the chance of you doing
something twice in a long debugging session. For structured note-
taking, I do enjoy Zim, a desktop wiki software.

Best regards,
Marcus

¹  "hey rubber
   ducky, my correlation TDOA system doesn't work" would not make the
   ducky any smarter about the problem, but a
   "hey rubber ducky, I've 
   got this TDOA receiver based on a windowed crosscorrelation of two 
   WiFi packets, but I'm getting two peaks in the crosscorrelation
   function, but I need exactly one to find the time difference!"
   might make ducky look you in the eye and tell you to look at the
   autocorrelation function of your WiFi packet.
²  "hey rubber ducky, so I've got this job where they pay me to
   implement software, and so I thought I'd try my hands at finding the
   location of RF car keys through SDR; you see, I've been fascinated
   by car keys for nearly as long as I can think. I think it all
   started when my grandpa…"
On Tue, 2018-05-29 at 20:59 -0400, Linda20071 wrote:
> Hello everybody,
> 
> Are there any good tutorials or videos on youtube that explains how
> to do 

Re: [Discuss-gnuradio] Resampling rate method assistance

[CEL]

I'd assume this might not be a computational issue, but more of a
hardware or hardware interfacing issue, or maybe something
algorithmically off. Care to save a picture of your flow graph (File-
>Screen Capture) and upload it (e.g. imgur.com)?

Thanks,
Marcus
On Wed, 2018-05-30 at 08:25 +1000, Carlo Manfredini wrote:
> Hi Marcus,
> I see. I thought you were referring to the "Polyphase Arbitrary
> Resampler"  block for a polyphase implementation.
> 
> Having that optimisation in the "Rational Resampler" is excellent,
> and thank you for the detailed explanation. Very helpful.
> 
> I'll look further into why I was getting underflow issues as
> resampling between 100kSps and 48kSps using 12/25 ratios should be no
> problem for my i7 based PC.
> ( I assume that what I was getting: aUaUaU...being printed onscreen
> in GRC..and some breaks in the continuous signal)
> 
> Regards.
> 
> On 29 May 2018 at 23:19, Müller, Marcus (CEL) 
> wrote:
> > Hi Carlo,
> > 
> > if you're using GNU Radio's rational resampler, you're already
> > using
> > that method!
> > 
> > Really, at your 100 kS/s rate... things should be trivial for your
> > CPU,
> > even if they weren't implemented efficiently. I'm really not
> > convinced
> > the resampling is to blame here!
> > 
> > Best regards,
> > Marcus
> > 
> > On Tue, 2018-05-29 at 22:03 +1000, Carlo Manfredini wrote:
> > > Hi Marcus,
> > > Thanks for that reply.
> > > The reduction in computation with the polyphase implementation
> > sounds very tempting esp as I'm getting underflow errors at the
> > moment.
> > > I will give it a try and see how it compares.
> > > Regards.
> > > 
> > > On 29 May 2018 at 19:34, Müller, Marcus (CEL) 
> > wrote:
> > > > Hi Carlo, hi Linda:
> > > > 
> > > > as Linda said,the RR approach works really well and is
> > numerically
> > > > relatively stable until you hit really ugly ratios (after, of
> > course,
> > > > cancelling the fraction as far as possible).
> > > > But what is "ugly" here? 
> > > > 
> > > > In theory, rational resampling by M/N (note: M,N coprime!)
> > would work
> > > > like the following
> > > > 
> > > > input --> insert (M-1) zeros between each sample
> > > >   --> low-pass 1/M-band filter to get rid of the images
> > > >   --> low-pass 1/N-band filter to avoid aliasing in next
> > step
> > > >   --> throw away (N-1) of N samples --> output
> > > > 
> > > > Now, either of the 1/M and the 1/N-band filter doesn't do
> > anything
> > > > useful, simply because the other is narrower.
> > > > 
> > > > So, we reduce that to 
> > > > 
> > > > input --> insert (M-1) zeros between each sample
> > > >   --> low-pass 1/max(M,N)-band filter against images and
> > aliases
> > > >   --> throw away (N-1) of N samples --> output
> > > > 
> > > > and pay a bit of attention to the transition width of the
> > filter (which
> > > > will become smaller the closer the ratio M/N becomes to 1).
> > > > 
> > > > This is all fine and dandy, but let's say max(M,N) is N=25.
> > > > A quick calculation[1] shows that this filter might have 220
> > taps,
> > > > which we need to apply to 12× the input sample rate, so that's
> > 12·220,
> > > > that is ca 2600, multiply-accumulate operations per input
> > sample –
> > > > ooof.
> > > > 
> > > > We avoid that by having an elegant polyphase implementation,
> > which by
> > > > the
> > > > power of greyskull (or was it harris?) allows us to run this
> > core
> > > > filter
> > > > at 1/N of the input rate (instead of M times the input rate!);
> > so, we
> > > > get
> > > > 220 / 25 = 9 multiply-accumulates per input sample - which is
> > very
> > > > bearable, and thus, the rational resampler works very well in
> > this
> > > > scenario.
> > > > 
> > > > With M,N coprime, we basically get two good cases:
> > > > 
> > > > 1. N >> M (rational decimation): The core filter runs at a very
> > low
> > > > rate of 
> > > >1/N of the input rate, its length being proportional to M·N.
> > > > 2. M >> N (rational interpolation): The cor

Re: [Discuss-gnuradio] Resampling rate method assistance

[CEL]

Hi Carlo, hi Linda:

as Linda said,the RR approach works really well and is numerically
relatively stable until you hit really ugly ratios (after, of course,
cancelling the fraction as far as possible).
But what is "ugly" here? 

In theory, rational resampling by M/N (note: M,N coprime!) would work
like the following

input --> insert (M-1) zeros between each sample
  --> low-pass 1/M-band filter to get rid of the images
  --> low-pass 1/N-band filter to avoid aliasing in next step
  --> throw away (N-1) of N samples --> output

Now, either of the 1/M and the 1/N-band filter doesn't do anything
useful, simply because the other is narrower.

So, we reduce that to 

input --> insert (M-1) zeros between each sample
  --> low-pass 1/max(M,N)-band filter against images and aliases
  --> throw away (N-1) of N samples --> output

and pay a bit of attention to the transition width of the filter (which
will become smaller the closer the ratio M/N becomes to 1).

This is all fine and dandy, but let's say max(M,N) is N=25.
A quick calculation[1] shows that this filter might have 220 taps,
which we need to apply to 12× the input sample rate, so that's 12·220,
that is ca 2600, multiply-accumulate operations per input sample –
ooof.

We avoid that by having an elegant polyphase implementation, which by
the
power of greyskull (or was it harris?) allows us to run this core
filter
at 1/N of the input rate (instead of M times the input rate!); so, we
get
220 / 25 = 9 multiply-accumulates per input sample - which is very
bearable, and thus, the rational resampler works very well in this
scenario.

With M,N coprime, we basically get two good cases:

1. N >> M (rational decimation): The core filter runs at a very low
rate of 
   1/N of the input rate, its length being proportional to M·N.
2. M >> N (rational interpolation): The core filter runs at a still low
1/M
   of the output rate, its length being proportional to M.

So, the efforts of an M/N and an N/M filter are very manageable,
because
either the filter isn't that long (no M factor in the length) or the
filter 
runs at a very low rate (1/N of the input).

A problem only occurs if M and N are relatively close to each other:

In that case, the transition width of the core filter becomes very
small, and
the inverse of transition width goes linearly into the necessary length
of a 
FIR filter; at the meantime, the polyphase saving don't balance that
out.
To make matters worse, a some point, having a polyphase decomposed
large filter
becomes a problem for your CPU: while a modern CPU can happily keep a
couple
hundred filter coefficients and the same amount of in- and of output
samples in
L2 (or even L1) cache, you can quickly get into trouble if the filter
becomes
so large that you regularly have to flush your cache; then you quickly
become
RAM bandwidth bound and performance plummets. Don't expect that to
happen before
ratios like 1023/1024 or so on your x86.

In these cases, just like in the finely adjustable ratio cases, an
arbitrary 
ratio resampler becomes the method of choice – but even then, you'd
often try to
get "as close as feasible" to the target rate with a rational
resampler, and then
only do the remainder that's really close to 1 with an arbitrary
resampler.

Best regards,
Marcus

[1] https://dsp.stackexchange.com/questions/31066/how-many-taps-does-an
-fir-filter-need#31077
with δ_1 = 10^-2, δ_2 = 10^-6, and the transition width half an
alias distance, 
i.e. f_s/50
On Tue, 2018-05-29 at 14:37 +1000, Carlo Manfredini wrote:
> Thanks, that works well.
> I'm pleased to be able to use the RR, and am using the default taps.
> 
> 
> On 29 May 2018 at 10:07, Linda20071  wrote:
> > Use the rational resampler module (12/25). Decimation 25; interpolation: 12
> > 
> > On Mon, May 28, 2018 at 7:44 PM, Carlo Manfredini 
> >  wrote:
> > > Hi,
> > > I wish to transfer continuous data between two devices operating at these 
> > > two rates: 
> > > 100kSps and 48kSps
> > > I would appreciate some suggestions as to the "best " method or resampler 
> > > to use.
> > > I imaging the RR is not useful here.
> > > Im thinking some fractional resampler is best.
> > > Since these rates are quite low I imagine processing load is not an issue.
> > > 
> > > Also, how does one select the filter taps required ? Are there some 
> > > tutorials or "rules of thumb" I can follow ?
> > > 
> > > Thanks for hints.
> > > 
> > > 
> > > 
> > > ___
> > > 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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] Resampling rate method assistance

[CEL]

Hi Carlo,

if you're using GNU Radio's rational resampler, you're already using
that method!

Really, at your 100 kS/s rate... things should be trivial for your CPU,
even if they weren't implemented efficiently. I'm really not convinced
the resampling is to blame here!

Best regards,
Marcus

On Tue, 2018-05-29 at 22:03 +1000, Carlo Manfredini wrote:
> Hi Marcus,
> Thanks for that reply.
> The reduction in computation with the polyphase implementation sounds very 
> tempting esp as I'm getting underflow errors at the moment.
> I will give it a try and see how it compares.
> Regards.
> 
> On 29 May 2018 at 19:34, Müller, Marcus (CEL)  wrote:
> > Hi Carlo, hi Linda:
> > 
> > as Linda said,the RR approach works really well and is numerically
> > relatively stable until you hit really ugly ratios (after, of course,
> > cancelling the fraction as far as possible).
> > But what is "ugly" here? 
> > 
> > In theory, rational resampling by M/N (note: M,N coprime!) would work
> > like the following
> > 
> > input --> insert (M-1) zeros between each sample
> >   --> low-pass 1/M-band filter to get rid of the images
> >   --> low-pass 1/N-band filter to avoid aliasing in next step
> >   --> throw away (N-1) of N samples --> output
> > 
> > Now, either of the 1/M and the 1/N-band filter doesn't do anything
> > useful, simply because the other is narrower.
> > 
> > So, we reduce that to 
> > 
> > input --> insert (M-1) zeros between each sample
> >   --> low-pass 1/max(M,N)-band filter against images and aliases
> >   --> throw away (N-1) of N samples --> output
> > 
> > and pay a bit of attention to the transition width of the filter (which
> > will become smaller the closer the ratio M/N becomes to 1).
> > 
> > This is all fine and dandy, but let's say max(M,N) is N=25.
> > A quick calculation[1] shows that this filter might have 220 taps,
> > which we need to apply to 12× the input sample rate, so that's 12·220,
> > that is ca 2600, multiply-accumulate operations per input sample –
> > ooof.
> > 
> > We avoid that by having an elegant polyphase implementation, which by
> > the
> > power of greyskull (or was it harris?) allows us to run this core
> > filter
> > at 1/N of the input rate (instead of M times the input rate!); so, we
> > get
> > 220 / 25 = 9 multiply-accumulates per input sample - which is very
> > bearable, and thus, the rational resampler works very well in this
> > scenario.
> > 
> > With M,N coprime, we basically get two good cases:
> > 
> > 1. N >> M (rational decimation): The core filter runs at a very low
> > rate of 
> >1/N of the input rate, its length being proportional to M·N.
> > 2. M >> N (rational interpolation): The core filter runs at a still low
> > 1/M
> >of the output rate, its length being proportional to M.
> > 
> > So, the efforts of an M/N and an N/M filter are very manageable,
> > because
> > either the filter isn't that long (no M factor in the length) or the
> > filter 
> > runs at a very low rate (1/N of the input).
> > 
> > A problem only occurs if M and N are relatively close to each other:
> > 
> > In that case, the transition width of the core filter becomes very
> > small, and
> > the inverse of transition width goes linearly into the necessary length
> > of a 
> > FIR filter; at the meantime, the polyphase saving don't balance that
> > out.
> > To make matters worse, a some point, having a polyphase decomposed
> > large filter
> > becomes a problem for your CPU: while a modern CPU can happily keep a
> > couple
> > hundred filter coefficients and the same amount of in- and of output
> > samples in
> > L2 (or even L1) cache, you can quickly get into trouble if the filter
> > becomes
> > so large that you regularly have to flush your cache; then you quickly
> > become
> > RAM bandwidth bound and performance plummets. Don't expect that to
> > happen before
> > ratios like 1023/1024 or so on your x86.
> > 
> > In these cases, just like in the finely adjustable ratio cases, an
> > arbitrary 
> > ratio resampler becomes the method of choice – but even then, you'd
> > often try to
> > get "as close as feasible" to the target rate with a rational
> > resampler, and then
> > only do the remainder that's really close to 1 with an arbitrary
> > resampler.
> > 
> > Best regards,
> > Marcus
> > 
> > [1] https://dsp.stackex

[Discuss-gnuradio] Release 3.7.13.1 is out!

[CEL]

Dear best community of an SDR project known to mankind!

It took me longer than I'd like to admit, but we've finally come to a
release of GNU Radio's maintenance branch 3.7. I'm very thankful for
the contributors we've had this time, especially because the amount of
first-time code contributions is so high! 

* Derek Kozel 
* Douglas Weber 
* ilovezfs 
* Marcus Müller 
* Michael Dickens 
* Sebastian Koslowski 
* soggysec 

The main feature, about which I presume most of you care about, is that
there are fixes for the nasty Qtgui / code generation bug we've
introduced with 3.7.12.0; promise we'll avoid such messes in the
future!

As you can imagine, we're working on the "next bigger step" in the
meantime: For GRCon, we'd like to have GNU Radio 3.8 out of the door,
in proper use and with sufficient experiences with the progressive
changes we have in stock for that.

Needless to say, 3.7 isn't dead by any means! You'll find plenty of
issues on github that carry the "backport-3.7" tag, which means that
once we fix them on the current development branch, I'll also make sure
to let them flow into the next 3.7 release.

On the side of making GNU Radio easier to use, I'm very happy to say
that Marc Lichtman has taken it upon him to make the documentation –in
every sense of the word– more accessible. As making sure GNU Radio
works as intended, and that is very closely related to working as
understood, this is an effort very dear to me. You'll probably hear
from him sooner or later!

Talking about understanding things:
I'm extremely certain that there's excellent GNU Radio usage out there
that I simply don't know of. Don't hesitate to announce your projects
on the mailing list, ask GNU Radio-related questions very specific to
what you're doing and generally give feed back on both the small
building blocks as well as the large architectures GNU Radio puts you
up against!

And while you're doing that:

GRCon18's Call For Papers is still open until **June 3**! If you need
any help with the abstract/paper submission process, do not hesitate to
reach out – even if you have something unwieldy to talk about, I think
we can make it work.

Best regards,
Marcus Müller
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Selecting the precise sampling point from many samples

[CEL]

Hi Carlo,

not quite sure I get what you mean with "bandlimiting"? What with
"transposing"? 

Regarding "padding": do you mean interpolation? Again, you'd use a
resampler, and in your case, the rational resampler with decimation=1,
interpolation = 48 would do the trick.

Best regards,
Marcus

On Mon, 2018-06-04 at 22:09 +1000, Carlo Manfredini wrote:
> Thank you for your detailed reply.
> I've taken a look at those links and for now are having some success
> using the Clock Recovery MM block with default settings (and 24
> samples/symbol) to capture the data at 2kbps...followed by a Bit
> Slicer.
> 
> After I modulate this 2kbps bit stream to 4-QAM I have a complex 
> 1kSymbol/s stream...as a data stream...with bandlimiting from the QAM
> block.
> 
> Can you suggest how I can pad this out so that I can output it from
> my 48kSps DAC device  such that it is output at a real rate of
> 1kSymbol/sec ?
> 
> Ive tried out "repeat" blocks but without any significant progress.
> 
> What is the best approach for this situation of having to transpose a
> data  stream to a specific output rate ?
> 
> Regards.
> 
> 
> 
> 
> 
> On 1 June 2018 at 22:25, Andy Walls 
> wrote:
> > > From: Carlo Manfredini
> > > Date: Fri, 1 Jun 2018 21:24:26 +1000
> > > Hello,
> > > I have a 2kbps bipolar data stream (in hardware) which I will
> > sample
> > > at 48kSps and bring into GR.
> > > Once in GR, I wish to be able to sample only once per bit...so I
> > use
> > > the "Keep 1 in N" block (where N=24) and this reduces my rate to
> > > 2kSps...with 1 sample per original data bit.
> > > 
> > > However, I wish to be able to control exactly at which point in
> > the
> > > 48kSps stream that I sample down to 2kSps.
> > > 
> > > This is equivalent in hardware terms to being able to select at
> > which
> > > point in each bit period that I sample once per bit.ie: selecting
> > the
> > > decision point in an eye pattern).
> > > 
> > > The reason for this process is that I simply wish to read in the
> > > original 2kbps bit stream so that I can use this data to do some
> > PSK
> > > modulation in GR etc...but my inputting device only runs at
> > 48kSps.
> > > 
> > > Is there some way with existing GR blocks that I can tell where
> > > abouts in the 48kSps stream that I have actually sampled ? so
> > that I
> > > can manually set this sampling point.
> > 
> > This is precisely the function of the Symbol Synchronization
> > blocks.
> > 
> > https://www.gnuradio.org/wp-content/uploads/2017/12/Andy-Walls-Samp
> > les-to-Digital-Symbols.pdf
> > 
> > You should play with the example here:
> > 
> > https://github.com/gnuradio/gnuradio/blob/master/gr-digital/example
> > s/demod/symbol_sync_test_float.grc
> > https://github.com/gnuradio/gnuradio/blob/master/gr-digital/example
> > s/demod/symbol_sync_test_float_ted_gain.m
> > 
> > 
> > You'll probably want to do something like:
> > 
> >  -> Decimating FIR filter -> FIR Filter -> Symbol Sync -> Binary
> > Slicer -> 
> > 
> > The first decimating FIR filter would anti-alias filter and
> > downsample
> > by, let's say, 2 or 4, to bring the stream down to either 12 or 6
> > samples per symbol.
> > 
> > The second FIR filter would be a pulse matched filter, to get rid
> > of
> > noise and peak the symbol centers.  (You can merge this filter into
> > the
> > previous filter, if you want.)
> > 
> > The Symbol Sync block estimates the exact symbol centers, and
> > downsamples to just those sample points.
> > 
> > The binary slicer just thresholds its input samples to give you 1
> > or 0
> > valued samples on output.
> > 
> > > Perhaps a simpler question is : how do I know where the "Keep 1
> > in N"
> > > block is sampling ?
> > 
> > You don't.
> > 
> > Regards,
> > Andy
> > 
> > > Thanks for any hints...hopefully I have explained this
> > adequately.
> > 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to modify the existing module and make it effective

[CEL]

Hello!

If you've modified it, I guess you already have the GNU Radio source
code.

So, you must make sure that you're using the GNU Radio that you have
built from source: 

https://www.gnuradio.org/doc/doxygen/build_guide.html

Simply build your modified GNU Radio and install it :)

How that works depens on the operating system you are using.

Best regards,
Marcus

On Mon, 2018-06-04 at 15:55 +0800, Mr。树 wrote:
> Hello all,
> I have changed something in OFDM Carrier Allocator modular，but I
> don't know how to rebuilt it and use it.
> Hopefully I have explained this adequately.
> Thanks for any ideas...
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Release 3.7.13.2 is out! (was: Release 3.7.13.1 is out!)

[CEL]

I messed up, and v3.7.13.1 was tagged off-branch, whereas I pushed a
commit that incorrectly changed the version number to the maint-3.7
branch.

I ask you to not use 3.7.13.1 but 3.7.13.2. Thank you!

Best regards,
Marcus

On Thu, 2018-05-31 at 19:30 +, Müller, Marcus (CEL) wrote:
> Dear best community of an SDR project known to mankind!
> 
> It took me longer than I'd like to admit, but we've finally come to a
> release of GNU Radio's maintenance branch 3.7. I'm very thankful for
> the contributors we've had this time, especially because the amount
> of
> first-time code contributions is so high! 
> 
> * Derek Kozel 
> * Douglas Weber 
> * ilovezfs 
> * Marcus Müller 
> * Michael Dickens 
> * Sebastian Koslowski 
> * soggysec 
> 
> The main feature, about which I presume most of you care about, is
> that
> there are fixes for the nasty Qtgui / code generation bug we've
> introduced with 3.7.12.0; promise we'll avoid such messes in the
> future!
> 
> As you can imagine, we're working on the "next bigger step" in the
> meantime: For GRCon, we'd like to have GNU Radio 3.8 out of the door,
> in proper use and with sufficient experiences with the progressive
> changes we have in stock for that.
> 
> Needless to say, 3.7 isn't dead by any means! You'll find plenty of
> issues on github that carry the "backport-3.7" tag, which means that
> once we fix them on the current development branch, I'll also make
> sure
> to let them flow into the next 3.7 release.
> 
> On the side of making GNU Radio easier to use, I'm very happy to say
> that Marc Lichtman has taken it upon him to make the documentation
> –in
> every sense of the word– more accessible. As making sure GNU Radio
> works as intended, and that is very closely related to working as
> understood, this is an effort very dear to me. You'll probably hear
> from him sooner or later!
> 
> Talking about understanding things:
> I'm extremely certain that there's excellent GNU Radio usage out
> there
> that I simply don't know of. Don't hesitate to announce your projects
> on the mailing list, ask GNU Radio-related questions very specific to
> what you're doing and generally give feed back on both the small
> building blocks as well as the large architectures GNU Radio puts you
> up against!
> 
> And while you're doing that:
> 
> GRCon18's Call For Papers is still open until **June 3**! If you need
> any help with the abstract/paper submission process, do not hesitate
> to
> reach out – even if you have something unwieldy to talk about, I
> think
> we can make it work.
> 
> Best regards,
> Marcus Müller
> ___
> 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] install issue with c++11

[CEL]

Then the answer is really, very likely, to use a container of sorts.
Docker seems to be the choice for that these days.

Best regards,
Marcus

On Tue, 2018-06-05 at 08:08 -0700, Jason Matusiak wrote:
> I wasn't worried about my gnuradio builds as much as my system as a whole 
> when I was mucking with the actually cmake and compilers themselves to try 
> and fix the problem.
> > The whole purpose of using PyBOMBS is to work in PREFIXes, so no need
> > to do that – PyBOMBS does that automatically.

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] install issue with c++11

[CEL]

Hi Jason,

to not hose my system every day, I simply work in prefixes. Basically,
find my shell's RC file below. With options like `-
DCMAKE_INSTALL_PREFIX=$GRPREFIX` (for CMake) or `export`ing
PREFIX=$GRPREFIX (before running ./configure scripts) one can set the
installation directory so that things end up in the right place.

At times, I just paste my build instructions into a Dockerfile, or I
clone a bare CentOS/Fedora/Ubuntu Docker container and do my stuff
there. While not giving the isolation that a proper VM would give, this
still is a pretty safe bet.

Cheers,
Marcus

#.zshenv for multiple GNU Radio installations
GRPREFIX=/home/marcus/.usrlocal
export EDITOR="/usr/bin/vim"

if [[ -z $( echo $PATH | grep $GRPREFIX ) ]] {
export PATH=$PATH:~/bin:$GRPREFIX/bin
export PATH=$PATH:$GRPREFIX/lib64/uhd/examples
export LD_LOAD_LIBRARY=$LD_LOAD_LIBRARY:$GRPREFIX/lib64
export LD_LOAD_LIBRARY=$LD_LOAD_LIBRARY:$GRPREFIX/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GRPREFIX/lib64
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GRPREFIX/lib
export PYTHONPATH=$PYTHONPATH:$GRPREFIX/lib64/python2.7/dist-
packages
export PYTHONPATH=$PYTHONPATH:$GRPREFIX/lib64/python2.7/site-
packages
export
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$GRPREFIX/lib64/pkgconfig
}

On Tue, 2018-06-05 at 07:17 -0700, Jason Matusiak wrote:
> Marcus, I started to suspect after the thread started that that was the case. 
>  I was doing this work in a VM so as to not hose my host system too much, but 
> I just started another install on my host system to do the work without 
> memory being an issue.
>  
> That said, the c++11 concerns are definitely there, and the new change to 
> gr-blocks that was committed about 7 days ago was when we decided we need to 
> come up with a good solution since I couldn't simply fetch/mod/rebuild that 
> as easy as I could gqrx.
>  
> Fingers crossed that Dave's advice works on my beefier setup (sadly, one of 
> my 100 other attempts might have worked, I don't recall when this memory 
> issue started cropping up after I took on the c++11 task, but it wasn't there 
> the other day).
>  
> > 
> > On 06/05/2018 09:07 AM, Jason Matusiak wrote:
> > > Thanks Dave, but that did not seem to work for me.  Here were the 
> > > commands I ran (slightly different than recommended, but that was for 
> > > some different recipe mods that have nothing to do with this issue):
> > > $ export CXXFLAGS="-std=c++11"
> > > $ PREFIX=/opt/gnuradio/v3.7.12.0
> > > $ yes | pybombs prefix init $PREFIX
> > > $ yes | pybombs -p $PREFIX recipes add gr-recipes 
> > > git+https://github.com/gnuradio/gr-recipes.git
> > > $ source /opt/gnuradio/v3.7.12.0/setup_env.sh
> > > $ pybombs -vvv -p $PREFIX install gnuradio
> > > And currently things keep erroring out at the same place while installing 
> > > UHD:
> > > [ 43%] Building CXX object 
> > > lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
> > > [ 43%] Building CXX object 
> > > lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
> > > c++: internal compiler error: Killed (program cc1plus)
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See  for instructions.
> > > make[2]: *** 
> > > [lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o]
> > >  Error 4
> > > make[2]: *** Waiting for unfinished jobs
> > > I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
> > >  
> >  That error is internal to the compiler, it is failing to perform its job 
> > correctly.  This has nothing to do with Gnu Radio, per se, or PyBombs
> >   or any of that.  This ordinarily means you compiler is broken in some way.
> > 
> > HOWEVER.  How much memory do you have on the system?
> > 
> > This issue used to happen on systems with small physical memory, because 
> > compiling certain things requires a lot of virtual memory
> >   on the part of the compiler.
> > 
> > 
> > > > Jason,
> > > >  
> > > >  You can set the CXXFLAGS env variable to "-std=c++11" and any 
> > > > CMake builds you run (assuming the same shell) will check the CXXFLAGS 
> > > > var first.  This assumes that you don't overwrite the value of 
> > > > CMAKE_CXX_FLAGS.  I just tried it in a terminal with `export 
> > > > CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally `VERBOSE=1 make -j 
> > > > 1`.  The verbose make command will show you if your flags are taking or 
> > > > not.
> > > >  
> > > > -Dave
> > > > 
> > > > On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak 
> > > >  wrote:
> > > > > I am trying to install gnuradio onto a Centos 7 box and am having 
> > > > > more and more issues with packages that use c++11 commands.  For some 
> > > > > of the packages, I add the line:
> > > > > CMAKE_CXX_FLAGS "-std=c++11"
> > > > > to the module's CMakeLists.txt file.
> > > > >  
> > > > > The issue is that that 

Re: [Discuss-gnuradio] install issue with c++11

[CEL]

The whole purpose of using PyBOMBS is to work in PREFIXes, so no need
to do that – PyBOMBS does that automatically.
On Tue, 2018-06-05 at 10:38 -0400, Dave NotTelling wrote:
> Check out 
> https://github.com/gnuradio/pybombs#configuring-a-prefix-environment-eg-for-cross-compiling.
>   You might be able to set CXXFLAGS with the `--env` flag
> 
> On Tue, Jun 5, 2018 at 10:36 AM Dave NotTelling  wrote:
> > I would suspect that PyBombs doesn't care about your env variables.  That 
> > or it overwrites the CMAKE_CXX_FLAGS at some point.  I have no idea how 
> > PyBombs builds the CMake projects.  If it's not calling the `cmake` command 
> > directly, then it likely will not pick up the env variable.
> > 
> > On Tue, Jun 5, 2018 at 10:33 AM Philip Balister  wrote:
> > > On 06/05/2018 10:06 AM, Marcus D. Leech wrote:
> > > > On 06/05/2018 09:07 AM, Jason Matusiak wrote:
> > > >> Thanks Dave, but that did not seem to work for me.  Here were the
> > > >> commands I ran (slightly different than recommended, but that was for
> > > >> some different recipe mods that have nothing to do with this issue):
> > > >>
> > > >> $ export CXXFLAGS="-std=c++11"
> > > >> $ PREFIX=/opt/gnuradio/v3.7.12.0
> > > >> $ yes | pybombs prefix init $PREFIX
> > > >> $ yes | pybombs -p $PREFIX recipes add gr-recipes
> > > >> git+https://github.com/gnuradio/gr-recipes.git
> > > >> $ source /opt/gnuradio/v3.7.12.0/setup_env.sh
> > > >> $ pybombs -vvv -p $PREFIX install gnuradio
> > > >>
> > > >> And currently things keep erroring out at the same place while
> > > >> installing UHD:
> > > >>
> > > >> [ 43%] Building CXX object
> > > >> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
> > > >>
> > > >> [ 43%] Building CXX object
> > > >> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
> > > >>
> > > >> c++: internal compiler error: Killed (program cc1plus)
> > > >> Please submit a full bug report,
> > > >> with preprocessed source if appropriate.
> > > >> See  for instructions.
> > > >> make[2]: ***
> > > >> [lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o]
> > > >> Error 4
> > > >> make[2]: *** Waiting for unfinished jobs
> > > >>
> > > >> I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
> > > >>
> > > > That error is internal to the compiler, it is failing to perform its job
> > > > correctly.  This has nothing to do with Gnu Radio, per se, or PyBombs
> > > >   or any of that.  This ordinarily means you compiler is broken in some
> > > > way.
> > > > 
> > > > HOWEVER.  How much memory do you have on the system?
> > > 
> > > 
> > > Run dmesg and look for messages from the OOM killer (Out of Memory)
> > > 
> > > Philip
> > > 
> > > > 
> > > > This issue used to happen on systems with small physical memory, because
> > > > compiling certain things requires a lot of virtual memory
> > > >   on the part of the compiler.
> > > > 
> > > > 
> > > >>
> > > >> Jason,
> > > >>  You can set the CXXFLAGS env variable to "-std=c++11" and any
> > > >> CMake builds you run (assuming the same shell) will check the
> > > >> CXXFLAGS var first.  This assumes that you don't overwrite the
> > > >> value of CMAKE_CXX_FLAGS.  I just tried it in a terminal with
> > > >> `export CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally
> > > >> `VERBOSE=1 make -j 1`.  The verbose make command will show you if
> > > >> your flags are taking or not.
> > > >> -Dave
> > > >>
> > > >> On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak
> > > >>  > > >> > wrote:
> > > >>
> > > >> I am trying to install gnuradio onto a Centos 7 box and am
> > > >> having more and more issues with packages that use c++11
> > > >> commands.  For some of the packages, I add the line:
> > > >> CMAKE_CXX_FLAGS "-std=c++11"
> > > >> to the module's CMakeLists.txt file.
> > > >> The issue is that that requires a fetch, the mod, and then a
> > > >> rebuild.  This worked OK with it was just gqrx I was doing it
> > > >> for, but now I need it for other modules it appears, and so I
> > > >> am trying to find a more elegant solution that covers
> > > >> everything that is built via a pybombs install gnuradio
> > > >> command (like gr-blocks, which I can't use this trick for).
> > > >> If I understand the problem correctly, Ubuntu uses new enough
> > > >> tools to realize that it needs to use the c++11 version (or
> > > >> newer I assume) to build since it is needed.  It seems like
> > > >> even though Centos 7 has the c++11 capability, it does not
> > > >> smartly trying to use it, and must be directed to for the
> > > >> installs to work.
> > > >> Is there something I can do at an upper level to make things
> > > >> happy on an 

Re: [Discuss-gnuradio] A small embedded python block which does frequency peak detect

[CEL]

Hello Ji-yeon,

I think the best way to help you forward here is point out that the
description of the block is very close to actually being an
algorithmical description of what you need to do!
So, maybe you're just missing the tools to build your own blocks and
use the existing blocks; in that case, the GNU Radio guided tutorials
help you very far, as they introduce you to writing Python blocks,
adding tags and using existing blocks.

https://tutorials.gnuradio.org

It's recommendable to read these tutorials in the right order.

Best regards,
Marcus

On Wed, 2018-06-06 at 02:33 +0900, 김지연 wrote:
> Hello,
>  
> Thank you so much for your replying.
> I'm sorry, but could you explain more about a small embedded python
> block which does peak detect and adds tags with the frequency
> information then display using the vector sink?
> Or could you show me a similar example?
> Are there any sites to refer to?
> 
> Best regards,
> Ji-yeon
>  
> -Original Message-
> From: "Derek Kozel" 
> To: "김지연"; 
> Cc: "GNURadio Discussion List"; 
> Sent: 2018-05-28 (월) 20:52:51
> Subject: Re: [Discuss-gnuradio] How can I obtain the frequency value
> from WX GUI FFT Sink block?
>  
> Hello,
>  
> No, there are no automatic peak search markers in the GUI toolkits at
> the moment. It's a frequently requested feature though so we'd be
> eager to merge any implementations into GNU Radio.
>  
> The WX GUI widgets are deprecated and will be removed fairly soon.
> I'd recommend moving over to the QT widgets. For your application it
> would be possible to use the FFT block into a small embedded python
> block which does peak detect and adds tags with the frequency
> information then display using the vector sink.
>  
> Regards, 
> Derek 
> 
> On Mon, May 28, 2018 at 10:15 AM, 김지연  wrote:
> > How can I obtain the frequency value from WX GUI FFT Sink block
> > graph??
> > As in the picture, the frequency that have high power(dB) like
> > 1.39199MHz, 1.57356MHz, 3.26816MHz.
> > Are there other options except moving mouse to that location??? 
> > 
> > ___
> > 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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] functions to generate random signals

[CEL]

Hi!

Linda, you **must not** use rand(). It's not thread-safe, and GNU Radio
is inherently multithreaded. For reference, I've pointed that out in a
recent mail exchange [-1]; the recommendation was the same as Dave's:
use C++11's std:: random generators; that email even has a small code
example :) !

That being said, be warned that this is a lengthy email, and it
presumes you actually care about generating random numbers in detail.

Otherwise you really shouldn't be writing your own code, but follow
Dave's advice, and use the C++11 built in random number generator; the Boost 
library also contains variate generators, i.e. you
can use boost to generate uniform, but also gaussian, laplace, … random
variables.
GNU Radio does export its own random number generators, but let's be
honest: there's zero advantage to using it compared to something that
your language (C++11) brings.

To add something new to what Dave said: If you've got a recent release of GNU 
Radio (3.7.12.0 or later, or current master), then you'll find there's a 
gnuradio-runtime/include/gnuradio/xoroshiro128p.h [0], which
contains a fast, high-quality Pseudorandom number generator; it's usage
is pretty simple:

--
#include
// your other code
uint64_t internal_state[2];
uint64_t seed = 42; /* whatever you want to use as seed */
xoroshiro128p_seed(internal_state, seed);
// all set up for use now!
while(you_need_random_numbers) {
 uint64_t uniform_64bit_int = xoroshiro128p_next(internal_state);
}
--

which gives you uniformly distributed integers on [0;2⁶⁴-1]. Often, you
want floating point uniform numbers instead. Feel free to use these
functions (from [1], LGPL):

--
/*! \brief Convert the uint64_t output of the RNG to a uniform float32
on [0,1]
 */
static inline float uint64_to_f(const uint64_t in) {
  // Float32 has 24 significant bits.
  return (in >> (64-24)) * ( ((float)1.0f) / (UINT64_C(1) << 24));
}

/*! \brief Convert the uint64_t output of the RNG to a uniform double
(float64) on [0,1]
 */
static inline double uint64_to_d(const uint64_t in) {
  // Float64 has 53 significant bits.
  return (in >> (64-53)) * ( ((double)1.0) / (UINT64_C(1) << 53));
}
--

Now, generating Gaussians has traditionally been done with the Box-
Muller transform applied to a uniform variable; for example,
Boost::random does that. I find that this method is /very/ unsatisfactory in 
multiple aspects¹.
Instead, I propose approximating a Gaussian simply by applying the
Central Limit Theorem (CLT) to a sequence of random numbers. I've
tested that – with 32 summands² from the same XOROSHIRO128+ source, you
approximate the theoretical gaussian CDF to a degree much better than
you're likely ever to require. One caveat: The tails of the CDF
disappear, which is logical: by summing up 32 uniforms, you simply
can't get a number larger than 32 times the upper boundary.
My code [1] contains a method for that as well (I recommend using
iterations=32):

--
  /*! \brief Use the Central Limit Theorem to generate a Normal RNG
   */
  static inline float xoroshiro128p_cltf(uint64_t *state, const
uint32_t iterations, const float stddev) {
// expected value of a [0;2^32-1] uniformly discrete variable
// 2^31 - 1/2
static const int32_t mu_32 = (UINT64_C(1) << 31) - 1 ; // +0.5, see
sum -= iterations/2
// variance: ((b-a+1)^2 - 1)/12; b = 2^32 - 1, a = 0
//  =((2^32)^2 -1)  /12
//  =( 2^64 - 1)/12
//  =  2^64 / 12 - 1/12
//  =  2^62 / 3  - 1/12
// close enough
// ~=  2^31 / sqrt(3)
static const float std_32 = 1239850262.2531197f;
float norm = std_32 / stddev * sqrtf(iterations);
int64_t sum;
if(iterations%2) { //odd
  sum = (xoroshiro128p_next(state) >> 32) - mu_32;
} else {
  sum = 0;
}
for(uint32_t i = 0; i < iterations/2; i++) {
  uint64_t tmp = xoroshiro128p_next(state);
  sum +=  (tmp >> 32) - mu_32;
  sum +=  (tmp & 0x) - mu_32;
}
sum += iterations / 2;
float val = (float)sum / norm;
return val;
  }
--

Hope that helps!

Best regards,
Marcus

[-1] http://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0023
7.html
[0] https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/i
nclude/gnuradio/xoroshiro128p.h
[1] https://github.com/marcusmueller/gr-xoroshiro/blob/master/include/x
oroshiro/xoroshiro-variates.h
[2] https://projecteuclid.org/download/pdf_1/euclid.aoms/1177706645
[3] https://github.com/marcusmueller/gr-
xoroshiro/blob/master/examples/Kolmogorov-Smirnov-Test.ipynb

¹ First of all, the code in Boost 

Re: [Discuss-gnuradio] Correct way to add constructor parameter

[CEL]

Also, while you're at it: If you have parameters (like potentially your
scaling) that you'd like to update externally, for example from a
different block, it's not that bad an idea to add a "command" message
port, with a message handler that does the setting.

I mention this because messages are handled only when the
[general_]work() is not currently running – and that means that
changing a property of the block through a message handler is
inherently thread-safe, which is important in the context of GNU Radio.
For examples, in cases where you could change the length of a tap
vector, you wouldn't want to do that in the middle of a convolution of
that tap vector, but another block (let's say a channel estimator that
has calculated a new set of equalizer taps) can't know whether you're
currently working with the taps or not.

Best regards,
Marcus

On Wed, 2018-06-06 at 18:33 +0200, Sumit Kumar wrote:
> Oops.. missed that. Thanks, its done now :) 
> Sumit
> 
> On 06/06/2018 18:28, Ron Economos wrote:
> > You have to add the variable in the . line of the .xml 
> > file.
> > Ron
> > On 06/06/2018 09:08 AM, Sumit Kumar wrote:
> > > I am adding additional option in a GRC block. Its Soft Frame Equalizer
> > > 
> > > 
> > > As you see in the figure, the block has options for Algorithm, Frequency, 
> > > Bandwidth, Log and Debug. I added my own variable "Scaling". 
> > > 
> > > For this, first I edited in soft_frame_equalizer_impl.cc as follows : 
> > > 
> > > soft_frame_equalizer::sptr
> > > soft_frame_equalizer::make(Equalizer_soft algo, double freq, double bw, 
> > > int scaling, bool log, bool debug) {
> > > return gnuradio::get_initial_sptr
> > > (new soft_frame_equalizer_impl(algo, freq, bw, scaling, log, 
> > > debug));
> > > }
> > > 
> > > 
> > > soft_frame_equalizer_impl::soft_frame_equalizer_impl(Equalizer_soft algo, 
> > > double freq, double bw, int scaling, bool log, bool debug) :
> > > gr::block("soft_frame_equalizer",
> > > gr::io_signature::make(1, 1, 64 * sizeof(gr_complex)),
> > > gr::io_signature::make2(2, 2, 48, 48 * sizeof(float))),
> > > d_current_symbol(0), d_log(log), d_debug(debug), d_equalizer(NULL),
> > > d_freq(freq), d_bw(bw), d_scaling(scaling), d_frame_bytes(0), 
> > > d_frame_symbols(0), 
> > > d_freq_offset_from_synclong(0.0)
> > > 
> > > void
> > > soft_frame_equalizer_impl::set_scaling(int scaling) {
> > > d_scaling = scaling;
> > > }
> > > 
> > > And then in soft_frame_equalizer_impl.h as follows : 
> > > 
> > > public:
> > > soft_frame_equalizer_impl(Equalizer_soft algo, double freq, double 
> > > bw, int scaling, bool log, bool debug);
> > > ~soft_frame_equalizer_impl();
> > > 
> > > void set_algorithm(Equalizer_soft algo);
> > > void set_bandwidth(double bw);
> > > void set_frequency(double freq);
> > > void set_scaling(int scaling);
> > > 
> > > private:
> > > 
> > > int d_scaling;
> > > 
> > > And then in soft_frame_equalizer.h from the include directory as follows :
> > > 
> > > public:
> > > typedef boost::shared_ptr sptr;
> > > static sptr make(Equalizer_soft algo, double freq, double bw, int 
> > > scaling,
> > > bool log, bool debug);
> > > virtual void set_algorithm(Equalizer_soft algo) = 0;
> > > virtual void set_bandwidth(double bw) = 0;
> > > virtual void set_frequency(double freq) = 0;
> > > virtual void set_scaling(int scaling) = 0;
> > > 
> > > And finally in the xml file as follows : 
> > > 
> > > 
> > > Scaling
> > > scaling
> > > 0
> > > real
> > > 
> > > 
> > > It compiles well, but when I execute the program, it throws following 
> > > error:
> > > 
> > > sender started
> > > Traceback (most recent call last):
> > >   File 
> > > "/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py",
> > >  line 569, in 
> > > main()
> > >   File 
> > > "/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py",
> > >  line 557, in main
> > > tb = top_block_cls(bandwidth=options.bandwidth, 
> > > encoding=options.encoding, frequency=options.frequency, 
> > > sensitivity=options.sensitivity)
> > >   File 
> > > "/home/john/myprefix/src/gr-ieee-80211/examples/soft_decision_receiver_simulator_under_interference.py",
> > >  line 282, in __init__
> > > self.ieee802_11_soft_frame_equalizer_0 = 
> > > ieee802_11.soft_frame_equalizer(ieee802_11.LS, 2.437e9, 20e6, False, 
> > > False)
> > >   File 
> > > "/home/john/myprefix/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py",
> > >  line 644, in make
> > > return _ieee802_11_swig.soft_frame_equalizer_make(*args, **kwargs)
> > > TypeError: Required argument 'debug' (pos 6) not found
> > > 
> > > What I am missing ? Where else I need to edit ? 
> > > 
> > > Regards
> > > Sumit 
> > > 
> > > 
> > > ___
> > > 

Re: [Discuss-gnuradio] Underflow and Overflow

[CEL]

Hi Alvin,

you've already gotten plenty of info on this list from where over- and
underflows come. 
We've really addressed all this before[1,2,3,4,5,6,7,8,9,10,11,12,etc],
and you've gotten sufficient recommendations. Please do avoid to spam
the mailing list with redundant questions.
Let me quickly give you a bit of perspective on this: If we consider
just the time spent to read your emails and write a quick answer, if
GNU Radio's community was a company, you will have amassed some work
cost of upwards of 1000 $. I'm very happy to say we're not a company,
but a community project, so that we can freely choose how to use our
time, help each other, and work on software. You are, however, becoming
a bit of a drain of time, so please consider condensing your questions
a bit more, making sure that everything you've been told has already
been taken into consideration, so that we can focus on giving good
answers – that, in the end, is in your own best interest, because you
risk getting ignored if you keep this up.

Best regards,
Marcus

[1] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0022
5.html
[2] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0023
0.html
[3] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0023
1.html
[4] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0024
2.html
[5] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0024
6.html
[6] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0028
8.html
[7] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0020
7.html
[8] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0020
9.html
[9] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0021
2.html
[10] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg002
18.html
[11] https://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg002
10.html
[12] …

On Tue, 2018-05-22 at 09:38 +, Yeo Jin Kuang Alvin (IA) wrote:
> Hi all,
>  
> May I know what causes my flowgraph to have so many U’s and O’s, is there any 
> block that causes this? I am trying to hit a higher sampling rate possibly 20 
> MHz or higher. I have searched online and some suggest switching to a 
> different OS and I did switch from windows to Ubuntu, only a slight 
> difference. Some say is the computer’s processing speed not fast enough, 
> thus, changing a better one will help. Others did mentioned that the 
> flowgraph connection might cause this problem.
>  
> I am getting “OOOUOO” when transmit a sine wave sampling at 20 MHz and 
> receive to a file sink.
>  
> I am using USRP B210, running on a Intel Core i7-4700MQ CPU @ 2.40 GHz x 8, 
> 64 bit computer.
>  
> Any help would be appreciated!
>  
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] random number coding problem

[CEL]

Hi!

So, I'm really not sure how to help you here: I have to expect you to
be able to call a function in C++ to give you value. The level of
understanding necessary to transfer my example to replace your usage of
rand() in your code isn't really high. 
Maybe you'd want to read a good C++ introductory book first[1]? That
will greatly accelerate your success!

Best regards,
Marcus

PS: having a screenshot of source code is always less comfortable to
the reader than just having the source code as text; just use copy and
paste.

[1] https://stackoverflow.com/questions/388242/the-definitive-c-book-gu
ide-and-list

On Wed, 2018-05-30 at 22:31 +0900, 김무연 wrote:
> Hi all
> I was trying to make a block 
> which acts if input is 1,then output is random number and if input is 0, then 
> output is the same previous time
> So last time I asked what should I use instead of rand()
> I tried to program as you told
> But I think there is something I didn't understand
> I post a picture of my screen
> So could you give me some advices?
> Thanks
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Resampling rate method assistance

[CEL]

Hi Carlo!

On Wed, 2018-05-30 at 23:04 +1000, Carlo Manfredini wrote:
> My hardware arrangement is fairly demanding, I think ?
> I wish to resample between a Red Pitaya connected via ethernet running at 
> 100kSps and a USB-audio unit (UCA-202) running at 48kSps.

That's not "much signal to process"! In the context of SDR, we're often
considering dozens of Megasamples per seconds.

> This code is simply a "loopback test" for both units running at once.

Ha, I think that's the point here.
So, this sounds like the good ole' two-clock-problem: The rate of your
sound card is slightly different from 48 kHz, and the rate of your
Pitaya. But you do a perfect adaptation between 100 and 48 kHz. So, at
the end, one device has too many or the other too little samples per
second.

> I would then add some signal processing to the signals in and out once I have 
> these working correctly.
> You can also see the break in the audio signal display in the time sink...as 
> well as the aUaUaU...
> When I view the PCs system monitor, it is using about 50% resources.

> Perhaps the USB-based audio device is struggling to operate continuously 
> given that the RP is communicating via ethernet at about 1000kBps (according 
> to System Monitor).

That's not really that much data, and you properly decimate that to the
rate your sound card can nominally do!

> USB devices tend to be "bursty" and rarely operate continuously without 
> breaks when the PC has other tasks to attend to.

Yeah, and something along these lines occasionally happens, because
talking to drivers is hard and GNU Radio's audio sink doesn't do that
in the best possible way, but really, the USB granularity doesn't lead
to discontinuities anywhere else, so why should it here?

> A screenshot of the code is: 
> https://drive.google.com/open?id=1XTNlHB87kNrX82cItMPWMvLGCGXvyr0U
> Thanks for any further suggestions.
> Maybe an option is to run the USB device at a slower sample rate ?

Really, the amount of data isn't much here. You can use your system
monitor to see how much your CPU is utilized. It should be... limited.


Best regards,
Marcus

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] making signal source based on a certain format

[CEL]

Hi Linda,

Do you mean "sending 0 in between" or do you mean "switch transmission
on some SDR device on and off"?

First case: multiply with a (threshold(sawtooth from signal source))

Second case: see the gr-uhd examples on how to do bursty transmissions,
if a USRP is what we're talking about!

If possible, when asking the mailing list, give enough context so that
we can unambigously understand what you're asking about!

Best regards,
Marcus Müller


On Sat, 2018-06-30 at 10:44 -0400, Linda20071 wrote:
> For some reason, I need to send out a sine wave for 1 second, wait
> for 5 seconds, and finally send out another sine wave for another 1
> second. Is it possible to make such a source in gnu radio directly,
> based on the existing gnu radio blocks?
> 
> Thanks in advance!
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] set_history() for multi-input blocks

[CEL]

The history is really just the same ring-alike buffer. Setting the
history really does nothing but tell the scheduler that although you
consumed N samples, it may only declare (N-history) as "done with", and
will present you the last (history) samples as beginning of your new
input item buffer on the next call to work.

So yes, just as you have independent input streams, these history items
are all independent.

Best regards,
Marcus

On Sun, 2018-07-01 at 12:37 +0430, Ali The GREAT! wrote:
> Hi all,
> the question is this:
> when there is a multi-input (sync) block, if we put set_history(N) in
> the constructor, does it mean there are separate histories for each
> input port?
> thanks
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] "sample delay" in "Decimating FIR Filter" at GRC

[CEL]

Hi Ali,

I went into the GRC file (in gnuradio/gr-filter/grc) and looked that
up: It calls block::declare_sample_delay

https://www.gnuradio.org/doc/doxygen/classgr_1_1block.html#acad5d6e62ea
885cb77d19f72451581c2

(this documentation isn't great and doesn't really say what
declare_sample_delay actually does – we should probably improve that)

The effect of that is that the block itself sees input tags shifted by
the delay, and thus, they are also propagated through the filter with
that delay.

Makes a lot of sense if you, for example, have something like

power_detector_of_kinds_that_tags_start_of_transmission
-> linear_phase_low_pass_filter
-> more_processing

and want the "more_processing", whatever that is, to see the tags the
power detector inserted at "logically" the right position, i.e. shifted
by the constant group delay of your linear phase filter.

Best regards,
Marcus


On Mon, 2018-07-02 at 13:59 +0430, Ali The GREAT! wrote:
> hi all,
> I was wondering what the "Sample Delay" parameter in "Decimating FIR
> Filter" block in GRC does.
> Thanks in advance!
> regards,
> Ali
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Project Announcement: "master" will require C++11 soon

[CEL]

Hello greatest SDR community to roam the earth,

as we're progressing towards a merge of the next branch into master,
which will actually bring us new features and challenges like Python3,
QT5, YAML instead of XML in GRC and many, many specific improvements,
I'll announce that we're switching over to mandatory C++11 on master.

This allows for a lot less verbose coding style in many places, and
gives us a whole load of language features that we formerly had to
import through Boost, which has the tendency to change API without
notice (we've been bitten by that, for example, in the shape of
random::mt19937, and other namespaces).

It was becoming "kind of a requirement, anyway" through cppunit, as
that switched to C++11 recently. Luckily, on machines with a "fresh
enough" cppunit to require C++11, we also were able to rely on a
compiler for that standard, and we figured out that for most systems,
getting a C++11 compiler means no extra effort.

Older systems will continue to be able to build the maint-3.7 branch,
which we still actively maintain and to which we add bugfixes.

Master will, in the closer future, look like next looks now, as we're
moving towards a 3.8 release. That will undoubtedly mean we'll have
quite a bit of application breakage with master. That is not
intentional, but might very well be inevitable, as the changes we're
making to the code base are quite fundamental, and thus we'll have to
understand master as what it was meant to be: the main development
branch. Releases from that branch are to be assumed "end-user
compatible", but not every intermediate state, at every cost. As said,
the upcoming release from master will be 3.8! 

Now, to get to that release, and we really *have* to, we'll need a
large set of good bug reports! So, whether you're working on next,
master or with the latest 3.7 release, and something doesn't work like
it should, please do file an issue with GNU Radio on github, and if
possible, make a test case; if you need help with any of that, please
do reach out!


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

Re: [Discuss-gnuradio] Need help with CtrlPort Performance Monitor

[CEL]

Hi Jim,

Can you share the full console output of your flow graph?

Also note that the most "fragile" dependency of GNU Radio right now is
Thrift, if you can check whether your CMake output says that Thrift was
used, it would be helpful. Thrift is the RPC middleware that ctrlport
uses to expose itself to programs like the performance monitor.

Thanks!
Marcus

On Fri, 2018-06-22 at 13:49 -0700, Jim Larsen wrote:
> I want to use the CtrlPort Performance Monitor block to compare CPU
> usage of several demodulator alternatives. I built GNU Radio version
> 3.7.12 using PyBOMBS on Ubuntu 18.04. I added -
> DENABLE_PERFORMANCE_COUNTERS=ON to the gnuradio.lwr recipe. I
> installed  networkx, matplotlib, and python-pygraphviz. I
> edited gnuradio-runtime.conf as follows:
> 
> [ControlPort] on = True
> [ControlPort] edges_list = True
> [PerfCounters] on = True
> [PerfCounters] export = True
> 
> I ran a simple flowgraph Signal Source > Throttle > Null Sink with
> the CtrlPort Performance Monitor block. The Performance Monitor
> window opens, but the graph is empty. Please let me know how to make
> CtrlPort Performance Monitor work.
> 
> Thanks!
> 
> Jim
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Import GNURadio data to matlab

[CEL]

Dear Priyanka,

um, the whole point of that article is that you need to give the third
parameter, the kind of date (Matlab docs erroneously call this
precision, it's really the data type):

fopen(your_filename_here, 'rb', 'float')

The fact that you're even asking about quotes around the file name
might indicate you're not very used to working with matlab - which is
totally fine! However, we're really not the forum to teach you basic
Matlab, and there's literally thousands of Matlab tutorials out there,
so save yourself a lot of time and read one of them :)

Best regards,
Marcus

On Sat, 2018-06-23 at 17:42 +0200, PRIYANKA PRIYADARSHINI wrote:
> Thanks Mr. Leech,
> 
> I have already seen this but when I use 
> 
> f = fopen(filename, 'rb'); 
> 
> It gives me an error saying “undefined variable or class”. When I
> write the filename as ‘filename’ which is under single quotes then it
> works but it takes some very weird data. It doesn’t load the same
> data as it was stored from GNURadio.
> 
> Thanks!
> 
> 
>  
> > On 23 Jun 2018, at 17:28, Marcus D. Leech 
> > wrote:
> > 
> > https://adamgannon.com/2014/11/18/gnuradio_offline_pt1/
> 
> ___
> 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] Need help with CtrlPort Performance Monitor

[CEL]

Hi Jim,
that's good news so far :)

So, each time you run your flow graph, the following line should
change:

 monitor::endpoints() = -h vmware -p 40161

at least in the port number at the end.

Now, remove the ctrlport monitor from your flowgraph (disable it);
start your flow graph and let it run. You should still see such a line
being printed!

In a separate terminal, start

gr-ctrlport-monitor vmware 40161

(replacing 40161 with the port number from the output of the flow
graph)

My guess is that it says "could not connect to endpoint..."; and that
might just be a network issue. I found that on my machine, thrift only
listens on IPv6, and if that's strangely set up (which it sometimes is
especially with VMs), things might go astray. 
You can check where (on which port) your flowgraph is listening for
connections by doing something like

netstat -lpn | grep 40161

Hope that helps us get forward,
Best regards,
Marcus
On Sat, 2018-06-23 at 16:50 -0700, Jim Larsen wrote:
> Marcus,
> 
> Thank you for your reply.
> 
> > On Jun 23, 2018, at 4:00 AM, Müller, Marcus (CEL) 
> > wrote:
> > 
> > Can you share the full console output of your flow graph?
> 
> Here is the flow graph console output:
> 
> jim@vmware:~/gnuradio/prefix/perform$ gnuradio-companion
> <<< Welcome to GNU Radio Companion 3.7.12.0 >>>
> 
> Block paths:
>   /home/jim/gnuradio/prefix/perform/share/gnuradio/grc/blocks
> 
> Loading: "/home/jim/gnuradio/perfmon.grc"
> > > > Done
> 
> Generating: '/home/jim/gnuradio/top_block.py'
> 
> Generating: '/home/jim/gnuradio/top_block.py'
> 
> Executing: /usr/bin/python2 -u /home/jim/gnuradio/top_block.py
> 
> ControlPort Monitor running.
> gr::log :INFO: controlport - Apache Thrift: -h vmware -p 40161
> monitor::endpoints() = -h vmware -p 40161
> running: ['gr-perf-monitorx', 'vmware', '40161']
> 
> > Also note that the most "fragile" dependency of GNU Radio right now
> > is
> > Thrift, if you can check whether your CMake output says that Thrift
> > was
> > used, it would be helpful. Thrift is the RPC middleware that
> > ctrlport
> > uses to expose itself to programs like the performance monitor.
> 
> Here is an excerpt from the PyBOMBS output:
> 
> PyBOMBS.install_manager - INFO - Installing package: apache-
> thrift
> Install tree:
> > 
> 
> \- gnuradio
>|
>+- uhd
>|
>\- apache-thrift
> 
> Here is the output from gnuradio-config-info --enabled-components:
> 
> jim@vmware:~/gnuradio/prefix/perfmon/bin$ gnuradio-config-info --
> enabled-components
> python-support;testing-support;volk;gnuradio-runtime;gr-ctrlport;*
> thrift;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-
> analog;gr-digital;gr-dtv;gr-atsc;gr-audio;* alsa;* oss;gr-
> channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr-
> vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq
> 
> Thanks for your help,
> 
> Jim
> 
> > On Fri, 2018-06-22 at 13:49 -0700, Jim Larsen wrote:
> > > I want to use the CtrlPort Performance Monitor block to compare
> > > CPU
> > > usage of several demodulator alternatives. I built GNU Radio
> > > version
> > > 3.7.12 using PyBOMBS on Ubuntu 18.04. I added -
> > > DENABLE_PERFORMANCE_COUNTERS=ON to the gnuradio.lwr recipe. I
> > > installed  networkx, matplotlib, and python-pygraphviz. I
> > > edited gnuradio-runtime.conf as follows:
> > > 
> > > [ControlPort] on = True
> > > [ControlPort] edges_list = True
> > > [PerfCounters] on = True
> > > [PerfCounters] export = True
> > > 
> > > I ran a simple flowgraph Signal Source > Throttle > Null Sink
> > > with
> > > the CtrlPort Performance Monitor block. The Performance Monitor
> > > window opens, but the graph is empty. Please let me know how to
> > > make
> > > CtrlPort Performance Monitor work.
> > > 
> > > Thanks!
> > > 
> > > Jim
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Text transmission using usrp

[CEL]

Hi Trueblues,

the packet encoder and decoder blocks are known to be broken – that's
why they are in the "deprecated" category! It'll be gone with the next
minor release of GNU Radio, even. (same will happen to WX GUI, so
switch to Qt now!)

So, please don't use them; I don't expect them to work.
Instead, you'll find, within the examples that came with GNU Radio¹ the
digital/packet/packet_rx.grc and digital/packet/packet_tx.grc examples.

These I expect to work. They are hierarchical blocks, which you can
generate and through reloading of the block library also find in GRC's
block library.

in digital/packet_loopback_hier.grc you'll find a fully fledged
transceiver – that has all the bells and whistles of a minimal
communication system, including error correction, and phase and clock
corrections. Much, much better than "packet decoder" ever has been.

As soon as you have a rough idea what happens in the loopback flow
graph, replace the "Channel Model" with your pair of USRP sink and
source, and try it over the air :)

As we're trying to stay atop of documentation, can I ask you how you
came to build your flow graph with the packet en- and decoder? Is it
completely a design of our own, or is there resources within our sphere
of influence that we might clean up?

Best regards,
Marcus

¹typically /usr/[local/]share/gnuradio/examples

On Wed, 2018-06-27 at 02:54 +0200, Trueblues 17 wrote:
> I'm having a problem sending a text file between two usrp 2922
> devices. I'm running gnuradio companion on both laptops on windows.
> The FFT sink in the receiver detects an incoming signal however the
> file sink size is 0 byte.I attached both tx and rx flow graphs i
> used. I previously implemented an FM transceiver without any problems
> but when it comes to text, image and video i can't get an output 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Gui mem alloc error - runs OK if R, C hints deleted

[CEL]

Hi Tom!

Hm, no, I wouldn't be aware of any limitations, and even if such exist,
things shouldn't die with a std::bad_alloc!

Ok, so I'm wondering how we can move forward with this. Let us try
this:

* Can you share a proof of failure flow graph with us? That way,
everyone's definitely talking about the same thing.
* I assume you've got GNU Radio built with debug symbols (cmake
-DCMAKE_BUILD_TYPE=RelWithDebInfo). This might even work if it wasn't,
but the backtraces below might be less exciting.
* you'll need gdb

gdb --args python2 /path/to/your/flowgraph.py⏎

(things flutter by)

(gdb)start⏎

(things flutter by)

(gdb)break std::bad_alloc::what()⏎

(it should NOT complain that this symbol isn't already loaded. If it
does, we might need to install the libststc++ debug symbols; haven't
used Ubuntu in a while, but probably `apt install libstdc++-dbg` or `-
dbgsym`)

(gdb)run⏎

(wait for the breakpoint defined above to trigger)

(gdb)info threads⏎

(this is the list of currently existing threads. Copy and save.)

(gdb)bt⏎

(short for `backtrace`. Now we should be getting a list that's
basically like "walking an onion from the middle to the peel", if
you're onion layers are defined by who called a function which called a
function...)

Share the output; if you look through it, the frame with the lowest
number that already happens somewhere inside libgnuradio-qtgui probably
contains info on where exactly that allocation happens that fails.

You can "jump" into that frame with `frame `, replacing
 with the index given by # in the backtrace. If these
variables/symbols weren't optimized away during compilation, you can
even use `print ` to print the values of local and global
variables, or use `list` to print the source code of what you're
looking at (that definitely requires debug info to be included with GNU
Radio's build).

Best regards,
Marcus

On Mon, 2018-06-25 at 16:52 -0700, Tom McDermott wrote:
> Ubuntu 16.04.3
> GRC 3.7.11.1   (from git)
> I was on 3.7.13 couple of weeks ago, completely removed all of
> gnuradio
> and rebuilt trying to debug this.  3.7.11.1 had same problem.
> 
> 
> Got back to the problem of several weeks ago.
> 
> 1. When I try to use a QT GUI sink (such as frequency) the invocation
> of
> the QT Gui Frequency sink in this example throws a memory allocation
> error.
> 
> Qt has caught an exception thrown from an event handler. Throwing
> exceptions from an event handler is not supported in Qt. You must
> reimplement QApplication::notify() and catch all exceptions there.
> 
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  std::bad_alloc
> 
> 2. If I remove the Row, Column GUI hints from just that one QT GUI
> item, then it
> comes up and runs OK. The other 9 of the QT controls (sliders,
> choosers, entry,
> ranges) still have their R,C hints.
> 
> 3. Went back to the GRC file in step 1 that still has the R,C hints
> in it
> and it still fails with the error as shown in step 1.  It did come up
> and run
> one time showing 'unable to set locale' error, but still ran.  Never
> seen that before.
> 
> 
> Is there some limitation against using R,C hints on the QT displays
> (time,
> frequency, etc.)?
> 
> -- Tom, N5EG
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Gui mem alloc error - runs OK if R, C hints deleted

[CEL]

Ah, I said:

>(gdb)break std::bad_alloc::what()⏎
> 
> (it should NOT complain that this symbol isn't already loaded. If it
> does, we might need to install the libststc++ debug symbols; haven't
> used Ubuntu in a while, but probably `apt install libstdc++-dbg` or
> `-dbgsym`

I was wrong, at that point it's totally OK to complain about missing
symbol. Just say it's OK to set the breakpoint on future library load.


On Tue, 2018-06-26 at 10:47 +, Müller, Marcus (CEL) wrote:
> Hi Tom!
> 
> Hm, no, I wouldn't be aware of any limitations, and even if such
> exist,
> things shouldn't die with a std::bad_alloc!
> 
> Ok, so I'm wondering how we can move forward with this. Let us try
> this:
> 
> * Can you share a proof of failure flow graph with us? That way,
> everyone's definitely talking about the same thing.
> * I assume you've got GNU Radio built with debug symbols (cmake
> -DCMAKE_BUILD_TYPE=RelWithDebInfo). This might even work if it
> wasn't,
> but the backtraces below might be less exciting.
> * you'll need gdb
> 
> gdb --args python2 /path/to/your/flowgraph.py⏎
> 
> (things flutter by)
> 
> (gdb)start⏎
> 
> (things flutter by)
> 
> (gdb)break std::bad_alloc::what()⏎
> 
> (it should NOT complain that this symbol isn't already loaded. If it
> does, we might need to install the libststc++ debug symbols; haven't
> used Ubuntu in a while, but probably `apt install libstdc++-dbg` or
> `-
> dbgsym`)
> 
> (gdb)run⏎
> 
> (wait for the breakpoint defined above to trigger)
> 
> (gdb)info threads⏎
> 
> (this is the list of currently existing threads. Copy and save.)
> 
> (gdb)bt⏎
> 
> (short for `backtrace`. Now we should be getting a list that's
> basically like "walking an onion from the middle to the peel", if
> you're onion layers are defined by who called a function which called
> a
> function...)
> 
> Share the output; if you look through it, the frame with the lowest
> number that already happens somewhere inside libgnuradio-qtgui
> probably
> contains info on where exactly that allocation happens that fails.
> 
> You can "jump" into that frame with `frame `, replacing
>  with the index given by # in the backtrace. If these
> variables/symbols weren't optimized away during compilation, you can
> even use `print ` to print the values of local and
> global
> variables, or use `list` to print the source code of what you're
> looking at (that definitely requires debug info to be included with
> GNU
> Radio's build).
> 
> Best regards,
> Marcus
> 
> On Mon, 2018-06-25 at 16:52 -0700, Tom McDermott wrote:
> > Ubuntu 16.04.3
> > GRC 3.7.11.1   (from git)
> > I was on 3.7.13 couple of weeks ago, completely removed all of
> > gnuradio
> > and rebuilt trying to debug this.  3.7.11.1 had same problem.
> > 
> > 
> > Got back to the problem of several weeks ago.
> > 
> > 1. When I try to use a QT GUI sink (such as frequency) the
> > invocation
> > of
> > the QT Gui Frequency sink in this example throws a memory
> > allocation
> > error.
> > 
> > Qt has caught an exception thrown from an event handler. Throwing
> > exceptions from an event handler is not supported in Qt. You must
> > reimplement QApplication::notify() and catch all exceptions there.
> > 
> > terminate called after throwing an instance of 'std::bad_alloc'
> >   what():  std::bad_alloc
> > 
> > 2. If I remove the Row, Column GUI hints from just that one QT GUI
> > item, then it
> > comes up and runs OK. The other 9 of the QT controls (sliders,
> > choosers, entry,
> > ranges) still have their R,C hints.
> > 
> > 3. Went back to the GRC file in step 1 that still has the R,C hints
> > in it
> > and it still fails with the error as shown in step 1.  It did come
> > up
> > and run
> > one time showing 'unable to set locale' error, but still
> > ran.  Never
> > seen that before.
> > 
> > 
> > Is there some limitation against using R,C hints on the QT displays
> > (time,
> > frequency, etc.)?
> > 
> > -- Tom, N5EG
> > 
> > 
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How do I interface my X310 with an NVIDIA K80 GPU in GNURadio

[CEL]

Hi LJ Eads,

I'm a bit confused: What has your sound card to do with GNU Radio, or
the USRP? And how is your sound card comparable to a GPU?

GNU Radio runs on CPUs.

Best regards,
Marcus

On Wed, 2018-05-02 at 13:23 +, Eads, LJ D. wrote:
> Hello,
> I just setup a USRP X310 that I plan on using with GNURadio over 10 gigabit.. 
> I have everything working and functioning properly (drivers and all) but my 
> only concern right now is that GNURadio is running off of the sound card on 
> my server and not the GPU. GNURadio isn’t able to handle practically anything 
> because I am limited by the sound card capability.
> How would I be able to use the CPU (Sixteen-Core Intel Xeon Processor E5-2683 
> v4 2.10GHz 40MB Cache (120W)) or the GPU (NVIDIA Tesla K80 GPU Computing 
> Accelerator - 24GB GDDR5 - Passive Cooler) for better functionality of the 
> X310?
>  
> My current error: “gr::log : INFO: audio_alsa_sink0 – [default]: unable to 
> support sample rate 50
> Card requested 192000 instead”
> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/msg00418.html - 
> This sounds like my issue
>  
> Thank you,
> LJ Eads
>  
>  
> L J Eads
> The MITRE Corporation
> (937) 874-7240 (Office)
> (954) 554-6801 (Mobile)
> lje...@mitre.org (FFRDC)
>  
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CIC + halfband filter compensation

[CEL]

Hi Geoff,

might be a good idea to ask this on usrp-us...@lists.ettus.com, because
these CICs are not part of GNU Radio :)

Anyway: There's nothing much to interpret about CIC responses; they are
well-known. The length (and potentially order, as in exponent) of the
CIC used depends on your specific USRP model. (and, potentially, UHD
version)

It's rare that one actually designs an equalizing filter for the CIC –
in all USRPs, the CIC comes before the halfband filter(s), and thus,
you'd typically only see "the flattest part" of the frequency response
of the CIC.

Designing a compensating filter is mathematically impossible, but you
can alleviate certain aspects of the CIC impulse response. But this
would really require you to state what the target metric is over which
bandwidth. Also, it's almost certain that this filter would be
computationally much worse than just oversampling at the USRP end and
then decimating in software with a filter that fits what you need
better.

Notice that I very much believe that "what you need" is the critical
aspect here: Occam's razor tells me that unless you can define why the
CIC is your problem very well, then it's likely you're trying to solve
something that doesn't need solving (or that equalizing parts of the
CIC response isn't the answer you're looking for ;) ).

So, if you asked me: Describe what your system need is, and how you
came to the conclusion that the CIC is a problem! This mailing list is
very prone to having interesting discussions about real-world problems
where every party learns a lot.

Best regards,
Marcus

On Wed, 2018-04-25 at 16:39 -0400, Geoffrey Mainland wrote:
> I hope you will forgive a few naive signal processing questions :)
> 
> 1) What is the frequency response of the CIC and halfband filters in the
> USRP? This was addressed long ago on the mailing list
> (https://lists.gnu.org/archive/html/discuss-gnuradio/2007-05/msg00191.html),
> but the associated MATLAB script is no longer available now that the
> nabble archive is gone.
> 
> 2) How do I design a filter to compensate appropriately?
> 
> I know there are other methods for avoiding CIC droop, like
> oversampling, but I'd like to understand how to compensate with a filter
> as well.
> 
> Thanks!
> Geoff
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Correct usage of gr::io_signature::makev

[CEL]

That certainly works, too!

If you're using C++11, you can also

static std::vector get_input_sizes(){
 std::vector input_sizes = {
 sizeof(gr_complex),
 sizeof(gr_complex),
 sizeof(gr_complex),
 sizeof(gr_complex),
 sizeof(float)
 };
 return input_sizes;
}

Or, even shorter, just:

static std::vector get_input_sizes(){
 return {
 sizeof(gr_complex),
 sizeof(gr_complex),
 sizeof(gr_complex),
 sizeof(gr_complex),
 sizeof(float)
 };
}

since C++11 allows you to just use initializer lists where you'd
normally have to explicitly construct a vector.

On Sun, 2018-04-29 at 16:17 +0200, Sumit Kumar wrote:
> Hi Marcus,
> 
> Ok I did that as you said and it work :)
> 
> Also I found another way. I made a separate method in the class short_sync
> 
> static std::vector get_input_sizes(){
>  std::vector input_sizes;
>  input_sizes.push_back(sizeof(gr_complex));
>  input_sizes.push_back(sizeof(gr_complex));
>  input_sizes.push_back(sizeof(gr_complex));
>  input_sizes.push_back(sizeof(gr_complex));
>  input_sizes.push_back(sizeof(float));
> 
>  return input_sizes;
>  }
> 
> and then call it like this
> 
> gr::io_signature::makev(5, 5, get_input_sizes())
> 
> So both of them work!
> 
> Thanks
> 
> Sumit
> 
> 
> On 28/04/2018 19:13, Marcus Müller wrote:
> > Ah, I got that wrong,
> > 
> > The difference is that fll_band_edge_cc_impl.cc doesn't declare that
> > static variable as class member, but you do – that leads to a problem,
> > because that way, the C++ type sync_short_impl as defined in your
> > _impl.cc differs from the one in the _impl.h, but requires that an
> > object be allocated in memory before the first instance of that type
> > can be allocated. Therefore, in-class defined static members can only
> > be integral types. (And if you didn't understand much of that, don't
> > worry, it only happened to cross my horizon because I introduced a
> > strange bug when I tried to fix PMT usage in GNU Radio, and had to go
> > back, understand a static initialization problem, which took hours, and
> > fix my changes.)
> > 
> > Workaround: don't make ios and iosig a part of the class, but only of
> > the gr::ieee802_11 namespace (and maybe give them more unique names
> > when doing so).
> > 
> > Best regards,
> > Marcus
> > 
> > On Sat, 2018-04-28 at 17:39 +0200, Sumit Kumar wrote:
> > > Hi Marcus,
> > > 
> > > Actually I din't do that since the reference code which I was
> > > following,
> > > i.e.,
> > > 
> > > fll_band_edge_cc_impl.cc, has no such declaration in the
> > > corresponding
> > > header fll_band_edge_cc_impl.h
> > > 
> > > Sumit
> > > 
> > > On 28/04/2018 17:28, Marcus Müller wrote:
> > > > Hi Sumit,
> > > > 
> > > > I don't see where `ios` is being declared constantly and/or
> > > > statically
> > > > before line 31? Does that happen in the header?
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > On Sat, 2018-04-28 at 16:51 +0200, Sumit Kumar wrote:
> > > > > Hi,
> > > > > In order to look for correct usage of gr::io_signature::makev, I
> > > > > checked this example https://github.com/gnuradio/gnuradio/blob/ma
> > > > > ster
> > > > > /gr-digital/lib/fll_band_edge_cc_impl.cc
> > > > > and found
> > > > > static int ios[] = {sizeof(gr_complex), sizeof(gr_complex),
> > > > > sizeof(gr_complex), sizeof(float)};
> > > > > static std::vector iosig(ios, ios+sizeof(ios)/sizeof(int));
> > > > > and then use as io_signature::makev(1, 4, iosig))
> > > > > Basically I have to use it in sync_short.cc from gr-ieee 80211 in
> > > > > order to create more inputs.
> > > > > But if I use the above two lines inside the class i.e.
> > > > > sync_short_impl, I get lots of error. I have attached the file
> > > > > for
> > > > > reference. Could you please suggest me correct usage. I can give
> > > > > more
> > > > > information if needed.
> > > > > ~
> > > > > 
> > > > > ~~~
> > > > > /home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:31:84:
> > > > > error:
> > > > > in-class initialization of static data member ‘int
> > > > > sync_short_impl::ios []’ of incomplete type
> > > > >tic int ios[] = {sizeof(gr_complex), sizeof(float),
> > > > > sizeof(float),
> > > > > sizeof(float)};
> > > > >   
> > > > >   
> > > > >   ^
> > > > > /home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:31:
> > > > > error:
> > > > > ‘ios’ is not a type
> > > > >static std::vector iosig(ios,
> > > > > ios+sizeof(ios)/sizeof(int));
> > > > >  ^
> > > > > /home/john/myprefix/src/gr-ieee-80211/lib/sync_short.cc:32:36:
> > > > > error:
> > > > > ‘ios’ is not a type
> > > > >static std::vector iosig(ios,
> > > > > ios+sizeof(ios)/sizeof(int));
> > > > >   ^
> > > > > 

Re: [Discuss-gnuradio] Changing the frequency of a source using message prompts. *Simulation Only*

[CEL]

Hi Jordan,

nice! But: what exactly do you need help with? What's that source? 

Best regards,
Marcus
On Tue, 2018-04-10 at 10:53 -0400, Jordan Nnabugwu wrote:
> 
> I want to be able to create a block that will sent a message to change my 
> source once it senses a certain amount of power coming to the receiver.  This 
> is simulation only. 
> -- 
> Jordan Nnabugwu
> Morgan State University 
> Electrical & Computer Engineering 
> jon...@morgan.edu
> jordannnab...@gmail.com
> 4432481465
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Help with using gnuradio c++ api

[CEL]

Hi Snehasish,

since this is defitnitely not your complete code, there's nothing we
can do to help you :(

Best regards,
Marcus

On Mon, 2018-04-02 at 19:13 +, Snehasish Kar wrote:
> Hello
> 
> I was trying to generate a flow graph using file source descriptor and a file 
> sink. But after generating the  output instead of writing to the file, it 
> prints the output in the screen. Below is the code. Please let me know where 
> I am going wrong.
> 
> 
> gr::blocks::file_descriptor_source::sptr 
> fileDescriptorSource(gr::blocks::file_descriptor_source::make(sizeof(std::complex)*20,clientSockfd,false));
>  
> gr::blocks::file_sink::sptr 
> filesink(gr::blocks::file_sink::make(sizeof(std::complex)*20,"/tmp/rx.bin",false));
> gr::top_block_sptr tb(gr::make_top_block("filedescriptor_test"));
>  
> tb->connect(fileDescriptorSource,0,filesink,0);
>  
> tb->start();
>  
> tb->wait();
> 
> BR
> Snehasish
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Read output of Packet Decoder, save it into a variable and print (inside generated python file)

[CEL]

Hi Marvin,
sorry to have been so late to react:

Don't use the Packet Decoder. It has a bug and doesn't work reliably!
That's why it's in the "deprecated" category.

Best regards,
Marcus
On Thu, 2018-04-05 at 19:28 +, Marvin Biedermann wrote:
> Hello,
> 
> I am new to Gnuradio and I have a simple protocol of sending a textfile from 
> one usrp to another. My receiver-flowgraph contains a USRP Source, GMSK Demod 
> and Packet Decoder. Finally the output of the Packet Decoder is saved to a 
> textfile with File Sink.
> 
> So far, the transmitter sends data of a textfile that only contains a 1 and 
> the receiver stores it in a textfile. That works but this is quiet 
> impractical.
> 
> I want to replace the step of saving the data by simply storing the 
> output-data of the Packet Decoder in a variable and print it on the screen. I 
> have extended the generated python-file of my flowgraph with a 
> threadfunction. Inside this function, when the variable (containing the 
> output-data of the Packet Decoder) has a speficif value (in this case a 1), 
> then it triggers an event. If the variable has another value, maybe 2, it 
> triggers another event.
> 
> But so far I have no idea how to get the byte-data from the output of the 
> Packet-Decoder and save it to a variable or print in on the console and I did 
> not find anything related to this problem. Could someone help me?
> 
> Greetings
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT Modules: PDU Utilities and Timing Utilities

[CEL]

Hi Jacob,

sorry, I wasn't around to react to this:
Wow! Thank you for sharing this. 

Would this be functionality that you'd like to see upstreamed into
mainline GNU Radio? That might ease future usage for you, as then "GNU
Radio" as a whole project would notice if something we do breaks the
unit tests, and fix that.

Best regards,
Marcus

On Wed, 2018-04-11 at 20:31 -0600, Jacob Gilbert wrote:
> I wanted to point out two general purpose OOT modules we developed for some 
> internal work and recently published: gr-pdu_utils and gr-timing_utils, 
> available here:
> 
> https://github.com/sandialabs/gr-pdu_utils
> https://github.com/sandialabs/gr-timing_utils
> 
> These contain a variety of useful blocks for manipulating PDUs, converting 
> to/from PDUs/streams, and an assortment of functions we've needed over time. 
> A lightweight method for reasonable (+/- a few samples) timing of receive 
> bursts is included based on UHD-style rx_time tags, and UHD-style transmit 
> timing is supported as well for transceiver applications. The PDU Utils 
> module has a fairly good README describing use, Timing Utils README is coming 
> soon (the module was published early as a the two are related).
> 
> These modules were initially developed for bursty transceiver applications, 
> but have found use in tons of other ways over the past few years from vector 
> signal measurements to static data analysis to FHSS systems, and sometimes 
> it's just more useful to work with messages vs streams.
> 
> There are other ways to do some of what we have implemented here, but these 
> modules were developed to address some features we needed in a lightweight, 
> easy to use way. We have used the core blocks fairly extensively, and they 
> should work very well, though I can't promise there aren't edge cases we 
> haven't worked through yet, and there are some in-progress blocks. Bug 
> reports/fixes are appreciated - hope some of you find these modules useful.
> 
> Jacob
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MPSK file transfer

[CEL]

Dear Kailash,

there's very much that can go wrong for over-the-air transmissions, and
you'll simply have to apply your digital wireless communications
knowledge to narrow this down.

Furthermore, the Packet encoder and decoder blocks are *heavily*
deprecated, and you mustn't use them. Use the packet header/payload
(de)mux architecture as shown in the example .grc files that come with
gr-digital.

Best regards,
Marcus

On Mon, 2018-04-09 at 17:07 +0530, kailash kumar wrote:
> Hi,
> I am trying to implement file transfer using MPSK plus Ettus E312 USRP 
> hardware.
> However, at the receiver end, I am not getting any output.
> Please find attached Tx and Rx flow graph.
> Please let me know if I am missing anything.
> Thanks
> Kailash
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] vector sink "malloc(): memory corruption" / object was probably modified after being freed

[CEL]

Ah, by the way, the function names where that error occurs are mangled
C++ names; I'll try to show what is what (using `c++filt` to demangle
the names)

> /lib64/libc.so.6(+0x7dd4d)[0x7fa14f448d4d]
> /lib64/libc.so.6(__libc_malloc+0x4c)[0x7fa14f44afbc]
OK, that's malloc; are we certain that this has anything to do with
`free`?
> /lib64/libstdc++.so.6(_Znwm+0x1d)[0x7fa145c0e0cd]
"operator new(unsigned long)"
so, we're reserving space. Which calls malloc. Makes sense
> /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(_ZNSt6vectorIfSaIfEEaSERKS1_+0xd4)[0x7fa13df58e64]
"std::vector<float, std::allocator
>::operator=(std::vector<float, std::allocator > const&)"

Assignment operator on a std::vector!

> /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(+0x12c8a0)[0x7fa13deea8a0]

So, we are indeed in gr-blocks; but since this is the first frame
called from libpython that isn't libpython, it's likely just SWIG
wrapper code, not our own code (which doesn't imply our code isn't the
one that's buggy here). In other words: This might be the place where
SWIG or you *assign* something to something preallocated. Strange!

The rest is just python internals:
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6df0)[0x7fa150195af0]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7fa150197e3d]
> /lib64/libpython2.7.so.1.0(+0x7088d)[0x7fa15012188d]
> /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x17fd)[0x7fa1501904fd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7fa150197e3d]
> /lib64/libpython2.7.so.1.0(+0x70798)[0x7fa150121798]
> /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3]
> /lib64/libpython2.7.so.1.0(+0x5a8d5)[0x7fa15010b8d5]
> /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3]
> /lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7fa15018e6f7]
> /lib64/libpython2.7.so.1.0(+0x1155c2)[0x7fa1501c65c2]
> /lib64/libpthread.so.0(+0x7dc5)[0x7fa14fe9cdc5]
> /lib64/libc.so.6(clone+0x6d)[0x7fa14f4c276d]

If this problem persists, I'd be very interested in you running the
flowgraph in GDB, e.g.

gdb --args python2 /path/to/your/fg.py
...
(gdb)run
...
crash
...
(gdb)backtrace

The backtrace would be even more useful if your GDB knows the python
debug symbols, and maybe even has the scripting in place to interleave
Python state with the back trace (since we then would even see which
Python line was being executed, as well as the state of the python
interpreter).

Best regards,
Marcus

On Mon, 2018-04-30 at 17:16 +, Müller, Marcus (CEL) wrote:
> Hi Brad,
> 
> Sorry that I missed your mail for so long!
> So, I'm pretty certain I've fixed a potential race condition when
> accessing the data vector in vector sink lately:
> 
> https://github.com/gnuradio/gnuradio/pull/1445
> 
> But that should be included in the 3.7.11.1 release you're using... hm.
> 
> We should probably be looking into what happens in reset(), right?
> 
> Best regards,
> Marcus
> 
> On Sun, 2018-04-15 at 15:10 +, Brad Hein wrote:
> > 
> > The Vector Sink is coming in very handy for some experimentation I'm doing. 
> > I'm analyzing the output of an FFT block which terminates into a float 
> > vector sink. every few seconds from a thread which then calls reset() to 
> > clear the contents in preparation for another read. This seems problematic 
> > as the program crashes quite frequently after seconds to minutes of 
> > operation. Based on my layman's perspective it seems to be a memory leak in 
> > the vector block.
> > 
> > I tried many things over the last couple of days. Nothing seems to mitigate 
> > it. For example self.lock and self.unlock to lock the flowgraph before 
> > reading from the vector (results in flowgraph never starting back up, seems 
> > to be a whole different issue)... I tried using python copy.deepcopy to 
> > make a copy of the vector contents before using it but that didn't help 
> > eiehter. 
> > 
> > When the exception occurs, it seems to happen right after resetting the 
> > vector sink. 
> > 
> > My flowgraph doesn't run standalone and requires a number of other 
> > applications to function but I'll work on getting it up to github for 
> > review if that helps
> > 
> > Gnuradio 3.7.11.1 on a CentOS VM (Linux 3.10.0-514.el7.x86_64 #1 SMP Tue 
> > Nov 22 16:42:41 UTC 2016 x86_64 

Re: [Discuss-gnuradio] nan error from wavfile sink coupled with delayed input data

[CEL]

Huh, no, barring great undiscovered bugs, the delay involved shouldn't
have anything to do with the data, and the error pretty certainly has
something to do with invalid input data.
Are you sure the data is always the same?

Best regards,
Marcus

On Thu, 2018-04-12 at 11:03 -0400, Brad Hein wrote:
> 
> error: 
> thread[thread-per-block[22]: ]: Error in function 
> boost::math::round(f): Value nan can not be represented in the target 
> integer type.
> 
> I have a flow graph that's connecting to a remote host on a TCP port using 
> the socket PDU. The flow graph is relatively simple and outputs a derivative 
> of the stream that it gets to a wav file sink. 
> 
> [data source (48khz floating point data stream using socket PDU)] ---> 
> TCP/internet ---> [destination flowgraph] ---> wavfile sink (stdout).
> 
> When I run the flow graph against the source locally (<5ms ping time) it 
> works fine. But when I run the flow graph against a remote host that's 20ms 
> away I get the above error 99% of the time. 
> 
> I have a hunch that what's happening is that the flow graph initializes and 
> starts to try and send data to the wavfile sink BEFORE the socket PDU starts 
> receiving data from the remote host. If this is the case, I would like to 
> adapt the flowgraph to better handle the arbitrary delay of data coming into 
> the flow graph. 
> 
> I'm looking for suggestions for what sort of block or blocks I can add to 
> help the flow graph better handle the delayed start of data coming into the 
> flowgraph from the socket pdu block. 
> 
> Thanks!
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] vector sink "malloc(): memory corruption" / object was probably modified after being freed

[CEL]

Hi Brad,

Sorry that I missed your mail for so long!
So, I'm pretty certain I've fixed a potential race condition when
accessing the data vector in vector sink lately:

https://github.com/gnuradio/gnuradio/pull/1445

But that should be included in the 3.7.11.1 release you're using... hm.

We should probably be looking into what happens in reset(), right?

Best regards,
Marcus

On Sun, 2018-04-15 at 15:10 +, Brad Hein wrote:
> 
> The Vector Sink is coming in very handy for some experimentation I'm doing. 
> I'm analyzing the output of an FFT block which terminates into a float vector 
> sink. every few seconds from a thread which then calls reset() to clear the 
> contents in preparation for another read. This seems problematic as the 
> program crashes quite frequently after seconds to minutes of operation. Based 
> on my layman's perspective it seems to be a memory leak in the vector block.
> 
> I tried many things over the last couple of days. Nothing seems to mitigate 
> it. For example self.lock and self.unlock to lock the flowgraph before 
> reading from the vector (results in flowgraph never starting back up, seems 
> to be a whole different issue)... I tried using python copy.deepcopy to make 
> a copy of the vector contents before using it but that didn't help eiehter. 
> 
> When the exception occurs, it seems to happen right after resetting the 
> vector sink. 
> 
> My flowgraph doesn't run standalone and requires a number of other 
> applications to function but I'll work on getting it up to github for review 
> if that helps
> 
> Gnuradio 3.7.11.1 on a CentOS VM (Linux 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 
> 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux)
> 
> BTW when the exception occurs on OSX the error is: 
> 
> Python(86100,0x7eab9000) malloc: *** error for object 0x7f94bf9042b8: 
> incorrect checksum for freed object - object was probably modified after 
> being freed.
> 
> 
> Stack Trace samples from Linux (they are all quite similar to eachother with 
> only slight differences in the  addresses):
> 
> 
> *** Error in `python': malloc(): memory corruption: 0x7fa0cc019ba0 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x7dd4d)[0x7fa14f448d4d]
> /lib64/libc.so.6(__libc_malloc+0x4c)[0x7fa14f44afbc]
> /lib64/libstdc++.so.6(_Znwm+0x1d)[0x7fa145c0e0cd]
> /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(_ZNSt6vectorIfSaIfEEaSERKS1_+0xd4)[0x7fa13df58e64]
> /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(+0x12c8a0)[0x7fa13deea8a0]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6df0)[0x7fa150195af0]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7fa150197e3d]
> /lib64/libpython2.7.so.1.0(+0x7088d)[0x7fa15012188d]
> /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x17fd)[0x7fa1501904fd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7fa1501954bd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7fa150197e3d]
> /lib64/libpython2.7.so.1.0(+0x70798)[0x7fa150121798]
> /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3]
> /lib64/libpython2.7.so.1.0(+0x5a8d5)[0x7fa15010b8d5]
> /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7fa1500fc8e3]
> /lib64/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7fa15018e6f7]
> /lib64/libpython2.7.so.1.0(+0x1155c2)[0x7fa1501c65c2]
> /lib64/libpthread.so.0(+0x7dc5)[0x7fa14fe9cdc5]
> /lib64/libc.so.6(clone+0x6d)[0x7fa14f4c276d]
> === Memory map: 
> 0040-00401000 r-xp  fd:00 242126 
> /usr/bin/python2.7
> 0060-00601000 r--p  fd:00 242126 
> /usr/bin/python2.7
> --
> *** Error in `python': malloc(): memory corruption: 0x7f03ac00f640 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x7dd4d)[0x7f04382b6d4d]
> /lib64/libc.so.6(__libc_malloc+0x4c)[0x7f04382b8fbc]
> /lib64/libstdc++.so.6(_Znwm+0x1d)[0x7f042ea7c0cd]
> /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(_ZNSt6vectorIfSaIfEEaSERKS1_+0xd4)[0x7f0426dc6e64]
> /usr/local/lib64/python2.7/site-packages/gnuradio/blocks/_blocks_swig1.so(+0x12c8a0)[0x7f0426d588a0]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x6df0)[0x7f0439003af0]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x7ed)[0x7f0439005e3d]
> /lib64/libpython2.7.so.1.0(+0x7088d)[0x7f0438f8f88d]
> /lib64/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f0438f6a8e3]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x17fd)[0x7f0438ffe4fd]
> /lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x67bd)[0x7f04390034bd]
> 

Re: [Discuss-gnuradio] signal cancellation example using GRC and USRP B210

[CEL]

Hi!
On Sun, 2018-04-29 at 01:17 +0800, Inkyu Bang wrote:
> Dear Marcus
> 
> Thank you for the comments.
> 
> I am trying to make a beam which is canceled out (i.e., null) at a
> specific location but is not elsewhere. 
> 
> I am aware of beamforming and half-wavelength things
> (By the way, a wavelength of 6GHz is 5cm)

ps :D

> So I put two Tx antennas and one Rx antenna in proper locations to
> satisfy the condition which you said (i.e., half wavelength distance
> difference).
> 
> I do not know much about phase offset and USRP hardware things.

So, your two TX chains have an unknown phase offset. You could actually
find that by, for example, sending the very same signal on both
antennas, and measuring the angle of the nulls :)

> 
> Can I ask a few more questions?
> (It might be silly questions.)

No such thing as silly questions!

> 
> I used USRP B210 which has two RF chains and it seems to use the same
> clock for those two RF chains.
> 
> Here is a link to brief specification of B210:
> https://www.ettus.com/content/files/b200-b210_spec_sheet.pdf
> 
> Q1) In this case, is there a chance of different phase offsets
> between two antennas from the same USRP?

Yes, there is. The clock's the same, but not necessarily its phase.

> 
> Q2) Then, how can we calibrate those different phase offsets between
> two antennas in the same USRP?
> (What happens in MIMO transmission in real SDR devices?)

For example, through geometric observation as described above, by some
kind of cable loopback (but that would require phase-length calibrated
cables and some way to switch over to the antennas afterwards), or by
techniques that would send two different (optimally: orthogonal)
signals, one from each TX antenna, and using math after the one RX
antenna to tell the phase difference of these two. A classic for that
would be to use Gold codes, but for your use case, basically any good
pseudorandom bit sequence would do (if you can construct a sufficiently
orthogonal counterpart, but that might be as simple as XOR with
10101010...).

Best regards,
Marcus
> 
> Thank you.
> Regards,
> 
> Inkyu
> 
> 
> 
> > 2018. 4. 27. 오후 10:13, Müller, Marcus (CEL) <muel...@kit.edu> 작성:
> > 
> > Dear Inkyu,
> > 
> > there's no guarantee that the phases of both TX are exactly
> > identical.
> > In fact, you should expect an unknown offset.
> > 
> > Also, you'll notice that your two antennas are at two different
> > positions in the room. You're accidentally building a beamforming
> > system! So, these nulls will not be everywhere in the room, but
> > only in
> > a specific direction in the far field of the TX antenna. And with a
> > carrier frequency of nearly 6 GHz, a wavelength in air is
> > 
> > c/f ≈ (3·10⁸ m/s) / (6·10⁹ 1/s) = 0.05 m = 50 cm
> > 
> > and half that distance from a (single) transmit antenna would be
> > the
> > distance at which two received signals would be exactly of opposite
> > phase.
> > 
> > So, I'm not sure what you want to demonstrate, but unless it's
> > beamforming, you're probably not doing it right :) Which is no
> > shame,
> > but it would be interesting to hear what it is that you want to
> > achieve.
> > 
> > Best regards,
> > 
> > Marcus
> > 
> > On Fri, 2018-04-27 at 20:44 +0800, Inkyu Bang wrote:
> > > Hi, all !!
> > > 
> > > I am trying to make a simple example of signal cancellation using
> > > GRC.
> > > However, I did not get any good results.
> > > 
> > > Here is my setting
> > > 
> > > Plan: sending two sine wave with different phases and receiving
> > > canceled signal (only noise)
> > > Center frequency: 5.89GHz (I am using the antenna supporting this
> > > center frequency)
> > > Sampling rate: 5MHz
> > > Frequency of sine wave: 1kHz
> > > 
> > > USRP: B210
> > > Tx GRC flow graph: signal source block + USRP sink (two channels)
> > > Rx GRC flow graph: USRP sink + QT GUI time sink
> > > 
> > > When I send two sine signals, I used two RF chains in the same
> > > USRP.
> > > I received those signals at the other USRP.
> > > 
> > > I expected to see canceled signals (i.e., only noise level power
> > > in time domain) 
> > > but still, I see sine wave signal.
> > > 
> > > I thought frequency offset in the receiving USRP is applied to
> > > both sine waves.
> > > 
> > > Do I need to consider frequency offset first?
> > > Could anyone help me to solve this problem?
> > > 
> > > Thank you.
> > > Regards,
> > > 
> > > Inkyu
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cannot install gr-burst and gr-eventstream on raspberry pi 3

[CEL]

Hi Ogün,

this might be many things – generally, your Pi might just be running
out of memory during the build, for example (in that case, you'll often
find a hint about the OOM (out-of-memory) killer in `dmesg`; I suspect
memory limits because SWIG is especially hungry for RAM).

make VERBOSE=1

might shed more light, but not necessarily so :(

I'd generally recommend cross-compiling when  building software for an
embedded-style device like the Pi; you wouldn't try to compile software
on your car's embedded computers, either!
It depends on the OS you're using on the Pi how easy that is.

Best regards,
Marcus

On Thu, 2018-01-11 at 14:15 +0300, ogün levent wrote:
> Hi everyone
> I cannot install gr-burst and gr-eventstream to raspberry pi rasbian
> os via cmake. I get these messages during installation
> 
> Best
> 
> [  7%] Building CXX object lib/CMakeFiles/gnuradio-
> burst.dir/synchronizer_v4_impl.cc.o
> [  7%] Building CXX object lib/CMakeFiles/gnuradio-
> burst.dir/qa_helpers.cc.o
> [  7%] Linking CXX shared library libgnuradio-burst.so
> [  7%] Built target gnuradio-burst
> Scanning dependencies of target test-burst
> [  7%] Building CXX object lib/CMakeFiles/test-
> burst.dir/test_burst.cc.o
> [  7%] Building CXX object lib/CMakeFiles/test-
> burst.dir/qa_synchronizer_v4.cc.o
> [  7%] Building CXX object lib/CMakeFiles/test-
> burst.dir/qa_burst.cc.o
> [  7%] Building CXX object lib/CMakeFiles/test-
> burst.dir/qa_helpers.cc.o
> [  7%] Linking CXX executable test-burst
> [  7%] Built target test-burst
> Scanning dependencies of target burst_swig_swig_doc
> [  7%] Built target burst_swig_swig_doc
> Scanning dependencies of target _burst_swig_swig_tag
> [  7%] Building CXX object
> swig/CMakeFiles/_burst_swig_swig_tag.dir/_burst_swig_swig_tag.cpp.o
> [  7%] Linking CXX executable _burst_swig_swig_tag
> [  7%] Built target _burst_swig_swig_tag
> [  7%] Generating burst_swig.tag
> Scanning dependencies of target burst_swig_swig_2d0df
> [  7%] Building CXX object
> swig/CMakeFiles/burst_swig_swig_2d0df.dir/burst_swig_swig_2d0df.cpp.o
> [  7%] Linking CXX executable burst_swig_swig_2d0df
> Swig source
> /home/pi/gr-burst/swig/burst_swig.i:6: Error: Unable to find
> 'mapper/mapper/swig/mapper_swig.i'
> swig/CMakeFiles/burst_swig_swig_2d0df.dir/build.make:134: recipe for
> target 'swig/burst_swig_swig_2d0df' failed
> make[2]: *** [swig/burst_swig_swig_2d0df] Error 1
> make[2]: *** Deleting file 'swig/burst_swig_swig_2d0df'
> CMakeFiles/Makefile2:274: recipe for target
> 'swig/CMakeFiles/burst_swig_swig_2d0df.dir/all' failed
> make[1]: *** [swig/CMakeFiles/burst_swig_swig_2d0df.dir/all] Error 2
> Makefile:138: recipe for target 'all' failed
> make: *** [all] Error 2
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio v3.7.11.6 no attribute to byte array error

[CEL]

Hi Brian,

this came up today already, and seems solved by a patch:

http://lists.gnu.org/archive/html/discuss-gnuradio/2018-01/msg00108.htm
l

Maybe this helps,
best regards,
Marcus

On Wed, 2018-01-17 at 19:00 +, Brian Clark wrote:
> Good evening all,
> 
> I have recently updated my kali linux distribution using the below commands.
> 
> apt-get update
> apt-get upgrade
> apt-get dist-upgrade
> 
> I have a strange error that has occurred within GNU Radio where an error 
> message as shown below appears:
> 
> self.restoreGeometry(self.settings.value("geometry").toByteArray())
> AttributeError: 'NoneType' object has no attribute 'toByteArray'
> 
> When I investigated this it appears that my gnuradio installation has updated 
> from 3.7.11.2 to 3.7.11.6.
> 
> I have attempted, (unsuccesfully) to resolve this issue and neither my own 
> knowledge or multiple google searches have identified the cause.  This is 
> true on a friends of mine build aswell so may be a wider problem.  
> 
> Is there something I am missing? and if so do you have any suggestions?
> 
> Kind Regards
> 
> Brian Clark
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRC: Bus connections updated while the property win is still open?

[CEL]

Hello everyone,

I'm currently debugging a strange spinlooping issue in GRC, which
happened just while I was entering the number of output streams in a
PFB channelizer's property dialog; I've not pressed enter or closed the
dialog.

However, as far as my htop and gdb debugging goes, the code path taken
by python now loops. A significant amount of times it seems to cross
through grc/giui/Port.py:68, create_shapes() and the calling
Element.py, as ultimatively called by grc/gui/FlowGraph.py:477 update()
(typical backtrace att.).

Any pointers on how to further debug this? I feel like update() is
triggered by some change in the output connectors of the block, but the
update() itself causes the output connectors to force an update.

Best regards,
Marcus#0  0x7fe117d1a2ff in _PyType_Lookup (type=0x5571635f3c20, name='_hide_evaluated') at /usr/src/debug/Python-2.7.14/Objects/typeobject.c:2536
#1  0x7fe117d0465c in _PyObject_GenericGetAttrWithDict (obj=, _n= Ron,
> many thanks for your hints. They are very usefull for me.
> 
> But just a question to the gnuradio developers:
> 
> Wouldn't it be appropriate to have some predefined categories.
> Otherwise I expect an uncontrolled growth on categories.
> 
> But at the moment I know, how to proceed.
> 
> Thanks again
> 
> -- Volker
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Lost samples from RTL2832 dongle

[CEL]

Hi John,

my experience, indeed, is that USB passthrough support in VMs is
suboptimal. So, this could very well be a virtual USB host controller
problem.

I'd actually recommend circumventing the issue, e.g. by running rtl_tcp
on the host machine, and using the appropriate source string in the gr-
osmosdr source.

Best regards,
Marcus

On Tue, 2018-01-23 at 12:40 +, john cooper wrote:
> Hello GNU people, some help greatly appreciated.
> 
> I am a newbie to GNU Radio and have a lost samples problem,  lost from the 
> USB 2  RF device, seemingly not in the Flowgraph signal chain.
> 
> Although I have no hard evidence I am coming to the point of suspecting the 
> problem lies with the running of GNU under Oracle VM,  hosted by Win 10.
> 
> Physical RF device is a  DVB-T+DAB+FM USB dongle, with Realtek RTL2832U and 
> the R820 device.
> 
> System is GNU Radio ( latest version )  running as a guest under Oracle VM, 
> hosted by Win 10 Pro on a machine with significant system resources.
> 
> Oracle version is VM 5.2.6r
> 
> Problem is *always* dropped samples from a DVB-T+DAB+FM USB dongle, tens to 
> hundreds of lost samples.
> 
> I have done the following :-
> 
> Added my name to the virtualbox users list.
> 
> added the Virtual Box Extension Pack 5.2.6 to allow USB 2 support in 
> the VM
> 
> Selected USB2 in the Oracle VM machine.
> 
> Blacklisted the RTL2338 DVB-T  driver  via   
> /etc/modprobe.d/blacklist-rtl.confetc.
> 
> Tested with rtl_test with sample speeds from 2.4e6 down to 0.25 e6
> 
> Several Flowgraphs of various example FM broadcast receivers all have 
> choppy audio, believed to be due to lost sample from the RF device via USB2 
> and not seemingly due to mismatch of audio sing sample rates.
> 
> 
> Using only the RTL_SDR source block and Low Pass Filter, plus the WX GUI FFT 
> Sink and the WX GUI Scope Sink, in a FlowGraph produces spikes in the Audio 
> which coincide with the suggested sample losses from the physical dongle.
> 
> 
> Under any and all tests and sample rates the result of rtl_test when ran in 
> the terminal is a continual stream of lost samples.
> 
> 
> Other information;
> 
> running SDR# via the host system ( Win 10 Pro )  is faultless at 2.4e6 sample 
> speed and all lower speeds.
> 
> I have also  installed Gqrx in the VM and this system stalls with the 
> Terminal screen failing to enter the initial set up dialogue screen but does 
> list in the terminal screen the list of parameters, then hangs.
> 
> If anyone has input to the problem, I would be very pleased to hear back and 
> offer my thanks in advance.
> 
> John
> 
> 
>   Virus-free. www.avg.com
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Lost samples from RTL2832 dongle

[CEL]

Ah, and: Choppy audio from low-buffer streaming applications within VMs
is another common issue with many VM hypervisors.
On Tue, 2018-01-23 at 12:44 +, Müller, Marcus (CEL) wrote:
> Hi John,
> 
> my experience, indeed, is that USB passthrough support in VMs is
> suboptimal. So, this could very well be a virtual USB host controller
> problem.
> 
> I'd actually recommend circumventing the issue, e.g. by running rtl_tcp
> on the host machine, and using the appropriate source string in the gr-
> osmosdr source.
> 
> Best regards,
> Marcus
> 
> On Tue, 2018-01-23 at 12:40 +, john cooper wrote:
> > Hello GNU people, some help greatly appreciated.
> > 
> > I am a newbie to GNU Radio and have a lost samples problem,  lost from the 
> > USB 2  RF device, seemingly not in the Flowgraph signal chain.
> > 
> > Although I have no hard evidence I am coming to the point of suspecting the 
> > problem lies with the running of GNU under Oracle VM,  hosted by Win 10.
> > 
> > Physical RF device is a  DVB-T+DAB+FM USB dongle, with Realtek RTL2832U and 
> > the R820 device.
> > 
> > System is GNU Radio ( latest version )  running as a guest under Oracle VM, 
> > hosted by Win 10 Pro on a machine with significant system resources.
> > 
> > Oracle version is VM 5.2.6r
> > 
> > Problem is *always* dropped samples from a DVB-T+DAB+FM USB dongle, tens to 
> > hundreds of lost samples.
> > 
> > I have done the following :-
> > 
> > Added my name to the virtualbox users list.
> > 
> > added the Virtual Box Extension Pack 5.2.6 to allow USB 2 support 
> > in the VM
> > 
> > Selected USB2 in the Oracle VM machine.
> > 
> > Blacklisted the RTL2338 DVB-T  driver  via   
> > /etc/modprobe.d/blacklist-rtl.confetc.
> > 
> > Tested with rtl_test with sample speeds from 2.4e6 down to 0.25 e6
> > 
> > Several Flowgraphs of various example FM broadcast receivers all have 
> > choppy audio, believed to be due to lost sample from the RF device via USB2 
> > and not seemingly due to mismatch of audio sing sample rates.
> > 
> > 
> > Using only the RTL_SDR source block and Low Pass Filter, plus the WX GUI 
> > FFT Sink and the WX GUI Scope Sink, in a FlowGraph produces spikes in the 
> > Audio which coincide with the suggested sample losses from the physical 
> > dongle.
> > 
> > 
> > Under any and all tests and sample rates the result of rtl_test when ran in 
> > the terminal is a continual stream of lost samples.
> > 
> > 
> > Other information;
> > 
> > running SDR# via the host system ( Win 10 Pro )  is faultless at 2.4e6 
> > sample speed and all lower speeds.
> > 
> > I have also  installed Gqrx in the VM and this system stalls with the 
> > Terminal screen failing to enter the initial set up dialogue screen but 
> > does list in the terminal screen the list of parameters, then hangs.
> > 
> > If anyone has input to the problem, I would be very pleased to hear back 
> > and offer my thanks in advance.
> > 
> > John
> > 
> > 
> > Virus-free. www.avg.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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Lost samples from RTL2832 dongle

[CEL]

You'll find instructions at 
https://osmocom.org/projects/sdr/wiki/rtl-sdr#rtl_tcp

On Tue, 2018-01-23 at 12:50 +, john cooper wrote:
> Hello Marcus, good idea, I will research how  to do this and report back. 
> Many thanks. John
> 
> On Tue, 23 Jan 2018, 12:47 Müller, Marcus (CEL), <muel...@kit.edu> wrote:
> > Ah, and: Choppy audio from low-buffer streaming applications within VMs
> > is another common issue with many VM hypervisors.
> > On Tue, 2018-01-23 at 12:44 +, Müller, Marcus (CEL) wrote:
> > > Hi John,
> > >
> > > my experience, indeed, is that USB passthrough support in VMs is
> > > suboptimal. So, this could very well be a virtual USB host controller
> > > problem.
> > >
> > > I'd actually recommend circumventing the issue, e.g. by running rtl_tcp
> > > on the host machine, and using the appropriate source string in the gr-
> > > osmosdr source.
> > >
> > > Best regards,
> > > Marcus
> > >
> > > On Tue, 2018-01-23 at 12:40 +, john cooper wrote:
> > > > Hello GNU people, some help greatly appreciated.
> > > >
> > > > I am a newbie to GNU Radio and have a lost samples problem,  lost from 
> > > > the USB 2  RF device, seemingly not in the Flowgraph signal chain.
> > > >
> > > > Although I have no hard evidence I am coming to the point of suspecting 
> > > > the problem lies with the running of GNU under Oracle VM,  hosted by 
> > > > Win 10.
> > > >
> > > > Physical RF device is a  DVB-T+DAB+FM USB dongle, with Realtek RTL2832U 
> > > > and the R820 device.
> > > >
> > > > System is GNU Radio ( latest version )  running as a guest under Oracle 
> > > > VM, hosted by Win 10 Pro on a machine with significant system resources.
> > > >
> > > > Oracle version is VM 5.2.6r
> > > >
> > > > Problem is *always* dropped samples from a DVB-T+DAB+FM USB dongle, 
> > > > tens to hundreds of lost samples.
> > > >
> > > > I have done the following :-
> > > >
> > > > Added my name to the virtualbox users list.
> > > >
> > > > added the Virtual Box Extension Pack 5.2.6 to allow USB 2 
> > > > support in the VM
> > > >
> > > > Selected USB2 in the Oracle VM machine.
> > > >
> > > > Blacklisted the RTL2338 DVB-T  driver  via   
> > > > /etc/modprobe.d/blacklist-rtl.confetc.
> > > >
> > > > Tested with rtl_test with sample speeds from 2.4e6 down to 0.25 e6
> > > >
> > > > Several Flowgraphs of various example FM broadcast receivers all 
> > > > have choppy audio, believed to be due to lost sample from the RF device 
> > > > via USB2 and not seemingly due to mismatch of audio sing sample rates.
> > > >
> > > >
> > > > Using only the RTL_SDR source block and Low Pass Filter, plus the WX 
> > > > GUI FFT Sink and the WX GUI Scope Sink, in a FlowGraph produces spikes 
> > > > in the Audio which coincide with the suggested sample losses from the 
> > > > physical dongle.
> > > >
> > > >
> > > > Under any and all tests and sample rates the result of rtl_test when 
> > > > ran in the terminal is a continual stream of lost samples.
> > > >
> > > >
> > > > Other information;
> > > >
> > > > running SDR# via the host system ( Win 10 Pro )  is faultless at 2.4e6 
> > > > sample speed and all lower speeds.
> > > >
> > > > I have also  installed Gqrx in the VM and this system stalls with the 
> > > > Terminal screen failing to enter the initial set up dialogue screen but 
> > > > does list in the terminal screen the list of parameters, then hangs.
> > > >
> > > > If anyone has input to the problem, I would be very pleased to hear 
> > > > back and offer my thanks in advance.
> > > >
> > > > John
> > > >
> > > >
> > > > Virus-free. www.avg.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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC: Bus connections updated while the property win is still open?

[CEL]

Hi!
Sorry I forgot to mention that, but: I'm still not sure how to reliably
reproduce; but I'll try your approach as soon as I can.

Best regards,
Marcus

On Tue, 2018-01-23 at 05:50 -0500, Jeff Long wrote:
> You could try removing the bus_structure_source from the GRC file to see if 
> it's somewhere in that logic.
> 
> On Tue, Jan 23, 2018 at 5:37 AM, Müller, Marcus (CEL) <muel...@kit.edu> wrote:
> > Hello everyone,
> > 
> > I'm currently debugging a strange spinlooping issue in GRC, which
> > happened just while I was entering the number of output streams in a
> > PFB channelizer's property dialog; I've not pressed enter or closed the
> > dialog.
> > 
> > However, as far as my htop and gdb debugging goes, the code path taken
> > by python now loops. A significant amount of times it seems to cross
> > through grc/giui/Port.py:68, create_shapes() and the calling
> > Element.py, as ultimatively called by grc/gui/FlowGraph.py:477 update()
> > (typical backtrace att.).
> > 
> > Any pointers on how to further debug this? I feel like update() is
> > triggered by some change in the output connectors of the block, but the
> > update() itself causes the output connectors to force an update.
> > 
> > Best regards,
> > Marcus
> > ___
> > 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

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] fastnoise_source is not thread-safe

[CEL]

Hello Markus,

just to add to the things said:
The (non-fast) noise source in GR has experienced a bit of bugfixing
(but more on a mathematical level: turns out that the built-in random
function GNU Radio used wasn't all that random if one looked for about
10^8 samples)...

I'm currently reading the fastnoise_source block's code, I'm really not
all that sure it's *fast*. I mean, neither `rand()` nor `indirectly
addressing a RAM buffer that's larger than a CPU cache` are really an
indication for speed. The reason why it's still faster than the noise
source is that the distribution shaping happens offline (which means
that probably, our distribution shaping is suboptimal; then again, the
method used in the generation of normally distributed variables can be
found all over the internet, probably because it's the method in
/Numerical Recipes/, and it's a cool method, anyway!).

That having been said, maybe, instead of just fixing fastnoise source
(which we must do, I agree!) only, we might simply want to look into
replacing it by something faster yet threadsafe. I'll whip something up
for benchmarking purposes; XOROSHIRO128+ has an excellent reputation
with respect to both speed and statistical properties, and I'd be
surprised if we couldn't use it to generate both random floats as well
as random integers. Problem, as usual, is that a good random number
generator does not make a good source of (pseudo)continuous or even
just discrete randomness of any given distribution. However, I'm
willing to test a few reference distributions (mainly, Numpy's, because
they're easy to use in tests and hopefully well-tested themselves) for
distributional similarity¹ to the expected distributions, and some
auto- and crosscorrelation tests.

So, hm, how do we do this?

Anyway: Seeing you post on the mailing list lately I'd say it really
can't hurt letting you sign the FSF CRA; I think you'd greatly benefit
of having the possibility to quickly upstream a fix, even if it's
complex. For smaller fixes, a CRA isn't always strictly necessary, but
your friendly maintainer knows more :)

Best regards,
Marcus



¹ seriously, I'll have to restrict myself to a Kolmogorov-Smirnov test,
and maybe Kullback-Leibler divergence considerations. That's all I can
honestly claim to understand well enough to make qualified statements.

On Fri, 2018-01-26 at 00:45 +0100, Markus Wirsing wrote:
> Hello,
> 
> I noticed that the fastnoise_source block is not thread safe, as it
> calls rand(), which keeps global state.
> This makes it non-reproducable between multiple runs once more than one
> such source is used.
> 
> I also opened an issue about this on github:
> https://github.com/gnuradio/gnuradio/issues/1542
> However, there were no reactions to it.
> 
> I'm considering to write a fix for it when I find the time.
> However, I'm not sure about the requirements that need to be met that it
> can later be included in gnuradio.
> 
> Would this already require me to have a CRA?
> I'm also wondering whether C++11 is allowed in gnuradio.
> I guess it is not as I found this message on the mailing list:
> https://lists.gnu.org/archive/html/discuss-gnuradio/2014-06/msg00014.html
> It might be worth mentioning that on the coding guide in the wiki though:
> https://wiki.gnuradio.org/index.php/Coding_guide_impl
> It also might be worth considering to change that rule.
> C++11 is pretty well supported by now. And it does add some nice features.
> 
> I think the easiest fix would be to use random::ran_int() in place of
> rand() or lrand48(). That way it would also be possible to get rid of
> the (slightly) biased method of using a linear congruence to reduce the
> range.
> 
> However, while looking at the code in random.cc
> https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/math/random.cc
> I noticed that it keeps raw pointers to the different random generators.
> I don't see why this is done. If I don't misunderstand anything, it
> would work equally well to have the objects as members in the class.
> With the added benefit of having them correctly deconstructed in the
> case of exceptions. Even though that may not be of much relevance in
> this case.
> But it at least would make sense to use unique pointers instead of raw
> pointers.
> So if I find the time to create a fix for the other problem, would some
> cleanup in this place be appreciated too?
> 
> I have no experience so far with submitting code to open source projects.
> These issues seem to be a good starting point. However, before investing
> time, I want to make sure my work can actually be used.
> 
> Appreciating any feedback on the proposed changes and on the necessary
> formalities,
> Markus
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio 

Re: [Discuss-gnuradio] OOT Module Not Working Properly

[CEL]

Hi Tellrell,

>def forecast(self, noutput_items, ninput_items_required):
>#setup size of input_items[i] for work call
>for i in range(len(ninput_items_required)):
>ninput_items_required[i] = noutput_items

what your forecast does: it tells the GNU Radio runtime that your block
behaves like a sync block. So, you should've probably saved yourself
the hassle of implementing a forecast – and that source of bugs – by
simply using a sync_block instead!

>def general_work(self, input_items, output_items):
>in0 = input_items[0]
>self.seen+=in0.shape[0]

Your logic misses one interesting case:
So, let's say self.num_samples = 1024. Then, let your block have
consumed 1000 items in the last work(), so that now self.seen == 1000.

Now, you're greeted with 1000 new items, self.seen == 2000. However,
let the first threshold-exceeding item be the first one of these 1000
new items (or, the absolute 1001. item). So, that is not an item that
came after the 1024, but before. Still, it counts!

There's a high chance that already your first call gets for example
2048 items. So, your program logic breaks down instantly! Even if all
but the first sample of these 2048 are smaller than your threshold,
your block will trigger :(. 

So, what you want is some kind of very simple state machine:

Let your block have a self.status variable, which can hold different
values. Often, these values are just integers or so from a constants
table, but it could be strings, whatever is unique. What your work()
does depends on which state your block currently has:

Start your block in the STATUS_IDLE state; in that state, you use a
variable that counts the number of items already consumed in that state
(your self.seen).
After consuming **exactly** self.num_samples items (not the whole
noutput_items, just how much is need to make
self.seen==self.num_samples!!), you switch to the STATUS_ARMED state.
Now, you look for samples that exceed your threshold, consume all
samples up to (and including) that one, and then switch back to
STATUS_IDLE (don't forget to reset self.seen).

Best regards,
Marcus

On Fri, 2018-01-12 at 02:47 -0500, Tellrell White wrote:
> Hello Guys
> 
> I'm creating a customized block in the GNU Radio framework using python that 
> takes in a number of input items and once that number of input items 
> surpasses a certain number, 1024 of the input items are taken and stored into 
> an array, and then those items are converted to dB and lastly compared to a 
> threshold value, 5 in this case. If any of the values are greater than the 
> threshold value, a message is printed indicating a signal is present, and if 
> none of the values are greater than 5, this is indicated with a message 
> stating "No signal is present".
> 
> In the flow graph attached, I'm using a cosine source and a gaussian noise 
> source to test my block in two different scenarios. 
> 
> In scenario 1, I run the flow graph with both signal sources and I expect to 
> receive a message stating "A signal is present" because the power of the 
> signal will be greater than the threshold. 
> 
> In scenario 2, the cosine source is disabled and only the noise source is 
> runing. In this scenario I expect to get a message indicating no signal is 
> present because the calculated power will be lower than the threshold.
> 
> Scenario 1 works, however, scenario 2 doesn't work no matter how high I raise 
> the threshold value and, at this point, I'm not quite sure as to why. 
> 
> Any help would be appreciated. Both the .py script for the oot block and the 
> .grc file are included.
> 
> Tellrell 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio