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