Frequency Offsets in RFX 2400

Hi,
I am trying to run a few experiments to transmit a data stream from a
transmitter to receiver using a RFX 2400. However, I am observing that
the
frequency offset is extremely high at 40-80kHz. In addition, it also
changes
significantly, nearly 2-8kHz, every time I restart the usrps. I have
used
various ways of estimating the frequency offset and all of them converge
on
the above observations.

So I have a couple of questions

  1. Is this high a frequency offset in the specs?
  2. Is this variation in the frequency offset in the specs of these
    radio?
    (I have been working on other costume made hardware and the frequency
    offset has been almost constant for the past couple of months)
  3. Is there are way to prevent the frequency offset variation after
    every
    reboot?

Thanks in advance for any replies
Shyam


View this message in context:
http://www.nabble.com/Frequency-Offsets-in-RFX-2400-tp14718911p14718911.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Wed, Jan 09, 2008 at 11:02:47AM -0800, Shyamnath wrote:

  1. Is this high a frequency offset in the specs?
  2. Is this variation in the frequency offset in the specs of these radio?
    (I have been working on other costume made hardware and the frequency
    offset has been almost constant for the past couple of months)
  3. Is there are way to prevent the frequency offset variation after every
    reboot?

Thanks in advance for any replies
Shyam

I’m not sure of the tolerance of the oscillators Matt’s currently
using on the 2400’s, but 40k/2.4G is about 17 ppm. I wouldn’t call
that “extremely high”. In general any receiver has to be able to
track out any frequency offset and symbol timing variation. Expensive
test equipment has better specs (and costs more) because they use
things like ovenized crystal oscillators.

All xtal oscillators move around with temperature. The question is
how much, and how much money is being spent on compensation and
environmental control.

Eric

Hi Eric,

Thanks a ton for the reply. My main concern is not that the frequency
offset is high enough but that it changes pretty often (every time I run
a new run) which makes it difficult for repeatability.

So is there a way in software where I can make sure that the frequency
offset is constant either by finely controlling the center frequency at
the tranmitter every time I run or is there some other way around this
problem?

Thanks
Shyam

On 1/9/08, shyamnath gollakota [email protected] wrote:

Thanks a ton for the reply. My main concern is not that the frequency
offset is high enough but that it changes pretty often (every time I run
a new run) which makes it difficult for repeatability.

The frequency offset in the USRP is largely due to thermal transients
associated with either power cycling the unit, or periods of on-off
activity.

So is there a way in software where I can make sure that the frequency
offset is constant either by finely controlling the center frequency at
the tranmitter every time I run or is there some other way around this
problem?

Frequency tracking/synchronization is often the most complex (read,
fun :slight_smile: part of receiver design. Depending on your modulation type,
there are a variety of phase-locked loop architectures that can fine
tune the center frequency of your signal. Simplified, you calculate
an error value based on some property of your received signal, then
use that to nudge the center frequency up or down until the error
value goes to zero.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

On Thu, Jan 10, 2008 at 08:46:09AM -0600, LRK wrote:

While the ‘right’ fix would be to supply a stable frequency source to
the USRP, it would be difficult.

Not impossibly difficult… it would, however, have been nice to
have a VCXO option for the USRP-1 that would have allowed external phase
locking circuitry to phase lock the 64 MHz to something without
significantly impacting phase noise (AKA clock jitter) of the 64 MHz
when not phased locked (or for that matter, when phase locked). It is
quite a bit easier to use some fairly straightforward external PLL
hardware to lock a 64 MHz clock by tweaking an EFC DC voltage input than
it is to actually generate a clean, low phase noise external 64 MHz
clock and import it correctly to the USRP so clock jitter (and thus S/N
of the ASC sampling) is as good as with the current oscillator.

Next best would be an ‘offset’ or ‘calibration’ value in the environment
which would be included in the frequency calculations. This should be an
indication of the error at 64 MHz and scaled. Thus ‘+914.125 Hz’ at 64 MHz
would cause a 914.125 x 35.15625 = +32137 Hz correction at 2250 MHz
(which is what I need at this moment :).

This change is acutely needed… and everything that computes a
frequency based on the 64 MHz timebase should use it…

And best in the future would be a source on the USRP which could just
lock itself to a 1PPS signal from a GPS at 0-5 volt levels.

I’m not sure I want Matt and Eric to do an entire GPSDO as part
of a new USRP… much better to just build a USRP clock generator that
takes the universal standard reference frequency of 10 MHz as an input
like most all of the world’s current test equipment and many radios and
most satellite and telecom gear… 10 MHz GPSDOs are a standard item -
readily available and highly accurate (and even pretty cheap on Ebay)
and no other reference frequency is as widely used. And one can find
cheap surplus ex-telcom rubidiums that will supply 10 MHz within parts
in 10^10th or so if one doesn’t want to (or can’t) use GPS as a
reference
but still needs accurate frequency.

A hack I have thought about adding to the USRP FPGA code (but
not implemented yet) would allow collection of the count in a
continuously rolling 64 MHz counter driven by the current 64 MHz clock
on a rising or falling edge of a 1 PPS signal brought in on some spare
pin and stuff this value in a register that could be read via the I2C
mechanism. I think this takes few enough FPGA resources to be doable
with the current USRP code, but again I haven’t tried it yet. This
would allow software in gnuradio to compute frequency error every second
(or whatever rate the ticks came in at) by determining whether the time
stamp on the 1 PPS edge was early or late relative to the count of 64
MHz clocks.

A while back I proposed a more general and less inelegant
approach involving passing back time stamp messages in the data stream
in the new message passing format based on such external pin events as
a 1 PPS and I hope this eventually gets implemented, but simply
providing a register that contains the clock count sampled on the last
rising (or falling) edge of an input signal is pretty simple and should
allow real time compensation for frequency error and drift of the TXCO
clock at a rate sufficient to solve the frequency error problem for many
applications - if not all of them - provided one has a suitable source
of an accurate reference clock at some useful frequency (typically 1
PPS, but other values like 1 or 10 KHz are possible).


Dave Emery N1PRE/AE, [email protected] DIE Consulting, Weston,
Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
‘For Rent’ sign still vainly flapping outside on the weed encrusted pole

  • in
    celebration of what could have been, but wasn’t and is not to be now
    either."

On Wed, Jan 09, 2008 at 11:15:37AM -0800, Eric B. wrote:

using on the 2400’s, but 40k/2.4G is about 17 ppm. I wouldn’t call
that “extremely high”. In general any receiver has to be able to
track out any frequency offset and symbol timing variation. Expensive
test equipment has better specs (and costs more) because they use
things like ovenized crystal oscillators.

I have found similar problems trying to use usrp_fft.py at 2.2 GHz. Mine
is off about -33 kHz with a drift of about 3 kHz from idle to stable
when
the program is started. I’m using the DBSRX fed from a pre-amp.

While the ‘right’ fix would be to supply a stable frequency source to
the USRP, it would be difficult.

Next best would be an ‘offset’ or ‘calibration’ value in the environment
which would be included in the frequency calculations. This should be an
indication of the error at 64 MHz and scaled. Thus ‘+914.125 Hz’ at 64
MHz
would cause a 914.125 x 35.15625 = +32137 Hz correction at 2250 MHz
(which is what I need at this moment :).

And best in the future would be a source on the USRP which could just
lock itself to a 1PPS signal from a GPS at 0-5 volt levels.


LRK
[email protected]

On Fri, Jan 11, 2008 at 06:46:46AM -0800, Johnathan C. wrote:

David I. Emery wrote:

A hack I have thought about adding to the USRP FPGA code (but not
implemented yet) would allow collection of the count in a
continuously rolling 64 MHz counter driven by the current 64 MHz
clock on a rising or falling edge of a 1 PPS signal brought in on
some spare pin and stuff this value in a register that could be read…

I think would be very easy to do in the Verilog. Is there a simple
(read cheap) PPS generator I could purchase?

Yes, several… Many GPS receivers (notably the Motorola Oncore
series and it’s successor the M12/M12+) have a highly accurate 1 PPS
output when they are locked to the satellite constellation. Typical
accuracy of the 1 PPS when seeing good satellite coverage in timing mode
is around 20 ns from true UTC.

Motorola Oncore family receivers are often available on Ebay
used or NOS for around $20-50. The M12+ is available new for
reasonable prices as well.

Many other GPS devices output a 1 PPS pulse of varying accuracy
and stability, most are accurate to under 1 us though many of those will
have several hundred ns jitter and wander on the 1 PPS.

And for those who want something better, there are lots of
surplus time and frequency reference boxes that show up on eBay surplus
from CDMA cell sites. These contain a 10 MHz OCXO or rubidium standard
disciplined by GPS to typical accuracies in the part in 10^10 to 10^11
or better area and usually provide precision 10 MHz with low phase
noise, high short term stability and very good long term accuracy when
GPS locked. They also provide a 1 PPS locked to GPS derived from the
10 MHz and usually ASCII RS-232/422 output of the time of day once a
second.

Small units of this sort - notably made by Datum, Trimble
(Thunderbolt and successors) and Symmetricom are quite often available
on Ebay for prices in the $100-$400 area. The Z3801A/Z3816A made by HP
(now Symmetricom) is very popular with hams and available on eBay and
sometimes at Hamfests - these contain one of HP’s best OCXOs… (the
10811 family).

Is the standard PPS output compatible with the GPIO pins on the USRP
(voltage, drive level, rise time, etc.)?

Most GPS 1 PPS is 5 volt TTL level. As such I think they will
work with the USRP FPGA, but I defer to experts on the exact rules of
signals for that (too lazy to look it up)… usually the 1 PPS is
fairly heavy drive current and can drive significant lengths of 50/75
ohm cable (though that varies - the Oncore receivers don’t have as mogey
drivers I don’t believe).

Any interested in this topic should look up the time-nuts mailing
list at febo.com


Dave Emery N1PRE/AE, [email protected] DIE Consulting, Weston,
Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
‘For Rent’ sign still vainly flapping outside on the weed encrusted pole

  • in
    celebration of what could have been, but wasn’t and is not to be now
    either."

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs