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.ettus.
> > > > 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.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
