Re: [Discuss-gnuradio] Trouble installing gr-baz

[Cinaed Simson]

On 06/04/2017 05:04 PM, Brandon Lester wrote:
> I am having issues getting some components installed for gnuradio. I am
> trying to install gr-baz and op25.
> 
> My OS is Debian 8, and I installed gnuradio from the standard repository
> with
> 
> sudo apt-get build-dep gnuradio
> sudo apt-get install gnuradio gnuradio-dev gr-osmosdr librtlsdr-dev
> libuhd-dev  libhackrf-dev libitpp-dev libpcap-dev

You can't have 2 different installs of gnuradio unless you know what
you're doing and your careful.

Type

   apt-get purge gnuradio gnuradio-dev gr-osmosdr librtlsdr-dev
libuhd-dev  libhackrf-dev

Blow away the the pybombs install directory and then try again with
pybombs.

I would recommend using the prefix /usr/local/gnuradio, i.e., in it's
own independent directory.

Then find the lastest sources for the hardware libraries for the SDRs
you're planning on running - and ensure you have the latest firmware
installed on the devices and the libraries match the fireware.

gr-baz will compile under 3.7.11.1 but then you will need to find a
script which will translate the gr-baz blocks to version 3.7.11.1 of
gnuradio.

You probably don't want to take the route from gr-baz to OP25 - try

  https://github.com/robotastic/trunk-recorder

instead.

-- Cinaed


> 
> I then cloned the gr-baz from github, and did cmake and make. Make
> failed with the following:
> 
> [ 58%] Building CXX object
> lib/CMakeFiles/gnuradio-baz.dir/baz_dpll_bb.cc.o
> /home/brandon/gnuradio/gr-baz/lib/baz_dpll_bb.cc: In member function
> ‘virtual int gr::baz::dpll_bb_impl::work(int,
> gr_vector_const_void_star&, gr_vector_void_star&)’:
> /home/brandon/gnuradio/gr-baz/lib/baz_dpll_bb.cc:245:85: error:
> ‘from_float’ is not a member of ‘pmt’
>  add_item_tag(0, nitems_written(0)+i,
> pmt::mp("current_period"), pmt::from_float(current_period));
>
>  ^
> lib/CMakeFiles/gnuradio-baz.dir/build.make:813: recipe for target
> 'lib/CMakeFiles/gnuradio-baz.dir/baz_dpll_bb.cc.o' failed
> make[2]: *** [lib/CMakeFiles/gnuradio-baz.dir/baz_dpll_bb.cc.o] Error 1
> CMakeFiles/Makefile2:106: recipe for target
> 'lib/CMakeFiles/gnuradio-baz.dir/all' failed
> make[1]: *** [lib/CMakeFiles/gnuradio-baz.dir/all] Error 2
> Makefile:127: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> 
> I checked the source of gnuradio on github, and from_float is indeed
> defined in pmt. The version of gnuradio-companion that is installed is
> version 3.7.5. I added the full output from make as an attachment.
> 
> I also tried with pybombs, but couldn't get pybombs to run at all.
> Simply trying to add a recipe to pybombs caused a very long stack trace
> of errors.
> 
> Any help/guidance is appreciated
> -- 
> Brandon
> 
> 
> 
> ___
> 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] Audio issues on BBB

[Cinaed Simson]

On 05/31/2017 03:36 AM, Philip Balister wrote:
> On 05/29/2017 07: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
> 
> Try using perf top to get an idea where the flowgraph hot spots are. The
> BBB is a single core arm, so there isn't much processing power.

Post your flow chart.

Does the sound card work as a sound card on the BBB - can you play a
wave or mp3 file witout any issues?

> 
> Philip
> 
> 
>>
>>
>>
>> ___
>> 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] GNU Radio Coverity statis analysis

[Philip Balister]

As part of some GNU Radio infrastructure work, the Coverity static
analyses is running again. Thanks guys!

https://scan.coverity.com/projects/gnuradio

This is a great way to find places the code needs some work and a good
way to start contributing to the project. Go ahead and take a look!

Philip

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

[Discuss-gnuradio] why can't use iwconfig when I run the gr-ieee802-11

