Re: [Discuss-gnuradio] [USRP-users] Configuring TX Gain During Simulation in USRP N210

[Marcus D. Leech]

On 12/13/2016 02:53 PM, Qurat-Ul-Ann Akbar wrote:

Hi,

Can you kindly tell me how to do that? Because I am using GNU Radio 
with the USRP N210 and the uhd sink block basically consists of the 
parameters for configuring the USRP device. How can I do that during 
simulation?


Thanks!


This is a good question for the discuss-gnuradio mailing list, to which 
I have cross-posted, and the conversation can continue on there.


Any of the parameters in a block can be tied to a variable in GRC, and 
many of the parameters are also programmable using the

  message port on the UHD sink block.

The details of "how do I make my software do that" requires more input 
about what your software is supposed to do, what your

  level of programming experience is, etc.


On Tue, Dec 13, 2016 at 11:56 AM, > wrote:


Yes, TX gain, frequency, etc, are all changeable at runtime--they
aren't just "setup only" parameters.

On 2016-12-13 12:11, Qurat-Ul-Ann Akbar via USRP-users wrote:


Hi,
Is it possible to change the transmitted power just before the
signal is about to be transmitted during a simulation sending
some data. I know that you can configure TX Gain but can you keep
changing it?
For example the first 100 packets for a certain amount of time
have this much power and the next 100 have a different value of
power. Is this possible with USRP N210 ?
Best,
Annie

___
USRP-users mailing list
usrp-us...@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com 






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

[Discuss-gnuradio] UHD 3.09 in Pybombs

[Gregory Ratcliff]

Did a fresh Pybombs install today.  Everything pybombs and gnuradio seems to be 
really working well lately.  Great work guys.

I noticed that the UHD recipes seem to be yanking from 3.09 rather than the 
August release of 3.10.

Not complaining; It will give me a chance to modify a recipe.

Is “LTS” our criteria before Pybombs recipes point at the latest releases for 
core at OOT modules?

This caused me to look into Pybombs for a way to control the recipe “ersion; 
looks like you get the best.  This has worked pretty well for me so far, but I 
recently flashed my N210 since macports used 3.10.

Any plans to update core pybombs to 3.10?

Greg


___
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)

[Martin Braun]

They're both deprecated. Maybe this helps:
https://archive.fosdem.org/2014/schedule/event/tutorial_ofdm_packet_transceivers/

Cheers,
M

On 12/12/2016 10:20 AM, Qurat-Ul-Ann Akbar wrote:
> 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
> 


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

Re: [Discuss-gnuradio] PMT Oddities

[Martin Braun]

I'd agree that your code is not behaving as expected. Don't have
something off the top of my head though :/

M

On 12/13/2016 02:51 PM, Dave NotTelling wrote:
> Assuming that is reproducible, does anyone have suggestions on how to
> get around it?
> 
> On Fri, Dec 9, 2016 at 9:16 PM, Dave NotTelling  > wrote:
> 
> Here is a full example:
> 
> [code]
> 
> #!/usr/bin/python
> 
> import pmt
> 
> d = pmt.make_dict()
> d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
> d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
> d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))
> 
> a = pmt.cons(d, pmt.make_u8vector(10, 10))
> 
> print 'dict_keys with a populated dictionary'
> print pmt.dict_keys(a)
> 
> a = pmt.cons(pmt.make_dict(), pmt.make_u8vector(10, 10))
> 
> print 'dict_keys with an empty dictionary'
> print pmt.dict_keys(a)
> 
> [/code]
> 
> You end up with the following output:
> 
> [output]
> 
> dict_keys with a populated dictionary
> ((c . c))
> dict_keys with an empty dictionary
> Traceback (most recent call last):
>   File "test.py", line 18, in 
> print pmt.dict_keys(a)
>   File "/usr/local/lib/python2.7/dist-packages/pmt/pmt_swig.py",
> line 3010, in dict_keys
> return _pmt_swig.dict_keys(dict)
> RuntimeError: pmt_car: wrong_type : ()
> 
> 
> [/output]
> 
> The first call to dict_keys(a) returns the last element in the
> dictionary.  The second call errors out.  Both should error out correct?
> 
> On Fri, Dec 9, 2016 at 9:11 PM, Dave NotTelling  > wrote:
> 
> I understand that it should bomb, but it doesn't if there are
> elements in the dictionary of the pair generated by cons.
>  that's the problem.  calling dict_keys should die on both
> tests, but returns just fine on the first test. 
> 
> 
> On Dec 9, 2016 1:35 PM, "Martin Braun"  > wrote:
> 
> On 12/05/2016 01:56 PM, Dave NotTelling wrote:
> > Marcus & Martin:
> >
> >  I tried the dict_keys() method of checking, but even
> that can
> > fail.  Here is an example:
> >
> > [code]
> >
> > import pmt
> >
> > d = pmt.make_dict()
> > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
> > d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
> > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))
> >
> > a = pmt.cons(d, pmt.make_u8vector(10, 10))
> >
> > print pmt.dict_keys(a)
> >
> > [/code]
> >
> > You end up with: ((c . c))
> >
> > The dict_keys() method will bomb if there are no elements
> in the dictionary:
> >
> > print pmt.dict_keys(pmt.cons(pmt.make_dict(),
> pmt.make_u8vector(10, 10)))
> 
> It's supposed to bomb -- pmt.cons() does not return a dict.
> That's
> exactly how you can test for dicts.
> 
> See:
> 
> https://github.com/gnuradio/gnuradio/blob/1e8562c8d5430667b48fced2d2e50ab5771dfb5e/gr-uhd/lib/usrp_block_impl.cc#L486-L494
> 
> 
> 
> -- M
> 
> ___
> 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] uhd_images_downloader with RFNoC

