Thanks, Kristoff, for this description. It is most helpful. Yrs, Bruce On Thu, Jun 21, 2012 at 6:45 AM, Kristoff Bonne <[email protected]> wrote: > 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
-- http://ve9qrp.blogspot.com ------------------------------------------------------------------------------ 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
