[Discuss-gnuradio] Build failing on Ubuntu 18.04

[Anshul Thakur]

Hi all,

I just finished installing Ubuntu 18.04 on one of my systems and tried
installing GNURadio using pybombs. The build seems to be misbehaving and
isn't fully unattended.

Mine is an x86_64 machine.

1. UHD: For some reason, cmake starts to use 'pthreads' instead of
'pthread' and the system cannot find it. Commented it out of the recipe as
I won't be using a UHD device for now.

2. Apache-thrift cannot find libcrypto with BN_init defined in it, despite
it being installed libssl-dev. Optional component, so the installation
continues.


Could someone verify if it is just me or it is a generic problem?

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

[Discuss-gnuradio] Unused Message port in 'Chunks to Symbols' block?

[Anshul Thakur]

Hi all,

I am trying to implement an adaptive modulation scheme for OFDM using the
example ofdm_tx as initial source. To change the modulation scheme
dynamically, I am thinking of changing the Symbol Table in the block
'Chunks to Symbols' for the Payload.

a. Does this approach sound correct? Suggestions?

b. I noticed that in the implementation of the
chunks_to_symbols_bc_impl.cc, we do register an in port 'set_symbol_table',
but a template for using that port has not been defined in the
'digital_chunks_to_symbols.xml'. Is this intentional, or am I missing
something? 'set_symbol_table' is also a method defined to set the symbol
table on change of the class attribute (using callbacks?)

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

Re: [Discuss-gnuradio] Setting up OOT module to include/extend another OOT Module class

[Anshul Thakur]

I tried modifying the gr-osmosdr source to add the message sink in the
source_impl.cc. Turns out, we cannot have message passing in hierarchical
blocks as discussed in this post:

https://lists.gnu.org/archive/html/discuss-gnuradio/2016-01/msg00291.html

and this one:

https://lists.gnu.org/archive/html/discuss-gnuradio/2015-10/msg8.html

Now, what other options do I have? Is it possible to connect to a message
port insde the hierarchical block from outside?

Warm regards,
Anshul

Warm regards,
Anshul Thakur

On 5 April 2018 at 21:33, Anshul Thakur <anshultha...@rediffmail.com> wrote:

> I am trying to extend the gr-osmosdr source block with a PMT message sink
> to send messages to it during runtime (to say, change the sample rate). I
> intend to develop this as a part of a differnt OOT module.
>
> How do I add such dependencies in the CMake list? (I am not very
> conversant with Cmake)
>
> Is there a good tutorial demonstrating one such example?
>
> Regards,
> Anshul
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Setting up OOT module to include/extend another OOT Module class

[Anshul Thakur]

I am trying to extend the gr-osmosdr source block with a PMT message sink
to send messages to it during runtime (to say, change the sample rate). I
intend to develop this as a part of a differnt OOT module.

How do I add such dependencies in the CMake list? (I am not very conversant
with Cmake)

Is there a good tutorial demonstrating one such example?

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

Re: [Discuss-gnuradio] Avoiding divide by zero in case of input being zero.

[Anshul Thakur]

Hi Gilad,

You are correct about getting zeros when using history and I am using
history. But, I am accounting for that by using the offset:

const gr_complex *current = (const gr_complex *)&((const gr_complex
*)input_items[0])[(history() -1)];

Also, if that is the case, shouldn't the behaviour be consistent across
unit-tests and flowgraph usage?

Regarding getting 0s from the device, I went through the discussion. I
agree to it. So, I'll have to account for the zero values. Any ideas on how
to do that?

The reason why I don't want to use an 'if' block is simply because the
situation of 0 values is expected to share a very small fraction of the
entire run and
to handle that small case, the regular cases will also necessarily have to
go through that additional 'if' check. I wanted to avoid that.

Regards,
Anshul

On 31 March 2018 at 10:37, Gilad Beeri (ApolloShield) <
gi...@apolloshield.com> wrote:

> Disclosure: I haven't looked at your code.
>
> 0 values can be presented in GNU Radio when you use history, because if
> your history is N, the first N-1 items are going to be zeros.
>
> Anyway, regarding your comment "it is not expected that a device/stream
> would ever spit out zero values.",
> I did have 0 values from a USRP device, see discussion in
> http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2017-October/026851.html.
>
>
>
> On Sat, Mar 31, 2018 at 6:52 AM Anshul Thakur <anshultha...@rediffmail.com>
> wrote:
>
>> Michael, Marcus,
>>
>> Right now, the code is a work in progress so I haven't made a git
>> repository out of it. However, I have it on dropbox. Here's the link to the
>> source folder(p1_detector_impl.cc is the source in question):
>>
>> *https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0
>> <https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0>*
>>
>> As for Marcus's question regarding why use a circular buffer?
>>
>> It isn't exactly a circular buffer now, but more of a shift register. The
>> reasons are as follows:
>> 1. I needed running sums for correlations in B-Branch and C-Branch
>> correlators, and Power Sums (for average power) to normalize them. Then, I
>> also needed a finite delay buffer to delay the C-Branch before it gets
>> multiplied with the B-Branch.
>> 2. It kind of carried over from the last implementation attempt:
>>
>> Assertion: If a peak is detected after the multiplication, the signal
>> boundary is 1024 samples behind that index.
>>
>> Once the correlations crossed a threshold (the code entered state=1), 
>> *instead
>> of looking back, I then needed to look forward to see if it were a false
>> alarm or not*. So, I compute the correlations across all available
>> current inputs and try to find a peak. If a peak is found, enter state=3
>> where we do a correlation with the carrier distribution sequence after FFT
>> of all signals of interest. So, here, I not only needed just the single
>> value (the running sum), but the entire state of the delay register and the
>> B-Branch correlator.
>>
>> I hope I am able to convey the reason for implementing one myself.
>>
>> In the current implementation, I make an assumption that the threshold is
>> so high that only the desired signals would cross it (100-150 times the
>> average). So I skip the state=1 logic and directly go into state=2 logic of
>> aggressively doing a FFT and correlation with the CDS.
>>
>> However, I don't think this has a binding on the incoming values. Use of
>> buffers is internal to the implementation, I am just printing out the
>> current values as they arrive.
>>
>> For example, when I use the test file in 'make test', the values fed in
>> are non-zero from t=1. However, when using gnuradio-companion, t=56 line is
>> where the file source starts yielding proper inputs to my block. The stdout
>> prints of the initial values in both GRC and make tests are attached. The
>> gnuradio-companion version has my first 55 samples zeroed and the 56th
>> input onward is then same for both.
>>
>>
>> P.S.: The source stream is a 1.2 Gigs file, so haven't uploaded it. If
>> you'd like I can do that too. It was generated by using a DVB-T2 Tx block
>> and writing the output into a file sink.
>>
>> Warm regards,
>> Anshul Thakur
>>
>> On 31 March 2018 at 02:27, Müller, Marcus (CEL) <muel...@kit.edu> wrote:
>>
>>> Hi Anshul,
>>>
>>> you shouldn't have to have your own buffer for a running sum – can you
>>> explain why you're doing that?
>>> A running sum can tri

Re: [Discuss-gnuradio] Avoiding divide by zero in case of input being zero.

[Anshul Thakur]

Michael, Marcus,

Right now, the code is a work in progress so I haven't made a git
repository out of it. However, I have it on dropbox. Here's the link to the
source folder(p1_detector_impl.cc is the source in question):

*https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0
<https://www.dropbox.com/sh/blfmxsaidrkh28t/AAArp8IHavzCGFlJs6E6-Hrca?dl=0>*

As for Marcus's question regarding why use a circular buffer?

It isn't exactly a circular buffer now, but more of a shift register. The
reasons are as follows:
1. I needed running sums for correlations in B-Branch and C-Branch
correlators, and Power Sums (for average power) to normalize them. Then, I
also needed a finite delay buffer to delay the C-Branch before it gets
multiplied with the B-Branch.
2. It kind of carried over from the last implementation attempt:

Assertion: If a peak is detected after the multiplication, the signal
boundary is 1024 samples behind that index.

Once the correlations crossed a threshold (the code entered state=1), *instead
of looking back, I then needed to look forward to see if it were a false
alarm or not*. So, I compute the correlations across all available current
inputs and try to find a peak. If a peak is found, enter state=3 where we
do a correlation with the carrier distribution sequence after FFT of all
signals of interest. So, here, I not only needed just the single value (the
running sum), but the entire state of the delay register and the B-Branch
correlator.

I hope I am able to convey the reason for implementing one myself.

In the current implementation, I make an assumption that the threshold is
so high that only the desired signals would cross it (100-150 times the
average). So I skip the state=1 logic and directly go into state=2 logic of
aggressively doing a FFT and correlation with the CDS.

However, I don't think this has a binding on the incoming values. Use of
buffers is internal to the implementation, I am just printing out the
current values as they arrive.

For example, when I use the test file in 'make test', the values fed in are
non-zero from t=1. However, when using gnuradio-companion, t=56 line is
where the file source starts yielding proper inputs to my block. The stdout
prints of the initial values in both GRC and make tests are attached. The
gnuradio-companion version has my first 55 samples zeroed and the 56th
input onward is then same for both.


P.S.: The source stream is a 1.2 Gigs file, so haven't uploaded it. If
you'd like I can do that too. It was generated by using a DVB-T2 Tx block
and writing the output into a file sink.

Warm regards,
Anshul Thakur

On 31 March 2018 at 02:27, Müller, Marcus (CEL) <muel...@kit.edu> wrote:

> Hi Anshul,
>
> you shouldn't have to have your own buffer for a running sum – can you
> explain why you're doing that?
> A running sum can trivially be implemented with the IIR filter block
> with Feed-Forward taps (1,) and Feed-back taps (1,0)!
> Where does in a running sum does a division take place?
>
> > (a) Why am I getting the initial zero samples from the file block in
> > gnuradio_companion and non-zero values when using a vector_source in
> > unit tests?
>
> If these zeros are not in the file you're reading, your block has a
> bug!
>
>
> > (b) What can I do about it (here specifically as a fix to the
> > situation, and a general guideline to always remember)?
>
> good question, but we'd need to know your code, your motivation for a
> circular buffer, and why you're implementing a running sum yourself!
>
> Best regards,
> Marcus
>
> On Fri, 2018-03-30 at 23:19 +0530, Anshul Thakur wrote:
> > Hi,
> >
> > I used a circular buffer of finite size to keep the past 'N' power
> > values of the sample stream in my block as a part of creating a
> > running sum. This buffer is initialized to 0 in the constructor.
> > The running sum of powers is used to compute the average power used
> > in computing signal correlation.
> >
> > I have a capture stream (cfile) to test the operation of the block.
> > The test case uses a vector_source_c block to read the contents of
> > the file into memory. The unit tests pass without error.
> >
> > However, when I use the block in a flowgraph in that reads the same
> > file from a file source block gnuradio_companion, I am getting the
> > first few sample values as 0 which cause a divide by zero
> > problem. This messes up the rest of the running sum. I don't want to
> > put an 'if' block that checks for the zero condition as it is not
> > expected that a device/stream would ever spit out zero values.
> >
> > (a) Why am I getting the initial zero samples from the file block in
> > gnuradio_companion and non-zero values when using a vec

[Discuss-gnuradio] Avoiding divide by zero in case of input being zero.

[Anshul Thakur]

Hi,

I used a circular buffer of finite size to keep the past 'N' power values
of the sample stream in my block as a part of creating a running sum. This
buffer is initialized to 0 in the constructor.
The running sum of powers is used to compute the average power used in
computing signal correlation.

I have a capture stream (cfile) to test the operation of the block. The
test case uses a vector_source_c block to read the contents of the file
into memory. The unit tests pass without error.

However, when I use the block in a flowgraph in that reads the same file
from a file source block gnuradio_companion, I am getting the first few
sample values as 0 which cause a divide by zero problem. This messes up the
rest of the running sum. I don't want to put an 'if' block that checks for
the zero condition as it is not expected that a device/stream would ever
spit out zero values.

(a) Why am I getting the initial zero samples from the file block in
gnuradio_companion and non-zero values when using a vector_source in unit
tests?

(b) What can I do about it (here specifically as a fix to the situation,
and a general guideline to always remember)?

I am using GNURadio version 3.7.12.

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

Re: [Discuss-gnuradio] Signal start (timing acquisition) in DVB-T2

[Anshul Thakur]

Hi Marcus,

So I did an implementation using a similar logic as in gr-cdma
(courtesy Achilleas)
after smoothening the input. Once the correlation rose above a threshold, I
essentially started taking 1K point FFTs and correlated the power
distribution with the Carrier Distribution Sequence as specified in the
standard [1].  By doing this, I am able to find the peak position and
likewise, a more refined window of where the P1 symbol would be starting.

Now, for the frequency offset correction part, I am confused as to what it
should be. The standard says:

*The argument of the 'correlator' outputs contains information about the
fine frequency offset, but also the unknown*
*arbitrary phase (with respect to the transmitter) of the down-shifter
oscillator. By multiplying the two correlator pulsesas shown, the effect of
the unknown arbitrary phase is cancelled. The argument of the final output
pulse can be shownto be proportional to the 'fine' component of the
frequency offset.*

Mathematically, if each of my correlations in either branches had a
constant frequency offset of 'theta', then multiplying the two would have
given me (2*theta) while the random phase fluctuations are expected to have
cancelled. In that case, should I be dividing the argument by 2 to get to
my frequency offset?

Also, should I take the argument of the index at which peak was detected as
my frequency-offset, or should it be an average of something? Actually,
I've tried using the phase value at the peak directly, but it does not lead
to a meaningful P1 pre-signaling signal after DBPSK demodulation [2].

[1] DVBT2 Implementation Guidelines, Section 10.2.2.6 P1 Validation
[2] DVBT2 Standard ETSI EN 302 755 V1.4.1, Section 9.8.2.2

Warm regards,
Anshul Thakur

On 15 March 2018 at 22:29, Anshul Thakur <anshultha...@rediffmail.com>
wrote:

> Hi Marcus,
>
> Thank you for your inputs.
>
> On 13 March 2018 at 22:22, Müller, Marcus (CEL) <muel...@kit.edu> wrote:
>
>> Hi Anshul,
>>
>> do you normalize your correlation by the received signal power in that
>> same window?
>>
>
> No. I wasn't normalizing the correlations. I'm using the image attached as
> reference design.
> I guess I got a little excited to see the peaks in Matlab that I did not
> even consider the energy of the signal as a possible normalization
> denominator.  :D
>
>
> ​
>
>
>> How's your frequency correction doing? If you don't have frequency
>> detection at that point, your signal might get decorrelated.
>>
>
> The preamble detection step itself is supposed to find a coarse
> frequency-offset which must be
> further refined by correlation with the Carrier-Distribution-Sequence(cds)
> in the next step. So, no, currently, there is no frequency correction as
> per se.
>
>
>>
>> You can solve both by employing a fixed delay correlation of your
>> receive signal; IIRC, P1 is roughly split into three parts: A middle
>> part that repeats in the front and at the end of the symbol. Let's say
>> that repeated part in the front is N samples long. Take these N,
>> correlate with the N that follow, divide by the power of these samples.
>>
>
> Correct. I was not dividing by the power. I did that and the slopes have
> become more smooth except occasional blips over a single sample.
> I am correcting for these occasional blips by comparing my current value
> with the running average a small previous window (5 samples currently), the
> reasoning being -
> If the signal is rising fairly consistently, the current value will be
> greater than the average of what came in the short term past.
> By doing so, I am able to get a coarse window of prospective sample ranges
> where the signal might be starting.
>
> I will now try to filter them further by correlating with the CDS and
> revert back if I run into more trouble. Many thanks!
>
>
>>
>> You'll not only get a value that should be independent from absolute
>> receive signal strength (as long as fading is not faster than ¼ of the
>> P1 length), and as a bonus, the correlation coefficient's phase allows
>> for a relatively robust frequency offset estimate. You can use that
>> estimate to correct your receive signal and get a better detection
>> result :)
>
> Best regards,
>> Marcus
>>
>> On Tue, 2018-03-13 at 20:38 +0530, Anshul Thakur wrote:
>> > Hello all,
>> >
>> > I am trying to implement a DVB-T2 receiver's P1 symbol detection block
>> using C++ in GNURadio. From a non-real time code in MATLAB, I can see that
>> the correlation peaks during the P1 symbols are almost 50 to 100 times
>> larger than the rest of the time. This rise is not steep in consecutive
>> samples.
>> >
>> > However,

