[Discuss-gnuradio] OOT: General type block changing parameter with WX GUI slider

[Ali]

Hi to all,

I created a module and its type is general. It has 6 inputs and 2 outputs.
Also, there are 2 parameters. I noticed that I cannot change these
parameters while the GRC is running(I am using WX GUI Slider). Actually, I
can change them but my block uses the default value of WX GUI slider box.

In .cc file under the place where we define number of input/ouput ports, I
declare them as

parameter1(p1),
parameter2(p2)

Then in the .h file, under the private, I declare them as

float parameter1;
float parameter2;

What might be the problem?

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

[Discuss-gnuradio] USRP phase to sample index relation in the DDC/DUC chain

[Nicolas GALLAND]

Hello everyone,

I am using a USRP X310 with basic RX and basic TX daughterboards and I 
would like to know the exact relation between the number I enter as a 
parameter for the central frequency in the UHD USRP sink/source block 
(which is a real number) and the actual phase per each sample.


As a matter of facts, if the DDC/DUC chains were using a DDS, the 
relation would be pretty straightforward (knowing the control word of 
the DDS and the number of bits of the phase accumulator...). However, as 
I understand, the FPGA design uses a CORDIC for the DDC/DUC chain, for 
which the exact correspondence between sample index and phase is not as 
straight forward to derive. I am sorry if this is textbook material for 
CORDIC specialists (which I am not...), but I am wondering if someone 
could point me to the exact formula of phase vs sample index that I 
could use to very accurately know what is going on in the DDC/DUC chain. 
The bottom line is that I need to be sure of what is happening at the 
nrad level for MHz-ish input/output and mod/demod frequency, and the 
intricacies of the CORDIC behavior is - to my best understanding - 
playing a major role at this level.


Any help would be greatly appreciated.

Best regards,

Nicolas


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

Re: [Discuss-gnuradio] symbol already exists: cannot reuse! runtime error

[Marcus Müller]

Hi Eugene,

ouch, that's a heavy bug, considering we have blocks called agc2 in-tree.

Thanks for reporting this! Do you want to create an issue on
https://github.com/gnuradio/gnuradio/issues , or would you prefer we do
that? (I'd of course personally prefer you'd, as the discoverer &
solver, at least get the authorship of that ticket)

Best regards,

Marcus


On 09.06.2017 00:02, Eugene Grayver wrote:
> We figured out the cause of this error.  I had a block called 'vector_sink2' 
> .  I also have blocks called vector_sink. Turns out the block naming simply 
> appends the block's index to it.  
> The first vector_sink2 gets called vector_sink21
> The first vector_sink gets called vector_sink1
> So at some point we got an additional 20 vector_sink blocks.  So that created 
> a 'vector_sink21', which had a name conflict with the first vector_sink2.
> The moral of the story is not to end the block name with a number.  An even 
> better idea is to add a separator after the block name and its index for the 
> complete name: e.g. vector_sink2(1)
>
>
> ___
> 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] [GSoC 2017] gr-bokehgui: Updates on Week 4

[Kartik Patel]

Hello all,

This week, I have completed the Bokeh based Time Sink! I will complete GRC
integration by next Tuesday which will be a complete TimeSink package! For
more details, check out my blog !

Also, I have dropped the PR
 to master which
contains Time sink for float values last week. Kindly share your
suggestions and reviews of the code on Github for the same.

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

Re: [Discuss-gnuradio] PFB Clock Sync stops producing samples

[Andy Walls]

>  From: 
> devin kelly
>   Subject: 
> Re: [Discuss-gnuradio] PFB Clock
> Sync stops producing samples
>  Date: 
> Thu, 8 Jun 2017 15:41:38 -0400
> 
> __
> OK, I'll give that block a try.  Are you saying there's a bug in the
> PFB Clock Sync block?

Yes.

I'm also saying that since there are two fundamental bugs (incorrect tag
propagation, and conflation of symbol clock phase with resampling
interpolator sample phase) which both take a lot of work to fix and
should be fixed together, that it's not worth anyone's time to fix the
PFB clock sync blocks (complex IO and float IO).  The M&M clock sync
blocks (complex IO and float IO) and the MSK timing recovery block
(complex IO) also have those same two bugs.

Properly fixing those bugs for just the PFB clock sync blocks, results
in the PFB clock sync blocks evolving into a partial implementation of
the Symbol Synchronizer blocks, and still leaves the other 3 blocks
broken.  Properly fixing those bugs for all 5 of the in-tree
synchronizer blocks, in one place, results in most of the implementation
of the Symbol Synchronizer blocks.  There is no point in fixing the
existing blocks.

> That was my suspicion but I'm not sure I understand what the block is
> doing well enough to know with certainty.

For a quick overview of symbol recovery, see this MatLab documentation:
https://www.mathworks.com/help/comm/ref/comm.symbolsynchronizer-class.html#bumtxky-18

For the PFB clock sync block algorithms specifically, see figure 10 of:

Fredric J. Harris, Michael Rice, "Multirate Digital Filters for Symbol
Timing Synchronization in Software Defined Radios",
_IEEE_Journal_on_Selected_Areas_in_Communications_, Vol. 19, No. 12,
December 2001, pp. 2346 - 2357
https://pdfs.semanticscholar.org/3077/d85fc72d89c72c4c6d11f1014c5175e319c3.pdf

(The gist is to combine the receive pulse matched filter with the
resampling interpolator filter to save filtering operations.  The
resampling interpolator filter is implemented with a PFB and a
derivative PFB, since the (approximate) maximum likelyhood timing error
detector needs the derivative of the signal too.)

Also see this for an additional explanation written by Tom Rondeau:
https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation#7.6.1._Details_of_the_PFB_Clock_Recovery_Block


For the Symbol Synchronizer blocks, see this napkin diagram:
https://github.com/gnuradio/gnuradio/files/950045/Symbol_Synchronizer_block_diagram.pdf
and this comment:
https://github.com/gnuradio/gnuradio/pull/1294#issuecomment-296628308

For the symbol clock phase tracking loop transfer function and gain
computation, see this document:
https://github.com/awalls-cx18/gr-nwr/blob/master/docs/clock_loop.pdf


And now you can be certain that if I don't want to fix the existing PFB
clock sync blocks, neither do you. :)

-Andy


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

Re: [Discuss-gnuradio] Managing clutter in GRC GUI

[Dan CaJacob]

You can't manage the lines manually, but you can probably make things
closer to what you want by using virtual sources and sinks.

On Fri, Jun 9, 2017 at 1:52 AM Vipin Sharma 
wrote:

> I have an application with multiple blocks in the GUI. When I finish
> connecting all the blocks the picture looks really messy. I cannot seem to
> manually move/drag the connections from going over the blocks.
>
> Is there any way to guide connection routes manually so that my
> application looks more readable in the GUI?
>
> Vipin
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

Re: [Discuss-gnuradio] Managing clutter in GRC GUI

[Marcus Müller]

That, or make extensive use of hierarchical blocks! You can put
subgraphs into separate GRC documents, set the "Generate Options" to
"hierarchical block". Things will appear in the block list once you hit
the "generate" button.


Best regards,

Marcus


On 09.06.2017 15:20, Dan CaJacob wrote:
> You can't manage the lines manually, but you can probably make things
> closer to what you want by using virtual sources and sinks.
>
> On Fri, Jun 9, 2017 at 1:52 AM Vipin Sharma
> mailto:vipinsha...@photonpace.com>> wrote:
>
> I have an application with multiple blocks in the GUI. When I
> finish connecting all the blocks the picture looks really messy. I
> cannot seem to manually move/drag the connections from going over
> the blocks.
>
> Is there any way to guide connection routes manually so that my
> application looks more readable in the GUI?
>
> Vipin
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> -- 
> Very Respectfully,
>
> Dan CaJacob
>
>
> ___
> 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] OOT: General type block changing parameter with WX GUI slider

[Marcus Müller]

Please don't use WX Gui widgets for new designs. We're deprecating them,
and they are NOT part of the oncoming GNU Radio 3.8 release. Use Qt
instead. We simply have no-one to maintain the WX GUI elements, and
thus, it'll be very hard to help you with WX issues.

