discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [USRP-users] N310 self interference with packet comms and correlatio


From: Cameron Matson
Subject: Re: [USRP-users] N310 self interference with packet comms and correlation estimator
Date: Thu, 20 Aug 2020 10:21:02 -0500

Hello everyone, 

An update: I made an attempt to pad the tx signal with 0s to no avail.  My understanding is that TX/RX handles the switching from TX to RX, and is "always RX" unless there's something to TX.  The N310 datasheet says that the switching time is 140 us.  I've tried adding 0s which at my sample rate and frequency would be well above that.  But it looks like the message I'm sending is immediately received in full, with some shift in the IQ data (below).  It appears it's operating in full-duplex, which I don't want--I want TDD.  What's strange is that if I set it to send on TX/RX and receive on RX2 (which to my understanding should be full duplex) it doesn't see the transmitted signal.

Am I doing something wrong?
image.png

Thanks,
Cameron

On Tue, Aug 18, 2020 at 2:03 PM Cameron Matson <ncmatson95@gmail.com> wrote:
Forgot to reply to the list.

---------- Forwarded message ---------
From: Cameron Matson <ncmatson95@gmail.com>
Date: Tue, Aug 18, 2020, 2:01 PM
Subject: Re: [USRP-users] N310 self interference with packet comms and correlation estimator
To: Jeff Long <willcode4@gmail.com>


I'm using one TX/RX port for both.

I'm using the same frequency for transmit and receive because the system I'm trying to implement will eventually have multiple "transmitter" nodes like I've described trying to communicate to a single receiver.  The rx part of the transmitter is for collision avoidance, so it needs to be on the same frequency as the other transmitters so it can sense when the channel is busy.

I'm not sure I fully understand the post you included, with respect to the setup/teardown of the different streams. But the zero padding seems like it might work. My thoughts are that it's either a buffer remnant or reflections off nearby objects or the radio itself. I think transmitting empty data after the burst before transitioning back to rx might help.

Thanks!
Cameron

On Tue, Aug 18, 2020, 11:33 AM Jeff Long <willcode4@gmail.com> wrote:
Or maybe this is what you're seeing. Except from

"""
The buffers should clear whenever the device object is constructed, also
when the transmit or receive streamer is constructed.

If you dont want to tear-down and re-construct the rx streamer, you can
simply issue a stop stream command (if this is continuous streaming),
and call recv() until timeout. This will also flush out rx buffers.

Now the filters in the DSP chains do have history to them. So if you are
having some issue with that, tx streams should be padded out at their
end so the upconversion filters have zeros in their history; likewise,
you an throw out the first several rx samples, which could be rx history
from the last run.
"""

On Tue, Aug 18, 2020 at 12:07 PM Jeff Long <willcode4@gmail.com> wrote:
This is why cell phones use different uplink/downlink frequencies (or time slots). Are you using two different USRP ports for TX and RX and connecting them to the same antenna? Or are you using a TX/RX port with tx and rx streamers attached?

On Tue, Aug 18, 2020 at 11:48 AM Cameron Matson via USRP-users <usrp-users@lists.ettus.com> wrote:
Hey everyone,

I've copied both the gnuradio and usrp lists, since I'm not sure if the question has a software or hardware answer, so I apologize for duplicate emails.

I am attempting to set up a wireless transceiver using N310s and the packet tx/rx examples from gnuradio.  I combined both the tx and rx chains in one flowgraph with zeromq source/sink blocks like this:

[zmq source] -> [packet tx] -> [usrp sink]
and
[usrp source] -> [packet rx] -> [zmq sink]

I have a separate python file running in a separate process.  That handles messages from the zmq blocks and controls state changes between "backoff", "listen" and "talk"

I'm not sure the specific terminology for the variety of duplex I'm trying to implement, but I want the TX and RX to happen on the same frequency using one antenna.  The problem is that if I use the same frequency, my RX chain immediately "hears" the signal that was transmitted.  By "hears" I mean that the first part of the [packet rx] block, which is the [correlation estimator] block detects the signal as a valid packet.  The problem is that because the amplitude of my desired rx signal is low, I've had to set the threshold of the correlation estimator relatively low--and so the recently transmitted signal, which has a much higher amplitude being right next to the rx antenna, overwhelms the detector.  This doesn't happen if I have the TX and RX on different frequencies

What I don't quite fully understand is what happens on the N310 when a flow graph with both transmit and receive processes are active.  I can see from the LEDs that it is "receiving" most of the time and when it gets a message to transmit it will blink to tx and then back.  What happens in this process?  One thought is that since its the same antenna, the tx and rx might share a buffer and the tx data is still present there.

Is what I'm trying to do even possible?

Thanks for your time,

Cameron
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]