Hi Eric,
On Aug 19, 2010, at 5:35 AM, Eric Blossom wrote:
> Elvis, do you understand the high level source of the problem?
> That is, that there are two hardware devices whose clocks are not
> synchronized?
Yes, I do now, and that one possible solution is to rate match or buffer the
sample data
On Wed, Aug 18, 2010 at 18:35, Eric Blossom wrote:
> The relative rates may be mismatched by less than 0.1%. Even at that
> level, on the average you'd need to be adding or dropping 1 sample
> every 1000 to match the rates between the two clock domains.
I've had (cheap) sound cards that require
On Sat, Aug 14, 2010 at 03:16:38AM +0400, Elvis Dowson wrote:
> Hi Eric,
>
> On Aug 13, 2010, at 8:38 PM, Eric Blossom wrote:
>
> > Given the interfaces exported by ALSA, you'd need to figure out how to
> > honor the condition "ok_to_block == False".
>
> Could you please tell me the intent behin
On Wed, Aug 18, 2010 at 15:08, Moeller wrote:
> I wonder if it is time now for switching to the new UHD Firmware.
> It is declared as "alpha", but it seems that for new code now, the UHD
> should be the preferred API.
> The problem is, what to do with the old applications? They are all made
> f
On Fri, Aug 13, 2010 at 09:59:20PM +0400, Elvis Dowson wrote:
> Hi Eric,
>Before I dive into it, I just have a quick question.
> Why is it that others are not encountering the same issue? The same
> example code was run on a Mac Pro dual quad machine belonging to
> another member
On Sun, Aug 15, 2010 at 19:12, Marcus D. Leech wrote:
> I have an application that must operate in the 25MHz to 40MHz region,
[...]
> It's not a neighbourhood I've habitually "hung out" in
The 30-40 MHz region is typically very quiet. Much of the radio
traffic that used to exist there (LMR stuf
On Sat, Aug 14, 2010 at 18:26, George Nychis wrote:
> However, when I transmit using my scaled signal, I get some major clipping:
>
Aside from clipping, you are probably seeing some distortion due to
non-linearities in the PA of whatever daughterboard you are using.
Depending on your modulation
On Fri, Aug 13, 2010 at 12:06, Marc Epard wrote:
> Does anyone happen to have Octave or MATLAB code that models the USRP2's DDC
> (CIC and HBFs)?
This covers the CIC portion:
http://gnuradio.org/redmine/repositories/annotate/gnuradio/gnuradio-core/src/utils/plot_cic_decimator_response.m
This
On 19.08.2010 00:45, Josh Blum wrote:
>> Now with UHD the chances for Cygwin support are much better, right?
>> If the UHD is using UDP datagrams, this should be realistic in Cygwin
>> with standard sockets. The UHD build instructions for Windows only deal with
>> the MSVC.
>
> I believe that cma
On 08/18/2010 03:25 PM, Moeller wrote:
I managed to compile most of the Gnuradio for Cygwin, including the grc.
Only the USRP2 driver was incompatible with Windows, because
the raw-socket concepts are totally different (even in with Cygwin).
Now with UHD the chances for Cygwin support are muc
I managed to compile most of the Gnuradio for Cygwin, including the grc.
Only the USRP2 driver was incompatible with Windows, because
the raw-socket concepts are totally different (even in with Cygwin).
Now with UHD the chances for Cygwin support are much better, right?
If the UHD is using UDP dat
I wonder if it is time now for switching to the new UHD Firmware.
It is declared as "alpha", but it seems that for new code now, the UHD
should be the preferred API.
The problem is, what to do with the old applications? They are all made
for the old API model. So, switching to UHD on the USRP side
Hi,
Can anyone explain to me why do we need the hackery in OFDM tunnel? Is there
a problem with having different transmit and receive frequencies?
Thanks,
Tuan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/list
Hi,
n...@:~/uhdpriv$ grep -rl "} usrp2_ctrl_data_t" *
host/lib/usrp/usrp2/fw_common.h
Best,
Nick
Date: Wed, 18 Aug 2010 13:04:27 -0700
From: vlsi.ana...@gmail.com
To: m...@ettus.com; discuss-gnuradio@gnu.org
CC:
Subject: [Discuss-gnuradio] usrp2_ctrl_data_t
Hi,
There is a datatype
Hi,
There is a datatype"usrp2_ctrl_data_t" being used in
the "usrp2_iface.cpp" file in the UHD Host folder. I couldn't find the
definition for this data type. Please point me where this data type has been
defined.
Cheers
___
Disc
On 08/18/2010 01:41 PM, David Evans wrote:
> Hi,
>
> GRC Setup (used with RFX and WBX cards)...
>
> USRP1 ---to---> FFT Graphical sink (shows signal spectrum as expected)
> and ---to---> Complex to IShort -to> File Sink (signals are
> dumped
> to disk as expected)
>
> USRP2 ---to---
Hi,
GRC Setup (used with RFX and WBX cards)...
USRP1 ---to---> FFT Graphical sink (shows signal spectrum as expected)
and ---to---> Complex to IShort -to> File Sink (signals are
dumped
to disk as expected)
USRP2 ---to---> FFT Graphical sink (shows signal spectrum as expected)
Hi, I am using the usrp_wfm_rcv_nogui program to listen to FM radio. I have
also added code to the program so that I can perform a scan, for stations in
my area. My code works by first creating a usrp_source() for the FM code.
When I want to scan for stations I press a button on my keyboard and
Hi all,
Im a new user of the USRP2 (been playing with it recently)
I noticed that most of the code is written in gnuradio for usrp.
Im trying to use usrp_tv_rcv.py
Can someone point me to the right direction to what I need to know
when trying to port src from USRP to USRP2, also decimation chang
Ok Folks;
Haven't spoken to the vendors yet, but here's the board anyway.
The board is actually two circuits. One for the Si590 part and one for the
Pletronics part.
You will see that each board has tracking for two OCXO's, so you can have a
dual frequency source.
This seemed like a lot cl
Hi,
> It seems that 52MHz /64MHz precision clock references are like hen’s
> teeth, so I’m working on a design.
Have you seen http://code.google.com/p/clock-tamer/ ?
It can provide precision 52 / 64 MHz (and a lot of others) and can also
integrate a GPS receiver to lock itself to the 1 pps.
T
21 matches
Mail list logo