Best regards,

Marcus


On 09.06.2017 10:19, Ali wrote:
> Hi to all,
>
> I created a module and its type is general. It has 6 inputs and 2
> outputs. Also, there are 2 parameters. I noticed that I cannot change
> these parameters while the GRC is running(I am using WX GUI Slider).
> Actually, I can change them but my block uses the default value of WX
> GUI slider box.
>
> In .cc file under the place where we define number of input/ouput
> ports, I declare them as
>
> parameter1(p1),
> parameter2(p2)
>
> Then in the .h file, under the private, I declare them as
>
> float parameter1;
> float parameter2;
>
> What might be the problem?
>
> Best regards,
> Ali
>
>
>
>
> ___
> 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] Complex numbers in math operations

[Marcus Müller]

That's not the multiplication "*", that's an operator that takes only
one argument (hence, "operand type is", singular). Point being

IdealFMCW[tapIdx] is already a (reference to) a bare gr_complex, NOT a
gr_complex* !

Best regards,

Marcus


On 09.06.2017 07:57, Vipin Sharma wrote:
> I have a custom block with some input streams being declared as
> gr_complex type as shown here:
>
> /Control_impl::general_work (int noutput_items,/
> /   gr_vector_int &ninput_items,/
> /   gr_vector_const_void_star &input_items,/
> /   gr_vector_void_star &output_items)/
> /{/
> /  const gr_complex *hTx1 = (const gr_complex *) input_items[0];/
> /  const gr_complex *hTx2 = (const gr_complex *) input_items[1];/
> /  const gr_complex *IdealFMCW = (const gr_complex *) input_items[2];/
>
>
> Later on I use IdealFMCW as follows:
>
> /   for(tapIdx=0; tapIdx /*Tx1 = *Tx1 + *(IdealFMCW[tapIdx]) * (*hTx1); /
>
> When I do make, I get compile errors:
>
> *error: no match for ‘operator*’ (operand type is ‘const gr_complex
> {aka const std::complex}’)*
> * *Tx1 = *Tx1 + *(IdealFMCW[tapIdx]) * (*hTx1); *
>
> I am simply trying to de-reference the pointer (defined by
> IdealFMCW[tapIdx]) and use the value. What am I not doing right?
>
> Vipin
>
>
> ___
> 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] Complex numbers in math operations

[Michael Dickens]

Hi Vipin - You're doubly dereferencing IdealFMCW. I think your code
should read:{{{
*Tx1 = *Tx1 + (IdealFMCW[tapIdx]) * (*hTx1); 
}}}
because the [tapIdx] already dereferences the gr_complex* (IdealFMCW) to
be just gr_complex. The error provided by your compiler isn't very
helpful. Clang's error reads:{{{
error: indirection requires pointer operand ('gr_complex' (aka 
'complex') invalid)}}}
which at least gives a clue about the extra dereference but it's great
either. Hope this helps! - MLD
On Fri, Jun 9, 2017, at 01:57 AM, Vipin Sharma wrote:
> I have a custom block with some input streams being declared as
> gr_complex type as shown here:> 
> *Control_impl::general_work (int noutput_items,*
> *   gr_vector_int &ninput_items,*
> *   gr_vector_const_void_star &input_items,*
> *   gr_vector_void_star &output_items)*
> *{*
> *  const gr_complex *hTx1 = (const gr_complex *) input_items[0];*> *  
> const gr_complex *hTx2 = (const gr_complex *) input_items[1];*> *  const 
> gr_complex *IdealFMCW = (const gr_complex *)
>input_items[2];*> 
> Later on I use IdealFMCW as follows:
> 
> *   for(tapIdx=0; tapIdx **Tx1 = *Tx1 + *(IdealFMCW[tapIdx]) * (*hTx1); *
> 
> When I do make, I get compile errors:
> 
> *error: no match for ‘operator*’ (operand type is ‘const gr_complex
> {aka const std::complex}’)*> * *Tx1 = *Tx1 + 
> *(IdealFMCW[tapIdx]) * (*hTx1); *
> 
> I am simply trying to de-reference the pointer (defined by
> IdealFMCW[tapIdx]) and use the value. What am I not doing right?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC 17] DAB: Updates of week 4

[Moritz Luca Schmid]

Hi everyone,

here  is my latest blog post 
about the implementation of the DAB transmitter.


I got some issues with the convolutional coding that I have not fixed yet.


Cheers

Luca

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

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

[Neel Pandeya]

Yes, you should be able to start and stop streaming using timed commands on
the E310.

Are you using the Release 4 image?

--​Neel Pandeya



On 5 June 2017 at 11:54, Marcus Müller  wrote:

> Hi Jessica,
>
> not 100% sure you're right about timed commands not being supported on the
> E310 – yes, things like tuning and setting the gain can't be timed on the
> E310, but I thought stream commands should work. Will check.
>
> Best regards,
>
> Marcus
>
> On 02.06.2017 19:16, Jessica Iwamoto wrote:
>
> Hi all,
>
>
>
> We’re trying to implement a fast sweep over a range of frequencies on the
> E310. Currently, I have a Python block that takes in a stream from the USRP
> Source, counts up the number of samples, and after receiving n samples,
> issues a stream command to the USRP Source to receive n more samples. There
> is currently a delay (of a few ms) between when the stream command is
> issued and when the work function of my custom block is called, and we are
> trying to find ways to shorten this delay. We can’t use timed commands
> because they are not supported in the E310 and it doesn’t look like you can
> queue up a series of stream commands either. We also can’t use a custom C++
> block because of the issues discussed previously in this email thread.
>
>
>
> Does anyone have ideas on what to try? Or, could you point me to the
> relevant UHD code, as it is a bit confusing to follow? Also, are there any
> plans to add support for timed commands in the E310 or for a queue of
> stream commands?
>
>
>
> Thank you,
>
> Jessica
>
>
>
>
>
> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+jessica.iwamoto=aero@gnu.org
> ] *On Behalf
> Of *Marcus Müller
> *Sent:* Wednesday, May 24, 2017 12:26 PM
> *To:* discuss-gnuradio@gnu.org; Philip Balister 
> 
> *Subject:* Re: [Discuss-gnuradio] Custom C++ blocks on E310
>
>
>
> Hi Jessica,
>
> that's really interesting!
>
> It means that the problem only happens when you use your compiler to build
> your C++ blocks, but not when only using the GNU Radio that's already part
> of your image. Not quite sure what that entails; maybe it means that
> openembedded builds broken SDKs... That shouldn't happen. The other thing I
> could think of would be a slight misconfiguration of the compiler (or the
> linker). Maybe Philip has an idea!
>
> Best regards,
>
> Marcus
>
>
>
>
>
> On 24.05.2017 20:51, Jessica Iwamoto wrote:
>
> Hi all,
>
>
>
> I never found the solution to this problem, but I ended up using a work
> around by writing my custom blocks in Python instead of C++.
>
>
>
> Jessica
>
>
>
> *From:* Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+jessica.iwamoto=aero@gnu.org
> ] *On Behalf
> Of *Jessica Iwamoto
> *Sent:* Monday, May 15, 2017 8:38 AM
> *To:* Ben Hilburn  
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re:
> [Discuss-gnuradio] Custom C++ blocks on E310
>
>
>
> Hi Ben,
>
>
>
> Here is some of the backtrace from the error. At the top level, the error
> starts in the msg_connect function and it looks like it gets tripped up
> reading something from memory when checking for a valid message port.
>
>
>
> #0  0xb635c67c in fetch_add (order=boost::memory_order_relaxed, v=1,
>
> storage=@0x6: )
>
> at /home /prefix /sysroots/armv7ahf-vfp-neon-
> oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:100
>
> #1  fetch_add (order=boost::memory_order_relaxed, v=1, this=0x6)
>
> at /home /prefix /sysroots/armv7ahf-vfp-neon-
> oe-linux-gnueabi/usr/include/boost/atomic/detail/atomic_template.hpp:115
>
> #2  pmt::intrusive_ptr_add_ref (p=0x2)
>
> at /home /prefix /src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:69
>
> #3  0xb63e56e4 in intrusive_ptr (rhs=..., this=0xbeffec7c)
>
> at /home /prefix /sysroots/armv7ahf-vfp-neon-
> oe-linux-gnueabi/usr/include/boost/smart_ptr/intrusive_ptr.hpp:92
>
> #4  gr::flowgraph::check_valid_port (this=this@entry=0x10c578, e=...)
>
> at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:162
>
> #5  0xb63e95d0 in gr::flowgraph::connect (this=this@entry=0x10c578,
> src=...,
>
> dst=...)
>
> at /home /prefix /src/gnuradio/gnuradio-runtime/lib/flowgraph.cc:503
>
> #6  0xb63f4c84 in gr::hier_block2_detail::msg_connect (
>
> this=this@entry=0x10c528, src=..., srcport=..., dst=..., dstport=...)
>
> at /home /prefix /src/gnuradio/gnuradio-runtime/lib/hier_block2_
> detail.cc:198
>
> #7  0xb63f1b14 in gr::hier_block2::msg_connect (this=this@entry=0x0,
> src=...,
>
> srcport=..., dst=..., dstport=...)
>
> at /home /prefix /src/gnuradio/gnuradio-runtime/lib/hier_block2.cc:104
>
> #8  0xb5cd6958 in _wrap_top_block_sptr_primitive_msg_connect__SWIG_1 (
>
> args=)
>
> at /home /prefix_new/src/gnuradio/build-arm/gnuradio-runtime/
> swig/runtime_swigPYTHON_wrap.cxx:47551
>
>
>
> Thanks,
>
> Jessica
>
>
>
> *From:* Ben Hilburn [mailto:bhilb...@gnuradio.org ]
>
> *Sent:* Friday, May 12, 2017 1:35 PM
> *To:* Jessica

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

[zhan siyu]

Hi ,

I made a mistake. The unit of the throughput is wrong. It should be Kb/s.
And I wrote a TCP client and server to run over the gr-ieee802-11. I set
the sample rate to 5M so that no O errors and the packet lost rate is only
3%. Also I choose the BPSK1/2 encoding. The throughput is only 115K bits/s
as shown by my TCP server.  If I run my program over wifi cards, the result
is around 15M bits/s. I mean my program works fine. Then how to explain the
relationship between the 5M and the 115K bits/s throughput?

Best regards.

Siyu


2017-06-08 21:41 GMT+08:00 Bastian Bloessl :

> Hi,
>
> On 06/07/2017 02:32 PM, zhan siyu wrote:
>
>> 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?
>>
>
> I'm afraid I can't help a lot, since I have no idea what iperf is doing. I
> guess it floods the network stack with UDP packets. The GNU Radio
> transceiver, however, has no back pressure mechanism, so it will just drop
> the frames when they are injected into the GNU Radio flow graph.
>
> Also, I don't understand what exact analytical number you are trying to
> reproduce here. In fact, I have no idea what this experiment is supposed to
> show/prove or what part of the transceiver you are trying to profile. If,
> at all, this experiment will tell you how fast the TX-side can produce
> frames.
>
> This was investigated in
>
> Gonzalo Arcos, Rodrigo Ferreri, Matías Richart, Pablo Ezzatti and Eduardo
> Grampín, "Accelerating an IEEE 802.11 a/g/p Transceiver in GNU Radio,"
> Proceedings of 9th Latin America Networking Conference (LANC'16),
> Valparaíso, Chile, October 2016, pp. 13-19.
>
> Turns out, you can improve the TX-side by improving the OFDM Carrier
> Allocator.
>
> Best,
> Bastian
>
>
>
>> Best regards.
>>
>> Siyu
>>
>> 2017-06-07 14:02 GMT+08:00 Bastian Bloessl > m...@bastibl.net>>:
>>
>>
>> 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
>> Wi

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

[Bastian Bloessl]

Hi,

On 06/09/2017 05:14 PM, zhan siyu wrote:
Then how to explain the relationship between the 5M and the 115K bits/s 
throughput?


I cannot since I see absolutely no relationship. Maybe you want to 
explain (in detail) why you think these numbers should match.



Best,
Bastian





Best regards.

Siyu


2017-06-08 21:41 GMT+08:00 Bastian Bloessl >:


Hi,

On 06/07/2017 02:32 PM, zhan siyu wrote:

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?


I'm afraid I can't help a lot, since I have no idea what iperf is
doing. I guess it floods the network stack with UDP packets. The GNU
Radio transceiver, however, has no back pressure mechanism, so it
will just drop the frames when they are injected into the GNU Radio
flow graph.

Also, I don't understand what exact analytical number you are trying
to reproduce here. In fact, I have no idea what this experiment is
supposed to show/prove or what part of the transceiver you are
trying to profile. If, at all, this experiment will tell you how
fast the TX-side can produce frames.

This was investigated in

Gonzalo Arcos, Rodrigo Ferreri, Matías Richart, Pablo Ezzatti and
Eduardo Grampín, "Accelerating an IEEE 802.11 a/g/p Transceiver in
GNU Radio," Proceedings of 9th Latin America Networking Conference
(LANC'16), Valparaíso, Chile, October 2016, pp. 13-19.

Turns out, you can improve the TX-side by improving the OFDM Carrier
Allocator.

Best,
Bastian



Best regards.

Siyu

2017-06-07 14:02 GMT+08:00 Bastian Bloessl mailto:m...@bastibl.net> >>:


 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
mailto:m...@bastibl.net>
 >


 

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

[zhan siyu]

Hi Bastian,

Thanks for reply. I know they are two different values. 5M is for
the physical layer and 115K bits/s is for the application layer.  The
application layer's upper bound should be the physical layer. So the value
of application layer should always be less than the physical layer' s.
However, I think my program is right which can take as much as the physical
layer bandwidth can support. You can see my program's result. The 802.11
average speed is 22Mb/s and I can get 15Mb/s. So I think, as the bandwidth
is 5M, then the coding rate should be 5/3 = 1.67M bits/s. So I expect a
throughput around 1M b/s.  But the result is just 1/10 of my expection. Too
far away. I'm new to the communication. Not sure if I'm right. Please
correct me if I'm wrong.

My professor wants me to use it in his prototype, please help me. And could
you tell me if there is any software which can correctly measure the
physical layer bit rate?

Best regards.

Siyu

2017-06-10 1:08 GMT+08:00 Bastian Bloessl :

> Hi,
>
> On 06/09/2017 05:14 PM, zhan siyu wrote:
>
>> Then how to explain the relationship between the 5M and the 115K bits/s
>> throughput?
>>
>
> I cannot since I see absolutely no relationship. Maybe you want to explain
> (in detail) why you think these numbers should match.
>
>
> Best,
> Bastian
>
>
>
>
>> Best regards.
>>
>> Siyu
>>
>>
>> 2017-06-08 21:41 GMT+08:00 Bastian Bloessl > m...@bastibl.net>>:
>>
>>
>> Hi,
>>
>> On 06/07/2017 02:32 PM, zhan siyu wrote:
>>
>> 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?
>>
>>
>> I'm afraid I can't help a lot, since I have no idea what iperf is
>> doing. I guess it floods the network stack with UDP packets. The GNU
>> Radio transceiver, however, has no back pressure mechanism, so it
>> will just drop the frames when they are injected into the GNU Radio
>> flow graph.
>>
>> Also, I don't understand what exact analytical number you are trying
>> to reproduce here. In fact, I have no idea what this experiment is
>> supposed to show/prove or what part of the transceiver you are
>> trying to profile. If, at all, this experiment will tell you how
>> fast the TX-side can produce frames.
>>
>> This was investigated in
>>
>> Gonzalo Arcos, Rodrigo Ferreri, Matías Richart, Pablo Ezzatti and
>> Eduardo Grampín, "Accelerating an IEEE 802.11 a/g/p Transceiver in
>> GNU Radio," Proceedings of 9th Latin America Networking Conference
>> (LANC'16), Valparaíso, Chile, October 2016, pp. 13-19.
>>
>> Turns out, you can improve the TX-side by improving the OFDM Carrier
>> Allocator.
>>
>> Best,
>> Bastian
>>
>>
>>
>> Best regards.
>>
>> Siyu
>>
>> 2017-06-07 14:02 GMT+08:00 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.