Hi Raphael, don't think switching from GNU Radio to directly talking to UHD will change much – the GNU Radio USRP Sink is pretty much a thin wrapper around UHD. You might have already said that, but I can't find in this email chain: What's the daughterboards you're using in your TX USRP N210?
Thank you, Marcus On Thu, 2018-02-22 at 09:34 +0100, NAVES Raphael wrote: > Hi Marcus, > > I'm only sending bursts of "null packets". I send them every 400 ms > and > I notice at the receiver side that the spikes happen exactly at the > beginning of EACH transmission of null packets (for this verification > I > use GPS clock on the the transmitter and the reveiver). > > It's like if when the USRP transmitter receives the burst to send it > turn on its power amplifier and send something (what does it send, I > don't know). Moreover, the spikes "last" almost 30 ms whereas my > packet > burst sending lasts only 5.8 ms. Then, when I increase the burst to > send > size, the spikes "duration" increases also. Last but not least, when > I > increase the sampling rate (I first used 400k), the spikes still > exist > but their duration seems reduce. > > I'm a bit confused, I have always used Gnuradio but maybe the key to > solve that is to code directly over UHD. However, it seems a bit > tricky > ! What do you think ? > > Thanks for your help > > Raphaël > > > On Wed, 21 Feb 2018 22:41:40 +0100, Marcus Müller wrote: > > 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.ettu > > > > > s. > > > > > > > > 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
