Hi Peter,
On 22-06-12 17:31, Peter wrote:
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.
No problem. We all have a life outside radio too, no. :-)
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 problem is that a modem must also work when receiving a stream with
bit-errors. That's why I allow a certain number of biterrors in the
syncronisation pattern.
I would need to check what would be the effect off exor-ing a scrambling
pattern on top of that.
But, in the end, I would like to change the "sync-pattern per frame"
principle. It looks like quite overkill and it would be nice to be able
to put some usefull data in there.
So why not reduce the number of sync-pattern to -say- one per 8 frames,
or one per 6, or something like that. That would also remove the
repetition of the sync-pattern every frame.
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.
Correct.
Perhaps, with some other error-encoding sceme which produces less
repetitive patterns; there is no need to do scramblng.
The FEC system we now have is very basic. It's only there "to have
something on the air".
But I would not be surprised if there would be FEC-systems that provide
more protection in less bits. I would like to remove some of the FEC
code to use it for something else.
Is there somebody with a more mathematical background who can make a
comparison between the 1/3 FEC we now use and -say- a 1/2 FEC system
like golay.
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?
Well, it didn't sound as it expected; but looking at the
spectrum-analysis, it does look like it does cause co-channel
interference and additional on-channel QRM.
But I do not have the real life tests to prove this.
It would be nice to have a number of comparison:
- only-interleaving vs. interleaving + scrambling.
- 25 scrambling pattern vs. less scrambling patterns (say 6, 8)
- scrambling all 168 bits (all three DV frames) vs. only scrambling the
last 112 bits (the last two DV frames).
Ah well, some things that can only be discovered in practice I guess :)
And a bit more maths too. :-(
Regards,
Peter - M6DGI.
73
Kristoff - ON1ARF
------------------------------------------------------------------------------
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
