On Fri, 2016-03-25 at 22:14 +0000, Landsman, Arik wrote: > Hi Andy, > > I gave it a few more touches since we last spoke, but to no avail... > Costas still flips sporadically on a simulated channel. > > Generally the corr_est block would show a large spike in |corr|^2 on > the very first packet I send (>1600), but on all subsequent loops > (same packet) the value diminishes to ~100 with multiple peaks.
That doesn't seem right. > I tried various preamble formats and sizes, including an 8 byte long > version to avoid any possible corr with payload. corr^2 certainly > changes but results in either multiple peaks at low levels (say 100 > and 140), or with a huge spike at start as mentioned. > > I can generate tags by reducing the threshold to extremely low values > (say 0.1, 0.3), which I suppose makes sense with the delta between the > first and subsequent spike levels. > > In either case there are more than one tag generated per packet as the > packet loops. Only one preamble per packet, non repeating. > > > matched filter taps - can the corr_est block accept taps in any way? No. The idea with corr_est is to give it exactly the reference samples that you are looking to match against. That usually means building them with one of the gnuradio modulator blocks *and* discarding the the initial samples which are a transient emitted during the initial delay of the gnuradio particular modulator. Look at the GRC file I just posted to the list regarding "GMSK 9600 baud". I had a modulator build the preamble samples. I had to add in a few flush/fill bits at the end of the preamble, which never get emitted by the modulator. I had to discard the initial transient emitted by the modulator. > I'd like to hold sps=8 at least for the time being, and without a > filter there is little correlation between the stream and the > reference preamble. sps=2 was too low for timing recovery without a > preamble. what do you generally use? (btw all of the debug above was > with sps=2). I use sps=10 with low data rate stuff. > I am told I've been loosing sleep over this.. in any case I'll keep > trying but in the meanwhile if you had any comments I would deeply > appreciate it. If you have a flowgraph that you could share that simulates the input, I'd would probably be easier for me to see what's wrong about the corr_est process. Regards, Andy > Many Thanks, > Arik > > > > > > > > > > From: Landsman, Arik > Sent: Monday, March 14, 2016 11:59 AM > To: Andy Walls; [email protected] > Subject: RE: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block > in qpsk > > Hi Andy, > > Thank you for the detailed answer, I am certainly going to try what you > suggest in the next couple of days. will post with updates as progressing > along. > > As a side, I tried to hack the corr_and_sync block using a preamble which in > BPSK looks the same as both I and Q of the QPSK data (e.g. [1,-1] in bpsk is > [1+j,-1-j] in qpsk). This does not quite work in practice, I was getting > sinusoids with very weak correlation (amplitude in 30's 40's) from the corr > port. Strange, since the block should ignore the imaginary portion of the > stream anyways since designed for BPSK. > > in terms of a clock pattern for preamble, looks like Barker codes is the way > to go, at least statistically speaking for low correlation with any random > "preamble-like" bit combinations in the payload. So avoiding clock patterns > for sure. > > Will look to tag the end of preamble, from your comments it appears to be the > more universal approach. In my case freq lock should be fairly good though, > channel is largely stationary, and I am using a FLL (although it does require > longer bit combinations that are to result in a balanced spectrum to detect > band edges). point well noted though. > > You mentioned M&M for timing recovery, have you tried the Polyphase block? > without passing tags, I had better results with the latter for whatever > reason. MM is more efficient though as I read. > > Just to clarify, were you capturing the time_est tags, or just relying on a > combination of phase_est for costas and MM converging fast enough ahead of > payload? > > finally, would you know of any good references for passing tags in gnuradio? > I will certainly search around, but in case anything comes to mind (?) > > Best Regards, > Arik > > > > P.S. - In case it helps future causes - see "Phase-ambiguity resolution for > QPSK modulation systems" by Nguyen, Tien Manh, NASA, 1989. Part1 outlines the > basic two approaches for correcting phase, which are diff encoding or > preamble correlation. The preamble algorithm there is very much similar to > the one Andy describes, although likely implemented as an IC (aka ASSP). In > this case the author suggests diff encoding for burst transmissions, since > bits are wasted on a preamble (which theoretically has 2x BER compared to > diff encoding). > > That said, if phase rotation occurs in mid-payload the full packet is lost, > unless some form of post-processing is used to recover - so at higher SNR > diff encoding is possibly better. But I am yet to find a publication that > compares real data on the topic. > > http://ntrs.nasa.gov/search.jsp?N=0&Ntk=All&Ntt=Phase-ambiguity%20resolution%20for%20QPSK%20modulation%20systems&Ntx=mode%20matchallpartial > > > > ________________________________________ > From: Andy Walls [[email protected]] > Sent: Sunday, March 13, 2016 8:51 AM > To: [email protected] > Cc: Landsman, Arik > Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block > in qpsk > > On Sun, 2016-03-13 at 01:35 -0500, [email protected] > wrote: > > Message: 1 > > Date: Sat, 12 Mar 2016 21:34:03 +0000 > > From: "Landsman, Arik" > > > > > Hello folks, > > > > I am trying to resolve the 90* ambiguity of costas for a QPSK > > receiver, and was hoping folks could weigh-in in case anyone had > > success with this in the past. > > > > yes, diff encoding works.. :) trying to make it work without though. > > > > Also, I had seen Tom R's example of his cor-and-sync block > > implementation in BPSK (but not qpsk). maybe the block could be > > "hacked" to support qpsk, such as by passing the preamble as bpsk but, > > say, upsampling the block to make the generated complex reference > > align with the incoming qpsk stream. going to try this when I get home > > tonight. > > > > Since Trx will be bursty and will use a preamble anyways, another > > thought was to correlate the stream with the 4 possible versions of > > the preamble (i.e. constellation rotations), and pass the best > > candidate downstream to select the proper constell object for demod > > (as opposed to adjusting costas, as in cor-and-sync block), or use the > > result for post-processing the incorrectly demodulated data. But both > > seem a bit indirect or wastefull.. > > > > Any thoughts? > > Using a preamble makes sense to me. > > Do not use the correlate_and_sync block; it is unreliable and provides > and errant "phase_est" value. > > Use the corr_est block; it does correctly and more generically what the > correlate_and_sync block aimed to do. > > To use the corr_est block: > > 1. Generate a vector of samples which represents your preamble. A > test_corr_est.grc file can be found here: > > https://github.com/gnuradio/gnuradio/tree/master/gr-digital/examples/demod > > which should give an example of how to use gnuradio modulator blocks to > build the preamble samples vector for you. You could also use, pyhton, > Matlab, octave, or whatever. > > > 2. Tell the corr_est block where on the preamble you want it to place > the tags. You must give the tag delay in units of samples. Common > choices are: > a. start of preamble > b. middle of first symbol after start of preamble > c. middle of last symbol before end of preamble > d. end of preamble > > 3. The corr_est block outputs the following tags: > > corr_start: that start of your preamble > > corr_est: the absolute value of the correlation squared > > phase_est: the phase offset between the reference preamble and the > received preamble at the sample corresponding to the correlation peak > (which happens at the end of the preamble). > > time_est: the fractional sample delay from the sample that is at the > correlation peak to where the actual coorelation peak (which happens in > between samples) > > > 4. If you are well synchronized in frequency, you can just apply the > phase_est correction to the whole burst with a phase rotation by > multiplying the burst by exp(1.0j*-phase_est_value), IIRC. > > If you are not well synchronized in frequency, the phase_est value is > only sensible to apply at the samples at the end of the preamble. > But that's enough to resync a tracking loop. > > > 5. Modify your downstream blocks to look for the above tags, and reset > their state as appropriate, to acquire and maintain synchronization. > > 6. BTW, avoid a preamble that has a clock pattern (1010101010..). It > causes duplicate correlation peaks (which you then have to inspect the > corr_est tag for the highest value), and the M&M clock recovery block > really drifts off such preambles badly for some reason. > > > Thank you in advance, > > Arik > > > Regards, > Andy > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
