On 24 May 2012 17:23, Graham Bryce <[email protected]> wrote:
> 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)
> ****
>
> **
>
Well, in the D-starlike spec. I'll outline the general idea.
Essentially like D-Star, the data is laid out in blocks of 96 bits (4
segments of 24 bits)
The general idea is that there's 2 different sync patterns (both 24 bit).
One for signifying that the next coming blocks are to be data only (all 4
segments are data). This would be used for the header, and data only modes.
For the data that follows there would be further packet type markers (to
let the receiving side know what kind of data is being sent). The other
sync pattern signifies that the next coming blocks are to be voice (1
segment data, 3 segments voice). The data segment is always the first of
the 4 segments, and in this way the sync marker can be repeated as often as
needed without infringing on the voice frame rate.
So a typical transmission would be:
Data sync (24 bits), Header data frame ID, Header data.........
Voice sync (24 bits), Voice frames (with interleaving, FEC).
Data frame, voice frames (with interleaving, FEC). With interspersed data
being either user supplied modes, or the header data slowly reproduced for
receivers tuning in halfway through the over, or if the header was missed.
....... sync frame repeated every 16 or so blocks.
End sync (24 bits) sent when over is complete.
So very similar to D-star, but with the Icom enhancements specified as
standard. Plus (I think) a more logical layout of having the data frame
before voice and allowing a switching from data to voice modes (so for
example commands could be sent to a repeater without sending voice
frames).. etc etc.
Now of course distributing the sync would probably be an issue for
switching between the modes. In practice it would usually only happen after
the header is sent. But the system is designed to be not so rigid.
------------------------------------------------------------------------------
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
