Maybe Manchester encoding would be better.
Thanks
Bruce
On 05/23/2012 03:13 PM, Bruce Perens wrote:
Hi Kristoff,The suggested implementation of synchronization pattern would be easy for a simple hardware demodulator to figure out. But we're not limited to a simple hardware demodulator. We can probably as easily run 4 software demodulators at once, custom-tuned for each of the potential speeds and data-rates.But even if we don't do that, I might have a more versatile way to do this. I suggest that instead of a hard-coded synchronization pattern, we run an NRZI-encoded data stream at least as long as your suggested 64-bit minimum synchronization length. The characteristics of NRZI make it simple to derive the clock rate from the data stream. The NRZI-encoded information can be real data, like the version number of the encoding used for the rest of the packet. So, we can get both synchronization and protocol information from the synchronization pattern.Thanks Bruce
<<attachment: bruce.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
