[Discuss-gnuradio] Streaming Live Video

[Mojtaba Mansour Abadi]

Hi Everyone,

Is it possible to stream a live video in GNURadio?

What I want to do is to transmit the video over air (using a pair of USRP)
for demonstration purposes.

Even if the video is from a file, it would be perfect.

Cheers.

-- 
Regards,
Mansour.

https://www.linkedin.com/in/mojtaba-mansour-abadi-4311b451
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Audio issues on BBB

[Usman Haider]

Hi,

I am using GNU Radio on beaglebone black (BBB). I have transmitter and
receiver flowgraph with audio sink audio source. When I run the flowgraphs
on laptop or desktops I receive all the data packets correctly. But when I
run either receiver or transmitter flowgraph on BBB there are intermittent
packet drops. Packet loss is very small but it is there. There are no audio
underruns or audio overruns. I am using a usb sound card with BBB.

I am using jessie 8.6 on BBB, GNU Radio version is 3.7.10.1. Enabled
components are shown below

$ gnuradio-config-info --enabled-components
python-support;testing-support;volk;gnuradio-runtime;gr-blocks;gnuradio-companion;gr-fft;gr-filter;gr-analog;gr-digital;gr-audio;*
alsa;* oss;* jack;*
portaudio;gr-channels;gr-noaa;gr-pager;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq


Have anyone else tried using usb audio sound card on BBB with gnuradio
before? Any idea what could be wrong? Thanks

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

Re: [Discuss-gnuradio] Streaming Live Video

[Julian Arnold]

Hey Mansour,

on the transmit side, you can use vlc for example to stream video to a
Socket PDU block in GNU Radio.
On the receiver side you can do the same but in reverse.
Also, you could use the TUNTAP PDU block for this.

I did it once for a demo using the MAC and PHY form [1].

[1] https://github.com/RWTH-iNets/gr-inets
 
Cheers,
Julian

On 05/29/2017 01:33 PM, Mojtaba Mansour Abadi wrote:
> Hi Everyone,
>
> Is it possible to stream a live video in GNURadio?
>
> What I want to do is to transmit the video over air (using a pair of
> USRP) for demonstration purposes.
>
> Even if the video is from a file, it would be perfect.
>
> Cheers.
>
> -- 
> Regards,
> Mansour.
>
> https://www.linkedin.com/in/mojtaba-mansour-abadi-4311b451
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Julian Arnold, M.Sc.

Institute for Networked Systems
RWTH Aachen University

Kackertstrasse 9
52072 Aachen
Germany


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

[Discuss-gnuradio] Packet based system

[Vamsi Krishna Adsumilli]

Hi,

Is there a way to existing block which sends out data only when packet arrives 
but keeps sending out nothing until then? I expected “PDU to tagged stream” 
block to work that way, but it seems like that block waits for input to fill to 
start sending out stream.

I would like to build something like a packet based system where packet occurs 
only at certain times.

Thanks in advance.

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

Re: [Discuss-gnuradio] Rational Resampler no output.

[Cor Legemaat]

Hi:

 * The only warning is about the thread priority but that's on both.
 * Type "Complex->Complex (Complex Taps)"
 * When using 1 as "taps" there is output.

I can open it in Nemiver if I know where to put the break point...

Regards:
Cor

