Kristoff, could you sent o us the examples of command line that you use to make this tests ?
I have download and compile gmskmodem_codec2 to ubuntu but I don't know exactly how to use the program. Thanks very much. Em 20/06/2012, às 04:11, Kristoff Bonne escreveu: > 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
