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

Reply via email to