[zhan siyu]

Hi all,

I just found I can't use the iwconfig tap0 rate 20M to setup the bandwidth
of the tap0. The error message is :

Error for wireless request "Set Bit Rate" (8B20) :
 SET failed on device tap0 ; Operation not supported.

But in their video , it can be set in this way. May I know how to solve it ?

Many thanks.

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

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

[Benny Alexandar]

Hi Luca,


Nice to see your progress so far. Once you have the
DAB receiver audio listening in place, I would
suggest to have an audio synchronization for continuous
playback without any buffer overflow or under-runs.

DAB+ audio super frame length is 120ms according to DAB+
standard (ETSI TS 102 563). Each audio super frame is
carried in five consecutive logical DAB frames.
Which means 120ms of audio is mapped to 5 DAB frames.

If I add a timestamp at the receiver when the first DAB frame
sample arrives, I can check the max latency when it comes to
audio renderer, I mean after buffering to adjust the variable
decoding time of compressed audio.

t_D = t_A -  t_B ,
where,
 t_A = time at audio out
 t_B = time at input baseband sample.
 t_D = maximum system delay.

The difficulty is to estimate the slow clock drift correctly
and separate it from the short-time channel/decoding jitter.

Add a delay to buffer audio at audio out, say  D, which is larger
than max system delay. Whenever the audio reaches audio out, check the
delay to separate the clock drift.

 drift = t_D - D

Please let me know if you need any more details.

-ben













From: Discuss-gnuradio  
on behalf of Moritz Luca Schmid 
Sent: Friday, May 26, 2017 6:19:31 PM
To: GNURadio Discussion List
Subject: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week


Hi everyone,

I just published my latest updates of my DAB project in a new blog 
post.

This week, I created a source block for the Fast Information Channel and 
started to build a reception chain for the Main Service Channel (where the 
audio data is transmitted).

Read more about it in my post.


Cheers

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

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

[Marcus Müller]

Hi ben,


I love this topic of how to match hardware clocks just as much as you
do, but I personally think that solving the two-clock problem between an
SDR receiver and an audio device might be just a tiny bit out of scope
of a GSoC project on a broadcast standard implementation. Also, it's not
part of the milestones / deliverables that Luca set in cooperation with
the community, and a considerable effort, so I don't think I'd advise
Luca to do that;
however, I'd really like to see this happening in another context. Maybe
we can help /you/ get that working, preferably with an analog audio
modulation first? Also, haven't we been talking about this extensively
before? I don't see how the fact that your PC simply can't, with
sufficient accuracy, measure what you call t_A for this approach to work
without much higher-level tracking has changed. But that's a discussion
that we really shouldn't be having (again) within the context of an
unrelated GSoC project.


background: in digital mod, you have to recover the TX sample clock,
anyway, and then this problem boils down to matching the studio's audio
sample rate to your soundcard's sample rate.

Studio equipment typically has rather good oscillators (I think: better
than 10ppm offset), and even the cheapest USB codec from Texas
Instruments advises you to use a <=25ppm oscillator. That leads to a
total worst-case rate offset of 35 ppm; with an 48 kHz sample clock,
that's an offset of about 0.6 Hz, or one sample every 1.68 s. Thus, meh,
assume your ALSA does 1024-sample periods, it'd take some half hour for
a single frame to go missing or accumulate. And that's not even when you
get an issue. It's just the first point that you'd actually be able to
count things worthy of being sent to the audio driver not being the
number that would be correct.


In analog audio modulation, you don't get the benefit of anything that
inherently transports the transmitter's sampling clock, and thus, your
SDR's frequency error can't be corrected.


Best regards,

Marcus


