[Discuss-gnuradio] Connecting USRP N210s with loopback kit - Still not receiving packets at higher sampling rate (above 5 MHz)

[Qurat-Ul-Ann Akbar]

Hi,

I previously posted about the possibility of connecting USRPs with a
loopback cable kit. I have connected the two USRPs with the loopback cable
kit to eliminate the wireless channel and low SNR problem but I am still
not receiving packets at higher sampling rates, anything above 5 MHz. It
works till 4 MHz but with a high packet error rate. What could be the
reason for this ?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IEEE 802.11 Transceiver Module - Timing offset at receiver side

[Qurat-Ul-Ann Akbar]

I have been doing this for a long time now and I have changed all these
parameters that you just mentioned in order to understand whats going on. I
have changed both the transmitter and receiver gain and set different
values but gain is not changing the SNR for some reason. It only works till
2.5 Mhz and at higher sampling rates data is not decoded at all. It does
detect the correlation and start of frames in sync_Short block but data is
not decoded probably because of high noise. I have also used different DC
offset values and that doesn't help either. The antennas are placed within
each other's LOS and I dont think interference should be a problem. And if
you have used Vert2450 antennas then I really dont understand whats the
problem.

On Sun, Jun 4, 2017 at 11:47 AM, Bastian Bloessl  wrote:

>
> On 06/04/2017 05:35 PM, Qurat-Ul-Ann Akbar wrote:
>
>> Then what could be the problem for a low SNR. The average power I see at
>> the receiver is -100 to -120 db and the signal is too distorted within
>> noise.
>>
>
> This can have many reasons (including gain, interference, DC offsets, LO
> leakage, etc etc.) I think it will take some more effort from your side to
> find out what's going wrong.
>
> You might find lots of helpful information on
> - wime-project.net/installation/
> - the GNU Radio Wiki
> - the mailing list archive
> - Stack overflow
>
>
>
>> And I watched your video on YouTube in which you were showing a demo of
>> the WiFi receiver. In that video you had big antennas and I don't think
>> those were Vert 2450.
>>
>
> If the video shows larger dipoles with cables, they were ECOM9-5500.
> Again, I don't believe that the antennas are your problem. I used the
> transceiver successfully with many different antennas, including the Vert
> 2450 that you are using.
>
> Best regards,
> Bastian
>
>
>
>
>> On Jun 4, 2017 11:21 AM, "Bastian Bloessl" > m...@bastibl.net>> wrote:
>>
>>
>>
>> On 06/04/2017 05:16 PM, Qurat-Ul-Ann Akbar wrote:
>>
>> I understand. But you didnt connect them directly to the USRP.
>> You used some cable to connect the two and had a stand for your
>> antenna. Can you tell me which cable was that ?
>>
>>
>> I have no idea what you are talking about. When I used the Vert
>> antennas, I connected them directly to the USRP.
>>
>> If you experience low SNR you'll probably not improve things if you
>> add cables between the SDR and the antenna. I doubt that the antenna
>> or cables are your problem.
>>
>> Best,
>> Bastian
>>
>>
>>
>>
>> On Jun 4, 2017 11:13 AM, "Bastian Bloessl" > <mailto:m...@bastibl.net> <mailto:m...@bastibl.net
>> <mailto:m...@bastibl.net>>> wrote:
>>
>>  Hi,
>>
>>
>>  On 06/04/2017 04:25 PM, Qurat-Ul-Ann Akbar wrote:
>>
>>  Thank you for the explanation. Can you tell me which
>> antennas
>>  did you use for your experiments when you wrote your
>> paper?
>>  Because I think a major problem with my receiver is a
>> very low
>>  SNR because everything works fine with simulations.
>> Currently I
>>  am using Vert 2450 antenna with my USRP N210.
>>
>>
>>  I used the same setup with the Vert 2450 antennas.
>>
>>  Best,
>>  Bastian
>>
>>
>>
>>
>>
>>
>>  On Sun, Jun 4, 2017 at 12:33 PM, Bastian Bloessl
>>  mailto:m...@bastibl.net>
>> <mailto:m...@bastibl.net <mailto:m...@bastibl.net>>
>>  <mailto:m...@bastibl.net <mailto:m...@bastibl.net>
>> <mailto:m...@bastibl.net <mailto:m...@bastibl.net>>>> wrote:
>>
>>   Hi,
>>
>>   On 6/3/2017 9:11 PM, Qurat-Ul-Ann Akbar wrote:
>>
>>   Hello,
>>
>>   How is the timing offset being handled in the
>> 802.11
>>  module. I
>>   see that the sync_long block does frequency
>> offset
>>  correction
>>   and the frame_equalizer block does the phase
>> correction
>>  but I
>>   dont understand where is the timing offset bein

Re: [Discuss-gnuradio] IEEE 802.11 Transceiver Module - Timing offset at receiver side

[Qurat-Ul-Ann Akbar]

Then what could be the problem for a low SNR. The average power I see at
the receiver is -100 to -120 db and the signal is too distorted within
noise.

And I watched your video on YouTube in which you were showing a demo of the
WiFi receiver. In that video you had big antennas and I don't think those
were Vert 2450.

On Jun 4, 2017 11:21 AM, "Bastian Bloessl"  wrote:

>
>
> On 06/04/2017 05:16 PM, Qurat-Ul-Ann Akbar wrote:
>
>> I understand. But you didnt connect them directly to the USRP. You used
>> some cable to connect the two and had a stand for your antenna. Can you
>> tell me which cable was that ?
>>
>
> I have no idea what you are talking about. When I used the Vert antennas,
> I connected them directly to the USRP.
>
> If you experience low SNR you'll probably not improve things if you add
> cables between the SDR and the antenna. I doubt that the antenna or cables
> are your problem.
>
> Best,
> Bastian
>
>
>
>
>> On Jun 4, 2017 11:13 AM, "Bastian Bloessl" > m...@bastibl.net>> wrote:
>>
>> Hi,
>>
>>
>> On 06/04/2017 04:25 PM, Qurat-Ul-Ann Akbar wrote:
>>
>> Thank you for the explanation. Can you tell me which antennas
>> did you use for your experiments when you wrote your paper?
>> Because I think a major problem with my receiver is a very low
>> SNR because everything works fine with simulations. Currently I
>> am using Vert 2450 antenna with my USRP N210.
>>
>>
>> I used the same setup with the Vert 2450 antennas.
>>
>> Best,
>> Bastian
>>
>>
>>
>>
>>
>>
>> On Sun, Jun 4, 2017 at 12:33 PM, Bastian Bloessl
>> mailto:m...@bastibl.net>
>> <mailto:m...@bastibl.net <mailto:m...@bastibl.net>>> wrote:
>>
>>  Hi,
>>
>>  On 6/3/2017 9:11 PM, Qurat-Ul-Ann Akbar wrote:
>>
>>  Hello,
>>
>>  How is the timing offset being handled in the 802.11
>> module. I
>>  see that the sync_long block does frequency offset
>> correction
>>  and the frame_equalizer block does the phase correction
>> but I
>>  dont understand where is the timing offset being
>> handled. Can
>>  anyone tell me which algorithm is being used to do that?
>>
>>
>>  The Sync Long block correlates the signal with the known
>> pattern of
>>  the long preamble to derive how the FFTs have to be aligned
>> in time.
>>
>>  Best,
>>  Bastian
>>
>>
> --
> Dipl.-Inform. Bastian Bloessl
> CONNECT Center
> Trinity College Dublin
>
> GitHub/Twitter: @bastibl
> https://www.bastibl.net/
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IEEE 802.11 Transceiver Module - Timing offset at receiver side

[Qurat-Ul-Ann Akbar]

I understand. But you didnt connect them directly to the USRP. You used
some cable to connect the two and had a stand for your antenna. Can you
tell me which cable was that ?

On Jun 4, 2017 11:13 AM, "Bastian Bloessl"  wrote:

> Hi,
>
>
> On 06/04/2017 04:25 PM, Qurat-Ul-Ann Akbar wrote:
>
>> Thank you for the explanation. Can you tell me which antennas did you use
>> for your experiments when you wrote your paper? Because I think a major
>> problem with my receiver is a very low SNR because everything works fine
>> with simulations. Currently I am using Vert 2450 antenna with my USRP N210.
>>
>>
> I used the same setup with the Vert 2450 antennas.
>
> Best,
> Bastian
>
>
>
>>
>>
>>
>> On Sun, Jun 4, 2017 at 12:33 PM, Bastian Bloessl > <mailto:m...@bastibl.net>> wrote:
>>
>> Hi,
>>
>> On 6/3/2017 9:11 PM, Qurat-Ul-Ann Akbar wrote:
>>
>> Hello,
>>
>> How is the timing offset being handled in the 802.11 module. I
>> see that the sync_long block does frequency offset correction
>> and the frame_equalizer block does the phase correction but I
>> dont understand where is the timing offset being handled. Can
>> anyone tell me which algorithm is being used to do that?
>>
>>
>> The Sync Long block correlates the signal with the known pattern of
>> the long preamble to derive how the FFTs have to be aligned in time.
>>
>> Best,
>> Bastian
>>
>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IEEE 802.11 Transceiver Module - Timing offset at receiver side