[Andrew Lanez]

On https://kb.ettus.com/RFNoC_Getting_Started_Guides it says

"We will be updating the default image occasionally, and you can run
uhd_images_downloader again after running git pull and re-installing."

1. What would I be pulling and re-installing (UHD)? If I opt not to
configure a github account, what are the complete commands to install the
latest version to work with the default prefixed ~/rfnoc working
directory setup
with pybombs?

2. What are the complete commands to revert to previous versions that work
with the default prefixed ~/rfnoc directory setup with pybombs? I'm
currently using UHD 4.0.0 and uhd_probe_devices errors out so I want to try
older versions of the default usrp_x310_fpga_HG.bit to troubleshoot.

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

Re: [Discuss-gnuradio] Replacement for packet encoder/decoder

[Damindra Bandara]

Dear Marcus,

Thank you very much for being patient with me and answering all my
questions. I have one last question. Is there a good reference you could
recommend me to read, to understand how the current GNURadio OFDM
implementation works?

Best regards,
Damindra

On Tue, Dec 13, 2016 at 6:10 PM, Marcus Müller 
wrote:

> Hi Damindra
>
> On 13.12.2016 23:42, Damindra Bandara wrote:
>
> Dear Marcus,
>
> Thank you for your suggestion.  However, according to my use case, I
> cannot do multiple transmissions at a higher layer.
>
> I kind of doubt that - you're writing your own OFDM transceiver right now,
> and thus you're the one currently defining the format in which data is
> transported
>
> I have few questions about the  "OFDM Carrier Allocator."
>
> 1- Can current  "OFDM Carrier Allocator" support multiple streams using
> multiple channels, or you suggest me to write a new block?
>
> As said: write a new block!
>
> Best regards,
> Marcus
>
>
> 2- If the current block can support, is there any documentation I could
> refer?
>
> Thanks,
> Damindra
>
>
>
>
> On Tue, Dec 13, 2016 at 2:19 PM, Marcus Müller 
> wrote:
>
>> Dear Damindra,
>>
>> To me, that sounds like a higher-level problem – ie. you can send
>> whatever you want across your OFDM link, and that includes e.g. ethernet or
>> IP packets with different destinations; that would make things more
>> flexible – you wouldn't have to statically assign a set of carriers to a
>> single logical data stream.
>>
>> But you can of course also write a OFDM Carrier Allocator (compare
>> tx_ofdm.grc)
>>
>> Best regards,
>>
>> Marcus
>> On 12/13/2016 07:32 PM, Damindra Bandara wrote:
>>
>> Dear Marcus,
>>
>> Thank you for your response.
>>
>> My objective is to send multiple streams of data. For example a
>> transmitter to use two different streams to talk to two receivers. I was
>> thinking something similar to Frequency Division Multiplexing, where each
>> stream is represented using a different sub channel.
>>
>> Thank you,
>> Damindra
>>
>> --
>> Damindra Savithri Bandara,
>> Ph.D. in Information Technology (Candidate)
>> George Mason University,
>> Fairfax,
>> Virginia
>>
>>
>>
>
>
> --
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
>
>
>


-- 
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Replacement for packet encoder/decoder

[Marcus Müller]

Hi Damindra


On 13.12.2016 23:42, Damindra Bandara wrote:
> Dear Marcus,
>
> Thank you for your suggestion.  However, according to my use case, I
> cannot do multiple transmissions at a higher layer.
>
I kind of doubt that - you're writing your own OFDM transceiver right
now, and thus you're the one currently defining the format in which data
is transported
> I have few questions about the  "OFDM Carrier Allocator."
>
> 1- Can current  "OFDM Carrier Allocator" support multiple streams
> using multiple channels, or you suggest me to write a new block?
As said: write a new block!

Best regards,
Marcus

