Odd use of LO phase lock feature on USRP for RFID application

Hi All,

In RFID applications, a reader receives (backscatter from RFID tag) and
transmits (constant tone) at the same frequency. With commercial
readers, a
single LO will be shared by the RX and TX chain. However, in the USRP
case,
two separate daughter boards are used so different LOs are in use for
the RX
and TX chain. So you should end up with some frequency offset in RX
chain
due to mismatched clocks.

Is it possible to lock the LOs of a TX daughter board and a RX daughter
board, as you would for a traditional MIMO 2 TX or 2 RX setup? There
appears
to numerous discussions and examples of the latter. I’m thinking it
would be
possible. But I’m more of a systems guy and less of a RF hardware guy,
so
any comments would be appreciated.

Thanks,
Colby

On 04/19/2011 11:38 AM, Colby B. wrote:

board, as you would for a traditional MIMO 2 TX or 2 RX setup? There
appears to numerous discussions and examples of the latter. I’m thinking
it would be possible. But I’m more of a systems guy and less of a RF
hardware guy, so any comments would be appreciated.

Thanks,
Colby

As long as you set them to the same frequency, they’re already locked.
No need to do anything different.

Matt

On Tue, 19 Apr 2011 11:41:46 -0700, Matt E. [email protected] wrote:

Is it possible to lock the LOs of a TX daughter board and a RX daughter
No need to do anything different.

Matt


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

True, for a SISO system with TDD(not FDD) theres no problem for your
kind of application.
Regards
Agile Solutions

The two boards should have different clocks, so there should be some
frequency offset. Even in typical SISO systems, you use a PLL block to
deal
with this since you can’t access the other LO because its physically
somewhere else.

While receiving, the transmitter is still running at full power to run
the
RFID tag. The transmitters carrier is down converted by the receiver
board.
Unless I have a misunderstanding, and the two daughter boards share the
same
clock there should be some frequency offset.

?

Thanks,
Colby

On Tue, 19 Apr 2011 14:00:01 -0700, Colby B. wrote:

The two
boards should have different clocks, so there should be some frequency
offset. Even in typical SISO systems, you use a PLL block to deal with
this since you can’t access the other LO because its physically
somewhere else.

While receiving, the transmitter is still running at
full power to run the RFID tag. The transmitters carrier is down
converted by the receiver board. Unless I have a misunderstanding, and
the two daughter boards share the same clock there should be some
frequency offset.

?

Thanks,
Colby

On Tue, Apr 19, 2011 at 12:44 PM,
wrote:

On Tue, 19 Apr 2011 11:41:46 -0700, Matt E. wrote:

On
04/19/2011 11:38 AM, Colby B. wrote:

Hi All,

In RFID
applications, a reader receives (backscatter from RFID tag) and

transmits (constant tone) at the same frequency. With commercial

readers, a single LO will be shared by the RX and TX chain. However, in

the USRP case, two separate daughter boards are used so different
LOs

are in use for the RX and TX chain. So you should end up with
some

frequency offset in RX chain due to mismatched clocks.

Is it possible to lock the LOs of a TX daughter board and a RX daughter

board, as you would for a traditional MIMO 2 TX or 2 RX setup? There

appears to numerous discussions and examples of the latter. I’m
thinking

it would be possible. But I’m more of a systems guy and
less of a RF

hardware guy, so any comments would be appreciated.

Thanks,
Colby

As long as you set them to the same
frequency, they’re already locked.
No need to do anything different.

Matt


Discuss-gnuradio mailing list

[email protected] [3]

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio [4]

True, for a
SISO system with TDD(not FDD) theres no problem for your
kind of
application.
Regards
Agile Solutions

If you are using two separate
boards for Tx and RX, certainly you will experience relative frequency
offset between the two.

Links:

[1]
mailto:[email protected]
[2] mailto:[email protected]
[3]
mailto:[email protected]
[4]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Basically, if possible use the same LO, or lock the two LO’s together.

Going back to the original question: is locking the LOs for an RX card
and a
TX card on a USRP1 feasible?

Thanks for your comments Vijay, you helped to add focus to my question.

–Colby

Hi Colby,

Even if the two boards have slightly different frequencies, this should
not impact decoding of the receive signal as the received signal jumps
between the I and Q channels (depending of course on the packet lengths
and assuming that you have a packet decoder on I and Q separately).

More seriously using separate uncorrelated LO signals for transmit and
receive significantly degrades receiver sensivity. The transmit signal
is typically 30dBm+ and the same antenna or nearby antenna is used to
get the receive signal - the received signal has this huge transmit
signal along with a -60dBm backscattered signal from the tag that is 50
to 200kHz away from carrier. If the same LO is used for transmit and
receive, then at the dowconversion mixer, there is a high degree of
correlation between signals at the LO port and the RF port (esp. the
transmitter leakage), and much of the transmitter noise shows up as a DC
offset. If separate LO’s then the noise at the two ports are large
uncorrelated contributing to the baseband noise. You can expect 5db to
20db difference in SNR between using same LO’s vs separate LO’s

Best regards,
-Vijay

— On Tue, 4/19/11, Colby B. [email protected] wrote:

From: Colby B. [email protected]
Subject: Re: [Discuss-gnuradio] Odd use of LO phase lock feature on USRP
for RFID application
To: [email protected]
Cc: “Matt E.” [email protected], “GNU Radio D.ion”
[email protected]
Date: Tuesday, April 19, 2011, 5:00 PM

The two boards should have different clocks, so there should be some
frequency offset. Even in typical SISO systems, you use a PLL block to
deal with this since you can’t access the other LO because its
physically somewhere else.

While receiving, the transmitter is still running at full power to run
the RFID tag. The transmitters carrier is down converted by the receiver
board. Unless I have a misunderstanding, and the two daughter boards
share the same clock there should be some frequency offset.

?

Thanks,
Colby

On Tue, Apr 19, 2011 at 12:44 PM, [email protected] wrote:

On Tue, 19 Apr 2011 11:41:46 -0700, Matt E. [email protected] wrote:

On 04/19/2011 11:38 AM, Colby B. wrote:

Hi All,

In RFID applications, a reader receives (backscatter from RFID tag) and

transmits (constant tone) at the same frequency. With commercial

readers, a single LO will be shared by the RX and TX chain. However, in

the USRP case, two separate daughter boards are used so different LOs

are in use for the RX and TX chain. So you should end up with some

frequency offset in RX chain due to mismatched clocks.

Is it possible to lock the LOs of a TX daughter board and a RX daughter

board, as you would for a traditional MIMO 2 TX or 2 RX setup? There

appears to numerous discussions and examples of the latter. I’m thinking

it would be possible. But I’m more of a systems guy and less of a RF

hardware guy, so any comments would be appreciated.

Thanks,

Colby

As long as you set them to the same frequency, they’re already locked.

No need to do anything different.

Matt


Discuss-gnuradio mailing list

[email protected]

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

True, for a SISO system with TDD(not FDD) theres no problem for your

kind of application.

Regards

Agile Solutions

-----Inline Attachment Follows-----

On 04/19/2011 05:26 PM, Colby B. wrote:

Basically, if possible use the same LO, or lock the two LO’s together.

Going back to the original question: is locking the LOs for an RX card
and a TX card on a USRP1 feasible?

Yes, it is possible to lock them together.

Matt

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