On Wed, Aug 17, 2011 at 11:58 PM, Marcus D. Leech wrote:
> Using GRC, instantiating a UHD Source block, and modify its parameters.
> Provokes errors from Python:
Marcus,
How recent are these errors? Has the offending commit been identified?
There's been some work done on gr-uhd very recently. An
On 23/08/11 10:54 PM, Tom Rondeau wrote:
> On Wed, Aug 17, 2011 at 11:58 PM, Marcus D. Leech wrote:
>
>> Using GRC, instantiating a UHD Source block, and modify its parameters.
>> Provokes errors from Python:
>>
>
> Marcus,
> How recent are these errors? Has the offending commit been ident
On Fri, Aug 19, 2011 at 10:58 AM, Scott Johnston
wrote:
> Hi Tom,
>
> What kind of topics do you expect to be covered in the Open Presentation /
> Discussion Session(s)?
>
> Looking forward to it.
>
> Scott
Well, since they are open, I'm willing to listen to suggestions. We
are also still plannin
On Fri, Aug 19, 2011 at 11:53 AM, Abhishek Gupta wrote:
> Hi,
>
> We want to modify the source of a single component, compile it and then
> reinstall it.
> Is it possible to do so or I have to install the whole gnuradio?
Yes, you can just go into the directory of the component, say
gr-audio, and
On Tue, Aug 23, 2011 at 5:58 PM, Philip Balister wrote:
> On 08/23/2011 05:15 PM, Morgan Redfield wrote:
>
>> Hi everyone,
>>
>> I updated the ofdm_benchmark_tx.py script to use UHD and I'm running it on
>> my E100. If I run it at a high enough sample rate, I get a lot of "S"
>> characters printed
On 08/23/2011 05:15 PM, Morgan Redfield wrote:
Hi everyone,
I updated the ofdm_benchmark_tx.py script to use UHD and I'm running it on
my E100. If I run it at a high enough sample rate, I get a lot of "S"
characters printed to the screen. Some googling shows that this means
there's packet loss w
On 08/23/2011 05:15 PM, Morgan Redfield wrote:
Hi everyone,
I updated the ofdm_benchmark_tx.py script to use UHD and I'm running it on
my E100. If I run it at a high enough sample rate, I get a lot of "S"
characters printed to the screen. Some googling shows that this means
there's packet loss w
Hi everyone,
I updated the ofdm_benchmark_tx.py script to use UHD and I'm running it on
my E100. If I run it at a high enough sample rate, I get a lot of "S"
characters printed to the screen. Some googling shows that this means
there's packet loss within a burst. What causes this? Is there any way
Alexandru-
I thought I would revisit the "dynamic file creation" issue under GRC. The
last suggestion was to simply code this up as a GRC custom block. I was hoping
to get some help from you on this, since my GRC/python programming skills are
very limited. I have modified a simple GRC-create
> When you construct a tune_request in your UHD-only C++ code, you can
> specify the desired LO offset. Consult the UHD Doxygen
> documents for more details.
>
You can call uhd.tune_request(freq, lo_offset) in grc
:-)
___
Discuss-gnuradio mailing
On 23/08/2011 3:49 PM, Bastien Auneau wrote:
Thanks again for the answer
Posting on both Discuss Gnuradio and USRP User. So far never got answer
from USRP User list... So I stick on Gnu Radio
Here is a screenshot of the the FFT. You can see some of the small
bursty carriers on the right, but als
On 08/23/2011 12:18 PM, Bastien Auneau wrote:
> Thanks for the advice
> The thing is we want to use pure UHD, no gnuradio or flow graph...
> We already have done many test using labview and Gnu Radio Companion
>
You are mailing the gnuradio mailing list. You cant blame me for
recommending you t
On 23/08/2011 3:18 PM, Bastien Auneau wrote:
Thanks for the advice
The thing is we want to use pure UHD, no gnuradio or flow graph...
We already have done many test using labview and Gnu Radio Companion
In which case, you should probably be posting your questions to
usrp-users, instead of this l
Also regarding the bell shaped high and thin carrier that is added on
top of sampled signal. My colleague noticed that this bell shaped
carrier is present in the .dat file. So it is not a tx problem. He looks
at the .dat file using some FFT (FFT power spectrum), running through
the samples. (I gues
Thanks for the advice
The thing is we want to use pure UHD, no gnuradio or flow graph...
We already have done many test using labview and Gnu Radio Companion
Also, by increasing the gain on capture (using rx_samples_to_file.exe)
we get a better signal. When playing out, we can actually see small
b
Hi Josh
I'll stop flying blind for now
But I'm not sure what else can be done ?!
We are using USRP to create a DVB-RCS terminal
We already have a commercial product using another HW platform
We are now moving this product to the USRP N210 platform
UHD programming has been mostly done, especially
On 08/23/2011 10:36 AM, Bastien Auneau wrote:
> Hi All
>
> Using USRP N 210, WBX board, GPSDO, UHD 3.2.2, under Windows 7
>
> We want to use the example scripts to capture then playout a signal we
> get from the air (satellite link with bursts). We proceed as follow :
> 1. capture using rx_samp
Hi All
Using USRP N 210, WBX board, GPSDO, UHD 3.2.2, under Windows 7
We want to use the example scripts to capture then playout a signal we
get from the air (satellite link with bursts). We proceed as follow :
1. capture using rx_samples_to_file.exe --type short --rate 1000
--freq 1057232000
hi sir,
i don't have problem while compiling and installing the comedi block.
i am not getting why this error occur when i run in GRC.
Traceback (most recent call last):
File "/home/jagdish/top_block.py", line 8, in
from gnuradio import comedi
File "/usr/local/lib/python2.6/dist-packages
19 matches
Mail list logo