On 06.06.2017 18:02, Benny Alexandar wrote:
>
> Hi Luca,
>
>
> Nice to see your progress so far. Once you have the
> DAB receiver audio listening in place, I would
> suggest to have an audio synchronization for continuous
> playback without any buffer overflow or under-runs.
>
> DAB+ audio super frame length is 120ms according to DAB+
> standard (ETSI TS 102 563). Each audio super frame is
> carried in five consecutive logical DAB frames.
> Which means 120ms of audio is mapped to 5 DAB frames.
>
> If I add a timestamp at the receiver when the first DAB frame
> sample arrives, I can check the max latency when it comes to
> audio renderer, I mean after buffering to adjust the variable
> decoding time of compressed audio.
>
> t_D = t_A -  t_B ,
> where,
>  t_A = time at audio out
>  t_B = time at input baseband sample.
>  t_D = maximum system delay.
>
> The difficulty is to estimate the slow clock drift correctly
> and separate it from the short-time channel/decoding jitter.
>
> Add a delay to buffer audio at audio out, say  D, which is larger
> than max system delay. Whenever the audio reaches audio out, check the
> delay to separate the clock drift.
>
>  drift = t_D - D
>
> Please let me know if you need any more details.
>
> -ben
> 
>
>
>
>  
>
>  
>  
>  
>  
>
> 
> *From:* Discuss-gnuradio
>  on behalf of
> Moritz Luca Schmid 
> *Sent:* Friday, May 26, 2017 6:19:31 PM
> *To:* GNURadio Discussion List
> *Subject:* [Discuss-gnuradio] [GSoC 17] DAB: updates of the week
>  
>
> Hi everyone,
>
> I just published my latest updates of my DAB project in a new blog
> post .
>
> This week, I created a source block for the Fast Information Channel
> and started to build a reception chain for the Main Service Channel
> (where the audio data is transmitted).
>
> Read more about it in my post.
>
>
> Cheers
>
> Luca
>
>
>
> ___
> 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] ninput_items_required=1024

[G Reina]

I'm creating a Python block that calculates a custom FFT. I need to ensure
that I get at least 1024 data points for every input to the block.

>From my reading, it looks like I should just be able to do this with the
forecast() function in the Python block. So I've done this:

class blk(gr.sync_block):  # other base classes are basic_block,
> decim_block, interp_block
>
> def __init__(self, bandWidthMHz=100.0):  # only default arguments here
> """arguments to this function show up as parameters in GRC"""
> gr.sync_block.__init__(
> self,
> name='test',   # will show up in GRC
> in_sig=[np.complex64],
> out_sig=[np.float32]
>)
> # if an attribute with the same name as a parameter is found,
> # a callback is registered (properties work, too).
> self.bandWidthMHz = bandWidthMHz
> self.MM = 0
>
> def forecast(self, noutput_items, ninput_items_required=1024):
> ninput_items_required[0] = 1024
>
> def work(self, input_items, output_items):
> if (np.shape(input_items[0])[0] < 1024):
> print(np.shape(input_items[0]))
> output_items[0] = [3.5, -1, 0, 1]
> return len(output_items[0])
>

According to the docs, if I set ninput_items_required[0] = 1024, then
forecast should prevent the work from being done until I have at least 1024
input values.

Nevertheless, the print statement I have in the work function is showing
that the program gets to the work even when the input_items[0] is much less
(e.g. 24, 102, 960) than 1024.

Can anyone point me in the right direction? Can I just have the work
function skip execution if len(input_items[0]) < 1024? Or, will that drop
data?

Thanks for your help.
-Tony

p.s. I'm just doing this in a Python block from the GRC. So this is not a
custom OOT module. Does that matter?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ninput_items_required=1024

[G Reina]

I may have just answered it. I change the sync_block to a basic_block and
it seems to be working.

-Tony


On Tue, Jun 6, 2017 at 11:12 AM, G Reina  wrote:

> I'm creating a Python block that calculates a custom FFT. I need to ensure
> that I get at least 1024 data points for every input to the block.
>
> From my reading, it looks like I should just be able to do this with the
> forecast() function in the Python block. So I've done this:
>
> class blk(gr.sync_block):  # other base classes are basic_block,
>> decim_block, interp_block
>>
>> def __init__(self, bandWidthMHz=100.0):  # only default arguments here
>> """arguments to this function show up as parameters in GRC"""
>> gr.sync_block.__init__(
>> self,
>> name='test',   # will show up in GRC
>> in_sig=[np.complex64],
>> out_sig=[np.float32]
>>)
>> # if an attribute with the same name as a parameter is found,
>> # a callback is registered (properties work, too).
>> self.bandWidthMHz = bandWidthMHz
>> self.MM = 0
>>
>> def forecast(self, noutput_items, ninput_items_required=1024):
>> ninput_items_required[0] = 1024
>>
>> def work(self, input_items, output_items):
>> if (np.shape(input_items[0])[0] < 1024):
>> print(np.shape(input_items[0]))
>> output_items[0] = [3.5, -1, 0, 1]
>> return len(output_items[0])
>>
>
> According to the docs, if I set ninput_items_required[0] = 1024, then
> forecast should prevent the work from being done until I have at least 1024
> input values.
>
> Nevertheless, the print statement I have in the work function is showing
> that the program gets to the work even when the input_items[0] is much less
> (e.g. 24, 102, 960) than 1024.
>
> Can anyone point me in the right direction? Can I just have the work
> function skip execution if len(input_items[0]) < 1024? Or, will that drop
> data?
>
> Thanks for your help.
> -Tony
>
> p.s. I'm just doing this in a Python block from the GRC. So this is not a
> custom OOT module. Does that matter?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[John Ackermann N8UR]

I don't have a view whether an audio synchronizer (is that the right 
term?) is appropriate for GSoC, but it's a problem that's biting me 
right now.  I'm doing a multi-channel nbfm receiver with a polyphase 
channelizer that feeds a bunch of power squelch/nbfm demod blocks, with 
the audio streams added together, rationally resampled to theoretically 
48kHz, and then fed to an audio sink.


With this setup, I seem to have two choices:  (a) I can tell the audio 
sink to block, in which case I get nice clean audio but latency of about 
5 seconds, or (b) I can say not to block, in which case I get much less 
latency but also many aU underruns and audio that's very choppy.


I wonder if I am suffering from rounding or truncation errors that's 
causing the demod rate to not be quite what it should be.


It seems that there would be use for a block that provides a combination 
of buffering and a loop to measure input and consumption rates and steer 
a rational resampler to correct for mismatch.  I have no idea whether 
that would be easy, hard, or infeasible to implement.


