Thanks for the advice all. It turns out the BladeRF is not transmitting properly in this case. I probably should have figured that out long ago. An equivalent flowgraph (for some reason my original did not work) performed as expected at lower sample rates with a USRP b205.
Follow up: It does not seem like GRC plots can keep up with incoming RX data without having overflows from the USRP. I imagine all I can do about this is save to a file and process (i.e. correlate and display) the data later? It seems odd that that was not a problem with the BladeRF that I was aware of. Thanks, Jonathan On Wed, Feb 27, 2019 at 4:17 PM Qasim Chaudhari <qasim.chaudh...@gmail.com> wrote: > 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 < > qasim.chaudh...@gmail.com> 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 < >> 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
