Hi Josh,
It seems you are right. Even though all libraries were in release mode,
my app was in debug. I recompiled it in release and everything goes
fine. I recompiled boost, uhd, qt, gnuradio and my app in debug and it
does not work. Do you know why?
Thanks.
Pol Henarejos
Research Engineer, MS
Dear all,
I am planning to purchase a gpsdo kit from ettus research to set up a 2X2
mimo system using 4 usrp2s. I need your help in answering a few questions
that i have.
is the gpsdo kit only meant fro the usrpN series devices only? or can they
be used with usrp2 also?
in order to sync 2 Tx and
On 29 May 2012 09:27, bharadwaj desikan wrote:
> Dear all,
>
> I
am planning to purchase a gpsdo kit from ettus research to set up a 2X2
mimo system using 4 usrp2s. I need your help in answering a few
questions that i have.
>
> is the gpsdo kit only meant fro the usrpN
series devices only? o
Dear list,
I am using gr_uhd_source as the source of my app. At some moment, there
is an overflow, an O is printf'ed and the scheduler stops. The program
is still running but there is no flow of samples between blocks. They
are waiting for something. I added the following lines in the work() of
gr
The hardware information page here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Hardware#RTL2832-TV-tuners
Refers to the gr-baz RTL-SDR driver, which, IMHO isn't as good as the
gr-osmosdr drivers, here:
http://sdr.osmocom.org/trac/wiki/rtl-sdr
AMONG OTHER THINGS THE GR-OSMOSDR DRI
On 05/29/2012 07:29 AM, Pol Henarejos wrote:
> Dear list,
>
> I am using gr_uhd_source as the source of my app. At some moment, there
> is an overflow, an O is printf'ed and the scheduler stops. The program
> is still running but there is no flow of samples between blocks. They
> are waiting for
On 05/29/2012 01:22 AM, Pol Henarejos wrote:
> Hi Josh,
>
> It seems you are right. Even though all libraries were in release mode,
Im glad its working for you!
> my app was in debug. I recompiled it in release and everything goes
> fine. I recompiled boost, uhd, qt, gnuradio and my app in deb
On 05/25/2012 09:18 PM, Page Jack wrote:
> Hi Philip,
> How does the conclusion be made that ARM can not swallow the current
> max data transfer rate? I need to build a project that need to process
> 60MB/s data, so any way to achieve my goal. Use a more powerful CPU or
> use dsp on the omap?
60 M
Hi list,
We've setup 4 USRP N210 rev4s with a Dell PowerEdge R510 server to collect
RF data for GPS related experiments. The server works great and we seem to
be able to write 20 Msps from each device simultaneously to a RAID array
with no overflows. However, after each collection program is ter
I don't want to using a ethernet wire to connect N series to an ARM board.
anyone have tried
build N series with ARM or DSP in one board which means the ethernet line
between N and
the processor is on PCB.
On Wed, May 30, 2012 at 6:24 AM, Philip Balister wrote:
> On 05/25/2012 09:18 PM, Page Jack
I have been considering using GnuRadio with the USRPN210 as a realtime fading
simulator for radio hardware testing, however any approaches I've considered in
doing this seem to fall down fundamentally if I limit to using a single USRP.
I'm still relatively sure it could be done, was wondering i
On Tue, May 29, 2012 at 9:47 PM, J Mc wrote:
> I have been considering using GnuRadio with the USRPN210 as a realtime
> fading simulator for radio hardware testing, however any approaches I've
> considered in doing this seem to fall down fundamentally if I limit to using
> a single USRP. I'm still
On 05/29/2012 05:36 PM, Ryan Wolfarth wrote:
> Hi list,
>
> We've setup 4 USRP N210 rev4s with a Dell PowerEdge R510 server to collect
> RF data for GPS related experiments. The server works great and we seem to
> be able to write 20 Msps from each device simultaneously to a RAID array
> with n
If memory serves correctly the n200 or the usrp 2 has an fpga expansion
interface to some xilinx development platform which you might be able to
use to create a custom solution to serve your needs.
Al
On May 29, 2012 6:17 PM, "Page Jack" wrote:
> I don't want to using a ethernet wire to connect
Hi,
I was using Funcube dongle and found a strange bug. Whenever I used the FCD
source in my flow graph and started the flow, the (demodulated) signal came
out corrupted. However, if I then just started qthid, it would correct itself
and could see bits in waveform perfectly well. This was happe
Dear Josh,
The hardware is USRP2 at 10Msps with latest UHD version
UHD_003.004.001-165-unstable.
As you pointed, it seems that does not restart the streamer. I made a
rough patch that works continously. I still get overflows but it does
not stop.
diff --git a/gr-uhd/lib/gr_uhd_usrp_source.cc
b/g
16 matches
Mail list logo
