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 <[email protected]> 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 <[email protected] > > <mailto:[email protected]>> wrote: > > > > Forgot to reply to the list. > > > > ---------- Forwarded message --------- > > From: *Cameron Matson* <[email protected] > > <mailto:[email protected]>> > > Date: Tue, Aug 18, 2020, 2:01 PM > > Subject: Re: [USRP-users] N310 self interference with packet comms > > and correlation estimator > > To: Jeff Long <[email protected] <mailto:[email protected]>> > > > > > > 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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[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] > > <mailto:[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] > > <mailto:[email protected]> > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > >
