Hi Henrique,
I know, the program seams to grow and grow, so options keep on being
added. It does not make things easier to understand.
You can start it with the option "-h" which will give some help; but the
problem is that the help file is not 100 % up-to-date and sometimes a
bit "short".
I use the "release fast, release often" principe, which means that
sometimes things are included that have not been 100 % tested or
completely documented. My appologies for that.
But, the advantage is that it allowes other people to follow the
development and keep track what is being done.
First, three things to remember:
- this is a "modem", so it's more then just a encoder or decoder. It's
actually designed to be able to run as a standalone application on some
device that interfaces with your radio. Other application can interface
with it either using files, standard-in or standard-out, UDP or TCP.
- It is both a sender and a receiver at the same time.
If you want it only to be a sender, use the option "-noreceiver"
if you want it only to be a receiver, use the option "-nosender".
If you do not add this parameters, you'll get errors with "missing
parameters" or something like that.
- it actually supports three modes: dstar, codec2 and raw.
These choices affects things like:
-> format of input and output files/streams/... expected
-> format of radio stream expected or created, including the
syncronisation part of the stream
-> certain options are only available for certain modes.
E.g. options dealing with frame-syncronisation for raw streams (-rs and
-rss) are only available in "raw" format. -z ("zap") and "resync" only
apply to d-star as they deal with the d-star sync patterns
Here are the options that apply to codec2. (again, try "-h" for this list)
1/ Format options
- format is "c" (input / output is expected to be raw codec2 format)
- recformat is not used. (it used when you expect a different format
when sending or receiving; this is more for debug stuff)
- dvsystem is "c" (codec2); but this is automatically "guessed" when
format is set to "c" so you do not have to fill this in.
2/ the sender: convert a codec2 file into an audio-file
* "si." define the sender input:
- sif <filename> = input is file
- sif - = input is standard-in
- sit <tcp port> = input is TCP: the modem will open a TCP port <port>
and listen for an incoming session on it containing the codec2 file to
be send
- siu <udp port> = inout is UDP. Simular to sit, only using an UCP port
instead of TCP port.
* "so." defines the sender output:
- soa <alsa-device> = output is ALSA linux audio device
- sof <filename> = output is filename. RAW WAV (48000 Khz, mono, 16 bit
signed).
Some examples:
- modulate c2 file into audio file
gmskmodem -noreceiver -format c -sif infile.c2 -sof outfile.raw
- modulate c2 file and play it out directly
gmskmodem -noreceiver -format c -sif infile.c2 -soa hw:0
(in this case, ALSA audio interface "hw:0" of your computer/board would
have the interface-board connected which then sends it to the tranceiver
- real-time encode a wav-file and play out
c2enc mymessage.raw - | gmsksender -noreceiver -format c -sif - -soa hw:0
- real-time encode a wav-file on an external machine and play out, use
TCP to communicate
(computer 1: interfacing board)
gmskmodem -noreceiver -format c -sit 12345 -soa hw:1
(computer 2: encoder)
c2enc mymessage.raw | nc 10.1.1.1 12345
This example uses TCP, but you can also use UDP. Then use the option
"-siu" instead of "-sit". For netcat on the remote machine, use "nc -u ..."
This kind of setup is usefull if the interfacing-board does not have
sufficient CPU-power to do real-time codec2-encoding (e.g. if it does
not have a FPU)
Also note, of course, for sending, you still need something to drive the
PTT. See below for more info on that.
3/ The PTT driver:
Here I noticed that the "help" and "usage" parts are not correct
anymore. If you look into "parsecliopts.h", you can find the correct list:
Driving the PTT can be done in three ways:
- ptt_cs <serial-device>: drive CTS, DSR, RTS and DTR of a serial port
- ptt_tx <serial-device>: continuesly send 0x00 to a tx-port of serial
device. According the RS232 standard, that is a continues +5V with the
exception of the start-bit at the beginning which becomes 0V. To deal
with that, add a cap between the input of the PTT part of the interface
board and ground.
I needed this as on both ARM deb-board I have (friendlyarm mini2440 and
the pandaboard), the control-signals are not connected; so "ptt_cs"
doesn't work overthere.
- ptt_lf <lockfile>: can be used to interface the modem with an external
application for PTT driving. It sets a posix lock on a file.
Say you want to use the CAT interface of your radio for PTT driving. You
can make your own appplication to do that, but you need some kind of
input of the gmskmodem when the PTT should be on of off.
With the ptt_lf, the gmskmodem will set a posix file-lock on a file;
something that can be monitored by your "CAT-driver" application.
- pttinvert: invert PTT bit
4/ The receiver: convert audio into a codec2 file/stream
* "ri.": define receiver input.
-rif <file>: input is a file (RAW audio, 48000 Khz, mono)
Note, multiple files will be creates, named file-0000.c2, file-0001.c2, ...
-ria <ALSA device>: input is a ALSA device
* "ro*": define receiver output
- rof <file>: output is file (raw codec2 dump)
- rof -: output is standard-out
- rou <ip-address> <port>: output will be send out as UDP packets
Again some examples:
- convert gmskencoded audio file into a codec2 file
gmskmodem -format c -nosender -rif infile.raw -sof mymessage
This will create a file "mymessage-0000.c2" for the first codec2 stream
detected in the audio file, "mymessage-0001.c2" for the second, etc.
- capture real-time audio, save in local files
gmskmodem -nosender -format c -ria hw:0 -sof mymessage
- capture real-time audio, send to remote machine or remote application
for processing
(computer 1, interface)
gmskmodem -nosender -format c -ria hw:0 -rou fc00::1 12345
(computer 2, decoder)
nc -l -u 12345 | c2dec - - | play -r ...
(in this case, the address is an ipv6 address, just as an example)
5/ Some other options:
-d: RECEIVER: dump stream data (when a valid stream is has been detected)
-dd: RECEIVER: dump more stream data (including bitstream before
start-sync has been detected)
-da: RECEIVER: dump audio amplitude (average of audio-samples per 20 ms
audio-capture)
-s: RECEIVER: receiver audio interface is STEREO (needed for certain
audio cards that cannot do captureing in mono)
-audioinvert: invert audio for input, outbut or both. Needed for certain
combinations of audio cards and/or certain transceivers
-m: add markers infront of and after a codec2 stream.
This might be usefull when sending a received codec2 stream to an
external application (using UDP or standard-out). As codec2 files are
just raw dump-file that have no start-markers or end-markers, this is OK
when dealing with files, but is more probematic when dealing with streams.
By inserting these markers, an external application receiving a codec2
stream via UDP or standard-in should be able to detect when one stream
has ended and another one has started.
-4 and -6: forces UDP output stream as "ipv4 only" or "ipv6 only".
-sb: SENDER: add silence before the transmission. This is used to
control the time between PTT switching and starting transmission. By
default, this is set to 2 seconds, which might be quite long. (that
value was put in when I was working on a D-STAR parrot). Perhaps I will
change this and make it configurable per 1/10 second.
Does anybody know what would be the good delay between "PTT switch on"
and "begin transmission"?
-se: SENDER: add silence after the transmission. Same thing as above;
but for the end of the transmission. Is by default set to 1 second;
which is probably also way to long!
Finally, a small quiz question. What would be the usefullness of this setup:
- (session 1)
gmskmodem -format c -siu 12345 -soa hw:0 -ptt_cs /dev/ttyS0 -ria hw:0
-rou 127.0.0.1 12346
- (session 2)
nc -l -u 12346 | c2dec - - | play -D hw:1 -r 8000 -c 1 -
- (session 3)
rec -D hw:1 -r 8000 - | c2enc - - | nc 127.0.0.1 12345
(I hope the options for "play" and "rec" are correct).
73
Kristoff - ON1ARF
On 20-06-12 15:55, Henrique Brancher Gravina wrote:
> 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
>
------------------------------------------------------------------------------
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
