Failed to tune to low frequency with usrp.tune

GNU Radio
1

Hi,

I am playing with a program which transmits music with narrow band

freq
modulation between two FLEX2400 broads.

The program works like a charm when I tune to 2.4Ghz with the

sentence:

" self.tx.tune(self.subdev._which, self.subdev, freq) ".

But it failed to work if the freq is tune to lower than 2.3Ghz. Is

that
because the freq license or something like that?

Best

DiX

–
View this message in context:
http://www.nabble.com/Failed-to-tune-to-low-frequency-with-usrp.tune-tf4313695.html#a12281686
Sent from the GnuRadio mailing list archive at Nabble.com.

2

DiX wrote:

because the freq license or something like that?

That is because the onboard VCO typically won’t tune below 2.3 GHz. You
can change line 456 in gr-usrp/src/db_flexrf.py to allow you to try
going lower.

Matt

3

That is because the onboard VCO typically won’t tune below 2.3 GHz. You
can change line 456 in gr-usrp/src/db_flexrf.py to allow you to try
going lower.

Matt

Is there someplace where the (nominal) tunable ranges of each of the
daughterboards is available?

4

Bahn William L Civ USAFA/DFCS wrote:

In that same file

5

On Wed, Aug 22, 2007 at 01:46:06PM -0700, Matt E. wrote:

In that same file

Given an instance of the daughterboard in question, you can ask it:

subdev.freq_range()

or

subdev.gain_range()

for the valid gain ranges

From the abstract daughterboard base class db_base.py:

def freq_range(self):
    """
    Return range of frequencies in Hz that can be tuned by this

d’board.

    @returns (min_freq, max_freq, step_size)
    @rtype tuple
    """
    raise NotImplementedError

def gain_range(self):
    """
    Return range of gain that can be set by this d'board.

    @returns (min_gain, max_gain, step_size)
    Where gains are expressed in decibels (your mileage may vary)
    """
    raise NotImplementedError

Eric

6

I’m working on a GNU Radio application that demodulates a synchronous
bitstream from a spacecraft telemetry downlink. Once I have the
bitstream, I need to get it back onto a wire in order to feed it into
our existing equipment.

Is it possible to do this by using the ppio_ppdev? I would get the
bitstream unpacked into the LSBits of a stream of bytes, and write these
using ppio_ppdev.write_data().

The bitstream is running at 76800 bits/sec, so my questions are:

  1. Is ppio_ppdev fast enough to keep up with this bitrate?

  2. Can this be done from Python, or does it need to be embedded in a C++
    block?

  3. Are there other, better or easier ways to do this, such as using one
    of the debug pins on a USRP daughterboard?

@(^.^)@ Ed

7

Eric B. wrote:

  1. Is ppio_ppdev fast enough to keep up with this bitrate?

I doubt it. It just bit bangs the serial port. Thus you’ve got no control
of the data rate, etc.

I assume you meant the parallel port. I suspected as much. I was just
hoping that it would keep up with my low data rate, which is being
throttled elsewhere.

  1. Are there other, better or easier ways to do this, such as using one
    of the debug pins on a USRP daughterboard?

If you’re willing to hack verilog, you can get it out the debug pins.

I’m willing, but I don’t have the time/funding to learn verilog. I’m
working under a very small, focused research grant.

If the output needs to be synchronous serial output, the easiest way to
get it out may be to use a serial card with a USART on it. E.g.,
something that’s capable of synchronous serial transmission. Look for
a card that’ll do HDLC, then see if there’s a “raw” or “unframed”
mode. Generally the hardware that’ll can do HDLC can also do
synchronous.

Yes, I’m very familiar with HDLC synchronous serial cards, having
written several Linux network device drivers for them. Again, this is
doable, but probably not under the tight time/money constraints I have.

Another thought occured to me. Since the LFTX daughterboard goes down to
DC, shouldn’t it be posible to use it to output the bitstream? It’s a
bit of a kludge, but it should be easy. Comments?

What’s the protocol for talking to the equipment? Is there any
handshaking, etc, or do you just need a raw synchronous stream?

For my immediate purpose, I just need a raw clock and data synchronous
bitstream with no handshaking. In reality, the bitstream is carying
NRZI-encoded HDLC/Frame-relay, with IP packet payloads that conform to
the Multi-Protocol-over-Frame-Relay (MPoFR) standard. This gets fed
into a COTS router which is performing all sorts of statistics gathering
on the HDLC. I know that I could do all this link layer stuff in
software, but I’d essentially be “re-inventing the wheel” when I can’t
afford to.

Let me give you a little background on what I’m trying to do. I’m
working with the US Naval Academy’s MidStar-1 spacecraft. Due to an
unfortunate design choice, the average of the digital waveform that gets
FSK modulated onto the carrier has a non-zero, varying DC offset,
dependent on the data content. As a result, once the waveform is
demodulated on the ground, a standard 0 volt bitslicer will not work.
We were forced to build hardware for an adaptive-level bitslicer, based
on a 1970s-era design which uses a pair of sample-and-hold circuits to
track the min and max levels in the signal, and slices at 1/2 of the
difference (effectively the mean instead of the average). But this
circuit performs poorly, especially at points where the DC offset
changes abruptly by a large amount. Unfortunately, this is a common
occurance in NRZI encoded HDLC. My goal is to use GNU Radio to implement
a smarter adaptive-level bitslicer that will outperform our hardware
one.

@(^.^)@ Ed

8

Ed Criscuolo wrote:

Another thought occured to me. Since the LFTX daughterboard goes down
to DC, shouldn’t it be posible to use it to output the bitstream?
It’s a bit of a kludge, but it should be easy. Comments?

That could work. You have a maximum output voltage swing of ±1V open
circuit. You’d probably need to construct a level shifter/amplifier
circuit to get the right logic levels for your follow-on circuit.

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

9

On Wed, Aug 22, 2007 at 07:04:29PM -0400, Ed Criscuolo wrote:

I’m working on a GNU Radio application that demodulates a synchronous
bitstream from a spacecraft telemetry downlink. Once I have the
bitstream, I need to get it back onto a wire in order to feed it into
our existing equipment.

What’s the protocol for talking to the equipment? Is there any
handshaking, etc, or do you just need a raw synchronous stream?

Is it possible to do this by using the ppio_ppdev? I would get the
bitstream unpacked into the LSBits of a stream of bytes, and write these
using ppio_ppdev.write_data().

The bitstream is running at 76800 bits/sec, so my questions are:

  1. Is ppio_ppdev fast enough to keep up with this bitrate?

I doubt it. It just bit bangs the serial port. Thus you’ve got no
control
of the data rate, etc.

  1. Can this be done from Python, or does it need to be embedded in a C++
    block?

  2. Are there other, better or easier ways to do this, such as using one
    of the debug pins on a USRP daughterboard?

If you’re willing to hack verilog, you can get it out the debug pins.

If the output needs to be synchronous serial output, the easiest way to
get it out may be to use a serial card with a USART on it. E.g.,
something that’s capable of synchronous serial transmission. Look for
a card that’ll do HDLC, then see if there’s a “raw” or “unframed”
mode. Generally the hardware that’ll can do HDLC can also do
synchronous.

Good luck!

Eric