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 <[email protected]> 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 < > [email protected]> 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 >> [email protected] >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >
