On 05/19/2011 11:51 PM, ikjtel wrote:
> Yep - it just so happens that these are "digital" (P25) channels,
> not analog ones, but robust detection/correction protocols at the
> higher levels are there to cope with the occasional glitches...
>
If they fly through the aether, they're analog. Once
> In the real world, glitches happen on analog channels.
> Which is why you develop techniques to cope with them.
> I see the occasional underrun/overrun as equivalent to
> these glitches.
Yep - it just so happens that these are "digital" (P25) channels,
not analog ones, but robust detection/corre
http://www.ettus.com/uhd_docs/manual/html/build.html
On Thu, 2011-05-19 at 19:50 -0700, hafiz zimran wrote:
> Hi
> I have installed UHD on SD Card. When I turn on USRP2, LED "D & F" on
> ( SD card is working properly) .
> Ubuntu 10.04 with GNUradio 3.2.2 has been installed on PC.
> When I run the
On 05/19/2011 07:50 PM, hafiz zimran wrote:
> Hi
> I have installed UHD on SD Card. When I turn on USRP2, LED "D & F" on ( SD
> card is working properly) .
> Ubuntu 10.04 with GNUradio 3.2.2 has been installed on PC.
> When I run the command " sudo find_usrps", I got " NO USRP2 Found".
> The com
Hi
I have installed UHD on SD Card. When I turn on USRP2, LED "D & F" on ( SD card
is working properly) .
Ubuntu 10.04 with GNUradio 3.2.2 has been installed on PC.
When I run the command " sudo find_usrps", I got " NO USRP2 Found".
The command "sudo find_usrps" worked fine with my previous SD car
On 05/19/2011 09:49 PM, ikjtel wrote:
>
> We're assuming that the design specs for our app say that:
> "USRP underruns are totally unacceptable"
> (is this a realistic goal to have in the "real world"?)
>
>
While extended underruns are problematic, a short underrun should be
equivalent to
a n
Nick Foster wrote:
> In the "real world" this problem is usually solved by
> dynamically resampling the audio stream at a rate controlled
> by a feedback loop responding to the observed clock mismatch.
I have a USRP1 with a BasicTX daughterboard. When transmitting,
what is the proper method in a
Nick Foster-4 wrote:
>
> I think your transmit side is fine. The .wav source should be
> unthrottled. The receive side is where you're going to run into trouble.
>
Indeed you're right. Upon further research, I realised that nothing
throttles the Tx side but the USRP. So, according to my pre
On Thu, 2011-05-19 at 12:44 -0700, justynnuff wrote:
> Hello, everyone.
>
> I have been coming here for all of my GNURadio and GRC problems, and
> everyone seems beyond knowledgeable. That being said, I have come to the
> end of my recourses and am forced to pose a question. I hope this hasn't
>
Hello, everyone.
I have been coming here for all of my GNURadio and GRC problems, and
everyone seems beyond knowledgeable. That being said, I have come to the
end of my recourses and am forced to pose a question. I hope this hasn't
already been answered, but I've been searching for a while, and
On 19/05/2011 1:21 PM, Robert McGwier wrote:
Vlad
It is apparent to me that you did not understand Josh's explanation.
Possibly he was not forceful enough. ;-).
This is not an error. It is the mathematical consequence of doing QAM
with rotational symmetries. YOU MUST provide your OWN sync
Wouldn't one normally use differential encoding to avoid this problem?
Maybe I'm missing something important.
Ben
On Thu, May 19, 2011 at 12:21 PM, Robert McGwier wrote:
> Vlad
> It is apparent to me that you did not understand Josh's explanation.
> Possibly he was not forceful enough. ;-).
> T
On 19/05/2011 3:13 PM, Bastien Auneau wrote:
why should I use set_time_next_pps() ? Is it needed to init USRP lock to
GPS time ?
Keep in mind that the PPS support pre-dates the existence of an "in
skin" GPSDO, and the
*primary* purpose of the GPSDO is to provide a stable 10MHz reference
cloc
Vlad
It is apparent to me that you did not understand Josh's explanation.
Possibly he was not forceful enough. ;-).
This is not an error. It is the mathematical consequence of doing QAM with
rotational symmetries. YOU MUST provide your OWN synchronization to remove
the phase ambiguity. It is
I don't understand why I should do :
> Typically, you call get_time() to get the UTC time
> in seconds, and then set_time_next_pps() to tell the FPGA to sync its
> sample time to the next PPS pulse
why should I use set_time_next_pps() ? Is it needed to init USRP lock to
GPS time ?
My understandi
On Thu, 2011-05-19 at 17:07 +, Bastien Auneau wrote:
> Hi
>
> I think there is a misunderstanding.
> I do not want to set the time of the USRP.
> I want to use the USRP (with GPSDO) as my time reference.
> This is why I want to query the USRP using the UHD function ptime
> get_time(void) in
>
Hi
I think there is a misunderstanding.
I do not want to set the time of the USRP.
I want to use the USRP (with GPSDO) as my time reference.
This is why I want to query the USRP using the UHD function ptime
get_time(void) in
/host/lib/usrp/gps_ctrl.cpp @ line 133
This function only returns date a
Dear list and Josh,
I'm still getting this error when using the QAM Demod block (qamX_demod is
not connected internally).
Are there any new developments concerning these blocks?
Vlad.
Josh Blum-2 wrote:
>
> Well, when you receive a qam signal, and lock to it, you still have some
> unknown ph
Hi Everyone
First, I would like to introduce myself (ourselves) :
VeriSat, Oslo based company (Norway). We are working on a project, using
USRP (N210) platform, which aim is to build a DVB-RCS Terminal
Shortly RCS is for satellite communication, and is Multi Frequencies
TDMA. (http://verisat.no)
We will be having our monthly Developers' conference call today.
Date: May 19, 2011
Time: 10 PM UTC (6 PM EDT, 3 PM PDT)
SIP: sip:gnura...@digitalbazaar.com
IRC: #gnuradio on freenode
I am traveling and on a semi-holiday right now, and it is unlikely that I
can make the call today. Johnathan Corg
On Wed, May 18, 2011 at 9:43 AM, Martin Braun wrote:
> On Tue, May 17, 2011 at 07:51:00PM -0400, Marcus D. Leech wrote:
> > What it seems to come down to is a lack of initiative. We are all
> willing
> > to wait until someone else does something for us, and then report on
> the
> > pr
21 matches
Mail list logo
