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