Re: [Discuss-gnuradio] Signal start (timing acquisition) in DVB-T2

[Anshul Thakur]

Hi Achilleas,

Thank you for this. Incidentally, this code matches the peak detection
algorithm used in gr-dab too (and IIRC, gr-dtv dvbt Receiver too).

Though this code doesn't explicitly remedy the problem I was facing, it
still has a fairly good implementation (post data-smoothening). I'll use
the understanding from this implementation into my own implementation too.

As for the smoothening problem, Marcus's prompt about normalizing the
correlations with signal energy worked for me. I'll keep you posted. :)

On 13 March 2018 at 22:12, Achilleas Anastasopoulos 
wrote:

> Hi  Anshul,
>
> take a look at how acquisition is done on the gr-cdma OOT module
>
> https://github.com/anastas/gr-cdma
>
> It is using a MF followed by a peak finder to generate flags for
> the beginning of the frame which is them processed downstream.
>
>
> Achilleas
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Signal start (timing acquisition) in DVB-T2

[Anshul Thakur]

Hi Marcus,

Thank you for your inputs.

On 13 March 2018 at 22:22, Müller, Marcus (CEL) <muel...@kit.edu> wrote:

> Hi Anshul,
>
> do you normalize your correlation by the received signal power in that
> same window?
>

No. I wasn't normalizing the correlations. I'm using the image attached as
reference design.
I guess I got a little excited to see the peaks in Matlab that I did not
even consider the energy of the signal as a possible normalization
denominator.  :D


​


> How's your frequency correction doing? If you don't have frequency
> detection at that point, your signal might get decorrelated.
>

The preamble detection step itself is supposed to find a coarse
frequency-offset which must be
further refined by correlation with the Carrier-Distribution-Sequence(cds)
in the next step. So, no, currently, there is no frequency correction as
per se.


>
> You can solve both by employing a fixed delay correlation of your
> receive signal; IIRC, P1 is roughly split into three parts: A middle
> part that repeats in the front and at the end of the symbol. Let's say
> that repeated part in the front is N samples long. Take these N,
> correlate with the N that follow, divide by the power of these samples.
>

Correct. I was not dividing by the power. I did that and the slopes have
become more smooth except occasional blips over a single sample.
I am correcting for these occasional blips by comparing my current value
with the running average a small previous window (5 samples currently), the
reasoning being -
If the signal is rising fairly consistently, the current value will be
greater than the average of what came in the short term past.
By doing so, I am able to get a coarse window of prospective sample ranges
where the signal might be starting.

I will now try to filter them further by correlating with the CDS and
revert back if I run into more trouble. Many thanks!


>
> You'll not only get a value that should be independent from absolute
> receive signal strength (as long as fading is not faster than ¼ of the
> P1 length), and as a bonus, the correlation coefficient's phase allows
> for a relatively robust frequency offset estimate. You can use that
> estimate to correct your receive signal and get a better detection
> result :)