On Mon, 2017-05-29 at 11:36 +0200, Marcus Müller wrote:
> Hi Cor,
> that's kind of surprising¹. My first bet is that your AMD system is
> missing some dependency that the intel system has, so that something
> goes wrong during build. But then again, you shouldn't be seeing the
> rational resampler block at all in that case. Let's head straight to
> debugging:
> * Do you get any warning/console output during the execution of that
> flow graph?
> * Which is the input/output type (float or complex, orange or blue
> connector in GRC, if using that)
> * If in GRC: when explicitly using [1,] as "taps", do you get output?
> Best regards,
> Marcus
> 
> ¹ "wat?!"
> 
> On 29.05.2017 06:35, Cor Legemaat wrote:
> > Hi:
> > 
> > I have 2 different hardware setup's with funtoo/gentoo and gnuradio
> > installed. On the Intel system the "Rational Resampler" is working
> > correctly but on the AMD system there is no output. This is on a
> > flow
> > graph for an basic wide band fm receiver based on the USPR 10min fm
> > receiver tutorial.
> > 
> > AMD system:
> >  * AMD FX(tm)-8150 Eight-Core Processor
> >  * CPU_FLAGS_X86="aes avx fma4 mmx mmxext popcnt sse sse2 sse3
> > sse4_1 sse4_2 sse4a ssse3 xop"
> > 
> > Intel system:
> >  * Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz
> >  * CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1
> > sse4_2
> >    ssse3"
> > 
> > Tried with different versions of GNURadio and gcc but the same
> > symptoms, both systems is compiled with CFLAGS="-march=native -O2
> > -pipe". At the moment it is gcc:6.3.0  and net-wireless/gnuradio-
> > 3.7.11:0/3.7.11  USE="alsa analog atsc audio channels digital doc
> > dtv
> > examples fec filter grc noaa pager performance-counters portaudio
> > qt4
> > uhd utils vocoder wavelet wxwidgets zeromq -fcd -jack -log -oss
> > -sdl {-
> > test} -trellis" PYTHON_TARGETS="python2_7"
> > 
> > Where do I start to search?
> > 
> > Regards:
> > Cor
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  


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

Re: [Discuss-gnuradio] IEEE 802.11 receiver not working for high sampling rates

[Qurat-Ul-Ann Akbar]

Hi,

As Marcus suggested, I put a frequency sink directly to the receiver to
look at the signal. Both at 1 MHz and 10 MHz the signal is noisy. The power
is around -120 to -100 db. However, in the case of 1 MHZ all packets sent
by the USRP transmitter are received correctly with almost negligible
packet error rate. However at 10 MHZ nothing is received. There are no over
or under runs. Why would it stop working at anything above 1 MHz ?

What could be the reason for this ?

On May 26, 2017 11:03 AM,  wrote:

> How can I change that in that USRP N210? And how do you think it's
> affecting the transmission.
>
> Thank you .
>
> On May 25, 2017 1:27 PM, "sakthivel velumani"  wrote:
>
>> What is the update rate of DAC in transmitter side? Try increasing it.
>>
>> On Thu, May 25, 2017 at 5:43 PM, Qurat-Ul-Ann Akbar <
>> quratulannakbar2...@u.northwestern.edu> wrote:
>>
>>> Hi,
>>>
>>> I am working with USRPs N210 and GNU Radio version 3.7. I wasn't able to
>>> work with higher sampling rate like 20 MHZ used in WiFi and that's why I
>>> bought a new workstation with better processor. However, the module still
>>> isn't working. The receiver isn't receiving anything at 20 MHZ if it's QAM
>>> 64 or BPSK . It works perfectly fine with 1 MHZ and receives all data from
>>> the transmitter USRP. But at 20 MHZ it receives a few WiFi packets from
>>> surrounding far off APs in the building but isn't receiving anything from
>>> the USRP transmitter in the room. It doesn't work for 10 MHZ as well.
>>>
>>> Can anyone tell me what could be the reason for that? I have tried
>>> changing LO offset etc.
>>>
>>>
>>>
>>> ___
>>> 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] NEWSDR -- This Thursday/Friday at Tufts University

[Neel Pandeya]

*
CALL-FOR-PARTICIPATION

*
NEWSDR 2017

  New England Workshop on Software Defined Radio

   Seventh-Annual

  Evening Workshops
   Thursday June 1
   17:30 to 21:00

  Day-Long Symposium
   Friday June 2
   08:00 to 16:00

  Tufts University
  Medford, MA, USA

  http://www.sdr-boston.org/

 Free Pre-Registration

*
 INVITATION TO PARTICIPATE

You are cordially invited to the 2017 New England Workshop on
Software Defined Radio (NEWSDR 2017), which is the seventh installment
of an annual series of symposium and workshop events organized by
the Boston SDR User Group (SDR-Boston).