[Qurat-Ul-Ann Akbar]

Thank you for the explanation. Can you tell me which antennas did you use
for your experiments when you wrote your paper? Because I think a major
problem with my receiver is a very low SNR because everything works fine
with simulations. Currently I am using Vert 2450 antenna with my USRP N210.





On Sun, Jun 4, 2017 at 12:33 PM, Bastian Bloessl  wrote:

> Hi,
>
> On 6/3/2017 9:11 PM, Qurat-Ul-Ann Akbar wrote:
>
>> Hello,
>>
>> How is the timing offset being handled in the 802.11 module. I see that
>> the sync_long block does frequency offset correction and the
>> frame_equalizer block does the phase correction but I dont understand where
>> is the timing offset being handled. Can anyone tell me which algorithm is
>> being used to do that?
>>
>
> The Sync Long block correlates the signal with the known pattern of the
> long preamble to derive how the FFTs have to be aligned in time.
>
> Best,
> Bastian
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] IEEE 802.11 Transceiver Module - Timing offset at receiver side

[Qurat-Ul-Ann Akbar]

Hello,

How is the timing offset being handled in the 802.11 module. I see that the
sync_long block does frequency offset correction and the frame_equalizer
block does the phase correction but I dont understand where is the timing
offset being handled. Can anyone tell me which algorithm is being used to
do that?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IEEE 802.11 receiver not working for high sampling rates

[Qurat-Ul-Ann Akbar]

Hi,

As Marcus suggested, I put a frequency sink directly to the receiver to
look at the signal. Both at 1 MHz and 10 MHz the signal is noisy. The power
is around -120 to -100 db. However, in the case of 1 MHZ all packets sent
by the USRP transmitter are received correctly with almost negligible
packet error rate. However at 10 MHZ nothing is received. There are no over
or under runs. Why would it stop working at anything above 1 MHz ?

What could be the reason for this ?

On May 26, 2017 11:03 AM,  wrote:

> How can I change that in that USRP N210? And how do you think it's
> affecting the transmission.
>
> Thank you .
>
> On May 25, 2017 1:27 PM, "sakthivel velumani"  wrote:
>
>> What is the update rate of DAC in transmitter side? Try increasing it.
>>
>> On Thu, May 25, 2017 at 5:43 PM, Qurat-Ul-Ann Akbar <
>> quratulannakbar2...@u.northwestern.edu> wrote:
>>
>>> Hi,
>>>
>>> I am working with USRPs N210 and GNU Radio version 3.7. I wasn't able to
>>> work with higher sampling rate like 20 MHZ used in WiFi and that's why I
>>> bought a new workstation with better processor. However, the module still
>>> isn't working. The receiver isn't receiving anything at 20 MHZ if it's QAM
>>> 64 or BPSK . It works perfectly fine with 1 MHZ and receives all data from
>>> the transmitter USRP. But at 20 MHZ it receives a few WiFi packets from
>>> surrounding far off APs in the building but isn't receiving anything from
>>> the USRP transmitter in the room. It doesn't work for 10 MHZ as well.
>>>
>>> Can anyone tell me what could be the reason for that? I have tried
>>> changing LO offset etc.
>>>
>>>
>>>
>>> ___
>>> 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] IEEE 802.11 receiver not working for high sampling rates

[Qurat-Ul-Ann Akbar]

Hi Victor,

I am using GNU Radio flow graph and it's actually IEEE 802.11 modules
wifi-tx for sending data. Also I am not using virtualized environment and
my ethernet port is 1Gbps.

On May 25, 2017 11:11 AM, "Diez Victor"  wrote:

> The problem could be the transmission of data via ethernet port.
>
> Are you working under virtualized OS conditions? These could be the origin
> of your problem, virtualized ethernet ports don’t reach enough high data
> rates.
>
> Another possibility could be that your ethernet adapter isn’t a gigabyte
> ethernet adapter.
>
> Finally, if you work with Matlab/Simulink, you can have the same problem.
> In this case I recommend you to change to GNU-Radio and its flowchart
> interface, GRC.
>
>
>
>
>
>
>
> *De:* Discuss-gnuradio [mailto:discuss-gnuradio-bounces+vdiez=
> ikerlan...@gnu.org] *En nombre de *Qurat-Ul-Ann Akbar
> *Enviado el:* jueves, 25 de mayo de 2017 17:44
> *Para:* GNURadio Discussion List
> *Asunto:* [Discuss-gnuradio] IEEE 802.11 receiver not working for high
> sampling rates
>
>
>
> Hi,
>
>
>
> I am working with USRPs N210 and GNU Radio version 3.7. I wasn't able to
> work with higher sampling rate like 20 MHZ used in WiFi and that's why I
> bought a new workstation with better processor. However, the module still
> isn't working. The receiver isn't receiving anything at 20 MHZ if it's QAM
> 64 or BPSK . It works perfectly fine with 1 MHZ and receives all data from
> the transmitter USRP. But at 20 MHZ it receives a few WiFi packets from
> surrounding far off APs in the building but isn't receiving anything from
> the USRP transmitter in the room. It doesn't work for 10 MHZ as well.
>
>
>
> Can anyone tell me what could be the reason for that? I have tried
> changing LO offset etc.
>
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] IEEE 802.11 receiver not working for high sampling rates

[Qurat-Ul-Ann Akbar]

Hi,

I am working with USRPs N210 and GNU Radio version 3.7. I wasn't able to
work with higher sampling rate like 20 MHZ used in WiFi and that's why I
bought a new workstation with better processor. However, the module still
isn't working. The receiver isn't receiving anything at 20 MHZ if it's QAM
64 or BPSK . It works perfectly fine with 1 MHZ and receives all data from
the transmitter USRP. But at 20 MHZ it receives a few WiFi packets from
surrounding far off APs in the building but isn't receiving anything from
the USRP transmitter in the room. It doesn't work for 10 MHZ as well.

Can anyone tell me what could be the reason for that? I have tried changing
LO offset etc.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] IEEE 802.11 a/g/p transreceiver module - Number of symbols per frame?

[Qurat-Ul-Ann Akbar]

Hi,

I want to look at the number of symbols copied for *each frame
received *in wifi_rx
flow graph. I have been trying to understand how the start of each frame is
calculated and by looking at the code it seems like its being done in the
wifi sync_short block where the auto correlation coefficient is being
checked against a threshold and then the d_plateau is being updated until
it reaches MIN_PLATEAU.

However, for the number of symbols per frame, there is a MAX_SAMPLES which
is set to 540*80 where 80 is the number of samples per symbol but I don't
understand why is the total number of symbols per frame set to 540?

Also in the code from the wifi sync_short.cc:

case COPY: {

int o = 0;
while( o < ninput && o < noutput && d_copied < MAX_SAMPLES) {
if(in_cor[o] > d_threshold) {
if(d_plateau < MIN_PLATEAU) {
d_plateau++;

// there's another frame
} else if(d_copied > MIN_GAP) {
d_copied = 0;
d_plateau = 0;
d_freq_offset = arg(in_abs[o]) / 16;
insert_tag(nitems_written(0) + o, d_freq_offset);
dout << "SHORT Frame!" << std::endl;
break;
}

} else {
d_plateau = 0;
}

out[o] = in[o] * exp(gr_complex(0, -d_freq_offset * d_copied));
o++;
d_copied++;
}

if(d_copied == MAX_SAMPLES) {
d_state = SEARCH;
}

dout << "SHORT copied " << o << std::endl;

consume_each(o);
return o;
}

Whats the role of MIN_GAP? Why is it being used to detect a shorter frame?

Moreover, does it mean that the number of symbols per frame can be either
MAX_SAMPLES or MIN_GAP because in both cases it starts searching for new
frames. What if one frame has less number of symbols than MIN_GAP and
MAX_SAMPLES?

Can anyone please explain this ?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 173, Issue 6

[Qurat-Ul-Ann Akbar]

Hi Marcus,

Thank you for your email. I forgot to add my port to the xml file. Its
fixed now.

