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
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 “LT
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 a
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 NotTellin
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,
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,
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 o
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'))
>
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 sugges
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
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
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 me
12 matches
Mail list logo