So long as you know what you're looking for in any given scenario, you can use that to correlate to. It can be data or a preamble. If your receiver knows the data will always be a certain way ahead of time though, it's hard to call that data. Semantics at that point.
Rich On Fri, Feb 5, 2016 at 2:44 PM, Henry Barton <kw...@outlook.com> wrote: > That sounds great, Richard. But I wonder, what if the useful payload > contains that sequence by chance? > > Sent from Windows Mail > > *From:* Richard Bell <richard.be...@gmail.com> > *Sent:* Friday, February 5, 2016 5:27 PM > *To:* Henry Barton <kw...@outlook.com> > *Cc:* discuss-gnuradio@gnu.org > > Typically a correlator is used to look for a known sequence of bits, > so the radio can align the rest of the processing from the end of this > known sequence. This is referred to as frame synchronization. You could use > the correlation estimation block to implement something like this. It would > place a tag on the stream when it finds your known sequence and you would > then know how everything is aligned from then on. > > Rich > > On Fri, Feb 5, 2016 at 1:04 PM, Henry Barton <kw...@outlook.com> wrote: > >> Hi all. I've successfully written a DSSS modulator and demodulator in >> Windows with a chip rate of 16x. It writes samples to a file that the >> demodulator can read and despread. Before I try any practical >> implementations, I need to know how a DSSS stream would be >> synchronized. Assuming the transmitter and receiver were perfectly clocked >> in unison, what stops the receiver from tuning in in the middle of a >> byte, thus getting a nibble from the current byte and a nibble from the >> next? >> >> _______________________________________________ >> 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