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
