FE-.5680A trimming resolution
On 02/02/12 01:17, Azelio Boriani wrote:
In my opinion the work done locking the VCTCXO of the Oncore is different
from the TBolt OCXO management: the TBolt steers the OCXO based on the
received signal instead they locked the Oncore oscillator to a Cs
reference. Yes, if all the world is the same then there is no difference:
the Cs locks the VCTCXO frequency where it should be as if steered from
satellites but how can you drive an OCXO from an Oncore even with hardware
modifications?. There is an oscillator offset in the @@Ha status message...
maybe by using it?
Well, what you say is true to some degree, but there is a few things
which we need to talk separately about not to confuse things.
- Use of a more stable clock.
The cesium locked Oncore VP and steered OCXO in the Thunderbolt shares
the same basic aspect of a lower noise level at taus around one and
longer, compared to most off the shelf GPS units. This gives an
increased receiver sensitivity which I was pointing at.
- Steering vs. stable error
A typical off the shelf clock has a fairly OK but still not very great
TCXO. It's frequency will be off and it will wander around. As a
consequence the GPS receiver's software will make regular adjustments of
the receivers time to compensate. With a more stable clock which is
geared towards a "good" rate, the software routine will just experience
a very long stable time and do not see very high rate of adjustments.
These adjustments can be found in both books and papers. They are
obvious in raw-carrier phase measurements among other things.
For GPS receivers which locks up their reference clock, a different
steering strategy may be employed once the clock have been steered.
There is by the way far more receivers able to steered their (external)
clocks if you look around, you will also find the commands to trim their
loop algorithm, just as the Thunderbolt allows you to.
So, to sum up:
You can get the gain of more stable clock, without locking it, but you
can use the locking to render better data out of it.
Using rubidiums to steer carrier phase receivers usually suffice to
provide good data.
Cheers,
Magnus
On 2/1/12 9:27 AM, Chris Albertson wrote:
On Wed, Feb 1, 2012 at 8:19 AM, Attila Kinaliattila@kinali.ch wrote:
On Wed, 01 Feb 2012 09:07:23 -0500
John Ackermann N8URjra@febo.com wrote:
There've been numerous threads on the Gnuradio mailing list about code
to receive GPS using the Ettus Research USRP hardware. I don't know
whether anyone has actually made it work, but it appears that it's been
the subject of quite a few academic projects.
That is the problem with an academic projects typically something like
this would be part of a Master's theses or a senior project. and then
the student graduates and was no more interrest in supporting it.
I thought it might be interresting but then found out you need to buy
$2,000+ worth of hardware for even start experimenting. Open Source
SDR needs to run on a common affordable platform or it will never gain
the critical mass of users that it take to make the project live
longer then a few months.
I think the way to go is to find a commercial GPS chip that has a low
level interface and then build the uP controller using a common
development system. Both the chip and the uP board need to be,
common, well documented and cheap. Then with this you build an open
source thunderbolt type device. An SDR that samples the microwave
RF is going to be un-affordable, even mixing and down converting
microwaves is not so simple as doing the same on HF ham bands. But
there might be low level GPS chip available for cheap.
Actually, most of the JPL GPS receivers do direct sampling from RF with
a single bit converter. You need about 100dB of gain from the antenna,
with some filtering (to get L1 by itself), and then you run it into a
limiter, and just sample the output at around 40 MHz, run it into an
FPGA, and do your stuff.
No superhet, no mixers, no nothing. It's only 1.5 GHz.. these days,
that's not particularly exotic.
http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/41781/1/11-0046.pdf
gives some hints on the hardware side.
From my experience the only way projects like this get started is one
guy works until he has a demo of a proof of concept and can say "Hey
look this sort of works and can do simple things" and then others join
Yep
On 2/1/12 10:12 AM, Attila Kinali wrote:
On Wed, 1 Feb 2012 09:27:30 -0800
Chris Albertsonalbertson.chris@gmail.com wrote:
I thought it might be interresting but then found out you need to buy
$2,000+ worth of hardware for even start experimenting. Open Source
SDR needs to run on a common affordable platform or it will never gain
the critical mass of users that it take to make the project live
longer then a few months.
That's because the URSP is a general purpose system. It is designed
to do many things. That makes it expensive. And being expensive,
it has a low production volume, which makes it even more expensive.
I think, a specialized GPS SDR can be build for less than 500 USD
in low (a dozen at max) volumes.
I guestimate, that the RF/ADC part would cost somewhere between
100 to 200 USD in parts. The big uncertainty here is the FPGA.
I have no clue how much logic space for a GPS SDR would be needed
at minimum and how much would be desirable. Hence i have no guess
what the FPGA would cost (could be anything from a cheap 20USD
FPGA to a 300 USD one).
how many channels do you want to track at once?
I can tell you that you can track at least 12 channels simultaneously
with single bit ADC sampling at around 40 MHz in a pair of Virtex II
3000 parts. You might be able to do better (I don't know how full the
two FPGAs are). (that's the published spec for the radio we're flying
on the SCAN Testbed on ISS) It's actually a L1,L2,L5 receiver, but, of
course, the tracking loop is the same for all frequencies, whether you
track 12 S/Vs in L1 or 4 in all three channels.. it's all the same.
You'll have to do the nav solution in some sort of other processor..
that's just running the tracking loops and generating raw observables.
On 2/1/12 12:22 PM, Attila Kinali wrote:
On Wed, 1 Feb 2012 11:49:51 -0800
Peter Montapmonta@gmail.com wrote:
One possible inexpensive design:
- RF input passively split three ways, with LC filters for the three
channels: L5/E5, L2, and L1/E1/Glonass - For each channel, a downconverter (Maxim MAX2121) feeding a ~65 Ms/s
ADC (e.g. MAX19505) - A low-cost FPGA (e.g. Spartan-6) that quantizes the channels to 2
bits, does AGC, assembles Ethernet packets - Ethernet PHY, power (PoE?), etc.
You don't need the ADC: you just need a limiter/comparator. But you do
need a bunch of RF gain. I think you can get suitable ceramic filters
off the shelf for the GPS frequencies that are inexpensive.
You don't need insane sampling rates. Think in terms of subharmonic
sampling.
Heh..That's pretty much the design i thought of, though using a higher
sampling frequency (100 to 200Msps) which would allow to coherently
decode the E5a and E5b signals together. There is an ADC from National
that can do 200Msps for 20 bucks, with FPGA friendly parallel output
(ADC08200).
Is there a publically-available antenna design that's easy to
fabricate, has a stable phase center, covers 1100--1600 MHz, and has a
good pattern over this band with low cross-polarization? Even a large
choke-ring design would be okay if it's fully specified.
I think there are some crossed dipole designs around. What about quad
helix?
On Wed, 1 Feb 2012 09:27:30 -0800
Chris Albertson albertson.chris@gmail.com wrote:
I thought it might be interresting but then found out you need to buy
$2,000+ worth of hardware for even start experimenting. Open Source
SDR needs to run on a common affordable platform or it will never gain
the critical mass of users that it take to make the project live
longer then a few months.
That's because the URSP is a general purpose system. It is designed
to do many things. That makes it expensive. And being expensive,
it has a low production volume, which makes it even more expensive.
I think, a specialized GPS SDR can be build for less than 500 USD
in low (a dozen at max) volumes.
http://www.sparkfun.com/products/10981
--
Björn
On Thu, 02 Feb 2012 00:50:39 +0100
Magnus Danielson magnus@rubidium.dyndns.org wrote:
I have not seen any such papers yet. Do you have any pointers or hints
what to search for?
Let me see... yes, here it is:
Thanks!
Printed and ready to be read :-)
Attila Kinali
--
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
On Thu, 02 Feb 2012 01:22:07 +0100
Magnus Danielson magnus@rubidium.dyndns.org wrote:
On 01/02/12 19:12, Attila Kinali wrote:
I guestimate, that the RF/ADC part would cost somewhere between
100 to 200 USD in parts. The big uncertainty here is the FPGA.
I have no clue how much logic space for a GPS SDR would be needed
at minimum and how much would be desirable. Hence i have no guess
what the FPGA would cost (could be anything from a cheap 20USD
FPGA to a 300 USD one).
That's why you start of with using an Ettus box as a boiler plate. Once
you have working code, you can re-target it for a smaller device and
situation. You can do dry synthesis towards the new platform without
having it as a physical device. The basic design can still be running on
that Ettus platform. Come to think of it, I did get a few university
point on a 2-week coarse teaching exactly this point, spin on big-ass
FPGA machines and then go to target. :) That's... 18 years ago. Time flies.
Well.. i rather thought about doing a scilab model of the gps signals.
Write the VHDL code, use ghdl to see whether it works correctly and
then use one of those web eddition synthesizers to see how much space
it uses. This way i already have working code when i get the hardware,
don't have to buy any Ettus box and can still choose the right FPGA ;-)
Front-end chips is still there. That's how they build these:
http://ccar.colorado.edu/gnss/
http://www.sparkfun.com/products/8238
http://www.sparkfun.com/products/10981
That will suffice to get you started in the SDR field.
Hmm.. the successor of the chip used there (the SE4150L) seems
to be available in small quantities... That wasn't the case
when i last looked. But it's limited to L1 C/A only and cannot even
be modified for the P(Y) or Galileos E1 signal.
The MAX2769 (mentioned by Tristan Steele) looks better in that
regard. It can be configured to 8MHz BW, which is enough for E1
reception. Probably a degraded L1 P(Y) tracking could be implemented
as well...
Attila Kinali
--
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
On Thu, 2 Feb 2012 11:41:17 +1100
Tristan Steele tristan.steele@gmail.com wrote:
I have been looking at SDR GPS reception for a while, and have a number of
ideas as to how to go about this process. My first point of call is the
layout of a board using a MAX2769B (1) receiver chip attached directly to a
Spartan 3E- 500 FPGA and then to a USB interface. I have decided to do
this using an add-on board to the Papillio FPGA boards (2) that have been
linked here before, incorporating the receiver chip, level shifters, power
supplies, as well as a somewhat buffered SMA input for monitoring an
external signal. The original board design requires an external reference
oscillator for the MAX2769B, I am intending to operate it with a 10MHz
signal to begin with.
Heh.. I thought about using teh DE0-nano board from terasic for something
similar.. but never got around to buy one..
Anyway, I will be happy to share progress as it occurs if anyone is
interested?
We are, of course, interested :-)
Attila Kinali
--
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
OK, got it: no need to lock the receiver clock to birds to get stable data
(e.g. Oncore+Cs) but the clock can be locked to birds to get even better
data and obtain "for free" a reference clock (TBolt). The use of a stable
clock (not locked to birds) feeding the receiver can show the various
errors that affect the downlink having removed the clock instabilities.
On Thu, Feb 2, 2012 at 9:30 AM, Attila Kinali attila@kinali.ch wrote:
On Thu, 02 Feb 2012 00:50:39 +0100
Magnus Danielson magnus@rubidium.dyndns.org wrote:
I have not seen any such papers yet. Do you have any pointers or hints
what to search for?
Let me see... yes, here it is:
Thanks!
Printed and ready to be read :-)
Attila Kinali
--
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
On Wed, 01 Feb 2012 21:53:16 -0800
Jim Lux jimlux@earthlink.net wrote:
You don't need the ADC: you just need a limiter/comparator.
Yes, but this degrades sensitivity quite a lot.
You don't need insane sampling rates. Think in terms of subharmonic
sampling.
This requires that you have an ADC that has the anlog bandwidth of
the signal. And ADCs with a analog BW in the GHz range are damn expensive
and hard to get.
Also a problem is to get the sampling frequency right if you want to
sample more than one band. Downmixing solves both of these problems
at the cost of higher complexity and a bit more noise.
Is there a publically-available antenna design that's easy to
fabricate, has a stable phase center, covers 1100--1600 MHz, and has a
good pattern over this band with low cross-polarization? Even a large
choke-ring design would be okay if it's fully specified.
I think there are some crossed dipole designs around. What about quad
helix?
Crossed dipole are narrow band and not easy to build as dual band designs
at least at those frequencies. Quad helix needs quite a precision to get
the right frequency and dual band designs (stacked helixes) get even more
difficult.
Attila Kinali
--
The trouble with you, Shev, is you don't say anything until you've saved
up a whole truckload of damned heavy brick arguments and then you dump
them all out and never look at the bleeding body mangled beneath the heap
-- Tirin, The Dispossessed, U. Le Guin