On Wed, Apr 5, 2017 at 11:00 AM,  wrote:

> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
>
> 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
> discuss-gnuradio-requ...@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>1. How to add project to CGRAN (Maxime Lastera)
>2. Re: How to add project to CGRAN (Marcus M?ller)
>3. GNU Radio/No Devices Found (NI USRP-2920) (bup487)
>4. Re: GNU Radio/No Devices Found (NI USRP-2920) (Derek Kozel)
>5. Re: GNU Radio/No Devices Found (NI USRP-2920) (Marcus D. Leech)
>6. Re: GNU Radio/No Devices Found (NI USRP-2920) (bup487)
>7. Re: GNU Radio/No Devices Found (NI USRP-2920) (Marcus M?ller)
>8. Adding command port to OFDM Allocator Block (Qurat-Ul-Ann Akbar)
>9. Re: Adding command port to OFDM Allocator Block (Marcus M?ller)
>
>
> --
>
> Message: 1
> Date: Tue, 4 Apr 2017 20:01:19 +0200
> From: Maxime Lastera 
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] How to add project to CGRAN
> Message-ID:
>  w...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi every body,
>
> Do you know where I can found information to add our own project to CGRAN?
>
> I don't see any information about that on GNURADIO website.
>
> Regards
> -- next part --
> An HTML attachment was scrubbed...
> URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/
> attachments/20170404/86ebf336/attachment.html>
>
> --
>
> Message: 2
> Date: Tue, 4 Apr 2017 20:05:26 +0200
> From: Marcus M?ller 
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] How to add project to CGRAN
> Message-ID: 
> Content-Type: text/plain; charset="windows-1252"
>
> Hi Maxime
>
> Write a recipe for PyBOMBS, make a Pull Request on Github to get it into
> the gr-etcetera repo :)
>
> Best regards,
>
> Marcus
>
>
> On 04/04/2017 08:01 PM, Maxime Lastera wrote:
> > Hi every body,
> >
> > Do you know where I can found information to add our own project to
> CGRAN?
> >
> > I don't see any information about that on GNURADIO website.
> >
> > Regards
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > 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/20170404/fdec7108/attachment.html>
>
> --
>
> Message: 3
> Date: Tue, 4 Apr 2017 11:49:29 -0700 (MST)
> From: bup487 
> To: Discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] GNU Radio/No Devices Found (NI USRP-2920)
> Message-ID: <1491331769602-63451.p...@n7.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> Two programs, MATLAB and GNU Radio, are giving me different results when
> searching for the USRP on my network.
> My setup is Laptop -> Wired Ethernet -> Switch -> NI USRP-2920.
>
> MATLAB can detect the USRP device, while GNU Radio throws an error whenever
> it tries to identify the USRP device at 192.168.10.3.
> <http://gnuradio.4.n7.nabble.com/file/n63451/RUBYFORUM_001.jpg>
> <http://gnuradio.4.n7.nabble.com/file/n63451/RUBYFORUM_002.jpg>
>
> My computer is configured with the static IP address 192.168.10.1. I'm
> using Windows 10 for this setup. I recently downloaded the automated
> NI-USRP driver software. Apparently, this software updates the USRP image
> to
> the latest firmware. Installing new firmware onto the USRP had no effect on
> the error message.
>
> How do I get GNU radio to detect my USRP device?
>
> If there is any help, I'd be very grateful.
>
> Thanks!
> <http://gnuradio.4.n7.nabble.com/file/n63451/RUBYFORUM_003.jpg>
>
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.
> com/GNU-Radio-No-Devices-Found-NI-USRP-2920-tp63451.html
> Sent from the GnuRadio mailing 

[Discuss-gnuradio] Adding command port to OFDM Allocator Block

[Qurat-Ul-Ann Akbar]

Hi,

I am trying to add a command port to the OFDM Allocator block in GNURadio.
The goal is for this command port to take a message every 1 ms to change
the amplitude of the complex pilot symbols. However, I can not see the port
appearing in GRC.

I just wrote some test code to see if the port is appearing. The changes I
made are given below:

*1)* I added this line here:
 ofdm_carrier_allocator_cvc_impl::ofdm_carrier_allocator_cvc_impl
{int fft_len,
 const std::vector > &occupied_carriers,
 const std::vector > &pilot_carriers,
 const std::vector > &pilot_symbols,
 const std::vector > &sync_words,
 const std::string &len_tag_key,
 const bool output_is_shifted
) : tagged_stream_block("ofdm_carrier_allocator_cvc",
  io_signature::make(1, 1, sizeof (gr_complex)),
  io_signature::make(1, 1, sizeof (gr_complex) * fft_len), len_tag_key),
d_fft_len(fft_len),
d_occupied_carriers(occupied_carriers),
d_pilot_carriers(pilot_carriers),
d_pilot_symbols(pilot_symbols),
d_sync_words(sync_words),
d_symbols_per_set(0),
d_output_is_shifted(output_is_shifted)
{
   //MY_CHANGES
*message_port_register_in(pmt::mp("test"));*
*set_msg_handler(pmt::mp("test"), boost::bind(&mac_impl::test_in, this,
_1));*


*2)* And then the function test_in is just a function printing out the
message "TESTER"

//MY_CHANGES
*void test_in (pmt::pmt_t msg) {*
* // this must be a pair*
* int count = 0;*
* if (!pmt::is_blob(pmt::cdr(msg))) {*
* throw std::runtime_error("PMT must be blob");*
* }*

* if(pmt::is_symbol(msg)) {*
* throw std::runtime_error("#TESTER#");*
*}*
*}*

*3) *I uninstalled everything and built again. But I cant see anything in
the block. I don't see this port at the input of the block.

Can anyone please tell me what am I doing wrong ?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ASK Modulation

[Qurat-Ul-Ann Akbar]

Hello,

Is ASK modulation implemented in gnuradio? I know that BPSK, QPSK and QAM
are.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] IEEE 802.11 Module - Pilot Tones in OFDM symbol

[Qurat-Ul-Ann Akbar]

Hi,

Are pilot tones used at all for equalization in wifi_rx ? I do not see that
being done in the WiFi frame equalizer block. Also even when I change the
amplitude and phase of the pilots in Wifi_tx other than the default 1, the
WiFi packets were still being decoded correctly. Is it because that the
pilot tones are not really playing any role in the decoding process?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver module - Making changes in WiFi PHY Hier Block

[Qurat-Ul-Ann Akbar]

Okay I will do that. Thanks!

On the receiver side I know the equalizer block does the phase offset
correction but usually pilot tones in each OFDM symbol are used for that.
When I looked at the file *gnuradio
<https://github.com/gnuradio/gnuradio>/gr-digital
<https://github.com/gnuradio/gnuradio/tree/master/gr-digital>/lib
<https://github.com/gnuradio/gnuradio/tree/master/gr-digital/lib>/ofdm_frame_equalizer_vcvc_impl.cc*
I dont see that happening. If for every OFDM symbol that we receive, I want
to access the frequency bin of the pilot tones how can I do that with the
current equalizer block?





On Sat, Mar 25, 2017 at 8:55 AM, Bastian Bloessl  wrote:

> Hi,
>
> Am 25.03.2017 um 16:12 schrieb Qurat-Ul-Ann Akbar:
>
>> Thanks for pointing me to the file. This list of pilot tones with
>> different polarities seems to be hard coded. Is there any way of
>> changing the amplitude value of this complex number encoded on the pilot
>> tone. E.g. if I want to change all the pilot tone values for frequency
>> bin +7 from 1 to 1.2 how can I do that dynamically without hard coding
>> these values ?
>>
>> Something like this (1,1,1,-1) -> (1,1,1.2,-1) and so on...
>>
>
> That, rather specific use-case, is AFAIK not supported by the upstream
> block. It is, however, straightforward to create your own block based on
> the OFDM Carrier Allocator. The Wiki has lots of useful information. In
> particular,
> https://wiki.gnuradio.org/index.php/OutOfTreeModules
>
> To change the amplitude of the pilots interactively, you might want to add
> a callback to the block (to change it from GUI elements) or add a message
> port to allow other blocks to change the amplitude.
>
> Best,
> Bastian
>
>
>
>>
>> On Fri, Mar 24, 2017 at 2:57 PM, Bastian Bloessl > <mailto:m...@bastibl.net>> wrote:
>>
>> Hi,
>>
>> On 03/24/2017 08:44 PM, Qurat-Ul-Ann Akbar wrote:
>> > How is a particular polarity picked for the pilot tones in each
>> symbol
>> > with 52 subcarriers in GNU Radio? I can see the list in the OFDM
>> Carrier
>> > Allocator block but where is this exactly happening in the code?
>>
>> the pilots are copied here:
>>
>> https://github.com/gnuradio/gnuradio/blob/master/gr-digital/
>> lib/ofdm_carrier_allocator_cvc_impl.cc#L185-L189
>> <https://github.com/gnuradio/gnuradio/blob/master/gr-digital
>> /lib/ofdm_carrier_allocator_cvc_impl.cc#L185-L189>
>>
>> The vector "d_pilot_carriers" is created from the list of pilots that
>> you mentioned (i.e. the argument of the carrier allocator block).
>> This list contains pilots according to the polarity pattern given in
>> the
>> standard.
>>
>> Best,
>> Bastian
>>
>> >
>> >
>> >
>> > On Mon, Mar 20, 2017 at 3:37 PM, Bastian Bloessl > <mailto:m...@bastibl.net>
>> > <mailto:m...@bastibl.net <mailto:m...@bastibl.net>>> wrote:
>> >
>> > Hi,
>> >
>> > On 03/20/2017 09:17 PM, Qurat-Ul-Ann Akbar wrote:
>> > > Hi,
>> > >
>> > > Thank you. I got it! I have another question. In the OFDM
>> Carrier
>> > > Allocator block, there are 127 values for pilot symbols each
>> of them
>> > > either (1,1,1,-1) or (-1,-1,-1,1). The pilot frequencies are
>> > > (-27,-7,7,21) according to IEEE 802.11 standard. But I do not
>> understand
>> > > why are there 127 symbol values. Can you kindly explain that ?
>> >
>> > The four values indicate the four pilot symbols (on subcarriers
>> -21, -7,
>> > 7, 21). With 802.11, the pilots change polarity based on a
>> predefined
>> > sequence (of length 127). It is in this exact format also in the
>> > standard (Section 18.3.5.10 of the 2012 version).
>> >
>> > Best,
>> > Bastian
>> >
>> >
>> >
>> > >
>> > > On Mon, Mar 20, 2017 at 12:09 PM, Bastian Bloessl <
>> m...@bastibl.net <mailto:m...@bastibl.net> <mailto:m...@bastibl.net
>> <mailto:m...@bastibl.net>>
>> > > <mailto:m...@bastibl.net <mailto:m...@bastibl.net> > m...@bastibl.net
>> <mailto:m...@bastibl.net>>>> wrote:
>> > >
>> > > Hi,
>> > >
>> >   

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver module - Making changes in WiFi PHY Hier Block

[Qurat-Ul-Ann Akbar]

Thanks for pointing me to the file. This list of pilot tones with different
polarities seems to be hard coded. Is there any way of changing the
amplitude value of this complex number encoded on the pilot tone. E.g. if I
want to change all the pilot tone values for frequency bin +7 from 1 to 1.2
how can I do that dynamically without hard coding these values ?

Something like this (1,1,1,-1) -> (1,1,1.2,-1) and so on...


On Fri, Mar 24, 2017 at 2:57 PM, Bastian Bloessl  wrote:

> Hi,
>
> On 03/24/2017 08:44 PM, Qurat-Ul-Ann Akbar wrote:
> > How is a particular polarity picked for the pilot tones in each symbol
> > with 52 subcarriers in GNU Radio? I can see the list in the OFDM Carrier
> > Allocator block but where is this exactly happening in the code?
>
> the pilots are copied here:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-
> digital/lib/ofdm_carrier_allocator_cvc_impl.cc#L185-L189
>
> The vector "d_pilot_carriers" is created from the list of pilots that
> you mentioned (i.e. the argument of the carrier allocator block).
> This list contains pilots according to the polarity pattern given in the
> standard.
>
> Best,
> Bastian
>
> >
> >
> >
> > On Mon, Mar 20, 2017 at 3:37 PM, Bastian Bloessl  > <mailto:m...@bastibl.net>> wrote:
> >
> > Hi,
> >
> > On 03/20/2017 09:17 PM, Qurat-Ul-Ann Akbar wrote:
> > > Hi,
> > >
> > > Thank you. I got it! I have another question. In the OFDM Carrier
> > > Allocator block, there are 127 values for pilot symbols each of
> them
> > > either (1,1,1,-1) or (-1,-1,-1,1). The pilot frequencies are
> > > (-27,-7,7,21) according to IEEE 802.11 standard. But I do not
> understand
> > > why are there 127 symbol values. Can you kindly explain that ?
> >
> > The four values indicate the four pilot symbols (on subcarriers -21,
> -7,
> > 7, 21). With 802.11, the pilots change polarity based on a predefined
> > sequence (of length 127). It is in this exact format also in the
> > standard (Section 18.3.5.10 of the 2012 version).
> >
> > Best,
> > Bastian
> >
> >
> >
> > >
> > > On Mon, Mar 20, 2017 at 12:09 PM, Bastian Bloessl <
> m...@bastibl.net <mailto:m...@bastibl.net>
> > > <mailto:m...@bastibl.net <mailto:m...@bastibl.net>>> wrote:
> > >
> > > Hi,
> > >
> > >
> > > > On 20 Mar 2017, at 17:50, Qurat-Ul-Ann Akbar <
> quratulannakbar2...@u.northwestern.edu
> > <mailto:quratulannakbar2...@u.northwestern.edu>
> > > <mailto:quratulannakbar2...@u.northwestern.edu
> > <mailto:quratulannakbar2...@u.northwestern.edu>>> wrote:
> > > >
> > > > If I want to make changes in the PHY hierarchical block, can
> > I just make changes in the grc file available in the examples folder
> > and then recompile ? Because I cant file a .cc file in the lib
> > folder in IEEE_802.11 module and the source code for most blocks is
> > in there.
> > > >
> > >
> > > I’m afraid I don’t get the question, but if you don’t see any
> .cc
> > > files in the lib folder, you might want to clone the repository
> > > again, because actually there are some
> > >
> > > https://github.com/bastibl/gr-ieee802-11/tree/next/lib
> > <https://github.com/bastibl/gr-ieee802-11/tree/next/lib>
> > > <https://github.com/bastibl/gr-ieee802-11/tree/next/lib
> > <https://github.com/bastibl/gr-ieee802-11/tree/next/lib>>
> > >
> > > If you only change the flow graph in GRC, you don’t have to
> > > recompile the module (i.e., recompile c++ code). Just click on
> the
> > > “generate” button (or press F5) this will rebuild the PHY.
> > Then the
> > > other flow graphs will automatically use the new version of
> > the PHY.
> > >
> > > Best,
> > > Bastian
> > >
> > >
> >
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver module - Making changes in WiFi PHY Hier Block

[Qurat-Ul-Ann Akbar]

How is a particular polarity picked for the pilot tones in each symbol with
52 subcarriers in GNU Radio? I can see the list in the OFDM Carrier
Allocator block but where is this exactly happening in the code?



On Mon, Mar 20, 2017 at 3:37 PM, Bastian Bloessl  wrote:

> Hi,
>
> On 03/20/2017 09:17 PM, Qurat-Ul-Ann Akbar wrote:
> > Hi,
> >
> > Thank you. I got it! I have another question. In the OFDM Carrier
> > Allocator block, there are 127 values for pilot symbols each of them
> > either (1,1,1,-1) or (-1,-1,-1,1). The pilot frequencies are
> > (-27,-7,7,21) according to IEEE 802.11 standard. But I do not understand
> > why are there 127 symbol values. Can you kindly explain that ?
>
> The four values indicate the four pilot symbols (on subcarriers -21, -7,
> 7, 21). With 802.11, the pilots change polarity based on a predefined
> sequence (of length 127). It is in this exact format also in the
> standard (Section 18.3.5.10 of the 2012 version).
>
> Best,
> Bastian
>
>
>
> >
> > On Mon, Mar 20, 2017 at 12:09 PM, Bastian Bloessl  > <mailto:m...@bastibl.net>> wrote:
> >
> > Hi,
> >
> >
> > > On 20 Mar 2017, at 17:50, Qurat-Ul-Ann Akbar <
> quratulannakbar2...@u.northwestern.edu
> > <mailto:quratulannakbar2...@u.northwestern.edu>> wrote:
> > >
> > > If I want to make changes in the PHY hierarchical block, can I
> just make changes in the grc file available in the examples folder and then
> recompile ? Because I cant file a .cc file in the lib folder in IEEE_802.11
> module and the source code for most blocks is in there.
> > >
> >
> > I’m afraid I don’t get the question, but if you don’t see any .cc
> > files in the lib folder, you might want to clone the repository
> > again, because actually there are some
> >
> > https://github.com/bastibl/gr-ieee802-11/tree/next/lib
> > <https://github.com/bastibl/gr-ieee802-11/tree/next/lib>
> >
> > If you only change the flow graph in GRC, you don’t have to
> > recompile the module (i.e., recompile c++ code). Just click on the
> > “generate” button (or press F5) this will rebuild the PHY. Then the
> > other flow graphs will automatically use the new version of the PHY.
> >
> > Best,
> > Bastian
> >
> >
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver module - Making changes in WiFi PHY Hier Block

