Re: [Discuss-gnuradio] strange deterministic frame error in gr-ieee802-11

[Bastian Bloessl]

Hi,

On 01/16/2017 05:37 AM, Nikita Airee wrote:

I haven't modified the flowgraphs from the examples folder at all,
except changing the variables/values for the experiment. It is for those
original flowgraphs of wifi_tx and wifi_rx that I get the deterministic
error.

Besides checking the gnuradio threads, is there anything else I could do
to find the cause for such errors?



My current understanding is that simulations work as expected, but 
experiments show deterministic errors.


I would:

- Make sure that there are no overruns or underruns. Disable all logging 
to the console and ensure that there are really no 'U's and 'O's.
- Try on a different frequency (just to make sure that there is no weird 
device).

- Make sure that the xy plot shows clear constellations.


tx_gain is set to 30dB and rx_gain to 0.


If constellations don't look nice, you could try lowering the tx and 
increasing the rx gain. (also make sure that the antennas are connected 
to the correct ports).



Best,
Bastian






Bests,
Nikita

On Sun, Jan 15, 2017 at 2:26 PM, Bastian Bloessl > wrote:

Hi,

On 01/15/2017 07:03 AM, Nikita Airee wrote:

The packet padding was enabled when I ran the flowgraph earlier
with the
pad front/back set to the default values of 1000/100. So I
increased the
values of the padding which lead to some improvement. However those
warnings wouldn't go away compeletely for values as high as
1 zeros.
I compared my flowgraph (PFA: wifi_tx_rx_jan) to the loopback in the
examples folder and couldn't find any difference besides the
fact the 3
blocks for channel effects(multiply const, channel model and
polyphase
resampler) were not present between the tx and the rx part
initially.
With these blocks in between, the frame rate of 10/s doesn't lead to
those warnings. Is that what going wrong or the presence of a
channel
shouldn't matter?


The receiver calculates the autocorrelation coefficient to detect
frames. If you pad 0's, it will constantly divide by zero, leading
to nondeterminism. With a bit noise (added by the channel model),
this is avoided.

I have yet to check for the threads, which I will only be able to do
tomorrow as I dont have access the hardware today.
Should I upload more of the project?


Depends. If simulations work as expected that will not help much.
I would recommend to start the hardware experiments with the
(unmodified) flow graphs from the examples folder and test whether
they also cause this deterministic errors.

Best,
Bastian



Thanks again for your help Bastian,
Nikita


On Fri, Jan 13, 2017 at 10:39 PM, Bastian Bloessl

');>> wrote:

Hi

On 01/13/2017 05:50 PM, Nikita Airee wrote:
> Thanks for your prompt response!
>
> I have tried connecting the wifi_tx and wifi_rx in loopback
> configuration. At 10Packets/s, it would give me a lot of
"Warning:
> starting to receive new frame before old frame was
complete" messages.

You should pad some 0's between frames (as in the example
loopback flow
graph). Otherwise, frames are really back to back in
simulations.

> So quite a lot of packets didn't reach the MAC decoding stage.
> To eliminate the above warning completely, I had to
increase the
> interval to 20s. But then these sequence numbers have
correct checksum
> values.

This is very strange. Something seems to go horribly wrong
in software,
as these simulations shouldn't depend at all on the frame
rate. Maybe
you could check for threads that are in a live-lock (are
always at 100%
even if nothing is sent).

I would recommend to try the (unmodified) loopback flow
graph in the
examples directory and, then, make your modifications step
by step to
see where it goes wrong.



> There is no under/overflow at the tx/rx in this
configuration.I believe
> this channel to be quite clean, I checked with the IT
department of my
> institute and also listened to the channel using a
spectrum analyzer.
> Even if it weren't, you are right that it shouldn't mess
up the same
> sequence numbers every time.

Could you maybe upload your project? Or produce a minimal
example for
the problem.

Best,

Re: [Discuss-gnuradio] strange deterministic frame error in gr-ieee802-11

[Nikita Airee]

