Dear Raphael, > Don't you think that 40-60ms is a bit long fot the amplifier to shut down
I didn't say it was the amplifier shutting down. I supposed it was the DC offset cancellation! Your recording is very interesting. I assume the "spike" you see happens exactly when you turn on the transmitter to transmit zeros? What you see might be remnants of the previous buffer; but that would only make sense if you sent anything but zeros before, so: Does this only happen exactly once, or all the time, once per "Null- packet"? Best regards, Marcus On Mon, 2018-02-19 at 16:23 +0100, NAVES Raphael wrote: > Hi Marcus, > > Thanks for your help. Don't you think that 40-60ms is a bit long fot > the amplifier to shut down ? I tried to increase the gain at the > receiver and the sender sides but I still have the problem. > > More important, I tried an other scenario by sending a burst of > symbols > whose value is 0. According to me, it's like if I do not send > anything. > However, if I take a look at the received signal over another USRP, > we > detect a signal which is not a "zero" signal. You may find this > received > signal attached and the flowgraph used (we nullify all the symbols > coming into the URSP transmitter). This residual signal is very close > to > the signal I get in my first scenario at the end of each packet and > I > think the "error" is the same > > May you reproduce this scenario and have the same result ? Does this > result seem weird to you too? For me, it comes from an hardware > problem. > Or Can it come from the fact we are using the burst mode? > > Thanks, > > Raphaël > > > On Mon, 12 Feb 2018 23:13:45 +0100, Marcus Müller wrote: > > Hi! > > > > This might really be the fact that the amplifier takes some time to > > shut down. This, paired with the possibility of TX/RX crosstalk > > might > > be a contributing factor: That might actually change the DC offset > > on > > the receiving side, and trigger the step response of the DC offset > > cancellation (which is observable for about 40-60 ms, if I remember > > correctly). You can try to disable the DC offset cancellation on > > the > > USRP source and see if that helps (but probably introduces a DC > > offset, > > which doesn't matter for practical OFDM). > > > > If I read your flow graph correctly, you're using 0 gain on TX and > > RX > > - > > can you try *a little more* gain on each end? This might change the > > ratio of received signal to in-device crosstalk sufficiently that > > you > > won't be able to spot this relative to your signal amplitude. > > > > Regarding consecutive packets: if you look at that overlayed > > signal, > > compared to your OFDM symbol, it's very slowly changing – almost > > constant. > > > > In other words, this will end up in the DC bin of the next OFDM > > frame > > anyways, and those are usually not used at all. This would have no > > adverse effects at all! > > > > Best regards, > > Marcus > > > > On Mon, 2018-02-12 at 14:29 +0100, NAVES Raphael wrote: > > > Hi Marcus, > > > > > > Thanks for your answer. I will try to be clearer. > > > > > > You may find attached the screen shot of my Gnuradio flowgraph > > > which > > > is > > > a classical OFDM transmission. First, I'm getting PDU on the > > > described > > > socket. PDU are sent on the socket every 25ms by another python > > > script > > > running in parallel. Then the message is transormed to a tagged > > > stream > > > and go through an classical OFDM modulator. I'm plotting the > > > received > > > symbols at the same USRP (reception antenna). > > > > > > The problem is described on the screen shot of the received > > > samples. > > > As > > > you may see, after each burst, the received samples take few time > > > to > > > go > > > back to "the ambient noise level". > > > In that case it's not a problem because following packets are > > > separated > > > enough in time and have the same power. However, imagine the case > > > where > > > I want to receive directly after a packet with high power, a new > > > packet > > > with lower power : this packet reception will be disturbed by the > > > noise > > > coming after the first packet. How could I remove the noise > > > following > > > a > > > packet burst ? Is that a problem of turning off the power > > > amplifier > > > in > > > the transmission part ? > > > > > > Do not hesitate if I'm not clear enough > > > > > > Best, > > > > > > Raphael > > > > > > > > > On Sat, 10 Feb 2018 17:56:11 +0100, Marcus Müller wrote: > > > > Hi Raphaël, > > > > > > > > not quite sure I get your problem, but this is rather hard to > > > > > > debug > > > > without knowing exactly what your transmitter does. > > > > > > > > For example, if you transmit something that isn't zero-mean, > > > > then > > > > the > > > > DC offset cancellation *in* the receiving end would start to > > > > > > cancel > > > > out. As that cancellation is effectively a narrow high-pass > > > > > > filter, > > > > you'd see its (inverted) step response after you turn off the > > > > transmitter. > > > > > > > > So, if you could share both your full transmit block diagram as > > > > well > > > > as > > > > your receiving block diagram, we might be able to help you! > > > > > > > > Best regards, > > > > Marcus > > > > On Fri, 2018-02-09 at 09:28 +0100, NAVES Raphael via USRP-users > > > > wrote: > > > > > Hello, > > > > > > > > > > For more details, please find attached the received signal > > > > > in > > > > > > the > > > > > time > > > > > domain. Clearly after the end of the packet, the signal takes > > > > > a > > > > > certain > > > > > time to come back to "the ambient noise". If I zoom, I notice > > > > > there > > > > > is > > > > > still some noise 40ms after the packet. It can disturb the > > > > > reception > > > > > of > > > > > the following packet if its power is less than this > > > > > additional > > > > > noise. > > > > > > > > > > What do you suggest to cancel it ? I'm using the USRP > > > > > > sink/source > > > > > blocks from gnuradio for the transmission/reception parts. > > > > > > > > > > Best, > > > > > > > > > > Raphaël > > > > > > > > > > > > > > > On Thu, 08 Feb 2018 21:48:10 +0100, NAVES Raphael via USRP- > > > > > users > > > > > wrote: > > > > > > Hello Dan, > > > > > > > > > > > > Thanks for your answer. I'm using for transmitting the > > > > > > traditional > > > > > > USRP sink block provided by Gnuradio Companion. Each packet > > > > > > coming > > > > > > to > > > > > > this block is tagged with its length at the first sample. > > > > > > For > > > > > > the > > > > > > receiving part, I'm using the USRP source block. Both are > > > > > > used > > > > > > > > > > with > > > > > > basic parameters. > > > > > > > > > > > > Do you think I should modify/use different parameters for > > > > > > these > > > > > > blocks ? > > > > > > > > > > > > Raphaël > > > > > > > > > > > > On Thu, 8 Feb 2018 11:54:07 -0500, Dan Veeneman wrote: > > > > > > > Hello Rafael, > > > > > > > > > > > > > > Are you sure the transmitter has stopped radiating > > > > > > > immediately > > > > > > > after > > > > > > > the > > > > > > > end of a packet? The power amplifier on the transmitter > > > > > > > may > > > > > > > > > > take > > > > > > > a > > > > > > > small amount of time to go from powered up to powered > > > > > > > down, > > > > > > > although > > > > > > > 40 > > > > > > > milliseconds may be excessive. > > > > > > > > > > > > > > Do you have a writeup and/or code for your burst > > > > > > transmission > > > > > > > system > > > > > > > (transmitter and receiver), that perhaps others may be > > > > > > > able > > > > > > > to > > > > > > > duplicate > > > > > > > the issue? > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > On 2/8/2018 11:33 AM, NAVES Raphael via USRP-users wrote: > > > > > > > > Hello everyone, > > > > > > > > > > > > > > > > I implemented a burst transmission between two USRP > > > > > > > > N210. > > > > > > > > The > > > > > > > > transmission and the packet receiving works well, > > > > > > > > however > > > > > > > > I'm > > > > > > > > facing the > > > > > > > > following problem. From the reception side, I notice > > > > > > > > that > > > > > > > > > > after > > > > > > > > the > > > > > > > > packet receiving, the sampling signal does not come > > > > > > > > back > > > > > > to > > > > > > > > the > > > > > > > > ambient > > > > > > > > noise immediatly. It takes few milliseconds (about 40 > > > > > > > > ms) > > > > > > > > to > > > > > > > > come > > > > > > > > back > > > > > > > > to "0". It's like if there is still a signal > > > > > > > > transmitted > > > > > > > > after > > > > > > > > the > > > > > > > > real > > > > > > > > packet transmission. It may be a problem when you want > > > > > > > > to > > > > > > > > receive > > > > > > > > many > > > > > > > > consecutive packets with few space between them > > > > > > > > > > > > > > > > I suppose that it comes from an hardware problem when > > > > > > > > the > > > > > > > > signal > > > > > > > > is put > > > > > > > > on the baseband ? Does that deal with the LO leakage ? > > > > > > > > What > > > > > > > > > > can > > > > > > > > we > > > > > > > > do to > > > > > > > > avoid this additional signal ? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > Raphaël > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > USRP-users mailing list > > > > > > > > USRP-users@lists.ettus.com > > > > > > > > > > > > > > > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettu > > > > > s. > > > > > > > > com > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > USRP-users mailing list > > > > > > USRP-users@lists.ettus.com > > > > > > > > > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus. > > > > > > com > > > > > > > > > > _______________________________________________ > > > > > USRP-users mailing list > > > > > USRP-users@lists.ettus.com > > > > > > > > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.co > > > > > m _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