[Qurat-Ul-Ann Akbar]

Hi,

Thank you. I got it! I have another question. In the OFDM Carrier Allocator
block, there are 127 values for pilot symbols each of them either
(1,1,1,-1) or (-1,-1,-1,1). The pilot frequencies are (-27,-7,7,21)
according to IEEE 802.11 standard. But I do not understand why are there
127 symbol values. Can you kindly explain that ?

On Mon, Mar 20, 2017 at 12:09 PM, Bastian Bloessl  wrote:

> Hi,
>
>
> > On 20 Mar 2017, at 17:50, Qurat-Ul-Ann Akbar  northwestern.edu> wrote:
> >
> > If I want to make changes in the PHY hierarchical block, can I just make
> changes in the grc file available in the examples folder and then recompile
> ? Because I cant file a .cc file in the lib folder in IEEE_802.11 module
> and the source code for most blocks is in there.
> >
>
> I’m afraid I don’t get the question, but if you don’t see any .cc files in
> the lib folder, you might want to clone the repository again, because
> actually there are some
>
> https://github.com/bastibl/gr-ieee802-11/tree/next/lib
>
> If you only change the flow graph in GRC, you don’t have to recompile the
> module (i.e., recompile c++ code). Just click on the “generate” button (or
> press F5) this will rebuild the PHY. Then the other flow graphs will
> automatically use the new version of the PHY.
>
> Best,
> Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver module - Making changes in WiFi PHY Hier Block

[Qurat-Ul-Ann Akbar]

Hi,

If I want to make changes in the PHY hierarchical block, can I just make
changes in the grc file available in the examples folder and then recompile
? Because I cant file a .cc file in the lib folder in IEEE_802.11 module
and the source code for most blocks is in there.

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

[Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver module - Making changes in WiFi PHY Hier Block

[Qurat-Ul-Ann Akbar]

Hi,

If I want to make changes in the PHY hierarchical block, can I just make
changes in the grc file and then recompile ? Becauase
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver module - Counting Decoded Frames

[Qurat-Ul-Ann Akbar]

Hi,

I want to calculate the number of frames correctly decoded by the wifi_rx
in the IEEE 802.11 module. I can not find the source file for the block
WiFi_Decode Mac where I can place a counter for the successfully decoded
frames. Can anyone tell me where this file is ? And is there any other way
of doing besides changing the block's code?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] IEEE 802.11 a/g/p transreceiver - Bit Error Rate in wifi_loopback

[Qurat-Ul-Ann Akbar]

Hi,

I have been working with the 802.11 module for GNU Radio and I want to
enable my receiver to perform some bit error rate calculations. I ran the
wifi_loopbck and noticed that a bit error rate field appears in the GUI. I
have been trying to see where and how is this error being calculated. Can
anyone tell me where is this calculation being done? And has error rate
block been deprecated?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Changing the USRP transmitter gain after a timeout

[Qurat-Ul-Ann Akbar]

I have looked at that file and you have made gain, frequency, and LO offset
variables and then you send messages every 2 secs. When I run the file, I
try to change the frequency from 2.4 to 2.5 G using the glider in the GUI.
It should change the value of the variable which should be reflected in the
actual center frequency. However, I do not see the frequency changing after
2 secs in the Frequency Sink Plot. Is that the right way to change the
value of the variable ?

On Fri, Feb 24, 2017 at 11:06 AM, Derek Kozel  wrote:

> Hello,
>
> For every message which you send UHD would change the gain once. So in
> order to alternate every 100ms you would send 10 messages a second,
> advancing the timestamp value by 100ms each time. The example I linked to
> shows the frequency and gain being changed every two seconds. You'll just
> need to alter the arguments to have it alternate the gain.
>
> Regards,
> Derek
>
> On Fri, Feb 24, 2017 at 8:52 AM, Qurat-Ul-Ann Akbar <
> quratulannakbar2...@u.northwestern.edu> wrote:
>
>> Also I want to keep doing this in a loop (the values keep alternating
>> after an interval). Will it be possible through the command port interface ?
>>
>>
>> On Fri, Feb 24, 2017 at 9:17 AM, Qurat-Ul-Ann Akbar <
>> quratulannakbar2...@u.northwestern.edu> wrote:
>>
>>> Hi Derek,
>>>
>>> Thank you for your email. If you could find that file it would be really
>>> helpful. What I want to do is to alternate between two or more values of
>>> gain after specific intervals. Can I alternate like this using the command
>>> port interface? How will the block USRP sink block know which value to use
>>> ? Can you kindly explain that a bit.
>>>
>>>
>>>
>>> On Thu, Feb 23, 2017 at 4:23 PM, Derek Kozel 
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> The command port interface can be used to change the gain value. There
>>>> is an example of creating messages for tuning included in gr-uhd.
>>>> https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/exam
>>>> ples/grc/uhd_msg_tune.grc
>>>>
>>>> I've used a function probe to generate coarsely timed "tick" messages
>>>> to a custom python block which is correctly formatting the messages before.
>>>> Unfortunately I cannot find that GRC file at the moment. The function probe
>>>> will run at an approximate interval dependent on your system and GNU
>>>> Radio's scheduler. If you don't need exact timing then just use the gain
>>>> message and function probe, if you do need exact timing include both time
>>>> and gain values in the pmt command message then the gain will be applied at
>>>> the specific time based on the radio timestamp. Set the Sync setting to
>>>> unknown_pps, which will set the radio timestamp to 0 when the flowgraph
>>>> starts, and set the initial timestamp for the command port message to a
>>>> second or two in the future to account for the startup time of the
>>>> flowgraph.
>>>>
>>>> Regards,
>>>> Derek
>>>>
>>>> On Thu, Feb 23, 2017 at 1:36 PM, Qurat-Ul-Ann Akbar <
>>>> quratulannakbar2...@u.northwestern.edu> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I want to alternate the gain of the USRP between two values after a
>>>>> certain period of time. For example after 100 ms it should go from A to B
>>>>> and after another 100 ms the value should go from B to A and so on.
>>>>>
>>>>> Is there an easy way of doing this in the GNU Radio companion or would
>>>>> I need to start a timer in python and put an IF condition to keep changing
>>>>> the value? Can I do this somehow using the probe block?
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> 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] Changing the USRP transmitter gain after a timeout

[Qurat-Ul-Ann Akbar]

Also I want to keep doing this in a loop (the values keep alternating after
an interval). Will it be possible through the command port interface ?


On Fri, Feb 24, 2017 at 9:17 AM, Qurat-Ul-Ann Akbar <
quratulannakbar2...@u.northwestern.edu> wrote:

> Hi Derek,
>
> Thank you for your email. If you could find that file it would be really
> helpful. What I want to do is to alternate between two or more values of
> gain after specific intervals. Can I alternate like this using the command
> port interface? How will the block USRP sink block know which value to use
> ? Can you kindly explain that a bit.
>
>
>
> On Thu, Feb 23, 2017 at 4:23 PM, Derek Kozel 
> wrote:
>
>> Hello,
>>
>> The command port interface can be used to change the gain value. There is
>> an example of creating messages for tuning included in gr-uhd.
>> https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/exam
>> ples/grc/uhd_msg_tune.grc
>>
>> I've used a function probe to generate coarsely timed "tick" messages to
>> a custom python block which is correctly formatting the messages before.
>> Unfortunately I cannot find that GRC file at the moment. The function probe
>> will run at an approximate interval dependent on your system and GNU
>> Radio's scheduler. If you don't need exact timing then just use the gain
>> message and function probe, if you do need exact timing include both time
>> and gain values in the pmt command message then the gain will be applied at
>> the specific time based on the radio timestamp. Set the Sync setting to
>> unknown_pps, which will set the radio timestamp to 0 when the flowgraph
>> starts, and set the initial timestamp for the command port message to a
>> second or two in the future to account for the startup time of the
>> flowgraph.
>>
>> Regards,
>> Derek
>>
>> On Thu, Feb 23, 2017 at 1:36 PM, Qurat-Ul-Ann Akbar <
>> quratulannakbar2...@u.northwestern.edu> wrote:
>>
>>> Hi,
>>>
>>> I want to alternate the gain of the USRP between two values after a
>>> certain period of time. For example after 100 ms it should go from A to B
>>> and after another 100 ms the value should go from B to A and so on.
>>>
>>> Is there an easy way of doing this in the GNU Radio companion or would I
>>> need to start a timer in python and put an IF condition to keep changing
>>> the value? Can I do this somehow using the probe block?
>>>
>>>
>>>
>>> ___
>>> 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] Changing the USRP transmitter gain after a timeout