I haven't modified the flowgraphs from the examples folder at all, except
changing the variables/values for the experiment. It is for those original
flowgraphs of wifi_tx and wifi_rx that I get the deterministic error.

Besides checking the gnuradio threads, is there anything else I could do to
find the cause for such errors?

Bests,
Nikita

On Sun, Jan 15, 2017 at 2:26 PM, Bastian Bloessl 
wrote:

> Hi,
>
> On 01/15/2017 07:03 AM, Nikita Airee wrote:
>
>> The packet padding was enabled when I ran the flowgraph earlier with the
>> pad front/back set to the default values of 1000/100. So I increased the
>> values of the padding which lead to some improvement. However those
>> warnings wouldn't go away compeletely for values as high as 1 zeros.
>> I compared my flowgraph (PFA: wifi_tx_rx_jan) to the loopback in the
>> examples folder and couldn't find any difference besides the fact the 3
>> blocks for channel effects(multiply const, channel model and polyphase
>> resampler) were not present between the tx and the rx part initially.
>> With these blocks in between, the frame rate of 10/s doesn't lead to
>> those warnings. Is that what going wrong or the presence of a channel
>> shouldn't matter?
>>
>
> The receiver calculates the autocorrelation coefficient to detect frames.
> If you pad 0's, it will constantly divide by zero, leading to
> nondeterminism. With a bit noise (added by the channel model), this is
> avoided.
>
> I have yet to check for the threads, which I will only be able to do
>> tomorrow as I dont have access the hardware today.
>> Should I upload more of the project?
>>
>
> Depends. If simulations work as expected that will not help much.
> I would recommend to start the hardware experiments with the (unmodified)
> flow graphs from the examples folder and test whether they also cause this
> deterministic errors.
>
> Best,
> Bastian
>
>
>
>> Thanks again for your help Bastian,
>> Nikita
>>
>>
>> On Fri, Jan 13, 2017 at 10:39 PM, Bastian Bloessl > > wrote:
>>
>> Hi
>>
>> On 01/13/2017 05:50 PM, Nikita Airee wrote:
>> > Thanks for your prompt response!
>> >
>> > I have tried connecting the wifi_tx and wifi_rx in loopback
>> > configuration. At 10Packets/s, it would give me a lot of "Warning:
>> > starting to receive new frame before old frame was complete"
>> messages.
>>
>> You should pad some 0's between frames (as in the example loopback
>> flow
>> graph). Otherwise, frames are really back to back in simulations.
>>
>> > So quite a lot of packets didn't reach the MAC decoding stage.
>> > To eliminate the above warning completely, I had to increase the
>> > interval to 20s. But then these sequence numbers have correct
>> checksum
>> > values.
>>
>> This is very strange. Something seems to go horribly wrong in
>> software,
>> as these simulations shouldn't depend at all on the frame rate. Maybe
>> you could check for threads that are in a live-lock (are always at
>> 100%
>> even if nothing is sent).
>>
>> I would recommend to try the (unmodified) loopback flow graph in the
>> examples directory and, then, make your modifications step by step to
>> see where it goes wrong.
>>
>>
>>
>> > There is no under/overflow at the tx/rx in this configuration.I
>> believe
>> > this channel to be quite clean, I checked with the IT department of
>> my
>> > institute and also listened to the channel using a spectrum
>> analyzer.
>> > Even if it weren't, you are right that it shouldn't mess up the same
>> > sequence numbers every time.
>>
>> Could you maybe upload your project? Or produce a minimal example for
>> the problem.
>>
>> Best,
>> Bastian
>>
>> > Is there something else I could look into?
>> >
>> > Bests,
>> > Nikita
>> >
>> > On Fri, Jan 13, 2017 at 8:30 PM, Bastian Bloessl <
>> bloe...@ccs-labs.org
>> 
>> > >
>> >> wrote:
>> >
>> > Hi,
>> >
>> > On 01/13/2017 11:17 AM, Nikita Airee wrote:
>> > > Hi everyone!
>> > >
>> > >   * Ubuntu 14.04
>> > >   * Gnuradio version : 3.7.10.1, UHD_3.11.0.git-28-gc66cb1ba
>> > >   * 2 USRP 2953R(x310 + cbx40) connected to host laptops
>> using pcie
>> > > cable, antennae=vert2450
>> > >   * center frequency=2.484GHz, samp_rate=10MHz
>> > >
>> > >  I have been transmitting at the rate of 10 Packets/s over
>> wireless link
>> > > with distance between the tx and rx 3m and 6m. tx_gain is
>> set to 30dB
>> > > and rx_gain to 0. (I have varied these gains to find no
>> improvement).
>> > > I get a constant total frame error rate at the receiver 