> 2- If the current block can support, is there any documentation I
> could refer?
>
> Thanks,
> Damindra
>
>
>
>
> On Tue, Dec 13, 2016 at 2:19 PM, Marcus Müller
> > wrote:
>
> Dear Damindra,
>
> To me, that sounds like a higher-level problem – ie. you can send
> whatever you want across your OFDM link, and that includes e.g.
> ethernet or IP packets with different destinations; that would
> make things more flexible – you wouldn't have to statically assign
> a set of carriers to a single logical data stream.
>
> But you can of course also write a OFDM Carrier Allocator (compare
> tx_ofdm.grc)
>
> Best regards,
>
> Marcus
>
> On 12/13/2016 07:32 PM, Damindra Bandara wrote:
>> Dear Marcus,
>>
>> Thank you for your response. 
>>
>> My objective is to send multiple streams of data. For example a
>> transmitter to use two different streams to talk to two
>> receivers. I was thinking something similar to Frequency Division
>> Multiplexing, where each stream is represented using a different
>> sub channel.
>>
>> Thank you,
>> Damindra
>>
>> -- 
>> Damindra Savithri Bandara,
>> Ph.D. in Information Technology (Candidate)
>> George Mason University,
>> Fairfax,
>> Virginia
>
>
>
>
> -- 
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia

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

Re: [Discuss-gnuradio] PMT Oddities

[Dave NotTelling]

Assuming that is reproducible, does anyone have suggestions on how to get
around it?

On Fri, Dec 9, 2016 at 9:16 PM, Dave NotTelling  wrote:

> Here is a full example:
>
> [code]
>
> #!/usr/bin/python
>
> import pmt
>
> d = pmt.make_dict()
> d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
> d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
> d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))
>
> a = pmt.cons(d, pmt.make_u8vector(10, 10))
>
> print 'dict_keys with a populated dictionary'
> print pmt.dict_keys(a)
>
> a = pmt.cons(pmt.make_dict(), pmt.make_u8vector(10, 10))
>
> print 'dict_keys with an empty dictionary'
> print pmt.dict_keys(a)
>
> [/code]
>
> You end up with the following output:
>
> [output]
>
> dict_keys with a populated dictionary
> ((c . c))
> dict_keys with an empty dictionary
> Traceback (most recent call last):
>   File "test.py", line 18, in 
> print pmt.dict_keys(a)
>   File "/usr/local/lib/python2.7/dist-packages/pmt/pmt_swig.py", line
> 3010, in dict_keys
> return _pmt_swig.dict_keys(dict)
> RuntimeError: pmt_car: wrong_type : ()
>
>
> [/output]
>
> The first call to dict_keys(a) returns the last element in the
> dictionary.  The second call errors out.  Both should error out correct?
>
> On Fri, Dec 9, 2016 at 9:11 PM, Dave NotTelling 
> wrote:
>
>> I understand that it should bomb, but it doesn't if there are elements in
>> the dictionary of the pair generated by cons.  that's the problem.  calling
>> dict_keys should die on both tests, but returns just fine on the first
>> test.
>>
>>
>> On Dec 9, 2016 1:35 PM, "Martin Braun"  wrote:
>>
>> On 12/05/2016 01:56 PM, Dave NotTelling wrote:
>> > Marcus & Martin:
>> >
>> >  I tried the dict_keys() method of checking, but even that can
>> > fail.  Here is an example:
>> >
>> > [code]
>> >
>> > import pmt
>> >
>> > d = pmt.make_dict()
>> > d = pmt.dict_add(d, pmt.intern('a'), pmt.intern('a'))
>> > d = pmt.dict_add(d, pmt.intern('b'), pmt.intern('b'))
>> > d = pmt.dict_add(d, pmt.intern('c'), pmt.intern('c'))
>> >
>> > a = pmt.cons(d, pmt.make_u8vector(10, 10))
>> >
>> > print pmt.dict_keys(a)
>> >
>> > [/code]
>> >
>> > You end up with: ((c . c))
>> >
>> > The dict_keys() method will bomb if there are no elements in the
>> dictionary:
>> >
>> > print pmt.dict_keys(pmt.cons(pmt.make_dict(), pmt.make_u8vector(10,
>> 10)))
>>
>> It's supposed to bomb -- pmt.cons() does not return a dict. That's
>> exactly how you can test for dicts.
>>
>> See:
>> https://github.com/gnuradio/gnuradio/blob/1e8562c8d5430667b4
>> 8fced2d2e50ab5771dfb5e/gr-uhd/lib/usrp_block_impl.cc#L486-L494
>>
>> -- M
>>
>> ___
>> 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] Replacement for packet encoder/decoder

[Damindra Bandara]

Dear Marcus,

Thank you for your suggestion.  However, according to my use case, I cannot
do multiple transmissions at a higher layer.

I have few questions about the  "OFDM Carrier Allocator."

