To clarify a confusion in my last email, by "until the point in signal processing chain where you decimate the signal down to the symbol rate", I meant the stage just before quantization; otherwise carrier recovery in BPSK still needs to work with complex samples at symbol rate.
Cheers, Qasim On Thu, Feb 28, 2019 at 11:06 AM Qasim Chaudhari <[email protected]> wrote: > 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 < > [email protected]> 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 < >> [email protected]> 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 <[email protected]> >>>> To: Jonathan Preheim <[email protected]> >>>> Cc: GNURadio Discussion List <[email protected]> >>>> Subject: Re: [Discuss-gnuradio] Distance Measurement by Correlation >>>> Message-ID: >>>> <CAHL+j0-D_THTOqoapb2N6VeLeR=BEkW9cyDHpt64= >>>> [email protected]> >>>> 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 >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