Re: [Discuss-gnuradio] Profiling Gnuradio message based blocks

[Jacob Gilbert]

Hi Emanuel,

This is related to a larger issue in which the controlport interface (used
for performance monitoring in addition to other features) is only started
for blocks with at least one stream connection. I submitted a PR for this (
https://github.com/gnuradio/gnuradio/pull/1119) which be included in the
upcoming 3.7.10.2 but if you want it now you can easily patch it in.

Jacob


On Fri, Jan 13, 2017 at 1:13 AM,  wrote:

> Hi all,
>
>
>
> I managed to get Apache thrift up and running and configured by
> environment to use the control port and performance counters.
> gr-perf-monitorx works fine and shows me my flowgraph as intended.
>
> My flowgraph consists of several streaming based blocks and many purely
> message based blocks (message in / message out) between a USRP source and a
> USRP sink.
>
>
>
> My question now is: are purely message based blocks without a work
> function correctly profiled as well?
>
>
>
> I see my  message blocks appearing in the gr-perf-monitorx visualizer with
> a box around, where the box size indicates the runtime usage. However when
> I switch the view to the runtime table and have a look there, I do not see
> my purely message based blocks in the table. Only those blocks which have
> at least one streaming interface are visible there. Any ideas?
>
>
>
> Thanks in advance and thanks to Thomas Rondau et. al. for this kind of
> profiling functionality. A very convenient tool indeed.
>
>
>
> Regards,
>
> Emanuel
>
> ___
> 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] GNUradio not working with SDRplay in Windows10

[Marcus Müller]

Dear Arie,

this again stresses how important your role as customer is! Go, and
write an honest email, maybe it's really all it takes to make SDRPlay
reconsider licensing.

Best regards,

Marcus


On 15.01.2017 16:35, Geof Nieboer wrote:
> Just to chime in to confirm, 
>
> SDRPlay support is not included in the windows build for 3.7.8.1 at
> this time.
>
> As Marcus said, since this driver is not GPL compatible, it can not be
> directly included in the installer, so it's a low priority to consider.
>
> Geof
>
>
>
> On Sat, Jan 14, 2017 at 12:18 PM, Arie Kleingeld PA3A  > wrote:
>
> Thanks for your advice guys.
>
> I will continue working on getting a solution for this.
>
> Kind regards,
>
> Arie
>
>
>
>
> ___
> 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] GNUradio not working with SDRplay in Windows10

[Geof Nieboer]

Just to chime in to confirm,

SDRPlay support is not included in the windows build for 3.7.8.1 at this
time.

As Marcus said, since this driver is not GPL compatible, it can not be
directly included in the installer, so it's a low priority to consider.

Geof



On Sat, Jan 14, 2017 at 12:18 PM, Arie Kleingeld PA3A 
wrote:

> Thanks for your advice guys.
>
> I will continue working on getting a solution for this.
>
> Kind regards,
>
> Arie
>
>
>
>
> ___
> 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] strange deterministic frame error in gr-ieee802-11

[Bastian Bloessl]

Hi,

On 01/15/2017 07:03 AM, Nikita Airee wrote:

