Forgot to reply to the list. ---------- Forwarded message --------- From: Cameron Matson <ncmatso...@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 <willco...@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 <willco...@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 <willco...@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-us...@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-us...@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>
