Re: [Discuss-gnuradio] Distance Measurement by Correlation

[CEL]

So, that means we're deep in the realm of signal debugging. 
Make sure your time- and frequency-domain signals look like you expect
them to look. Get to know where the limits of your system are, and make
sure you're far enough from them. For example, slightly increase your
gain until you see receiver nonlinearity/clipping. Then, note that gain
and make sure you stay away from that; same on the other end of the
amplitude scale. Do multi-tone tests superimposed with your signal;
does that work as expected? 

By doing these tests, you'll probably find the specific case of what
starts to *not* look like it should, according to your digital comms
textbook. That's where you investigate.

Best regards,
Marcus
On Tue, 2019-02-26 at 23:58 -0800, Jonathan Preheim wrote:
> Hi all,
> 
> Thanks for the responses. Ultimately, we won't be able to share a clock 
> source directly, and I don't have the right cables right now to link them for 
> troubleshooting. Even when I try to use the RF loopback modes though, I do 
> not see a correlation peak. Firmware-based loopback works as expected. I've 
> been trying to model a frequency offset with the Channel Model block, and 
> compensate with the Costas loop block with a little success. But actually 
> doing it on the radios does not work. 
> 
> The Costas loop handles frequency offsets up to 0.05 in simulations with an 
> otherwise ideal channel. The chip rate is 1.25Mchip/s, so that's an offset of 
> about 63kHz. The BladeRF's clock is 38.4MHz accurate to 1 ppm or 38.4Hz. 
> Multiplied up to our carrier frequency of 910MHz, that's an expected accuracy 
> of under 1kHz, so it's reasonable to expect that the Costas loop would take 
> care of any offset right? 
> 
> Using the conjugate of the samples doesn't seem to make difference. That 
> would make sense to me if I was trying to do the correlation as frequency 
> domain multiplication by the conjugate, but I'm not (the FIR filter method 
> has produced much more consistent results in simulations for us so far). 
> Ideally, the samples would be completely real since it's BPSK, and we'd want 
> to apply compensation in order to achieve roughly that, right?
> 
> T'hanks,
> Jonathan
> 
> On Tue, Feb 26, 2019 at 7:00 PM Qasim Chaudhari <address@hidden> wrote:
> > >Make sure both your radios are locked to the same clock source.
> > Any fsignificant requency offset between the two is going to ruin your
> > correlation peaks very quickly.
> > 
> > When the same clock source is not possible due to the distance between 
> > them, the carrier frequency offset can also be estimated and corrected at 
> > the initiating USRP and then the correlation can be applied. In this 
> > scenario, the quality of the result will depend on how good the CFO 
> > estimate is.
> > 
> > Cheers,
> > Qasim
> > 
> > 
> > > Message: 4
> > > Date: Tue, 26 Feb 2019 10:07:51 +0100
> > > From: Sylvain Munaut <address@hidden>
> > > To: Jonathan Preheim <address@hidden>
> > > Cc: GNURadio Discussion List <address@hidden>
> > > Subject: Re: [Discuss-gnuradio] Distance Measurement by Correlation
> > > Message-ID:
> > >         <address@hidden>
> > > Content-Type: text/plain; charset="UTF-8"
> > > 
> > > > Any ideas about how we can troubleshoot this more effectively? Or 
> > > > better model the channel?
> > > 
> > > Make sure both your radios are locked to the same clock source.
> > > Any fsignificant requency offset between the two is going to ruin your
> > > correlation peaks very quickly.
> > > 
> > > Frequency offset is going to end up as a progressive phase shift along
> > > your PN sequence. If that phase shift is a non-negligibe part of the
> > > unit circle during the time of your PN sequence, they won't 'add up'
> > > to a peak anymore.
> > > 
> > > Cheers,
> > > 
> > >    Sylvain
> > > 
> > > 
> > > 
> > > ------------------------------
> > 
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME cryptographic signature