This year, NEWSDR will be held at Tufts University, and consists of
a day-long symposium on Friday, as well as several hands-on technical
workshops the evening before on Thursday. You are welcome to attend
either or both events, which are entirely free when pre-registering.

Attendance is typically about 100 people, and attendees are evenly
split between academia and industry.

*
 EVENING WORKSHOPS

  THURSDAY JUNE 1
   17:00 to 21:00

  Tufts University
   Medford, Massachusetts

  AGENDA

16:00 – 17:30  Setup session for the Workshop Events (optional)

17:30 – 21:00  Workshop Events

Two hands-on technical workshops are being offered in parallel:

* "SDR Using USRP E310 and Simulink"
  by MathWorks

* "FPGA Programming on the USRP with the RFNoC Framework"
  by Ettus Research

MathWorks and Ettus Research will each run a workshop on the evening
before the main event. Workshops are technical, practical, hands-on
activities in a group setting. Specific topics and further details
about the workshops is listed below. Attendance is free, but
pre-registration is required. Free pizza and soda will be provided.

*
 DAY-LONG SYMPOSIUM

   FRIDAY JUNE 2
   08:00 to 16:00

Breed Memorial Hall
 Tufts University
51 Winthrop Street
   Medford, Massachusetts

  AGENDA

07:30 to 08:00  Coffee and Light Refreshments

08:00 to 08:15  Welcome and Introduction

08:15 to 09:40  Sponsor Overview Presentations (20 minutes each)

09:40 to 10:15  Elevator-Pitch Oral Presentations
of Poster Presenters (2 minutes each)

10:15 to 10:45  Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits, and Demos

10:45 to 11:45  Industry Tutorial Presentation by MediaTek USA:
"Prototyping Next Generation Wireless Devices"

11:45 to 13:00  Lunch and Attendee Networking

13:00 to 14:00  Keynote Presentation by Professor Dennis Roberson

14:00 to 14:30  Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits, and Demos

14:30 to 15:30  Industry Tutorial Presentation by Analog Devices:
"ADALM-PLUTO SDR Prototyping with Matlab"

15:30 to 16:00  Closing Remarks, Best Poster Award, Announcements

Keynote Speaker:
  * Professor Dennis Roberson, Illinois Institute of Technology

Technical Poster Presentations:
  *  Covering the recent work in SDR and cognitive radio technology
  *  Poster presentations are now being solicited
  *  See link at the bottom of this email to submit your abstract

Corporate Sponsors:
  *  Analog Devices
  *  Ettus Research
  *  MathWorks
  *  MediaTek USA

The symposium features plenary speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and workshops from the event sponsors, all focusing
on recent work in SDR and cognitive radio technology. Free breakfast,
lunch, and coffee will be provided. Attendance is free, but advance
registration is required.

The symposium provides an excellent networking opportunity and a
terrific venue to exchange thoughts and ideas with other people
working in the SDR space.

*
   WORKSHOP DESCRIPTION

   SDR with E310 using Simulink
MathWorks

This tutorial focuses on demonstrating modeling SDR-based designs in
MATLAB and Simulink, and c

Re: [Discuss-gnuradio] Python block help

[Marcus Müller]

Hi Zach,


On 29.05.2017 22:57, Zach Morris wrote:
> Hi Marcus,
>
> Sorry about the trouble with Nabble, I see that my code got cut off. I
> will communicate via the mailing list from now on.
>
> If I understand your explanation correctly, the forecast function
> below tells the scheduler that this block needs at least noutput_items
> on each input port in order to produce noutput_items. In actuality, my
> arbitrary ratio block would produce anywhere between (0,
> noutput_items); would this be a valid implementation of forecast() for
> my arbitrary ratio block?
> def forecast(self, noutput_items, ninput_items_required):
> for i in range(len(ninput_items_required)):
>  ninput_items_required[i] = noutput_items
>
yes, that would tell the scheduler that you'll need at least
noutput_items input items to produce noutput_items output items, indeed!