Best regards,
> Marcus
>
> On Tue, 2018-03-13 at 20:38 +0530, Anshul Thakur wrote:
> > Hello all,
> >
> > I am trying to implement a DVB-T2 receiver's P1 symbol detection block
> using C++ in GNURadio. From a non-real time code in MATLAB, I can see that
> the correlation peaks during the P1 symbols are almost 50 to 100 times
> larger than the rest of the time. This rise is not steep in consecutive
> samples.
> >
> > However, I am having trouble in implementing this as a kind of
> stream-algorithm that operates on blocks of data (like a real receiver
> would) rather than the entire thing (in GNU Radio, that is). The problem is
> thus:
> >
> > I want to detect when the signal correlation reaches its peak-plateau
> region. While the overall trend in correlations does rise, the consecutive
> values may fluctuate in both positive and negative directions due to
> noise/fading effects. I've tried a few rudimentary approaches:
> >
> > 1. Average the correlations over some period and see if the current
> average is greater than some sample at an offset in the history by a
> threshold value to term it as rising. While it can give some degree of
> rise, it is not very good at peak detection.
> >
> > 2. Keep a history of consecutive slopes in my block and use a small
> average. The fluctuations should die down and give some value near to 0.
> This doesn't seem to happen. The results are not satisfactory. Also, the
> consecutive slopes are also not that spectacular to contrast with the
> average case.
> >
> > Possibly, I need to use some smoothening and differentiator filter. Can
> you point to a sample implementation of a similar kind? Or give some more
> ideas I could experiment with?
> >
> >
> > Warm regards,
> > Anshul
> > ___
> > 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] Signal start (timing acquisition) in DVB-T2

[Anshul Thakur]

Hello all,

I am trying to implement a DVB-T2 receiver's P1 symbol detection block
using C++ in GNURadio. From a non-real time code in MATLAB, I can see that
the correlation peaks during the P1 symbols are almost 50 to 100 times
larger than the rest of the time. This rise is not steep in consecutive
samples.

However, I am having trouble in implementing this as a kind of
stream-algorithm that operates on blocks of data (like a real receiver
would) rather than the entire thing (in GNU Radio, that is). The problem is
thus:

I want to detect when the signal correlation reaches its
peak-plateau region. While the overall trend in correlations does rise, the
consecutive values may fluctuate in both positive and negative directions
due to noise/fading effects. I've tried a few rudimentary approaches:

1. Average the correlations over some period and see if the current average
is greater than some sample at an offset in the history by a threshold
value to term it as rising. While it can give some degree of rise, it is
not very good at peak detection.

2. Keep a history of consecutive slopes in my block and use a small
average. The fluctuations should die down and give some value near to 0.
This doesn't seem to happen. The results are not satisfactory. Also, the
consecutive slopes are also not that spectacular to contrast with the
average case.

Possibly, I need to use some smoothening and differentiator filter. Can you
point to a sample implementation of a similar kind? Or give some more ideas
I could experiment with?


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

Re: [Discuss-gnuradio] gr-ieee802_11 not able to send or receive packets.

[Anshul Thakur]

Hi,

I have for now circumvented the problem. But I did try looking into the
correlation values by logging the correlation after the divide block into a
file and inspecting the values in Matlab.

Here are some statistics:

Contiguous samples considered:  4.096e8;
# of samples with correlation > 0.7 : 2241
# of samples with correlation in (0.6, 0.7]: 2405
# of samples with correlation in (0.5, 0.6]: 14998

Threshold value considered in GNU RC block: 0.7

This was after removing all zero padding from delay block.

To get around the problem, I essentially used one of my SDRs as a dummy
repeater that just picked all samples at one frequency and transmitted them
at a different frequency. In this case, I was able to successfully receive
a large number of PDUs and decode them in wireshark. This begs the question
as to what I might be doing wrong with the original setup! Some more
pointers I could look at?

Also, when I use the Loopback flowgraph with no packet padding, I am unable
to receive any PDUs in wireshark. If I add some padding, they are detected.
Is that expected behaviour?

I took some pointers from this thread
http://gnuradio.4.n7.nabble.com/gr-ieee802-11-receiver-td63486.html#a63508

On 30 March 2017 at 01:56, Bastian Bloessl <m...@bastibl.net> wrote:

