Hi Kristoff,
Sorry I've not been about. It's been a busy month for me. But slowly I am
getting some free time back and should be able to get some documentation
solidified.
On 20 June 2012 20:29, Kristoff Bonne <[email protected]> wrote:
> Concerning syncing of the scrambler, well that's not fully descided yet.
> The current implementation simply has 25 predefined exor-patterns that
> are repeated in cycle.
> For a station that is in sync, that should not be a problem.
>
>
> But for a station tuning in in the middle of a QSO, that's more difficult.
>
> But,
> - every frame has a fixed sync-pattern at the beginning. A receiver that
> has just tuned in needs to detect that. Interleaving and scrambling do
> not have any effect on that as that sync-pattern is not interleaved nor
> scrambled.
>
> - Then it needs to know what scramble pattern of the 25 patterns to
> apply. I guess it can just try every 25 of them and see where it has the
> least errors.
> I don't know what time this would take in a modern CPU but I don't think
> this should be a real problem.
>
>
I think (processor intensive mind you) the solution would be as you say.
Try all 25 patterns. Since you have 3 copies of the same frame only one of
them will produce the same/similar data for all 3. Of course this check
needs to be able to know if it has spent so long checking that the next
frame has been missed (in the case of people running on external boards).
But probably even on those it would be OK.
Does the pattern really need to be more than 168 bits of scrambling
applied? If so, there's another way. If not, then 168 bits of scrambling
would keep it within a frame at least, and the voice frame on the next
radio frame will be different anyway. If the problem is that the voice
frames aren't different enough, then yeah it's a weird issue to get around.
If so, then there's another weird solution that may work. Scramble the sync
code too, this would mean you would have 25 different sync codes but also
that once you matched it, you would know which xor block to use right away.
The downside with that plan is of course that there would be 25x more
chances for a false positive hit also of course 25 matches upon initial
sync (after that you will know which sync to expect).
I didn't really expect scrambling to be needed at all on the voice frames.
D-Star doesn't do that. Only header and data parts have the scramble
applied. I do suppose having any pattern repeated 3 times in a row would
sound weird (and probably having the sync on every frame adds a predictable
audible pattern every 25th of a second). Neither of which D-star has.
A couple of questions to ask though, maybe I missed it being discussed
already (playing catch up here). Is the strange sounds observed (caused by
the repetitive data) causing co-channel interference, or causing the signal
to fail to be decoded? Or is it just that the sound isn't how you expected?
Ah well, some things that can only be discovered in practice I guess :)
Regards,
Peter - M6DGI.
------------------------------------------------------------------------------
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