Now, the forecast really is just that: a forecast. If you can't produce
as many samples as promised, the scheduler won't be upset.
>
> This is my general_work() function right now: it just outputs the
> elements in the input vector that are above a threshold. My eventual
> goal is to receive a vector from an FFT and update statistics for each
> frequency 'bin' as long as its power is above a threshold, then output
> the statistics when its power drops below the threshold.

> def general_work(self, input_items, output_items):
>  in0 = input_items[0][:len(output_items[0])]
This is **only** OK if you check that len(output_items[0]) <=
len(input_items[0]). You inherently do that with your forecast, but I'd
really recommend explicitly checking that condition.
Also, this the following code is really very redundant:
>  out0 = output_items[0]
>  ninput_items = len(in0)
well, you set in0 to be of len(output_items[0]).
>
>  j = 0
>  for i in range(0, ninput_items):
this is very un-pythonic.
>  if (in0[i] > self.threshold).all(): 
>  out0[j] = in0[i]
>   j += 1
>
I'd just say:

def general_work(self, input_items, output_items):
super_threshold = filter(lambda x: x > self.threshold, in[0])
output_items[0][:] = super_threshold
self.consume_each(len(super_threshold))
return len(super_threshold)

Best regards,
Marcus

>  self.consume(0, ninput_items)
>  self.produce(0, j)
>
>  return 0
>
> If I again understand your explanation, the 'self.consume(0,
> ninput_items)' is correct, because I 'use up' the elements of
> input_items on each loop. However, it sounds like I should either
> return WORK_CALLED_PRODUCE or return ninput_tems. Am I on the right
> track here? Is there a reason to prefer produce() over just returning
> the number of input items I consume?
>
> Thank you for your help.
>
> Zach
>
>
> On Sun, May 28, 2017 at 1:31 PM, Marcus Müller
> mailto:marcus.muel...@ettus.com>> wrote:
>
> Hi Zach,
>
> sorry it took me so long to react:
> so, let's dissect a few things:
>
> First, the general purposes of these functions:
>
> * forecast() is called by the *scheduler* to ask your block "hey,
> if I'd
> need you to produce N items, how much would you need on your 0.
> (and 1.,
> and 2.,… if existing) input for that?". The scheduler usually
> repeatedly
> calls that with a decreasing N until the number of samples your block
> requires can be fulfilled by the number of input items that the
> scheduler has ready. If that never happens, usually, something is
> broken.
>
> * consume() is something that *you* call from within a
> (general_)work()
> to signal the scheduler how many items you've consumed from the
> input(s).
>
> * produce() is something that *you* call from within a
> (general_)work()
> to signal the scheduler how many items you've put into the output
> buffer. *If* you use produce, you should return the magic
> WORK_CALLED_PRODUCE values. You usually don't call produce() – you
> just
> return the number of consumed samples instead.
>
> * noutput_items is **not** a variable that you set – it's the info how
> many items you are asked to produce (parameter to forecast()) or how
> many items you're **allowed at most** to produce (when it's the
> parameter to a (general_)work())
>
> Again, the better parts of your mail have been broken by Nabble.
> Abandon
> Nabble. Subscribe directly:
>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>
> Hope that helps,
> Marcus
>
> On 05/26/2017 07:49 PM, Zach Morris wrote:
> > That worked to create a general block, but I'm still having some 
> trouble with
> > implementing the forecast(), consume() and produce() functions.
> >
> > The goal of the block is to discard elements in an input vector
> that are
> > below a certain threshold, and eventually update some statistics
> based on
> > the remaining eleme

Re: [Discuss-gnuradio] Rational Resampler no output.

[Marcus Müller]

Hi Cor,

>  * When using 1 as "taps" there is output.
Aha!!
So, here's the thing: something might be going wrong in the python code
that sets up the taps automatically if you don't set them explicitly.
Maybe you can figure out where things go wrong; the interesting part
(maybe add some `print`s here?) from [1]:

# If we don't have user-provided taps, reduce the interp and
# decim values by the GCD (if there is one) and then define
# the taps from these new values.
if taps is None:
interpolation = interpolation // d
decimation = decimation // d
taps = design_filter(interpolation, decimation, fractional_bw)