> Hi,
>
> On 03/29/2017 07:01 PM, Anshul Thakur wrote:
> >
> >
> > You could also test different RX/TX gains and parameters for the
> padding
> > block (I don't have a BladeRF, so I have no experience). Also assert
> > that there are no overruns or underruns.
> >
> > I altered the values of gains and padding values (I increased the
> > padding values). That didn't seem to help.
> >
>
> Actually, I was thinking of decreasing (or completely removing) it. Did
> you only try to increase it? Did you do anything else to debug? Like
> sending a stream of '0' and monitor the autocorrelation?
>
> Best,
> Bastian
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee802_11 not able to send or receive packets.

[Anshul Thakur]

Hi,

 > No output. What I see at Rx is a fairly continuous value of about
>> 1 unit.
>> I don't get that part.
>>
>>
>> Here's a screenshot.
>>
>
> I see, so you are basically receiving a DC spike.
>
>
>>
>> ​
>> The DC Offset correction has not been performed here. Could that be the
>> culprit?
>>
>
> Yes. Frame detection works based on the autocorrelation of the signal. The
> DC offset also has a high autocorrelation. The receiver, therefore,
> triggers frame processing for each and every sample, which totally
> overloads the PC. I would recommend to enable DC offset correction.
>
>
I tried to do manual DC Offset correction as much as possible. That did not
reduce the spike to zero. So, in the end I used a DC blocker with length
512 in front of the Osmocom source. By doing this, I am able to capture
packets from the Wifi Access Point and devices working in the same band.

With this, two parts work independently:
- I am able to Rx packets from Wifi using wifi_rx.py (however, it works
best only when I use it from the shell script provided. That is strange!).
- I am able to Tx packets from SDR which are detected by a Wifi card in
monitor mode.

However, When one SDR transmits and the other is receiving, I am not able
to receive the packets sent by the SDR.
- I tried it using wifi_rx shell script on one, and wifi_tx.py on the
other. PDUs from other Wifi Devices are detected.
- I also tried putting a direct line between the Tx of one SDR to Rx of the
other. Still no reception.

Are there some parameters which I could tweak to get this working? Or
something that I might be doing wrong?


Regards,
Anshul

On 26 March 2017 at 23:00, Bastian Bloessl <m...@bastibl.net> wrote:

> Hi,
>
> Am 26.03.2017 um 19:39 schrieb Anshul Thakur:
>
>> Can't do that, don't have the transverters to operate in that range.
>> bladeRF has a max of 3.8GHz out of the box. But would it be any
>> different if, keeping everything else the same, the frontend just
>> transmitted the waveforms on some different frequency (say in the
>> sub-GHz range) if both Rx and Tx bladeRFs are tuned to the same frequency?
>>
>
> You deleted the context, but this was for the case where the SDR was
> supposed to receive frames from a normal WiFi device. On the 2.4GHz band,
> you will have to make sure that the WiFi card sends OFDM frames. In the
> 5GHz band, it would work out of the box. So it could make a difference.
>
>
>>  > No output. What I see at Rx is a fairly continuous value of about
>> 1 unit.
>> I don't get that part.
>>
>>
>> Here's a screenshot.
>>
>
> I see, so you are basically receiving a DC spike.
>
>
>>
>> ​
>> The DC Offset correction has not been performed here. Could that be the
>> culprit?
>>
>
> Yes. Frame detection works based on the autocorrelation of the signal. The
> DC offset also has a high autocorrelation. The receiver, therefore,
> triggers frame processing for each and every sample, which totally
> overloads the PC. I would recommend to enable DC offset correction.
>
> Best,
> Bastian
>
>
> Here, packetspammer is transmitting PDUs in channel 2 (and the AP is
>> also in the same channel).
>>
>>
>>
>> On 26 March 2017 at 20:28, Bastian Bloessl <m...@bastibl.net
>> <mailto:m...@bastibl.net>> wrote:
>>
>> Hi,
>>
>> you should fix the sample rate to 20Msps. Normal WiFi uses 20MHz
>> channels, the other modes are for 11p or communication between SDRs.
>>
>> On 03/26/2017 02:51 PM, Anshul Thakur wrote:
>> > Hi all,
>> >
>> > I'm trying to use the gr-ieee802_11 module with bladeRFs to
>> receive/send
>> > Wifi packets. However, I am not able to receive anything. Might I
>> add, I
>> > am not sure if it is transmitting anything valid either. Here are
>> the
>> > things that I have done:
>> >
>> > 1. Replaced the USRP source/sink modules with osmocom source and
>> sinks
>> > respectively.
>> > 2. Generated the hierarchical block.
>> > 3. Run the wifi_loopback flowgraph and it seems to work. (I am not
>> sure
>> > what am I supposed to look at? It shows me the constellation plots
>> for
>> > various encodings when I change them, and not all of them are
>> distinct.
>> > For example, the 64 QAM 3/4 is very noisy and I believe the
>> estimators
>> > are having a hard time decoding it). Console shows packets of the
>> form:
>> >
>>

[Discuss-gnuradio] gr-ieee802_11 not able to send or receive packets.

[Anshul Thakur]

Hi all,

I'm trying to use the gr-ieee802_11 module with bladeRFs to receive/send
Wifi packets. However, I am not able to receive anything. Might I add, I am
not sure if it is transmitting anything valid either. Here are the things
that I have done:

1. Replaced the USRP source/sink modules with osmocom source and sinks
respectively.
2. Generated the hierarchical block.
3. Run the wifi_loopback flowgraph and it seems to work. (I am not sure
what am I supposed to look at? It shows me the constellation plots for
various encodings when I change them, and not all of them are distinct. For
example, the 64 QAM 3/4 is very noisy and I believe the estimators are
having a hard time decoding it). Console shows packets of the form:

new mac frame  (length 524)
=
duration: 00 00
frame control: 00 08 (DATA)
Subtype: Data
seq nr: 9
mac 1: 42:42:42:42:42:42
mac 2: 23:23:23:23:23:23
mac 3: ff:ff:ff:ff:ff:ff
instantaneous fer: 0


*WiFi Tx:*
1. Using wifi_tx.grc to transmit. I have not changed the s-mac, d-mac and
other parameters (does it matter?). The antenna is a Wideband BowTie Dipole
antenna. RF gain values tried are 3dB and 6dB.
2. Put my Wifi card (Netgear WNA1100 N150) into monitor mode and capturing
packets using Wireshark. Directly assigning a channel number did not work
reliably, so I first configured my Wifi AP and BladeRf Tx to use the same
channel before putting the device into monitor mode.

Using this setup, the bladeRF seems to be in use (the Tx LED blinks).
Wireshark seems to receive some malformed packets from time to time. Like,
I've set the PDU length to 200, but I seldom receive a malformed packet
with a length greater than 61. The packet is not decoded properly.

*Another scenario:*
1. Using wifi_tx.grc to transmit and wifi_rx.grc to receive.
Here, I've tried even a direct line between the Rx and Tx (Tx of the first
bladeRF connected to Rx of second with a -20dB attenuator in between). No
success here either.

Out of curiosity, I've tried to watch the FFT plot at the Rx bladeRF to see
if I can see power levels rise if some transmissions occur. The FFT plot is
at 4k FFT with a refresh rate of 20. It is totally silent. For comparison,
I tried to see the FFT plot of the Wifi band over the air also. It does
show some spiking activity from time to time (which begs the question, what
am I supposed to be looking at, but I'll ask that as a separate question).

*WiFi Rx:*
1. using wifi_rx.grc to receive.
2. Put Wifi card into monitor mode and used the packetspammer utility to
inject packets into it. Wireshark capture at the transmitting machine shows
packets being put on the interface. I also put my router into 802.11g mode
to see if that would work, but I am not sure if it is in pure g-mode or in
802.11b compatibility mode.

No output. What I see at Rx is a fairly continuous value of about 1 unit.

Tried these with all 5,10 and 20msps settings.

Could someone explain what I might be doing wrong?

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