Re: [Discuss-gnuradio] Handling more than 3 output streams

Thank you; that is what I wanted to know.

On Wed, Jun 7, 2017 at 9:00 AM, <address@hidden> wrote:

Send Discuss-gnuradio mailing list submissions to
address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
address@hiddenorg

You can reach the person managing the list at
address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."

Today's Topics:

1. Re: [GSoC 17] DAB: updates of the week (Benny Alexandar)
2. Re: [GSoC 17] DAB: updates of the week (Marcus M?ller)
3. ninput_items_required=1024 (G Reina)
4. Re: ninput_items_required=1024 (G Reina)
5. Re: [GSoC 17] DAB: updates of the week (John Ackermann N8UR)
6. Re: why can't use iwconfig when I run the gr-ieee802-11
(Bastian Bloessl)
7. Re: [GSoC 17] DAB: updates of the week (John Ackermann N8UR)
8. symbol already exists: cannot reuse! runtime error
(Eugene Grayver)
9. Re: why can't use iwconfig when I run the gr-ieee802-11
(zhan siyu)
10. 1,024 in - 3 out (G Reina)
11. Re: why can't use iwconfig when I run the gr-ieee802-11
(Bastian Bloessl)
12. Handling more than 3 output streams (Vipin Sharma)
13. Re: Handling more than 3 output streams (Moritz Luca Schmid)
14. Re: Rational Resampler no output. (Anon Lister)
15. USRP sink clock rate (???)
16. Re: USRP sink clock rate (Derek Kozel)
17. Measure the Distance to another 802.11 device (Florian Adamsky)
18. Re: why can't use iwconfig when I run the gr-ieee802-11
(zhan siyu)
19. Re: Measure the Distance to another 802.11 device (Marcus M?ller)

----------------------------------------------------------------------

Message: 1
Date: Tue, 6 Jun 2017 16:02:32 +0000
From: Benny Alexandar <address@hidden>
To: Moritz Luca Schmid <address@hidden>, "GNURadio
Discussion List" <address@hidden>
Subject: Re: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week
Message-ID:
<HK2PR02MB13304001D3CCC4F38345address@hiddenapcprd02.prod.outlook.com>

Content-Type: text/plain; charset="us-ascii"

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 <discuss-gnuradio-bounces+ben.alex=address@hidden> on behalf of Moritz Luca Schmid <address@hidden>
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<https://dabtransceiver.wordpress.com/>.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170606/bcd8ed3c/attachment.html>

------------------------------

Message: 2
Date: Tue, 6 Jun 2017 19:10:06 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week
Message-ID: <520a2557-1506-5fd3-305a-address@hidden>
Content-Type: text/plain; charset="windows-1252"

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
> <discuss-gnuradio-bounces+ben.alex=address@hidden> on behalf of
> Moritz Luca Schmid <address@hidden>
> *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 <https://dabtransceiver.wordpress.com/>.
>
> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170606/204476a8/attachment.html>

------------------------------

Message: 3
Date: Tue, 6 Jun 2017 11:12:08 -0700
From: G Reina <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] ninput_items_required=1024
Message-ID:
<CAEBTegSZB3cj0f-UL+ncQRxh3Y_hQ=oAWiQ=address@hiddengmail.com>
Content-Type: text/plain; charset="utf-8"

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170606/e0ee6b42/attachment.html>

------------------------------

Message: 4
Date: Tue, 6 Jun 2017 11:30:29 -0700
From: G Reina <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] ninput_items_required=1024
Message-ID:
<CAEBTegSNRJFGC+FXydNXrS37HnRGyWmFe3tkb=nzPk7maddress@hidden>
Content-Type: text/plain; charset="utf-8"

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 <address@hidden> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170606/e2235296/attachment.html>

------------------------------

Message: 5
Date: Tue, 6 Jun 2017 15:46:53 -0400
From: John Ackermann N8UR <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week
Message-ID: <b44389c8-9b9f-f2b3-07ab-address@hidden>
Content-Type: text/plain; charset=utf-8; format=flowed

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
>> <discuss-gnuradio-bounces+ben.alex=address@hidden> on behalf of
>> Moritz Luca Schmid <address@hidden>
>> *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 <https://dabtransceiver.wordpress.com/>.
>>
>> 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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

------------------------------

Message: 6
Date: Tue, 6 Jun 2017 21:23:05 +0100
From: Bastian Bloessl <address@hidden>
To: zhan siyu <address@hidden>, address@hidden
Subject: Re: [Discuss-gnuradio] why can't use iwconfig when I run the
gr-ieee802-11
Message-ID: <d76f1dcb-4431-0849-7c6a-address@hidden>
Content-Type: text/plain; charset=utf-8; format=flowed

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

------------------------------

Message: 7
Date: Tue, 6 Jun 2017 17:17:50 -0400
From: John Ackermann N8UR <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week
Message-ID: <44ed7cf1-9584-88e7-e5ee-address@hidden>
Content-Type: text/plain; charset=utf-8; format=flowed

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
> <discuss-gnuradio-bounces+ben.alex=address@hidden> on behalf of
> Moritz Luca Schmid <address@hidden>
> *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
> <https://dabtransceiver.wordpress.com/>.
>
> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

------------------------------

Message: 8
Date: Wed, 7 Jun 2017 01:08:21 +0000
From: Eugene Grayver <address@hidden>
To: "address@hidden" <address@hidden>
Subject: [Discuss-gnuradio] symbol already exists: cannot reuse!
runtime error
Message-ID:
<BY2PR09MB0965C99ADD1D91A859FAaddress@hiddennamprd09.prod.outlook.com>

Content-Type: text/plain; charset="us-ascii"

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
________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170607/33bf626b/attachment.html>

------------------------------

Message: 9
Date: Wed, 7 Jun 2017 10:04:40 +0800
From: zhan siyu <address@hidden>
To: Bastian Bloessl <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] why can't use iwconfig when I run the
gr-ieee802-11
Message-ID:
<CAGNex4jsMd9WZkn7p4Fe-gPwxow1T2N+-4iU5gV+AyM3nkWpQw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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 <address@hidden>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170607/2083e1f0/attachment.html>

------------------------------

Message: 10
Date: Tue, 6 Jun 2017 21:08:34 -0700
From: G Reina <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] 1,024 in - 3 out
Message-ID:
<CAEBTegT92t3fUc_eotaBtK5ScGvNWSJp=xQBkr630tmnEaddress@hidden>
Content-Type: text/plain; charset="utf-8"

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170606/3c5cbdf5/attachment.html>

------------------------------

Message: 11
Date: Wed, 7 Jun 2017 07:02:31 +0100
From: Bastian Bloessl <address@hidden>
To: zhan siyu <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] why can't use iwconfig when I run the
gr-ieee802-11
Message-ID: <9eff9bd8-e09f-3b9f-8180-address@hidden>
Content-Type: text/plain; charset=utf-8; format=flowed

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 <address@hidden
> <mailto:address@hidden>>:
>
> 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/

------------------------------

Message: 12
Date: Tue, 6 Jun 2017 23:57:24 -0700
From: Vipin Sharma <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] Handling more than 3 output streams
Message-ID:
<CAJQb1zusxLXxMJ0J4Ff3jy+9ctGZFLvOVNBhY0c=0MK8hMovOg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170606/d0bd85e7/attachment.html>

------------------------------

Message: 13
Date: Wed, 7 Jun 2017 09:19:47 +0200
From: Moritz Luca Schmid <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Handling more than 3 output streams
Message-ID: <cb16f123-9f29-5fb2-6a6a-address@hidden>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hi Vipin,

you can find detailed information about the methods makeX to create an
i/o signature in the doxygen documentation
<https://gnuradio.org/doc/doxygen/classgr_1_1io__signature.html#a99e0f9e8de8e7ce16ed92d9f2655e66c>.

If you have multiple input streams with the same size, you don't have to
specify the size of each stream separately but you can simply define
their size in the last input item once (e.g. for make3 the the argument
sizeof_stream_item3: "specify the size of the items in the third and
subsequent streams"). If this is not the case and you have to define the
size for each stream separately or you have at least more than 3
different stream sizes, you choose makev.

You can initialize the vector sizeof_stream_items just before your
constructor. See /gr-digital constellation_receiver_cb_impl
<https://github.com/fengzhe29888/gnuradio-old/blob/master/gr-digital/lib/constellation_receiver_cb_impl.cc>/as
an example for that.

Best

Luca

On 07.06.2017 08:57, Vipin Sharma wrote:
> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170607/8383410e/attachment.html>

------------------------------

Message: 14
Date: Wed, 7 Jun 2017 04:26:58 -0400
From: Anon Lister <address@hidden>
To: Marcus M?ller <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Rational Resampler no output.
Message-ID:
<CAMp204QG9ttezukNHogskabUr6hVaddress@hiddengmail.com>
Content-Type: text/plain; charset="utf-8"

I have an AMD system with the same chip running Ubuntu 16.xx. I can
probably try to duplicate this weekend, if Cor doesn't get to it, as
another data point.

On Jun 5, 2017 3:14 PM, "Marcus M?ller" <address@hidden> wrote:

Hi Cor,

Excuse the language, but faaaark. Ok, looks like we have a bug in low_pass.
Or in GCC. Or SWIG (which does the python-wrapping of the code in
firdes.cc). yay.

So, let's narrow this down: on intel and amd64, same number of taps, right?

Then: If I asked you to use GDB to verify the C++ low_pass function in
gr::filter::firdes::low_pass actually returned the right float values,
would you feel that, with a few hints, be able to do that?

Best regards,

Marcus

On 01.06.2017 07:20, Cor Legemaat wrote:

Hi:

filter.firdes.low_pass get called with:
* fractional_bw = 0.4
* trans_width = 0.1
* mid_transition_band = 0.45
* interpolation = 24

But return: (nan, <788 times nan>)

Regards:
Cor

On Tue, 2017-05-30 at 00:06 +0200, Marcus M?ller wrote:

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
address@hiddenorghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing
address@hiddenorghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing
address@hiddenorghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing
address@hiddenorghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170607/c94fd215/attachment.html>

------------------------------

Message: 15
Date: Wed, 7 Jun 2017 17:37:20 +0900
From: ??? <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] USRP sink clock rate
Message-ID: <address@hiddenkr>
Content-Type: text/plain; charset="utf-8"

Hi all

I'm using Ettus Research USRP device with GRC

And I have one question

<The "sampling rate" is the rate at which samples are passed
between the host commuter and the USRP>
<The "master_clock_rate" is the rate at which samples are
passed between FPGA and the RF front end>

Is there anybody who can explain me why the clock rate on UHD:USRP sink
block

have only 4 choice? (200, 18432, 120, 3072MHz)

Regards

Kim taeyeong

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170607/b4bea426/attachment.html>

------------------------------

Message: 16
Date: Wed, 7 Jun 2017 10:29:32 +0100
From: Derek Kozel <address@hidden>
To: ??? <address@hidden>
Cc: GNURadio Discussion List <address@hidden>
Subject: Re: [Discuss-gnuradio] USRP sink clock rate
Message-ID:
<CAA+K=tuzn7L9C=v0-bMioRuVh-3PSaEr8NSE9pK=address@hiddengmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Kim,

The first two rates (200e6 and 184.32e6) are for the X310 which only
supports those two ADC sampling rates. The third rate (120e6) is no longer
supported, I'll get that removed. 30.72e6 is for the AD9361/AD9364 based
USRPs (B2x0, E310).

The field is a text field so you can enter any value you want. However for
most applications it is best to initialize the device with the master clock
rate set in the device arguments. You can supply a string such as
"master_clock_rate=61.44e6" into the Device Arguments field in the sink
block. If you have a source block using the same USRP the Device Arguments
and Device Address fields must be identical between these blocks.

Regards,
Derek

On Wed, Jun 7, 2017 at 9:37 AM, ??? <address@hidden> wrote:

> Hi all
>
>
>
> I'm using Ettus Research USRP device with GRC.
>
> And I have one question.
>
> <The "sampling rate" is the rate at which samples are passed between the
> host commuter and the USRP.>
> <The "master_clock_rate" is the rate at which samples are passed between
> FPGA and the RF front end.>
>
>
>
> Is there anybody who can explain me why the clock rate on UHD:USRP sink
> block
>
> have only 4 choice? (200, 184.32, 120, 30.72MHz)
>
>
>
>
>
> Regards
>
> Kim taeyeong
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170607/54022dae/attachment.html>

------------------------------

Message: 17
Date: Wed, 07 Jun 2017 14:58:37 +0200
From: Florian Adamsky <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] Measure the Distance to another 802.11
device
Message-ID: <address@hidden>
Content-Type: text/plain

Hi all,

in one of our projects we need to measure the distance between two
802.11 devices as accurately as possible. Our idea is to use the
round-trip time (RTT). To avoid any delay from the operation system and
from the network stack, our idea is to measure the arrival time of the
acknowledgment control frame. Means, we take a timestamp when device A
sent a small data frame to device B; when B has received the frame, it
replies with an acknowledgment control frame and when A has received it
we will take another timestamp. Of course we would repeat that n-times
to avoid outliers.

We bought a HackRF and tried to get the examples from gr-ieee802-11
running. After some minor problems (dc offset) we were able to receive
802.11 frames. However, we are not able to send any 802.11 packets,
because the hackrf driver does not support burst transmission with
tagged streams. One reader of this mailing list suggested to give
soapysdr a try. We did that as well, but again without success. Here we
didn't see any "UUUUU" in the debug console but we were still not able
to see any packets with another wireless card in monitor mode.

Now we begin to think if the HackRF is the right device to get the job
done. Is the HackRF maybe the wrong device and we need to get a better
one? If yes, which one would you suggest? Or do you think there is
better approach to solve our problem like modifying one of the open
firmware for wireless cards?

Thanks in advance.

Cheers!
--
Dr. Florian Adamsky
http://florian.adamsky.it/

------------------------------

Message: 18
Date: Wed, 7 Jun 2017 21:32:11 +0800
From: zhan siyu <address@hidden>
To: Bastian Bloessl <address@hidden>
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] why can't use iwconfig when I run the
gr-ieee802-11
Message-ID:
<CAGNex4ieGY+yyC7X96q3KMrO5+FOBgg_fVLZ=address@hiddengmail.com>
Content-Type: text/plain; charset="utf-8"

Thanks for your reply. Let me explain what I 'm doing.

I have two B210s connected with two computers. I want to measure the
throughput between the two computers over the usrp connection over
gr-ieee802-11. But no matter how hard I try, like tuning the parameters and
turning off my own wifi card and AP, I can only get 150K B/s, which should
be around 300K B/s if my theoretical calculation is right. There are no
underrun or overrun errors. The throughput measurement tool I'm using is
iperf, which is an application to measure the end to end throughput.

Could you give me some hints?

Best regards.

Siyu

2017-06-07 14:02 GMT+08:00 Bastian Bloessl <address@hidden>:

> 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 <address@hidden <mailto:
>> address@hidden>>:
>>
>> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20170607/099e661c/attachment.html>

------------------------------

Message: 19
Date: Wed, 7 Jun 2017 17:36:34 +0200
From: Marcus M?ller <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] Measure the Distance to another 802.11
device
Message-ID: <d593a29c-c303-f7ec-21d3-address@hidden>
Content-Type: text/plain; charset=windows-1252

Hi Florian,

that's an interesting approach!

On 06/07/2017 02:58 PM, Florian Adamsky wrote:
> Hi all,
>
> in one of our projects we need to measure the distance between two
> 802.11 devices as accurately as possible. Our idea is to use the
> round-trip time (RTT). To avoid any delay from the operation system and
> from the network stack, our idea is to measure the arrival time of the
> acknowledgment control frame. Means, we take a timestamp when device A
> sent a small data frame to device B; when B has received the frame, it
> replies with an acknowledgment control frame and when A has received it
> we will take another timestamp. Of course we would repeat that n-times
> to avoid outliers.
Your observation, that Wifi chipsets typically delegate most of what is
necessary to be a working Wifi device to the operating system. Highly
timing-sensitive things, however, are typically handled by the chip
firmware itself.
If I remember correctly, there's some degree of adjustability in that
firmware, at least in Atheros chipsets; [1] might be an interesting talk
for you.
>
> We bought a HackRF and tried to get the examples from gr-ieee802-11
> running. After some minor problems (dc offset) we were able to receive
> 802.11 frames. However, we are not able to send any 802.11 packets,
> because the hackrf driver does not support burst transmission with
> tagged streams. One reader of this mailing list suggested to give
> soapysdr a try. We did that as well, but again without success. Here we
> didn't see any "UUUUU" in the debug console but we were still not able
> to see any packets with another wireless card in monitor mode.
Another takeaway from [1] that in usual operation, the hardware doesn't
even hand over packets that don't make the checksum test ? maybe it'd be
interesting to disable that filtering.

Best regards,
Marcus

[1]
https://www.irongeek.com/i.php?page=videos/defcon-wireless-village-2014/20-inside-the-atheros-wifi-chipset-adrian-chadd

------------------------------

Subject: Digest Footer

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

------------------------------

End of Discuss-gnuradio Digest, Vol 176, Issue 7
************************************************

From:	Vipin Sharma
Subject:	Re: [Discuss-gnuradio] Handling more than 3 output streams
Date:	Wed, 7 Jun 2017 21:49:40 -0700