CW between bursts

I’m not sure whether this is a GNU radio or USRP issue, so I’m posting
to both lists. I played around with GNU radio’s stream tagging feature
and managed to implement something that does timed bursts (partially by
taking a lead from tag_source_demo.h, etc. in gr-uhd/examples).

I’m observing a continuous wave at the carrier frequency in between
bursts, and also during start-up when the gr_uhd_usrp_sink object is
instantiated before any samples get transmitted. The CW is about 30 to
40 dB down from my signal, but I’d like the radio to be silent in
between bursts.

I’ve looked into changing the LO offset, but this just seems to move the
CW to another part of the spectrum, but not knowing any better, this may
be the expected behavior. Would UHD calibration or playing around with
the DC offset help at all? I’m at the extent of my knowledge with this
one.

Thanks,
Sean

On 12/11/2011 08:26 PM, Nowlan, Sean wrote:

I’m not sure whether this is a GNU radio or USRP issue, so I’m
posting to both lists. I played around with GNU radio’s stream
tagging feature and managed to implement something that does timed
bursts (partially by taking a lead from tag_source_demo.h, etc. in
gr-uhd/examples).

Cool!

I’m observing a continuous wave at the carrier frequency in between
bursts, and also during start-up when the gr_uhd_usrp_sink object is
instantiated before any samples get transmitted. The CW is about 30
to 40 dB down from my signal, but I’d like the radio to be silent in
between bursts.

I suppose you are seeing the LO of the transmitter. What daughterboard
is this? I recently pushed a change because SBX was not properly
disabled between TX bursts.

-Josh

On 11/12/11 11:26 PM, Nowlan, Sean wrote:

I’ve looked into changing the LO offset, but this just seems to move
the CW to another part of the spectrum, but not knowing any better,
this may be the expected behavior. Would UHD calibration or playing
around with the DC offset help at all? I’m at the extent of my
knowledge with this one.

Thanks,
Sean

Mixers generally have between 30 and 40dB of LO suppression, so what you
see is roughly what you’d
expect. Calibrating the I/Q phase and magnitude will help move the
suppression towards the lower
end, I think.

There’s a “tension” here between wanting to maintain phase-coherence in
the mixer between bursts,
and wanting to suppress the LO between bursts. Not sure that it’s
configurable, but perhaps
it should be?

In a heterodyne system, the LO is very often outside the passband of the
TX filters, but in direct-conversion
or small-offset up-conversion, you may not have that luxury. I looked
at the git-log of the most recent
UHD, and it looks like Jason added shutting-down the TX mixer between
bursts, so I don’t know which
strategy “won” (keep mixer up between bursts to give phase coherency
across bursts, or shutdown
the mixer between bursts to suppress the LO between bursts).

You might try the most-recent UHD and appropriate FPGA, etc, to see if
you are now getting
LO suppression between bursts.

In a more traditional radio, the combination of the LO being out-of-band
with respect to the final
TX filters, and keying of the TX amplifiers makes this a
non-problem. But turning on and off
the various components in the analog chain has its own problems–they
take a finite time to turn
on, and stabilize, so you end up with other issues as a result.

I’m using RFX900. Does it employ the same mechanism to be disabled
between bursts? I thought it gets disabled after an end-of-burst packet.
(Perhaps I’m doing something wrong with my burst code, but I’m pretty
sure I send an EOB packet)

Thanks,
Sean


From: discuss-gnuradio-bounces+sean.nowlan=removed_email_address[email protected]
[[email protected]n.invalid] on behalf
of Josh B. [[email protected]]
Sent: Monday, December 12, 2011 12:00 AM
To: [email protected]
Subject: Re: [Discuss-gnuradio] CW between bursts

On 12/11/2011 08:26 PM, Nowlan, Sean wrote:

I’m not sure whether this is a GNU radio or USRP issue, so I’m
posting to both lists. I played around with GNU radio’s stream
tagging feature and managed to implement something that does timed
bursts (partially by taking a lead from tag_source_demo.h, etc. in
gr-uhd/examples).

Cool!

I’m observing a continuous wave at the carrier frequency in between
bursts, and also during start-up when the gr_uhd_usrp_sink object is
instantiated before any samples get transmitted. The CW is about 30
to 40 dB down from my signal, but I’d like the radio to be silent in
between bursts.

I suppose you are seeing the LO of the transmitter. What daughterboard
is this? I recently pushed a change because SBX was not properly
disabled between TX bursts.

-Josh


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Thanks for your response. Please see below.

Sean


From: [email protected]n.invalid
[[email protected]n.invalid] on behalf
of Marcus D. Leech [[email protected]]
Sent: Monday, December 12, 2011 12:05 AM
To: [email protected]
Subject: Re: [Discuss-gnuradio] CW between bursts

On 11/12/11 11:26 PM, Nowlan, Sean wrote:
I’m not sure whether this is a GNU radio or USRP issue, so I’m posting
to both lists. I played around with GNU radio’s stream tagging feature
and managed to implement something that does timed bursts (partially by
taking a lead from tag_source_demo.h, etc. in gr-uhd/examples).

I’m observing a continuous wave at the carrier frequency in between
bursts, and also during start-up when the gr_uhd_usrp_sink object is
instantiated before any samples get transmitted. The CW is about 30 to
40 dB down from my signal, but I’d like the radio to be silent in
between bursts.

I’ve looked into changing the LO offset, but this just seems to move the
CW to another part of the spectrum, but not knowing any better, this may
be the expected behavior. Would UHD calibration or playing around with
the DC offset help at all? I’m at the extent of my knowledge with this
one.

Thanks,
Sean

Mixers generally have between 30 and 40dB of LO suppression, so what you see is
roughly what you’d
expect. Calibrating the I/Q phase and magnitude will help move the suppression
towards the lower
end, I think.

I’ll give this a shot, but I’m not sure calibration is supported on
RFX900 yet. (It doesn’t appear here yet:
http://files.ettus.com/uhd_docs/manual/html/calibration.html)

There’s a “tension” here between wanting to maintain phase-coherence in the mixer
between bursts,
and wanting to suppress the LO between bursts. Not sure that it’s
configurable, but perhaps
it should be?

In a heterodyne system, the LO is very often outside the passband of the TX
filters, but in
direct->conversion or small-offset up-conversion, you may not have that luxury.
I looked at the git-log
of the most recent UHD, and it looks like Jason added shutting-down the TX
mixer between bursts, so
I don’t know which strategy “won” (keep mixer up between bursts to give phase
coherency across
bursts, or shutdown the mixer between bursts to suppress the LO between
bursts).

Is this phase coherence helped by using a stable reference clock? Is
phase incoherence caused by random drift in a PLL or some other
component?

You might try the most-recent UHD and appropriate FPGA, etc, to see if you are
now getting
LO suppression between bursts.

I’ll try this too. I think I’m using a version that is a month or 2 old.

In a more traditional radio, the combination of the LO being out-of-band with
respect to the final
TX filters, and keying of the TX amplifiers makes this a non-problem. But
turning on and off
the various components in the analog chain has its own problems–they take a
finite time to turn
on, and stabilize, so you end up with other issues as a result.

So could I use LO offset and push it outside the transmit filter bands?
(Whatever those are; I’ll have to look through the specs; but I believe
I’m limited by the range of the offset). Would this LO bleedthrough be
fully suppressed at that point, and what negative effects might I
expect? I’m not a very experienced RF guy, so a lot of the front-end
stuff is new to me.

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