and


def design_filter(interpolation, decimation, fractional_bw):
"""
Given the interpolation rate, decimation rate and a fractional
bandwidth,
design a set of taps.

Args:
interpolation: interpolation factor (integer > 0)
decimation: decimation factor (integer > 0)
fractional_bw: fractional bandwidth in (0, 0.5)  0.4 works well.
(float)
Returns:
: sequence of numbers
"""

if fractional_bw >= 0.5 or fractional_bw <= 0:
raise ValueError, "Invalid fractional_bandwidth, must be in (0,
0.5)"

beta = 7.0
halfband = 0.5
rate = float(interpolation)/float(decimation)
if(rate >= 1.0):
trans_width = halfband - fractional_bw
mid_transition_band = halfband - trans_width/2.0
else:
trans_width = rate*(halfband - fractional_bw)
mid_transition_band = rate*halfband - trans_width/2.0

taps = filter.firdes.low_pass(interpolation, # gain
  interpolation, # Fs
  mid_transition_band,   #
trans mid point
  trans_width,   #
transition width
  filter.firdes.WIN_KAISER,
  beta)  # beta

return taps



Best regards,
Marcus

[1]
https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python/filter/rational_resampler.py

On 29.05.2017 19:01, Cor Legemaat wrote:
> Hi:
>
>  * The only warning is about the thread priority but that's on both.
>  * Type "Complex->Complex (Complex Taps)"
>  * When using 1 as "taps" there is output.
>
> I can open it in Nemiver if I know where to put the break point...
>
> Regards:
> Cor
>
> On Mon, 2017-05-29 at 11:36 +0200, Marcus Müller wrote:
>> Hi Cor,
>> that's kind of surprising¹. My first bet is that your AMD system is
>> missing some dependency that the intel system has, so that something
>> goes wrong during build. But then again, you shouldn't be seeing the
>> rational resampler block at all in that case. Let's head straight to
>> debugging:
>> * Do you get any warning/console output during the execution of that
>> flow graph?
>> * Which is the input/output type (float or complex, orange or blue
>> connector in GRC, if using that)
>> * If in GRC: when explicitly using [1,] as "taps", do you get output?
>> Best regards,
>> Marcus
>>
>> ¹ "wat?!"
>>
>> On 29.05.2017 06:35, Cor Legemaat wrote:
>>> Hi:
>>>
>>> I have 2 different hardware setup's with funtoo/gentoo and gnuradio
>>> installed. On the Intel system the "Rational Resampler" is working
>>> correctly but on the AMD system there is no output. This is on a
>>> flow
>>> graph for an basic wide band fm receiver based on the USPR 10min fm
>>> receiver tutorial.
>>>
>>> AMD system:
>>>  * AMD FX(tm)-8150 Eight-Core Processor
>>>  * CPU_FLAGS_X86="aes avx fma4 mmx mmxext popcnt sse sse2 sse3
>>> sse4_1 sse4_2 sse4a ssse3 xop"
>>>
>>> Intel system:
>>>  * Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz
>>>  * CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1
>>> sse4_2
>>>ssse3"
>>>
>>> Tried with different versions of GNURadio and gcc but the same
>>> symptoms, both systems is compiled with CFLAGS="-march=native -O2
>>> -pipe". At the moment it is gcc:6.3.0  and net-wireless/gnuradio-
>>> 3.7.11:0/3.7.11  USE="alsa analog atsc audio channels digital doc
>>> dtv
>>> examples fec filter grc noaa pager performance-counters portaudio
>>> qt4
>>> uhd utils vocoder wavelet wxwidgets zeromq -fcd -jack -log -oss
>>> -sdl {-
>>> test} -trellis" PYTHON_TARGETS="python2_7"
>>>
>>> Where do I start to search?
>>>
>>> Regards:
>>> Cor
>>>
>>>
>>> ___
>>> 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] gr-fec

[Cinaed Simson]

There appears to be a bug in version 3.7.11 of gr-fec.

I was on poking around on my netbook this weekend - trying to run some
polar grc examples - but I couldn't load any of the polar flow graphs -
they would hang the grc - I had to kill grc to get out.

But

  make test

ran without any errors.

I tried running

  qa_polar_decoder_sc.py

but it gave me the

  ImportError: No module named fec_swig

To make a long story, in order for me to get

  qa_polar_decoder_sc.py

to run - plus a couple of other scripts which were needed, I had to
replace

   import fec_swig as fec

with

  from gnuradio import fec
  import _fec_swig as fec_swig

I did a find on

  /lib/python2.7/dist-packages/gnuradio

and located the following files

  fec_swig.py
  _fec_swig.so

and then played around with them until I got it to work.

-- Cinaed





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

Re: [Discuss-gnuradio] Audio issues on BBB

[Cinaed Simson]

On 05/29/2017 04:49 AM, Usman Haider wrote:
> Hi,
> 
> I am using GNU Radio on beaglebone black (BBB). I have transmitter and
> receiver flowgraph with audio sink audio source. When I run the
> flowgraphs on laptop or desktops I receive all the data packets
> correctly. But when I run either receiver or transmitter flowgraph on
> BBB there are intermittent packet drops. Packet loss is very small but
> it is there. There are no audio underruns or audio overruns. I am using
> a usb sound card with BBB.
> 
> I am using jessie 8.6 on BBB, GNU Radio version is 3.7.10.1. Enabled
> components are shown below
> 
> $ gnuradio-config-info --enabled-components
> python-support;testing-support;volk;gnuradio-runtime;gr-blocks;gnuradio-companion;gr-fft;gr-filter;gr-analog;gr-digital;gr-audio;*
> alsa;* oss;* jack;*
> portaudio;gr-channels;gr-noaa;gr-pager;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui;gr-zeromq
> 
> 
> Have anyone else tried using usb audio sound card on BBB with gnuradio
> before? Any idea what could be wrong? Thanks
> 
> -- 
> Usman

If you're using jessie, wheezy or ubuntu,

  apt-get install cpufrequtils

and set the frequency of the CPU - or the governor to 'performance' - if
you haven't done so already.

It installs the cpufreq-info and cpufreq-set programs. I forget how to
use them.

It might not be your problem - check your memory usage - if you have
swap you might be thrashing.

I can't remember if I used the USB sound card on the BBB - or on the
Odroid. I have a HDMI monitor with speakers so I haven't use the USB
sound card for awhile.

Check to see if pulse audio is installed

  apt list --installed | grep pluseaudio

-- Cinaed

> 
> 
> ___
> 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] gr-fec

[lists]

This isn't exactly the problem I was having since the polar tests failed for 
me. But as soon as the code is patched I will do a build and see if my problems 
go away. 

At one time the polar tests passed on Opensuse for me , but to be fair it was 
on a different build of Opensuse 42.2. (Long story short, bttrfs wasn't better, 
and I had to do some hacks to neuter it, so I decided to do a fresh OS 
installation. )


  Original Message  
From: Cinaed Simson
Sent: Monday, May 29, 2017 10:05 PM
To: GNURadio Discussion List
Subject: [Discuss-gnuradio] gr-fec

There appears to be a bug in version 3.7.11 of gr-fec.

I was on poking around on my netbook this weekend - trying to run some
polar grc examples - but I couldn't load any of the polar flow graphs -
they would hang the grc - I had to kill grc to get out.

But

make test

ran without any errors.

I tried running

qa_polar_decoder_sc.py

but it gave me the

ImportError: No module named fec_swig

To make a long story, in order for me to get

qa_polar_decoder_sc.py

to run - plus a couple of other scripts which were needed, I had to
replace

import fec_swig as fec

with

from gnuradio import fec
import _fec_swig as fec_swig

I did a find on

/lib/python2.7/dist-packages/gnuradio

and located the following files

fec_swig.py
_fec_swig.so

and then played around with them until I got it to work.

-- Cinaed





___
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