1- Can current  "OFDM Carrier Allocator" support multiple streams using
multiple channels, or you suggest me to write a new block?
2- If the current block can support, is there any documentation I could
refer?

Thanks,
Damindra




On Tue, Dec 13, 2016 at 2:19 PM, Marcus Müller 
wrote:

> Dear Damindra,
>
> To me, that sounds like a higher-level problem – ie. you can send whatever
> you want across your OFDM link, and that includes e.g. ethernet or IP
> packets with different destinations; that would make things more flexible –
> you wouldn't have to statically assign a set of carriers to a single
> logical data stream.
>
> But you can of course also write a OFDM Carrier Allocator (compare
> tx_ofdm.grc)
>
> Best regards,
>
> Marcus
> On 12/13/2016 07:32 PM, Damindra Bandara wrote:
>
> Dear Marcus,
>
> Thank you for your response.
>
> My objective is to send multiple streams of data. For example a
> transmitter to use two different streams to talk to two receivers. I was
> thinking something similar to Frequency Division Multiplexing, where each
> stream is represented using a different sub channel.
>
> Thank you,
> Damindra
>
> --
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
>
>
>


-- 
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Replacement for packet encoder/decoder

[Marcus Müller]

Dear Damindra,

To me, that sounds like a higher-level problem – ie. you can send
whatever you want across your OFDM link, and that includes e.g. ethernet
or IP packets with different destinations; that would make things more
flexible – you wouldn't have to statically assign a set of carriers to a
single logical data stream.

But you can of course also write a OFDM Carrier Allocator (compare
tx_ofdm.grc)

Best regards,

Marcus

On 12/13/2016 07:32 PM, Damindra Bandara wrote:
> Dear Marcus,
>
> Thank you for your response. 
>
> My objective is to send multiple streams of data. For example a
> transmitter to use two different streams to talk to two receivers. I
> was thinking something similar to Frequency Division Multiplexing,
> where each stream is represented using a different sub channel.
>
> Thank you,
> Damindra
>
> -- 
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia

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

Re: [Discuss-gnuradio] Replacement for packet encoder/decoder

[Damindra Bandara]

Dear Marcus,

Thank you for your response.

My objective is to send multiple streams of data. For example a transmitter
to use two different streams to talk to two receivers. I was thinking
something similar to Frequency Division Multiplexing, where each stream is
represented using a different sub channel.

Thank you,
Damindra

-- 
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee802.11 Questions

[Manolis Surligas]

Are you sure? Last time I checked, the RPi3 could not perform realtime 
(quite simple) filtering at 10 MHz. I doubt it can handle the 20 MSPS of 
the 802.11.



On 12/12/2016 09:01 PM, Eric Yates wrote:

Hi Paul,

Thanks for the quick response. The RPi 3 had enough processing power 
to receive a message using gr-ieee802.15.4 from a ZigBee chip in 
real-time. I believe I'm running the Wifi also in real-time, is there 
a way to do it in non-real time instead?


Thanks,

Eric Yates

On Mon, Dec 12, 2016 at 12:58 PM, Garver, Paul W > wrote:


I would be shocked if the Raspberry Pi 3 has the processing power
to run gr-ieee80211. Are you attempting to do this real-time?

PWG

On Dec 12, 2016, at 10:31 AM, Eric Yates > wrote:

Hello,

I'm running gr-ieee802.11 on a Raspberry Pi 3 running Raspbian.
I'm connected to a bladeRF and running GRC 3.7.10. At this point,
I want to sniff WiFi packets to demonstrate the bladeRF working
with receiving WiFi from say a router or laptop (no transmission
yet). I'm using the 2.4GHz band with 20MHz bandwidth because
bladeRF does not go up to the 5GHz band.

In the WiFi RX example, I only changed the USRP Source to a
Osmocom Source block. In this example, it appears Wireshark has
been connecting to GRC via the /tmp/wifi.pcap pipe because the
Wireshark capture session closes when I kill the WiFi RX script.
The constellation and time graphs both work, but I do not see any
packets in Wireshark no matter the channel. Executing the script
produces no errors, it just doesn't capture packets.

I thought the FFT block might be to blame because it had no
documentation for it while all the other blocks did. I
reinstalled fftw3 (v. >3) and it didn't update the documentation.
osmocom_fft also works, so I don't think the FFT block is the
problem but I wonder why it's missing documentation. Then, I
reinstalled gnuradio and gr-ieee802.11 both after making sure the
necessary dependencies were met for both. Still no changes.
Wireshark receives packets from the WiFi Loopback example sent by
the message strobe perfectly fine.

I would greatly appreciate any insights you have into why
Wireshark is not receiving any WiFi packets from the bladeRF
using the WiFi RX example. Do you have any ideas of what's going
on or would you need any more information?

Thank you,

Eric Yates
___
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


--
/* Code is the Law */

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