The packet padding was enabled when I ran the flowgraph earlier with the
pad front/back set to the default values of 1000/100. So I increased the
values of the padding which lead to some improvement. However those
warnings wouldn't go away compeletely for values as high as 1 zeros.
I compared my flowgraph (PFA: wifi_tx_rx_jan) to the loopback in the
examples folder and couldn't find any difference besides the fact the 3
blocks for channel effects(multiply const, channel model and polyphase
resampler) were not present between the tx and the rx part initially.
With these blocks in between, the frame rate of 10/s doesn't lead to
those warnings. Is that what going wrong or the presence of a channel
shouldn't matter?


The receiver calculates the autocorrelation coefficient to detect 
frames. If you pad 0's, it will constantly divide by zero, leading to 
nondeterminism. With a bit noise (added by the channel model), this is 
avoided.



I have yet to check for the threads, which I will only be able to do
tomorrow as I dont have access the hardware today.
Should I upload more of the project?


Depends. If simulations work as expected that will not help much.
I would recommend to start the hardware experiments with the 
(unmodified) flow graphs from the examples folder and test whether they 
also cause this deterministic errors.


Best,
Bastian




Thanks again for your help Bastian,
Nikita


On Fri, Jan 13, 2017 at 10:39 PM, Bastian Bloessl > wrote:

Hi

On 01/13/2017 05:50 PM, Nikita Airee wrote:
> Thanks for your prompt response!
>
> I have tried connecting the wifi_tx and wifi_rx in loopback
> configuration. At 10Packets/s, it would give me a lot of "Warning:
> starting to receive new frame before old frame was complete" messages.

You should pad some 0's between frames (as in the example loopback flow
graph). Otherwise, frames are really back to back in simulations.

> So quite a lot of packets didn't reach the MAC decoding stage.
> To eliminate the above warning completely, I had to increase the
> interval to 20s. But then these sequence numbers have correct checksum
> values.

This is very strange. Something seems to go horribly wrong in software,
as these simulations shouldn't depend at all on the frame rate. Maybe
you could check for threads that are in a live-lock (are always at 100%
even if nothing is sent).

I would recommend to try the (unmodified) loopback flow graph in the
examples directory and, then, make your modifications step by step to
see where it goes wrong.



> There is no under/overflow at the tx/rx in this configuration.I believe
> this channel to be quite clean, I checked with the IT department of my
> institute and also listened to the channel using a spectrum analyzer.
> Even if it weren't, you are right that it shouldn't mess up the same
> sequence numbers every time.

Could you maybe upload your project? Or produce a minimal example for
the problem.

Best,
Bastian

> Is there something else I could look into?
>
> Bests,
> Nikita
>
> On Fri, Jan 13, 2017 at 8:30 PM, Bastian Bloessl 
> >> wrote:
>
> Hi,
>
> On 01/13/2017 11:17 AM, Nikita Airee wrote:
> > Hi everyone!
> >
> >   * Ubuntu 14.04
> >   * Gnuradio version : 3.7.10.1, UHD_3.11.0.git-28-gc66cb1ba
> >   * 2 USRP 2953R(x310 + cbx40) connected to host laptops
using pcie
> > cable, antennae=vert2450
> >   * center frequency=2.484GHz, samp_rate=10MHz
> >
> >  I have been transmitting at the rate of 10 Packets/s over
wireless link
> > with distance between the tx and rx 3m and 6m. tx_gain is
set to 30dB
> > and rx_gain to 0. (I have varied these gains to find no
improvement).
> > I get a constant total frame error rate at the receiver ~10%
for a
> > payload of size 50 bytes. The problem is that the frames for
which the
> > checksum fails are always the same sequence
> > numbers(10,12,31,39,49,58,89,93,94,95...).
> > I have tried the different channel estimation algorithms and
tried
> > sending the same packet(seq number 0) over and over but
still the same
> > numbers are are dropped. I have also increased the interval
between
> > transmission to no affect.
>
> really strange that always the same frames are lost. Can you
run the
> flow graph in loopback mode without any hardware (i.e.,
connect RX to TX
> in GRC), just to rule out any software issues.