(If you're interested in the app, the current under-development version 
is at 
https://github.com/TAPR/N8UR_GnuRadio/blob/master/multi_fm/nbfm_27ch.grc)


John



On 06/06/2017 01:10 PM, Marcus Müller wrote:

Hi ben,


I love this topic of how to match hardware clocks just as much as you
do, but I personally think that solving the two-clock problem between an
SDR receiver and an audio device might be just a tiny bit out of scope
of a GSoC project on a broadcast standard implementation. Also, it's not
part of the milestones / deliverables that Luca set in cooperation with
the community, and a considerable effort, so I don't think I'd advise
Luca to do that;
however, I'd really like to see this happening in another context. Maybe
we can help /you/ get that working, preferably with an analog audio
modulation first? Also, haven't we been talking about this extensively
before? I don't see how the fact that your PC simply can't, with
sufficient accuracy, measure what you call t_A for this approach to work
without much higher-level tracking has changed. But that's a discussion
that we really shouldn't be having (again) within the context of an
unrelated GSoC project.


background: in digital mod, you have to recover the TX sample clock,
anyway, and then this problem boils down to matching the studio's audio
sample rate to your soundcard's sample rate.

Studio equipment typically has rather good oscillators (I think: better
than 10ppm offset), and even the cheapest USB codec from Texas
Instruments advises you to use a <=25ppm oscillator. That leads to a
total worst-case rate offset of 35 ppm; with an 48 kHz sample clock,
that's an offset of about 0.6 Hz, or one sample every 1.68 s. Thus, meh,
assume your ALSA does 1024-sample periods, it'd take some half hour for
a single frame to go missing or accumulate. And that's not even when you
get an issue. It's just the first point that you'd actually be able to
count things worthy of being sent to the audio driver not being the
number that would be correct.


In analog audio modulation, you don't get the benefit of anything that
inherently transports the transmitter's sampling clock, and thus, your
SDR's frequency error can't be corrected.


Best regards,

Marcus


On 06.06.2017 18:02, Benny Alexandar wrote:


Hi Luca,


Nice to see your progress so far. Once you have the
DAB receiver audio listening in place, I would
suggest to have an audio synchronization for continuous
playback without any buffer overflow or under-runs.

DAB+ audio super frame length is 120ms according to DAB+
standard (ETSI TS 102 563). Each audio super frame is
carried in five consecutive logical DAB frames.
Which means 120ms of audio is mapped to 5 DAB frames.

If I add a timestamp at the receiver when the first DAB frame
sample arrives, I can check the max latency when it comes to
audio renderer, I mean after buffering to adjust the variable
decoding time of compressed audio.

t_D = t_A -  t_B ,
where,
 t_A = time at audio out
 t_B = time at input baseband sample.
 t_D = maximum system delay.

The difficulty is to estimate the slow clock drift correctly
and separate it from the short-time channel/decoding jitter.

Add a delay to buffer audio at audio out, say  D, which is larger
than max system delay. Whenever the audio reaches audio out, check the
delay to separate the clock drift.

 drift = t_D - D

Please let me know if you need any more details.

-ben












*From:* Discuss-gnuradio
 on behalf of
Moritz Luca Schmid 
*Sent:* Friday, May 26, 2017 6:19:31 PM
*To:* GNURadio Discussion List
*Subject:* [Discuss-gnuradio] [GSoC 17] DAB: updates of the week


Hi everyone,

I just published my latest updates of my DAB project in a new blog
post .

This week, I created a source block for the Fast Information Channe

Re: [Discuss-gnuradio] why can't use iwconfig when I run the gr-ieee802-11

[Bastian Bloessl]

Hi,

On 06/06/2017 03:55 PM, zhan siyu wrote:

Hi all,

I just found I can't use the iwconfig tap0 rate 20M to setup the 
bandwidth of the tap0. The error message is :


Error for wireless request "Set Bit Rate" (8B20) :
  SET failed on device tap0 ; Operation not supported.

But in their video , it can be set in this way. May I know how to solve it ?


The WiFi transceiver is attached to the tun/tap interface, which is a 
virtual Ethernet device. This device doesn't support WiFi-specific 
configuration through iwconfig.


If you wanted this level of integration, you would have to write a 
kernel module that attaches the transceiver to a virtual WiFi card.


Some group already did that, but they didn't release the source code.

Best,
Bastian

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

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

[John Ackermann N8UR]

Hi Benny --

As I mentioned in another message, I'm struggling with the RF-audio 
interface now.  Do you have any example code for your suggestion that I 
might play with (in my mind, the idea would be an "audio synchronizer" 
block that would take input at the nominal audio rate and output at the 
actual rate, correcting for clock error to keep the stream flowing 
smoothly).


If a prototype exists, I'd be happy to plug it into my current app to 
see what happens.


John


On 06/06/2017 12:02 PM, Benny Alexandar wrote:

Hi Luca,


Nice to see your progress so far. Once you have the
DAB receiver audio listening in place, I would
suggest to have an audio synchronization for continuous
playback without any buffer overflow or under-runs.

DAB+ audio super frame length is 120ms according to DAB+
standard (ETSI TS 102 563). Each audio super frame is
carried in five consecutive logical DAB frames.
Which means 120ms of audio is mapped to 5 DAB frames.

If I add a timestamp at the receiver when the first DAB frame
sample arrives, I can check the max latency when it comes to
audio renderer, I mean after buffering to adjust the variable
decoding time of compressed audio.

t_D = t_A -  t_B ,
where,
 t_A = time at audio out
 t_B = time at input baseband sample.
 t_D = maximum system delay.

The difficulty is to estimate the slow clock drift correctly
and separate it from the short-time channel/decoding jitter.

Add a delay to buffer audio at audio out, say  D, which is larger
than max system delay. Whenever the audio reaches audio out, check the
delay to separate the clock drift.

 drift = t_D - D

Please let me know if you need any more details.

-ben












*From:* Discuss-gnuradio
 on behalf of
Moritz Luca Schmid 
*Sent:* Friday, May 26, 2017 6:19:31 PM
*To:* GNURadio Discussion List
*Subject:* [Discuss-gnuradio] [GSoC 17] DAB: updates of the week


Hi everyone,

I just published my latest updates of my DAB project in a new blog post
.

This week, I created a source block for the Fast Information Channel and
started to build a reception chain for the Main Service Channel (where
the audio data is transmitted).

Read more about it in my post.


Cheers

Luca



___
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] symbol already exists: cannot reuse! runtime error

[Eugene Grayver]

I have a rather complicated GR application.  I create (Python, w/out grc) 
multiple top_blocks, each containing dozens of blocks.  To make things even 
more complicated, the flowgraphs are created in stages - using runtime 
reconfiguration to add more blocks.

Everything works fine until I reach some critical size (apparently).  Then I 
get an error: 'symbol already exists cannot reuse'  It has something to do with 
registering a block name in 'block_registry::register_symbolic_name'

I experience this error with both versions 3.7.9.2 and 3.7.11.

I am at a loss on how to debug this problem.  Reviewing the code seems OK - the 
thread locks look good.  I have no idea how a block with the same name can show 
up twice.  Is this due to multiple top_block instances?  Due to runtime 
reconfig?

Ideas?

___
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

Re: [Discuss-gnuradio] why can't use iwconfig when I run the gr-ieee802-11

[zhan siyu]

Thanks. I just wonder why. Because I meet some performance problem. I
thought it maybe caused by my misconfiguration of the gr-ieee802-11 code.
Now, it seems not.

However, theoretically,  as my current sample rate is 10M and BPSK. So the
coding rate should be 10M/2 = 5M b/s. The throughtput should be around 5M/8
= 625K B/s. Assuming the 12% head cost, so the data throughput should be
625 * 88 % = 550K B/s.  But as my experiment shows, the throughput is only
150K B/s.

I'm new to the communication. Is my calculation right ? If it were right,
then what might cause the gap?

One more question, I didn't run the volk_profile. Does it matter?

Best regards.

Siyu


2017-06-07 4:23 GMT+08:00 Bastian Bloessl :

> Hi,
>
> On 06/06/2017 03:55 PM, zhan siyu wrote:
>
>> Hi all,
>>
>> I just found I can't use the iwconfig tap0 rate 20M to setup the
>> bandwidth of the tap0. The error message is :
>>
>> Error for wireless request "Set Bit Rate" (8B20) :
>>   SET failed on device tap0 ; Operation not supported.
>>
>> But in their video , it can be set in this way. May I know how to solve
>> it ?
>>
>
> The WiFi transceiver is attached to the tun/tap interface, which is a
> virtual Ethernet device. This device doesn't support WiFi-specific
> configuration through iwconfig.
>
> If you wanted this level of integration, you would have to write a kernel
> module that attaches the transceiver to a virtual WiFi card.
>
> Some group already did that, but they didn't release the source code.
>
> Best,
> Bastian
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] 1,024 in - 3 out

[G Reina]

I'm trying to implement a Python block that will take a signal (complex64
array of 1,024 values) and return a float32 array that includes the max,
min, and mean of the norm for the complex values.

So something with an input array of 1,024 complex elements and an output
array of 3 float elements. From my reading so far, I think I can use an
embedded basic Python block:

class blk(gr.basic_block):  # other base classes are basic_block,
> decim_block, interp_block
> """Embedded Python Block example"""
>
> def __init__(self, example_param=1.0):  # only default arguments here
> """arguments to this function show up as parameters in GRC"""
> gr.basic_block.__init__(
> self,
> name='Embedded Python Block',   # will show up in GRC
> in_sig=[np.complex64],
> out_sig=[np.float32]
> )
> # if an attribute with the same name as a parameter is found,
> # a callback is registered (properties work, too).
> self.example_param = example_param
>
> def forecast(self, noutput_items, ninput_items_required=1024):
> for i in range(len(ninput_items_required)):
> ninput_items_required[i] = 1024
>
> def general_work(self, input_items, output_items):
>
> output_items[0] = np.zeros(3)
> output_items[0][:] = [np.min(np.abs(input_items[0])),
> np.max(np.abs(input_items[0])), np.mean(np.abs(input_items[0]))]
>
> print('{}: {}'.format(len(input_items[0]), output_items[0]))
>
> return len(output_items[0])
>

This code runs. The print statement shows me that the data is getting in
(8,191 elements) and that it is correctly calculating the output_items[0]
vector.  However, when I try to hook up the output of the block to a GRC
number sink or time scope, I don't see anything at all. So it doesn't seem
to be passing anything back for another block to use.

Is there a better way for me to do this?  My intention is to turn this
simple block into a more complicated block that finds open channels from a
complex spectrum. So I'd be taking a 1,024 complex input and returning an
output with the open center frequency, bandwidth, and probability of being
unoccupied. Maybe the block can just pass messages back instead of an array
of values??

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

Re: [Discuss-gnuradio] why can't use iwconfig when I run the gr-ieee802-11

[Bastian Bloessl]

Hi,

On 06/07/2017 03:04 AM, zhan siyu wrote:
Thanks. I just wonder why. Because I meet some performance problem. I 
thought it maybe caused by my misconfiguration of the gr-ieee802-11 
code. Now, it seems not.


I'm a bit confused why the fact that the transceiver is not configured 
through iwconfig ruled out any configuration issues, but great that all 
seems to be set up now.




However, theoretically,  as my current sample rate is 10M and BPSK. So 
the coding rate should be 10M/2 = 5M b/s. The throughtput should be 
around 5M/8 = 625K B/s. Assuming the 12% head cost, so the data 
throughput should be 625 * 88 % = 550K B/s.  But as my experiment shows, 
the throughput is only 150K B/s.


I'm new to the communication. Is my calculation right ?


BPSK 1/3 is 3Mbit/s gross at 10MHz. The overhead per packet has to be 
subtracted, i.e. the actual maximum rate depends on the frame size.



If it were 
right, then what might cause the gap?


Since you don't explain what you are doing, this is very hard to tell. 
You would reach this theoretical throughput only if you send frames 
back-to-back (which probably only works if you pregenerate the sample 
stream). But also a WiFi card will insert inter-frame space, so that the 
actual throughput will not match the theoretical maximum physical layer 
throughput.


Best,
Bastian




One more question, I didn't run the volk_profile. Does it matter?

Best regards.

Siyu


2017-06-07 4:23 GMT+08:00 Bastian Bloessl >:


Hi,

On 06/06/2017 03:55 PM, zhan siyu wrote:

Hi all,

I just found I can't use the iwconfig tap0 rate 20M to setup the
bandwidth of the tap0. The error message is :

Error for wireless request "Set Bit Rate" (8B20) :
   SET failed on device tap0 ; Operation not supported.

But in their video , it can be set in this way. May I know how
to solve it ?


The WiFi transceiver is attached to the tun/tap interface, which is
a virtual Ethernet device. This device doesn't support WiFi-specific
configuration through iwconfig.

If you wanted this level of integration, you would have to write a
kernel module that attaches the transceiver to a virtual WiFi card.

Some group already did that, but they didn't release the source code.

Best,
Bastian




--
Dipl.-Inform. Bastian Bloessl
CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/

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

[Discuss-gnuradio] Handling more than 3 output streams

[Vipin Sharma]

I have a custom block for which I am trying to define the io signature in
the *impl.cc file correctly. The problem is that the custom block has more
than 3 output streams. I tried make5 but got a compile error saying make5
is not a member. After researching more, I found out that I need to use
makev instead. But I am not sure how and where to initialize the vector int
array type and then pass that variable as the third argument to the makev
function below. Here is the block of code below. For example, where do I
initialize the sizeOfInputStream vector-int array type?

/*
 * The private constructor
 */
Nulling_cc_impl::Nulling_cc_impl(int PBoostFactor, char TapSize, int
FrameSize, gr_complex *InitialTapsDb[2])
  : gr::block("Nulling_cc",
  gr::io_signature::makev(5, 5, &sizeOfInputStream),
  gr::io_signature::make4(4, 4, TapSize*sizeof(gr_complex),
TapSize*sizeof(gr_complex), sizeof(bool), TapSize*sizeof(gr_complex)))
{}

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