The error that you were getting was from some dead code (I tried to add one
arrowtop to the configurable band-diagrams and later left that feeling that it
looks bad, but forgot to remove the code).
I have updated the repo now. Please clone my latest code and let me know if you
are still facin
Hi Mac,
Could you please specify your version of pyqt. I have tested the tool with
version 4.9.1. The error has nothing to do with gnuradio version.
---
Regards
Sreeraj Rajendran
http://home.iitb.ac.in/~rsreeraj
From: Mac A. Cody
To: discuss-gnuradio@gnu.o
Hello,
I downloaded your updates to the filter design tool from
https://github.com/zeroXzero/gr-filtdes (zeroXzero-gr-filtdes-6cd8f37.zip)
After unzipping the archive, I followed the build instructions, using
the cmake command, as follows:
cmake -DCMAKE_INSTALL_PREFIX:PATH=
/home/mcody/.../zer
On 08/08/2012 10:31 AM, Weixian Zhou wrote:
> Hi Josh,
> The tone test works. And I have tried to use different antennas. The
> following is the result:
> https://docs.google.com/spreadsheet/ccc?key=0AiMWTi1wVxJedDBKNEdhaUFNSkNfdTJ6LUtjenZkTWc&pli=1#gid=1
>
> The results are very different even
On 08/08/2012 06:12 PM, Muhammad JUNAID wrote:
> How to install USRP1 block in GNU Radio 3.6? cmake version
> Is UHD source works for USRP1, if yes then How?
> Is sdr.osmocom works on UHD version USRP2?
> Thanks
>
Yes, install UHD and gnuradio and use the UHD source/sink blocks
Checkout the
On 08/05/2012 03:29 PM, Tom Rondeau wrote:
> Hey all,
>
> I just pushed a patch from Jaroslav Skarvada that should help ARM
> users without NEON support build GNU Radio. It's been tested and looks
> straight-forward, but as these things go, if you run into trouble with
> ARM processors after thi
How to install USRP1 block in GNU Radio 3.6? cmake version
Is UHD source works for USRP1, if yes then How?
Is sdr.osmocom works on UHD version USRP2?
Thanks
Regards
Muhammad Junaid
m_junaid0...@yahoo.com
___
Discuss-gnuradio mailing list
Discuss-gnura
On 08/08/2012 03:28 PM, Kinal, George V. wrote:
> We have an application which uses the uhd.usrp.sink3 block, with
> io_type.COMPLEX_FLOAT32. The complex vector is converted from a
> text-based I-Q file. It is then sent to the sink with the assignment
> self._src = gr.vector_source_c(z, True).
>
We have an application which uses the uhd.usrp.sink3 block, with
io_type.COMPLEX_FLOAT32. The complex vector is converted from a text-based I-Q
file. It is then sent to the sink with the assignment self._src =
gr.vector_source_c(z, True).
As I understand the documentation, the Boolean True p
Hi Josh,
The tone test works. And I have tried to use different antennas. The
following is the result:
https://docs.google.com/spreadsheet/ccc?key=0AiMWTi1wVxJedDBKNEdhaUFNSkNfdTJ6LUtjenZkTWc&pli=1#gid=1
The results are very different even with same antennas. The n_rcvd/n_right
is 626/623, and 289
Hi Alex,
I run benchmark_ofdm on my equipments. It can support 20MHz transmitting
and receiving. I run the commands
~/grforwarder_ylz/gr-uhd/apps$ ./benchmark_tx.py -f 2.485G -W 20M
~/grforwarder_ylz/gr-uhd/apps$ ./benchmark_rx.py -f 2.485G -W 20M
the receiver works well.
However, when I use t
I have enabled the real-time scheduling in my PCs. And my USRPs are
connected to PCs via direct link of a Gigabyte ethernet card.
I am now trying the volk.
--
Yang, Qing
Information Engineering, CUHK
2012/8/7 Nathan West
> On Tue, Aug 7, 2012 at 10:12 AM, wrote:
>
>> **
>>
>> On 06 Aug 2012
Cross posting to discuss-gnuradio.
The bug in question is that if you instanciate an alsa source on a busy
device (opened by another app), then the program crashed.
On 08/08/12 00:23, Dimitri Stolnikov wrote:
Hi Christian,
[...]
The other problem (segfault on trow in ctor) still has to be
It was for use in a multi-usrp configuration, but actually no longer
necessary. Thank you both!
On Tue, Aug 7, 2012 at 4:57 PM, Robert Cicconetti wrote:
> If you really needed to use a USRP as a standalone signal generator you
> could probably encode the signal into a hardware block on the FPGA,
14 matches
Mail list logo
