discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Distance Measurement by Correlation


From: CEL
Subject: Re: [Discuss-gnuradio] Distance Measurement by Correlation
Date: Mon, 18 Mar 2019 13:54:23 +0000

I don't intimately know the BladeRF driver, but it seems unlikely that
the USRP is way more computationally intense than the BladeRF. Chances
are the BladeRF driver doesn't /show/ the same errors.

Be a bit careful about saving away the data: your storage must be up to
supporting the constant data rate even in a realistic worst-case
scenario – a storage device with high average rate might still have
high variance in write speed, and that might or might not be manageable
with some limited write buffers.

Best regards,
Marcus

On Sun, 2019-03-17 at 22:26 -0700, Jonathan Preheim wrote:
> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]