After far to long, I’ve updated the information on the Gnu Radio GPS
board. I’ve finished a preliminary schematic, and I’d appreciate any
comments that anyone might have.
Page:
Schematic
Thanks
Dave
Is there an inherent problem with using the DBS Rx? I think this
discussion started once, but I can’t find it in the archives.
Has any one successfully captured GPS and processed out position
information using GNU Radio and USRP? I remember Krys Kamieniecki was
working on it, but last I remember, his code worked on some data files,
but he couldn’t capture with DBS Rx.
David Bengtson wrote:
After far to long, I’ve updated the information on the Gnu Radio GPS
board. I’ve finished a preliminary schematic, and I’d appreciate any
comments that anyone might have.
Why don’t you use the usrp to generate your 16.384 or 32.768 MHz
refclock.
Most daugterboards (except the tvrx) use this feature (They all use a
4Mhz refclock on io pin 0.
The only difference with your design is that you need another frequency.
The cyclone fpga in the usrp has internal PLLs which can generate all
kinds of frequencies.
(They are not used at the moment)
This way you would have a phase coherent system.
Which is very nice if you start to play with multiple gps
daughterboards.
You could then even play with modifying the refclock frequency to
receive other frequencies.
(like the russian or the european GPS-like systems, which are on
frequencies near the GPS frequency)
Greetings,
Martin
On Thursday 06 April 2006 13:14, Martin D. wrote:
other frequencies. (like the russian or the european GPS-like systems,
which are on frequencies near the GPS frequency)
Farnell sell 32.768 MHz crystals (They’re not what you’d call cheap
though -
AU$17). Hmm they have 16.384 MHz ones for $12.81. Still not cheap…
Also, I think getting 32.768 MHz from 4Mhz with a PLL would be pretty
difficult (if not impossible)
Farnell sell 32.768 MHz crystals (They’re not what you’d call cheap though -
AU$17). Hmm they have 16.384 MHz ones for $12.81. Still not cheap…Also, I think getting 32.768 MHz from 4Mhz with a PLL would be pretty
difficult (if not impossible)
Given that you haven’t looked into the PLLs on the FPGA, it’s rather too
early
to conclude that you couldn’t synthesize 32.768Mhz from the 4Mhz
reference
clock that’s already on the USRP.
Given reasonable dividers for both reference and VFO, I can’t see why
synthesizing
32.768Mhz would be all that difficult. I can understand why you might
want to
use a dedicated oscillator–you don’t have to muck with the FPGA.
But asserting that
it’s “difficult (if not impossible)” is hard to support if you haven’t
looked into it.
On Thursday 06 April 2006 15:11, Marcus L. wrote:
want to
use a dedicated oscillator–you don’t have to muck with the FPGA.
But asserting that
it’s “difficult (if not impossible)” is hard to support if you haven’t
looked into it.
According to the datasheet the PLL can only do m/n where m is between 1
and 32
and n is between 1 and 4.
Therefore I don’t see how it’s possible. I was only guessing before, but
I
just checked the datasheet and it seems impossible.
You could get close with a Stratix II… 4 * 498/62 = 32.129 MHz
Whereas a Cyclone can only do m/n where m is 1 to 32 and n is 1 to 4.
Martin D. wrote:
David Bengtson wrote:
After far to long, I’ve updated the information on the Gnu Radio GPS
board. I’ve finished a preliminary schematic, and I’d appreciate any
comments that anyone might have.
Why don’t you use the usrp to generate your 16.384 or 32.768 MHz refclock.
Most daugterboards (except the tvrx) use this feature (They all use a 4Mhz refclock on io pin 0.
The only difference with your design is that you need another frequency.
The cyclone fpga in the usrp has internal PLLs which can generate all kinds of frequencies.
(They are not used at the moment)
(Sorry, there is a typo, the reference frequencies are 16.368/32.736
MHz)
That might work. 16.368 MHz/4 MHz is 1023/250, or a comparison frequency
of 16 kHz. From a frequency generation point of view, I could probably
get the right frequency from the USRP. I’m concerned about jitter and
noise on that line though. The reference is used directly for the
comparison frequency in the on-chip PLL, to generate a LO that is
1571.328 MHz. A 16 kHz spurious on this would really cause problems.
Because of this, I’d like to use a a clean reference clock for the
reference. I could change the layout to bring a signal over from the
connector to the reference input to check that though. That would make
it possible to try this approach.
Re-Using the reference clock is why I brought the buffered clock signal
over to the connector, so that it will be available to the FPGA.
Dave
Daniel O’Connor wrote:
Well, that blows my “reasonable dividers” theory to flinders, then 
David Bengtson wrote:
(Sorry, there is a typo, the reference frequencies are 16.368/32.736 MHz)
That might work. 16.368 MHz/4 MHz is 1023/250, or a comparison
frequency of 16 kHz. From a frequency generation point of view, I
could probably get the right frequency from the USRP
I’m concerned about jitter and noise on that line though. The
reference is used directly for the comparison frequency in the on-chip
PLL, to generate a LO that is 1571.328 MHz. A 16 kHz
The generation of 1571.328 from this source is almost surely a deal
killer because of the phase noise. That LO must be accurate, stable,
and as phase noise free as possible. We are trying to work with a
signal of only a few dB dynamic range signal and it is weak, right at
the noise floor in most systems. Cascaded LNA’s will bring the signal
up but also lower the IP3 and the dynamic range and greatly increase the
front end susceptibility to overload, interference, and collapse. This
particular oscillator and the attendant mixer cannot be scrimped on. At
least do a serious noise budget analysis to make sure the system will
actually be usable after built.
Dave
–
Robert W. McGwier, Ph.D.
Center for Communications Research
805 Bunn Drive
Princeton, NJ 08540
(609)-924-4600
G’day,
gr-audio-oss segfaults when built using the gr-audio-oss-0.8.tar.gz
tarball.
The reason for this is that the tarball includes audio_oss.cc which
normally
is created by swig. Consequently, the interfaces created in this file
may not
be correct for the every target system. I guess this was overlooked
during
the creation of the tarball.
It would be nice if we can create a new tarball e.g
gr-audio-oss-0.8.1.tar.gz
that excludes this file. I believe that package maintainers would
appreciate
this.
cheerio Berndt
I guess I missed the answer to why you can’t do GPS with the DBS board?
It
has the hooks to apply power to the antenna and it certainly has the
bandwidth and tuning range. If you’re concerned about having a nice
clock
rate to make the despreading easier you can replace the oscillator on
your
USRP with a 32.768MHz oscillator, for example. (I’m in the process of
switching mine to 44 MHz ro make wlan easier.)
-Clark
After far to long, I’ve updated the information on the Gnu Radio GPS
connector to the reference input to check that though. That would make it
[email protected]
Discuss-gnuradio Info Page
Express yourself instantly with MSN Messenger! Download today - it’s
FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Robert W McGwier wrote:
(Sorry, there is a typo, the reference frequencies are
right at the noise floor in most systems. Cascaded LNA’s will bring
the signal up but also lower the IP3 and the dynamic range and
greatly increase the front end susceptibility to overload,
interference, and collapse. This particular oscillator and the
attendant mixer cannot be scrimped on. At least do a serious noise
budget analysis to make sure the system will actually be usable after
built.
I’m aware that this is a very weak signal system, which is why I’m
concerned about the phase noise. Since the Maxim Chip is a SOC, there
really isn’t much to be done with respect to adjusting the noise budget
other than improving the Reference oscillator phase noise. An external
GPS Band Pass filter and LNA are about the only degrees of freedom
available.
On Fri, Apr 07, 2006 at 07:50:53AM +0930, Berndt Josef W. wrote:
this.
cheerio Berndt
Thanks for the problem report and the solution.
Will fix soon.
Eric
Martin D. wrote:
This way you would have a phase coherent system.
Which is very nice if you start to play with multiple gps daughterboards.
GPS is a single frequency spread spectrum system, so you can get it all
from a single RF channel receiver with multiple de-correllators in the
baseband.
I’m sure there would be mandatory changes to do metrology grade gps
reception, but I’m not sure what they are, and I’m not sure I’m ready to
support this.
Dave
Clark P. wrote:
I guess I missed the answer to why you can’t do GPS with the DBS board?
It has the hooks to apply power to the antenna and it certainly has the
bandwidth and tuning range. If you’re concerned about having a nice
clock rate to make the despreading easier you can replace the oscillator
on your USRP with a 32.768MHz oscillator, for example. (I’m in the
process of switching mine to 44 MHz ro make wlan easier.)-Clark
You may well be able to do it with the DBS board. However, GPS is a
pretty weak signal, and I suspect that the noise figure is too high.
Also, there is a good sized population of college students doing GPS
work, so I thought that building a GPS specific board would be useful
for those folks.
You may well be able to do it with the DBS board. However, GPS is a
pretty weak signal, and I suspect that the noise figure is too high.
The DBS board has about a 3-5 dB noise figure as I recall, but that
doesn’t really matter. Nearly all GPS antennas have their own LNAs
inside, so noise figure after all that gain (usually 20 to 40 dB)
doesn’t make any difference.
Matt
David Bengtson wrote:
Then you should be able to get GPS from a DBS board using an external
LNA/Antenna combination. The software is left as an exercise for the
student :-).
Remind me, and I’ll show a spectral spike of the GPS L1 signal. I have
a DBS_RX, with an external LNA
right at the feed of my dish. The L1 signal at 1575.420 is quite
obvious… My application is Radio Astronomy
at 1420.4058Mhz, but my feed is fairly broad. I use GPS L1 as a
calibration signal sometimes…
Matt E. wrote:
You may well be able to do it with the DBS board. However, GPS is a
pretty weak signal, and I suspect that the noise figure is too high.The DBS board has about a 3-5 dB noise figure as I recall, but that
doesn’t really matter. Nearly all GPS antennas have their own LNAs
inside, so noise figure after all that gain (usually 20 to 40 dB)
doesn’t make any difference.Matt
Then you should be able to get GPS from a DBS board using an external
LNA/Antenna combination. The software is left as an exercise for the
student :-).
On Fri, Apr 07, 2006 at 07:50:53AM +0930, Berndt Josef W. wrote:
this.
cheerio Berndt
Hi Berndt,
After taking a look at this, I think the problem is in the
gnuradio-core build process. All the tarballs that I checked
designate the swig generated output files as BUILT_SOURCES, and all
contain the output of running swig on the machine I built the tarballs
on.
That part is right.
The part that’s wrong, is that something in the gnuradio-core build
process is triggering a dependency that’s having gnuradio-core’s swig
output be regenerated. This could lead to a situation where
gnuradio-core’s stuff is built with one version of swig, while all the
others use a different version. I suspect that some of the machine
generated code (particularly the .i and .h files) in general and/or
filter isn’t labeled BUILT_SOURCES, and thus isn’t in the tarball.
Building that stuff would then force swig to be run, causing the
potential swig version inconsistency.
I’ll continue to investigate, but not right now.
If someone else wants to help sort this out, please dive in.
BTW, this problem isn’t new. It’s been in all the tarballs generated
over the last couple of years. I think we’re seeing it now because I
used swig 1.3.29 on the build machine. The swig generated code changed
for the better between 1.3.27 and 1.3.28.
Thanks again for noticing & reporting the problem,
Eric
On Fri, Apr 07, 2006 at 11:52:47AM +0930, Berndt Josef W. wrote:
It would be nice if we can create a new tarball e.g
contain the output of running swig on the machine I built the tarballs
filter isn’t labeled BUILT_SOURCES, and thus isn’t in the tarball.
Building that stuff would then force swig to be run, causing the
potential swig version inconsistency.Not quite sure what you mean. Currently I have to regenerate this file with
swig in order to avoid the segfault.The log below shows the part that does go wrong. Note that swig wasn’t
executed in order to regenerate audio_oss.cc
Note that the compile from the the tarball does succeed. It does
generate some warnings about “defined but unused”, but no compile time
errors.
I believe the reason you’re seeing the segfault (based on
circumstantial evidence – I don’t even know where it’s blowing up)
is that the gnuradio-core tarball does run swig (which it
shouldn’t), while the other tarballs don’t run swig. This would
result in gnuradio-core using “your version of swig” and all the other
tarballs using “my version of swig”. As long as they all use the
same version of swig, everything should be OK. Right now they’re not.
Let me be clear: when compiling the tarballs, swig should not run
[at least that was the original intention 
] The fact that it is run
when building the gnuradio-core tarball is incorrect, and is what I
believe is causing the problem.
So, I think there are two solutions: ensure that either all of them run
swig,
or that none of them run swig.
This would make sense as the version of swig used here is 1.3.27.
That’s good to know.
I was going to commit an update of the latest gnuradio release into pkgsrc and
will have to work around it if no solution comes from here.
I appreciate your efforts. Maybe you should hold off a few days and
see if a solution materializes.
BTW: I’ve since create a package for gr-audio-portaudio which I hope to commit
soon.
Good.
How does gr-audio-portaudio sound under NetBSD?
Does it work as well as gr-audio-oss?
FWIW, my impression of gr-audio-portaudio under GNU/Linux is that it’s
not ready for prime time. I’d still choose gr-audio-alsa over
portaudio. It still needs some work. Not sure if it’s in our code,
the portaudio code, or both.
Eric