[Qurat-Ul-Ann Akbar]

Hi Derek,

Thank you for your email. If you could find that file it would be really
helpful. What I want to do is to alternate between two or more values of
gain after specific intervals. Can I alternate like this using the command
port interface? How will the block USRP sink block know which value to use
? Can you kindly explain that a bit.



On Thu, Feb 23, 2017 at 4:23 PM, Derek Kozel  wrote:

> Hello,
>
> The command port interface can be used to change the gain value. There is
> an example of creating messages for tuning included in gr-uhd.
> https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/
> examples/grc/uhd_msg_tune.grc
>
> I've used a function probe to generate coarsely timed "tick" messages to a
> custom python block which is correctly formatting the messages before.
> Unfortunately I cannot find that GRC file at the moment. The function probe
> will run at an approximate interval dependent on your system and GNU
> Radio's scheduler. If you don't need exact timing then just use the gain
> message and function probe, if you do need exact timing include both time
> and gain values in the pmt command message then the gain will be applied at
> the specific time based on the radio timestamp. Set the Sync setting to
> unknown_pps, which will set the radio timestamp to 0 when the flowgraph
> starts, and set the initial timestamp for the command port message to a
> second or two in the future to account for the startup time of the
> flowgraph.
>
> Regards,
> Derek
>
> On Thu, Feb 23, 2017 at 1:36 PM, Qurat-Ul-Ann Akbar <
> quratulannakbar2...@u.northwestern.edu> wrote:
>
>> Hi,
>>
>> I want to alternate the gain of the USRP between two values after a
>> certain period of time. For example after 100 ms it should go from A to B
>> and after another 100 ms the value should go from B to A and so on.
>>
>> Is there an easy way of doing this in the GNU Radio companion or would I
>> need to start a timer in python and put an IF condition to keep changing
>> the value? Can I do this somehow using the probe block?
>>
>>
>>
>> ___
>> 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] Changing the USRP transmitter gain after a timeout

[Qurat-Ul-Ann Akbar]

Hi,

I want to alternate the gain of the USRP between two values after a certain
period of time. For example after 100 ms it should go from A to B and after
another 100 ms the value should go from B to A and so on.

Is there an easy way of doing this in the GNU Radio companion or would I
need to start a timer in python and put an IF condition to keep changing
the value? Can I do this somehow using the probe block?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] TunTap Interace for GNU Radio IEEE 802.11 a/g/p module

[Qurat-Ul-Ann Akbar]

Thank you for explaining the interaction between the Tun/Tap interface and
the USRP. When I run the wifi_transceiver I get a lot of "Ds" on the
console which indicates overflow. But I am able to receive packets through
the wifi_rx without any overflow. Can you tell me why I am experiencing
just overflows when I run the transceiver. Is there a problem with the
TunTap interface in this case?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Python files giving error "No module named gnuradio" when GNU Radio installed via PyBOMBS

[Qurat-Ul-Ann Akbar]

Hi,

I recently installed gnuradio on one of my machines using pyBOMBS and this
is my first time trying pyBOMBS for installation. Whenever I generate a
python file from the GRC flow graph and try to run the python file, I
receive the error "No module named gnuradio".

I think the python is not able to find gnuradio. How can I fix this?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] TunTap Interace for GNU Radio IEEE 802.11 a/g/p module

[Qurat-Ul-Ann Akbar]

Hi,

I am trying to run the transceiver which has a tuntap pdu block for sending
messages through TCP. There is a bash file nic.sh which gives an example
configuration for the tuntap interface.

I am not very familiar with working with tuntap and trying to understand
it. Can anyone kindly tell me if the MAC address you set for the tuntap
interface is random? Or is there a particular logic behind setting to a
particular value. Also should its IP address be in the same subnet of the
Ethernet interface the USRP device is connected to? (in my case the IP of
the Ethernet interface is 192.168.10.1 and mask is /24) And can it be
anything in 192.168.10.0/24

?

In the file nic.sh the MAC address of the tap0 interface is set to
12:34:56:78:90:ab and the IP address is 192.168.123.1

And then the arp command is used to map 192.168.123.2 to the MAC address
30:14:4a:e6:46:e4.

How does this interface end up sending messages through the USRP?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with the ieee 802.11 a/g/p receiver (wifi_rx)

[Qurat-Ul-Ann Akbar]

Hi Bastian,

I was testing the wifi_tx as well and I followed your tutorial where you
asked to turn the wifi card into a monitor and then run the transmitter
through the SDR. I also connected the Wireshark connector block to the WiFi
PHY Hier block to see the packets being sent by the wifi_tx. After
transmission when I open the pcap file it just shows me 2 entries and they
say "Protocol WLAN, Info: Malformed Packet". I also dont see any UDP
packets sent by the USRP in the pcap file generated by the monitor.

I didn't change the wifi_tx at all. Can you please tell me what could be
going on? Isnt the script supposed to work. And what output should I be
expecting?

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

[Discuss-gnuradio] Problem with the ieee 802.11 a/g/p receiver (wifi_rx)

[Qurat-Ul-Ann Akbar]

Hi,

I have been working with the ieee 802.11 module for GNU Radio. I have GNU
Radio v 3.7.10.1 and I am using USRP N210 with a cbx daughterboard.

Right now I am just testing if the wifi_rx(the receiver) works. I am using
a wifi card to send beacon frames and trying to detect the frames through
the USRP. I get a lot of messages saying frame too short to parse
length(<20). And there's wireshark connector which is supposed to copy
received packets information into a pcap file and that pcap file shows
nothing and the message that the pacp is possibly corrupted pops up.

I tried to debug using the data flow. I see the that the frame is detected
properly and the symbols are copied in order to decode and the flow is fine
but after the data is decoded in the WiFi Decode MAC Block, the frame gets
dropped with the checksum wrong message. And it happens for most of the
packets and that's why the pcap file isn't showing anything.

I tried to play with the gain but that's not changing anything. I am using
11g beacon frames and the sampling rate on the receiver is 20MHz. Did
anyone encounter the same problem? And why are almost all checksums wrong?
It would be very helpful if someone could guide me on this.

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

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p transceiver - Data not being received at any frequency other than 5.89G

[Qurat-Ul-Ann Akbar]

Hi,

I changed the sample rate to 20 MHz and changed the beacon frames to be 11g
and now the receiver receives some WiFi packets. But it shows a parse error
which says :

new mac frame  (length 10)
=
frame too short to parse (<20)
WIRESHARK: received new message
message length 10
WIRESHARK: d_msg_offset: 0   to_copy: 43   d_msg_len 43
WIRESHARK: output size: 32768   produced items: 43

And there are some "Ds" printed on the console as well. I read through the
previous threads about the frame not being able to parse but didn't find
anything useful. I checked Wireshark and the packets make sense over there
and I can see the different beacon frames and RTS/CTS transmissions as
well. I also saw your wifi receiver video on Youtube and my constellation
plot looks nothing like yours. Its very random. Can you kindly tell me what
you think could be going on ?

Best,
Annie

On Tue, Jan 24, 2017 at 1:25 AM, Bastian Bloessl 
wrote:

