Hello again.
It's an idea. Not sure it's something to put in the first versions. I agree
with Kristoff on keeping the initial versions simple. Surely it takes more
memory/processing time to detect this sync though?
It does - and that's the major drawback of this kind of approach!
Because we don't know where we are at all. It'd need the full most recent
100+ bits, and check all permutations of 12 bits apart. But being able to
make a "best guess" early on after a sync loss is a nice thing I'll agree.
I suspect the best overall approach is to do, as I think you're suggesting,
both - put a D-Star-like header on the start of the transmission to
kick-start the sync and define the modem parameters - i.e. if it's
voice/data/something else, whether there's error correction or not and which
type, callsigns/IP etc, but then also insert the embedded sync bits into the
payload data that followed, so that, if the receiver wanted to, it could
confirm that things haven't slipped, re-establish sync if it missed the
start (computationally intensive) or to recover from a fade. A simple
receiver would just ignore the additional sync mechanism, and rely on
staying in sync based on the initial header. The contents of the header
could also be repeated through the TX in the slow metadata bits to allow
that to be recovered under those circumstances as well.
So I suppose we're back to trying to decide what goes into the header. ;o)
Graham
G7LGI
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
