Gregory W Heckler wrote:
To all concerned parties:
I think I've discovered the problem. My "tune" routine chose the R and
N dividers to minimize the difference between the command and desired
LO frequencies. For L1 this ended up being 64 and 25197. The refclk
was set at 4 MHz, producing an R
Gregory W Heckler wrote:
To all concerned parties:
I think I've discovered the problem. My "tune" routine chose the R and
N dividers to minimize the difference between the command and desired
LO frequencies. For L1 this ended up being 64 and 25197. The refclk
was set at 4 MHz, producing an R
To all concerned parties:
I think I've discovered the problem. My "tune" routine chose the R and N
dividers to minimize the difference between the command and desired LO
frequencies. For L1 this ended up being 64 and 25197. The refclk was set
at 4 MHz, producing an R divider frequency of 62500
I've noticed that the DLL of my software receiver settles to +15 Hz,
and the true IF is +24 kHz from the predicted IF. This would indicate
that the 64 MHz board clock is ~1 kHz from its spec value. This, in
itself is not a problem, but I was wondering if this was within
tolerances of the onbo
Robert McGwier wrote:
There is a multiplier circuit/ PLL in the DBS-RX. Whatever phase
noise is coming from the oscillator is being multiplied considerably
by this upconversion to be used at LO in the DBS-RX. You cannot get
low phase noise oscillators and high performance mixers in that sma
There is a multiplier circuit/ PLL in the DBS-RX. Whatever phase noise
is coming from the oscillator is being multiplied considerably by this
upconversion to be used at LO in the DBS-RX. You cannot get low phase
noise oscillators and high performance mixers in that small a package.
Together
Gregory W Heckler wrote:
I measured the phase noise of the 64 MHz board clock. Looking at the
result, I doubt the board clock is producing the phase noise I am
seeing in my receiver.
Peter Monta wrote:
Martin Dvh wrote:
Maybe you could inject a stable frequency near the wanted RX frequency.
Say a few Mhz away from the 1.57542e9 you want to receive.
Then you could use this in the output to remove the jitter and LO drift.
for example:
inject 16 Mhz (=25 harmonic of
You have not read or internalized the specifications for the oscillator
on the USRP which is intimately involved in this system. It is 50 ppm
accuracy which is bad enough, but look at the can. It is begging to
have thermal variances. Start up the usrp and your process and
investigate Newton
Martin Dvh wrote:
Maybe you could inject a stable frequency near the wanted RX frequency.
Say a few Mhz away from the 1.57542e9 you want to receive.
Then you could use this in the output to remove the jitter and LO drift.
for example:
inject 16 Mhz (=25 harmonic of 64MHz) at the input
Gregory W Heckler wrote:
The real problem lies in the fact that the carrier tracking loop (a
3rd order PLL) of my software receiver cannot achieve phase lock. The
phase jitter looks high, and the LO frequency drifts so much it
dominates over the Doppler derived from satellite motion.
Yes,
On Tue, Mar 06, 2007 at 04:57:55PM -0500, Gregory W Heckler wrote:
> Brian:
>
> From what I see it does not continuously stream data, which is a
> requirement for my needs. Additionally I am looking at recording GPS L2C
> and the new Galileo frequencies, so a tuneable front end is a must.
>
I'
Gregory W Heckler wrote:
> I've hit a wall with using the DBSRX to record GPS L1 C/A code data. The
> signal path consists of the following:
>
> Spirent GPS Simulator -> 2 MHz wide SAW @ L1 -> +40 dB Miteq Amp ->
> DBSRX -> USRP
>
> Notes/Settings:
>
> 1) Spirent Simulator:
> Static scenario, 39
2007/3/6, Gregory W Heckler <[EMAIL PROTECTED]>:
> If anyone would like any GPS IF data I would be happy to email it to
your personal email address (indicate how many seconds of data you would
like). Thanks!
I am very interested to here more about your experience with GNU Radio
and GPS! I am cr
Brian:
From what I see it does not continuously stream data, which is a
requirement for my needs. Additionally I am looking at recording GPS L2C
and the new Galileo frequencies, so a tuneable front end is a must.
Greg
Brian Padalino wrote:
On 3/6/07, Gregory W Heckler <[EMAIL PROTECTED]> wr
On 3/6/07, Gregory W Heckler <[EMAIL PROTECTED]> wrote:
I've noticed that the DLL of my software receiver settles to +15 Hz, and
the true IF is +24 kHz from the predicted IF. This would indicate that
the 64 MHz board clock is ~1 kHz from its spec value. This, in itself is
not a problem, but I was
I've hit a wall with using the DBSRX to record GPS L1 C/A code data. The
signal path consists of the following:
Spirent GPS Simulator -> 2 MHz wide SAW @ L1 -> +40 dB Miteq Amp ->
DBSRX -> USRP
Notes/Settings:
1) Spirent Simulator:
Static scenario, 39 deg North, -84.866 deg West, 0.0 meter h
Based on his Ham callsign, his name is Michael Gram. (However, based on
the whois for kd7lmo.net, his name is Michael Gray.)
-Roshan
Chris Stankevitz wrote:
Gregory W Heckler wrote:
Has anyone successfully collected any GPS L1 data with the DBSRX
Yes, I think this guy(*) used the DBSRX. He
Gregory W Heckler wrote:
Has anyone successfully collected any GPS L1 data with the DBSRX
Yes, I think this guy(*) used the DBSRX. He includes the collection
scripts on his site as well:
http://www.kd7lmo.net/ground_gnuradio_ota.html
(*) I hate to call him "this guy" but he keeps his true
Has anyone successfully collected any GPS L1 data with the DBSRX
daughterboard. If so what decimation, gain, and filter values did you
use to do so? Thanks!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listi
20 matches
Mail list logo