> Hi,
>
> On 01/24/2017 12:17 AM, Qurat-Ul-Ann Akbar wrote:
>
>> I did the following things that you suggested:
>>
>> 1) The gain is normalized and in the example file wifi_rx and tx it was
>> set to 0.75. I changed the gain to a bunch of values but nothing is
>> really changing. Also the scope plot in the receiver just shows noise
>> and even when I get some decoded message on the console I don't see
>> anything changing in the scope plot and the constellation plot is random
>> as well during the transmission. At 5.89 GHz (which is default in the
>> script when I downloaded it), it shows some packets on the console with
>> random sequence numbers but doesn't work at all at any other frequency
>> which I set by the frequency in the GUI.
>>
>
> I don't understand what exactly you are doing. The module is
> creating/decoding a baseband signal. It just instructs the hardware to tune
> to a certain frequency. So if your device works only on one particular
> frequency, it might be an issue of the device, the interference on the
> other channels, the antenna, etc ...
>
> However, I think that it is much more likely that you changed something in
> the flow graph and forgot to put the "freq" parameter properly in the HW
> source/sink. Maybe one device is not retuning when you click the GUI.
>
>
>
>> 2) I followed the instructions for testing wifi_rx with a wifi card on
>> your page. The beacon frames are not being detected by wifi_rx and
>> nothing gets printed on the console. I dont know whats wrong exactly. I
>> have tested my setup with a simple script sending a single and double
>> tone message at a frequency of 2.5 GHz and its successful so I dont
>> think its a hardware problem.
>>
>
> Make sure that these are 11a or 11g beacons (OFDM). Not 11b or some
> compatibility mode. You will have to set the sample rate to 20MHz.
>
>
>> Can you kindly tell me what could be going on ?
>>
>
>
> Sorry, but I have no idea. Make sure that there are no overruns/underruns
> ('O's and 'U's printed on the console).
>
> Best,
> Bastian
>
>
>
>
>> Thanks a lot,
>> Annie
>>
>> On Wed, Jan 18, 2017 at 12:24 AM, Bastian Bloessl > <mailto:bloe...@ccs-labs.org>> wrote:
>>
>> Hi,
>>
>> On 01/17/2017 11:57 PM, Qurat-Ul-Ann Akbar wrote:
>>
>> 1) The sequence numbers are not in accordance with the data.
>> Sometimes
>> the first packet I get has sequence number 0 but at other times
>> I get
>> sequence numbers like 5 or 41. The mac frame length is 524. An
>> example
>> sequence numbers pattern was 5,36,452,753,961. I do not
>> understand why
>> are the sequence numbers random? The antennas are very close to
>> each
>> other so shouldn't the packet loss rate be very low? And are
>> packets
>> corrupted and GNU Radio can not decode them properly?
>>
>>
>> The unreliability can have multiple reasons, like
>> - too high gain
>> - too low gain
>> - overruns/underrruns
>> - DC offset (try different LO offsets)
>>
>> The constellation plot is usually a good indicator how good it works.
>> Placing the USRPs side by side doesn't always make things better.
>>
>>
>> 2) My transmission does not work for any frequency other than
>> 5.89G. I
>> can't understand what could be the reason for this. Not even
>> 5.88G. My
>> daughter board supports 1.2G to 6GHz.
>>
>>
>>
>>

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p transceiver - Data not being received at any frequency other than 5.89G

[Qurat-Ul-Ann Akbar]

I did the following things that you suggested:

1) The gain is normalized and in the example file wifi_rx and tx it was set
to 0.75. I changed the gain to a bunch of values but nothing is really
changing. Also the scope plot in the receiver just shows noise and even
when I get some decoded message on the console I don't see anything
changing in the scope plot and the constellation plot is random as well
during the transmission. At 5.89 GHz (which is default in the script when I
downloaded it), it shows some packets on the console with random sequence
numbers but doesn't work at all at any other frequency which I set by the
frequency in the GUI.

2) I followed the instructions for testing wifi_rx with a wifi card on your
page. The beacon frames are not being detected by wifi_rx and nothing gets
printed on the console. I dont know whats wrong exactly. I have tested my
setup with a simple script sending a single and double tone message at a
frequency of 2.5 GHz and its successful so I dont think its a hardware
problem.

Can you kindly tell me what could be going on ?

Thanks a lot,
Annie

On Wed, Jan 18, 2017 at 12:24 AM, Bastian Bloessl 
wrote:

> Hi,
>
> On 01/17/2017 11:57 PM, Qurat-Ul-Ann Akbar wrote:
>
>> 1) The sequence numbers are not in accordance with the data. Sometimes
>> the first packet I get has sequence number 0 but at other times I get
>> sequence numbers like 5 or 41. The mac frame length is 524. An example
>> sequence numbers pattern was 5,36,452,753,961. I do not understand why
>> are the sequence numbers random? The antennas are very close to each
>> other so shouldn't the packet loss rate be very low? And are packets
>> corrupted and GNU Radio can not decode them properly?
>>
>
> The unreliability can have multiple reasons, like
> - too high gain
> - too low gain
> - overruns/underrruns
> - DC offset (try different LO offsets)
>
> The constellation plot is usually a good indicator how good it works.
> Placing the USRPs side by side doesn't always make things better.
>
>
>> 2) My transmission does not work for any frequency other than 5.89G. I
>> can't understand what could be the reason for this. Not even 5.88G. My
>> daughter board supports 1.2G to 6GHz.
>>
>>
>
> Can you describe a bit more verbose what you did and what happened?
> Actually, that should work by just changing the frequency in the GUI.
>
> To debug, it might also be helpful to test your setup with a WiFi card.
> This is helpful to understand if the problem is in the sender or the
> receiver.
>
> Best,
> Bastian
>
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRPs having the same IP address on a network

[Qurat-Ul-Ann Akbar]

I have checked my network configurations on both computers and the netmask
is set to 255.255.255.0.

I changed the IP of one USRP to 192.168.10.3 and then I started
transmitting data from the other USRP. It doesnt receive anything and when
I changed the IP back to 192.168.10.2 it started receiving data. Is it
related to the fact that I wasnt able to ping the USRP with IP address
192.168.10.3 from the other computer? But I should be able to change the IP
and still receive data.


On Wed, Jan 18, 2017 at 1:34 PM, Qurat-Ul-Ann Akbar <
quratulannakbar2...@u.northwestern.edu> wrote:

> There aren't dedicated ethernet cards for each USRP. I have just connect
> the ethernet data cable from the computer to the USRP.
>
> Oh. But if I can not ping the USRP with the other computer how will I send
> data from one USRP to the other ? And how do I find the original factory
> address?
>
>
>
> On Wed, Jan 18, 2017 at 1:20 PM,  wrote:
>
>> OK, so, dedicated ethernet cards on each computer for the N210s?
>>
>> If so, those are, unless you turn each machine into a router that "plays
>> nice" with the local network infrastructure, *private* connections--dont'
>> think of them as network connections but a bus connection between your
>> computer and the N210.  In which case, they could each have retained their
>> original factory address.
>>
>>
>>
>>
>>
>>
>> On 2017-01-18 14:13, Qurat-Ul-Ann Akbar wrote:
>>
>> Each USRP is connected with a different computer and therefore they both
>> have separate Ethernet ports. There is no switch in between the computers
>> and the USRPs.
>>
>> Best,
>> Annie
>>
>> On Wed, Jan 18, 2017 at 1:08 PM,  wrote:
>>
>>> We're going to need more of a description about how things are
>>> connected--do your USRPs have dedicated ethernet connections per computer,
>>> or are they connected to the same ports that your computers use to talk to
>>> the rest of your network?
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 2017-01-18 14:05, Qurat-Ul-Ann Akbar wrote:
>>>
>>> Hi Marcus,
>>>
>>> I have set the IP address of one USRPN210 to 192.168.10.3 replacing its
>>> default 192.168.10.2 IP but the I can not ping this USRP from a different
>>> computer which has the other USRP conneced to it. I can ping it from the
>>> same computer to which it is connected. Why is that? And how do you think I
>>> can fix this ?
>>>
>>> Best,
>>> Annie
>>> ___
>>> 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] USRPs having the same IP address on a network

[Qurat-Ul-Ann Akbar]

There aren't dedicated ethernet cards for each USRP. I have just connect
the ethernet data cable from the computer to the USRP.

Oh. But if I can not ping the USRP with the other computer how will I send
data from one USRP to the other ? And how do I find the original factory
address?



On Wed, Jan 18, 2017 at 1:20 PM,  wrote:

> OK, so, dedicated ethernet cards on each computer for the N210s?
>
> If so, those are, unless you turn each machine into a router that "plays
> nice" with the local network infrastructure, *private* connections--dont'
> think of them as network connections but a bus connection between your
> computer and the N210.  In which case, they could each have retained their
> original factory address.
>
>
>
>
>
>
> On 2017-01-18 14:13, Qurat-Ul-Ann Akbar wrote:
>
> Each USRP is connected with a different computer and therefore they both
> have separate Ethernet ports. There is no switch in between the computers
> and the USRPs.
>
> Best,
> Annie
>
> On Wed, Jan 18, 2017 at 1:08 PM,  wrote:
>
>> We're going to need more of a description about how things are
>> connected--do your USRPs have dedicated ethernet connections per computer,
>> or are they connected to the same ports that your computers use to talk to
>> the rest of your network?
>>
>>
>>
>>
>>
>>
>> On 2017-01-18 14:05, Qurat-Ul-Ann Akbar wrote:
>>
>> Hi Marcus,
>>
>> I have set the IP address of one USRPN210 to 192.168.10.3 replacing its
>> default 192.168.10.2 IP but the I can not ping this USRP from a different
>> computer which has the other USRP conneced to it. I can ping it from the
>> same computer to which it is connected. Why is that? And how do you think I
>> can fix this ?
>>
>> Best,
>> Annie
>> ___
>> 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] USRPs having the same IP address on a network

