Hi David,
It does not. The unit of the gmskmodem is 40 ms and the interleaving fites inside that frame. A 40 ms frame contains 3 times a 40 ms codec2 frame (7 ocets @ 1400 bps). The only thing the interleave does is change the order of the octets; so that there is no repetition between these 3 copies. (as this resulted in quite a lot of QRM). But the receiver still needs to receive the complete frame to do FEC decoing anyway so interleaving does not add any latency. 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. 73 Kristoff - ON1ARF On 20-06-12 11:43, David Rowe wrote: > Good work Kristoff, congratulations on yr first on air test. > > What sort of delay does the interleaver add and how do you sync with the > interleaver at the receiver? > > Cheers, > > David > > On Wed, 2012-06-20 at 09:11 +0200, Kristoff Bonne wrote: >> Hi, >> >> >> I just pushed a new version of the gmskmodem on github: >> - I applied both interleaving and scrambling on the codec2 part; this is >> avoid repetition of the same pattern which resulted in interference. >> >> This version might be a bit overkill as it based on a box pattern of 25 >> lines of known random data (exored on top of the actual data) which is >> repeated in cycle. It works great for scrambling that data, but it will >> make the process of trying to pick in on a ongoing signal more complex. >> >> Perhaps we will reduce this to (say) 8 or even only 4 lines in a future >> release. >> >> Note that this is NOT part of the specs as defined by Peter; just a test >> of myself. (see also my mail in the list "question on noise reduction" >> about this). >> >> >> - Also found a bug in the way codec2 files are processed by the sender, >> which became apperent when using ALSA-out streaming. >> - other bugfix in "resync" code >> >> >> And, I also did my the first onair tests. >> >> Setup: >> PC (linux laptop) -> ethernet -> friendlyarm board -> interface board -> >> yaesu FT-857D >> kenwood TH-7E -> interface board -> pandaboard >> >> >> -> c2-file (pre-encoded audio) send via TCP (netcat) from PC to friendlyarm >> -> stream is played out in real-time >> >> -> stream received by kenwoord + pandaboard, saved to file >> -> file decoded on pandaboard (not in real-time) >> -> played out >> >> >> The file was about 15 seconds, 100 % copy, no biterrors detected >> >> Two things noticed when using a kenwood TH-7E in "9k6 packet mode". >> - audio in inverted!!!! use the "-audioinvert" option in the receiver >> >> - When using the FT857D as receiver, the audio-level when a signal comes >> in is some 30 to 40 % smaller then receiving noise (see my blog-article >> "what does a D-STAR signal really look like" for more about that). On >> the kenwood that is not like that. >> The problem is that the receiver uses this fact to decide if a signal is >> present or not. This helped dealing with false positives of "start of >> stream" events. >> >> So I needed to change the code to make this test optional. >> >> It remains to be seen if -in a real live situation- the code is still >> robust enough without this check. >> >> >> >> >> Anycase, the first onair test has been done and was 100 % successfull. >> It also proves the modem works in practice. >> >> I plan to make a fully real-time setup, and make a small video about it. >> This to show this is not all vaporware or "theory" >> >> >> 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 > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
