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

[Cameron Matson]

Johannes,

The 140 came from this datasheet

https://www.ettus.com/wp-content/uploads/2019/01/USRP_N310_Datasheet_v3.pdf

It does indicate that this is probably a worst case scenario, and that UHD software would improve it.

My flow graph has two separate parts, one for the TX that goes to a USRP sink and one for RX that begins from a USRP source.  It's a little difficult for me to say exactly how the timing works in my setup because I'm using triggers to show the previous two plots.

Just to clarify: In your case are you saying that after transmitting on TX/RX the n310 switches to receiving on TX/RX and you receive the sent data 18us later?

Thanks,

Cameron

On Thu, Aug 20, 2020 at 12:30 PM Johannes Demel <demel@ant.uni-bremen.de> wrote:

Hi Cameron,

where did you find this 140us switching time? I'm curious.

If I recall correctly, my tests with N310s indicate 18us delay between
TX and RX with timed bursts at sample x and corresponding start of burst
in RX at x+18us. The behavior you observe seems to be different.

How does your flowgraph look like?

Cheers
Johannes

On 20.08.20 17:21, Cameron Matson wrote:
> 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
> <mailto:ncmatson95@gmail.com>> wrote:
>
>     Forgot to reply to the list.
>
>     ---------- Forwarded message ---------
>     From: *Cameron Matson* <ncmatson95@gmail.com
>     <mailto: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 <mailto: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
>     <mailto:willcode4@gmail.com>> wrote:
>
>         Or maybe this is what you're seeing. Except from
>         https://usrp-users.ettus.narkive.com/s4vNkAe9/buffer-reset-or-clear-issue-on-usrp-n200
>
>         """
>         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
>         <mailto: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
>             <mailto: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
>                 <mailto:USRP-users@lists.ettus.com>
>                 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>