[Qurat-Ul-Ann Akbar]

Each USRP is connected with a different computer and therefore they both
have separate Ethernet ports. There is no switch in between the computers
and the USRPs.

Best,
Annie

On Wed, Jan 18, 2017 at 1:08 PM,  wrote:

> We're going to need more of a description about how things are
> connected--do your USRPs have dedicated ethernet connections per computer,
> or are they connected to the same ports that your computers use to talk to
> the rest of your network?
>
>
>
>
>
>
> On 2017-01-18 14:05, Qurat-Ul-Ann Akbar wrote:
>
> Hi Marcus,
>
> I have set the IP address of one USRPN210 to 192.168.10.3 replacing its
> default 192.168.10.2 IP but the I can not ping this USRP from a different
> computer which has the other USRP conneced to it. I can ping it from the
> same computer to which it is connected. Why is that? And how do you think I
> can fix this ?
>
> Best,
> Annie
>
> ___
> 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] USRPs having the same IP address on a network

[Qurat-Ul-Ann Akbar]

Hi Marcus,

I have set the IP address of one USRPN210 to 192.168.10.3 replacing its
default 192.168.10.2 IP but the I can not ping this USRP from a different
computer which has the other USRP conneced to it. I can ping it from the
same computer to which it is connected. Why is that? And how do you think I
can fix this ?

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

[Discuss-gnuradio] IEEE 802.11 a/g/p transceiver - Data not being received at any frequency other than 5.89G

[Qurat-Ul-Ann Akbar]

Hello,

I am using two USRPs N210 with CBX daughterboards connected to different
machines and I have GNU Radio version 3.7 and uhd version 3.11.

I installed the IEEE 802.11 a/g/p module for GNU Radio. I ran the wifi_rx
and wifi_tx on different machines and the data I send gets printed on the
console. However, there are two issues I am facing:

1) The sequence numbers are not in accordance with the data. Sometimes the
first packet I get has sequence number 0 but at other times I get sequence
numbers like 5 or 41. The mac frame length is 524. An example sequence
numbers pattern was 5,36,452,753,961. I do not understand why are the
sequence numbers random? The antennas are very close to each other so
shouldn't the packet loss rate be very low? And are packets corrupted and
GNU Radio can not decode them properly?

2) My transmission does not work for any frequency other than 5.89G. I
can't understand what could be the reason for this. Not even 5.88G. My
daughter board supports 1.2G to 6GHz.

Can someone please tell me what could be going on ?

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

[Discuss-gnuradio] Reason for runtime error:fifo ctrl timed out looking for acks

[Qurat-Ul-Ann Akbar]

Hello,

I have Ubuntu 16.04 and GNU radio version 3.7.10.1. I have two USRPs N210
with CBX daughterboard (1.2-6 GHz). My USRP is connected through the
Ethernet cable directly to the computer

I am trying to send OFDM modulated data through the TX/RX antenna and I run
uhd_fft to see the spectrum of the signal but whenever I start my
transmission, the uhd_fft plot freezes and the runtime error:fifo ctrl
timed out looking for acks appears on the terminal.

I have looked through previous mailing lists to find a solution but
couldn't find anything useful. Can someone please tell me why is this
happening and how can I fix this? Its very urgent for my project.

Thank you,

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

Re: [Discuss-gnuradio] Difference between examples/ofdm/benchmark_tx.py and examples/ofdm/tx_ofdm.py (Annie)

[Qurat-Ul-Ann Akbar]

Hi Martin,

Thanks for your response. Are benchmark_tx and benchmark_rx both deprecated
? And is there any example flowgraph which uses the ofdm_transmitter which
I can use to send the data. I have a CS background and I do not know much
about the signal processing at PHY layer in great detail.

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

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 169, Issue 13

[Qurat-Ul-Ann Akbar]

ct one of
> >> us). Also, don't forget to include time for Q&A.
> >>
> >> You aren't limited to slide presentations, of course. Be creative.
> >> However, FOSDEM is an open source conference, therefore we ask you to
> >> stay clear of marketing presentations. Of course, we like nitty-gritty
> >> technical stuff.
> >>
> >> Here's a list of topics that will most likely be included:
> >> - SDR Frameworks + Tools
> >> - Wireless security
> >> - Radio hardware
> >> - Telecommunications
> >> - Random fun wireless hacks
> >>
> >> We will reserve time for interactiveness, it won't all be talks.
> >>
> >> ** Important Dates
> >>
> >> FOSDEM is February 4th and 5th, 2017.
> >>
> >> * December 9th 2016: Submission Deadline
> >> * January 2nd 2017: Announcement of final schedule
> >> * February 4th 2017: SDR Track (Saturday)
> >>
> >> These dates are not set in stone. However, the least years we were
> >> always full to the brim with presentations, so if you want to present,
> >> please make sure to submit your abstracts soon!
> >>
> >> ** Steering Committee
> >>
> >> The track committee consists of:
> >> * Phil "catvideos" Balister (OpenEmbedded / OpenSDR)
> >> * Martin "mbr0wn" Braun (GNU Radio)
> >> * Sylvain "tnt" Munaut (OsmoCom)
> >>
> >> Hope to hear from you soon! And please forward this announcement.
> >>
> >> Martin
> >>
> >
> >
> > ___
> > USRP-users mailing list
> > usrp-us...@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
>
>
> --
>
> Message: 2
> Date: Sun, 11 Dec 2016 11:31:07 -0800
> From: Martin Braun 
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Difference between
> examples/ofdm/benchmark_tx.py and examples/ofdm/tx_ofdm.py
> Message-ID: 
> Content-Type: text/plain; charset=windows-1252
>
> You can basically ignore benchmark_tx.py, it's deprecated, will be
> removed soon and uses old APIs.
>
> However, in an nutshell, benchmark_tx.py is a transmitter application,
> whereas tx_ofdm.grc is a GRC flowgraph that demonstrates the internals
> of the OFDM transmitter.
>
> Cheers,
> Martin
>
> On 12/09/2016 11:37 AM, Qurat-Ul-Ann Akbar wrote:
> > Hi,
> >
> > I am new to GNU Radio and I want to use OFDM to send signals at
> > frequency of around 2.4 GHz using USRP N210 with daughter board RFX2400.
> > I do not really understand the difference between benchmark_tx.py and
> > tx_ofdm.py. I know that benchmark runs with the USRP as well because it
> > has an option to transmit through USRP and tx_ofdm doesn't have a
> > uhd_block. But if I add the uhd_block as a sink in tx_ofdm.grc what is
> > the difference then between the two files ? And which one should I use ?
> >
> > Thank you,
> > Annie
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
>
>
> --
>
> Message: 3
> Date: Sun, 11 Dec 2016 23:16:39 -0800
> From: Vishwesh Rege 
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] RFNoC blocks in GRC
> Message-ID:
>  bah...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> I'm unable to view RFNoC blocks in gnuradio-companion (in the block list on
> the right side). Sometimes I can view them, under (unspecified) ? uhd ?
> rfnoc but sometimes I can't for some reason. I have sourced
> rfnoc/setup_env.sh which I believe had solved the problem previously. Does
> anyone know the solution?
>
> Any suggestions appreciated. Thanks.
>
> Vishwesh
> -- next part --
> An HTML attachment was scrubbed...
> URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/
> attachments/20161211/643f4fa7/attachment.html>
>
> --
>
> Message: 4
> Date: Mon, 12 Dec 2016 14:44:47 +0530
> From: Nikita Airee 
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] reading uhd_rx_cfile data
> Message-ID:
>  gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello everyone!
>
> I am tryning to capure the IQ samples o

[Discuss-gnuradio] Difference between examples/ofdm/benchmark_tx.py and examples/ofdm/tx_ofdm.py

[Qurat-Ul-Ann Akbar]

Hi,

I am new to GNU Radio and I want to use OFDM to send signals at frequency
of around 2.4 GHz using USRP N210 with daughter board RFX2400. I do not
really understand the difference between benchmark_tx.py and tx_ofdm.py. I
know that benchmark runs with the USRP as well because it has an option to
transmit through USRP and tx_ofdm doesn't have a uhd_block. But if I add
the uhd_block as a sink in tx_ofdm.grc what is the difference then between
the two files ? And which one should I use ?

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