Some pointer that might help you. - No, the samples are not completely real in BPSK until the point in signal processing chain where you decimate the signal down to the symbol rate. >From what I understand your problem, and given that your purpose is to find the correlation peak instead of demodulating the data, you'd be dealing with both I and Q samples.
- Be very careful with conjugation as they bring in both conjugation and reversal in the other domain ( https://dsp.stackexchange.com/questions/23733/conjugation-in-fourier-transform). Furthermore, you're correlating it with a clean copy that is stored in your system so there is a usual discrimination between cross-correlation and auto-correlation, the latter being the operation in which conjugations remove the phase/frequency effects and not the former. - Regarding the Costas loop, I usually do not trust the acquisition range/acquisition time numbers from simulation to practice, as simulations are done at a certain SNR with only one imperfection present. Even if everything expected is simulated, the loop starting points cannot be carefully controlled due to the unknown incoming phase! In addition, acquisition is a highly non-linear operation which strongly depends on both the Rx SNR and the loop SNR as well as the shape of the channel frequency response. In this particular ranging application, I would rather tune the frequency of one USRP receiving a test signal (e.g., simple CW and employing a simple PLL) until I get the lock. Then in the next experiment, I would initiate my ranging procedure and track small changes from there. Also keep in mind that there is a finite acquisition time for the loop to settle which might comprise of your entire sequence to be correlated. At least it will certainly eat away some part of it. Finally, Marcus' suggestion of starting with the simplest case and seeing where your signal deviates from what you expect is probably the best way to move forward. Cheers, Qasim On Wed, Feb 27, 2019 at 6:58 PM Jonathan Preheim <jonathan.preh...@gmail.com> 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 <qasim.chaudh...@gmail.com> > 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 <246...@gmail.com> >>> To: Jonathan Preheim <jonathan.preh...@gmail.com> >>> Cc: GNURadio Discussion List <discuss-gnuradio@gnu.org> >>> Subject: Re: [Discuss-gnuradio] Distance Measurement by Correlation >>> Message-ID: >>> <CAHL+j0-D_THTOqoapb2N6VeLeR=BEkW9cyDHpt64= >>> uo2tdw...@mail.gmail.com> >>> 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 >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
