On 29 May 2012 07:57, Kristoff Bonne <[email protected]> wrote:
> Hi Peter,
>
>
>
>
> On 29-05-12 01:05, Peter wrote:
>
>
> This is good stuff. I'll download and take a look-see, probably tomorrow.
> But. Hmm maybe tonight actually. I'll try and get some stuff published this
> week. But best man duties are likely to tie me up for most of this upcoming
> week. Probably I should add the ad-hoc changes and check it reflects what
> you did right, and we can make it a solution, for simplex at least.
>
> No problem.
>
> Just note that the changes I made where just "to have something". I will
> addapt them to your specification document.
>
>
Yep, that's fine. Sometimes you don't uncover things until you implement. I
have this all the time in professional work (I do both the design and
implementation usually). I write the design, everyone is happy it covers
every angle. I get to implementation and discover some things no-one
thought about. It's how it goes :)
>
>
>
> * How to use the application:
>> Basic file-based encoding/decoding:
>>
>> For encoding:
>> "../gmskmodem -format c -noreceiver -sif hts2a.c2 -sof hts2a.raw"
>>
>> For decoding
>> "./gmskmodem -format c -nosender -rif hts2a.raw -rof hts2a"
>> (add options "-v", "-v -v", "-d" or "-dd" for more debug information)
>>
>> All other options:
>> "./gmskmodem -h"
>>
>
> Can the -sof be stdout (-)?
>
> Of course. :-)
>
>
Good, good.
>
> Just thinking for realtime stuff. Whether we can stream it straight in:
>
> RX: rec -r 48000 -t raw -s -b 16 -c 1 -|./gmskmodem -format c -noreceiver
> -rif - -rof -|./c2dec.exe 1400 - -|play -r 8000 -t raw -s -b 16 -c 1 -
> TX: rec -r 8000 -t raw -s -b 16 -c 1 -|./c2enc.exe 1400 - -|./gmskmodem
> -format c -noreceiver -sif - -sof -|play -r 48000 -t raw -s -b 16 -c 1 -
> I've not looked yet. Just wondering if such a thing would be possible.
>
> It should but I haven't tried it that way.
>
> I wonder how alsa will react if you have two different applications using
> the same audio device. In theory it should work.
>
>
I actually couldn't compile it because of the alsa code (there isn't an
alsa lib at all for cygwin so far as I can see). Probably what might be
worth doing is adding conditional compiling (in the makefile) to rip out
alsa. If we want to support cygwin of course. Otherwise, for me I'll just
go make dual boot ubuntu some time :)
>
> The way I would do it would be like this: run the modem as a service:
> gmskmodem -v -format c -siu 12345 -soa hw:1 -ria hw:1 -rou 225.1.2.3 12345
> -ptt_cs /dev/ttyUSB
>
> -v: verbose
> - format c: codec2 format
>
> - siu 12345 : sender input UDP (i.e. listen for any UDP packets on port
> 12345)
> - soa hw:1 : sender output ALSA (device hw:1)
>
> -ria hw:1 : receiver input ALSA (device hw:1)
> -rou 225.1.2.3 12345: receiver output UDP, multicast packets to IP-address
> 225.1.2.3 port 12345. The destination can also be a unicast address, both
> ipv4 and ipv6 are supported
>
> - ptt_cs /dev/ttyUSB0: PTT switching via control signals on serial port
> /dev/ttyUSB0
>
>
> Then
> RX; nc -l -u -p 12345 | ./c3dec ....
> TX: rec -r ... | nc -u <ip-address of host running receiver> 12345
>
>
Hmm, I could possibly install it on a linux machine I already have
(performing file server/firewall/routing duties) then try this way I guess.
Assuming I can get netcat to work on cygwin...
> You can also use TCP-streams for input. I bit less "real-time", but a bit
> better shielded from packetloss. Use the option "-sit" (sender input TCP)
> instead of "-siu" (sender input UDP).
>
>
>
> (BTW. I just noticed that I did not change the "usage" and "help" for the
> PTT switching. Options are
> ptt_cs (serial port control signal pins)
> ptt_tx (serial port, TX 0 continuesly on servial port. This is equivalent
> to +12 V on RS232). Can be used on boards where the control-ports of a
> serial port is not connected (like on a pandaboard). Just add a cap between
> the input of the transistor base port of the PTT switch and the ground)
> ptt_lf (create lock-file and apply POSIX lock to it).
>
>
The Icom 746 "wired" PTT pins are separate from HF. My cable is for HF
(since PSK and so on are mostly on there). For 2m, IF I am using the cable
I tend to use the ICOM CI-V commands. But, that's another story. For
testing I'll use manual transmit. :P
Proper realtime working will be a later thing (perhaps I will make a
separate command that starts/stops TX via CI-V).
>
>
>
> This seperation between the "modem" and the "application" was done to have
> a quick way to do tests.
>
> E.g. you can very easily create a parrot with this:
> - run the modem, with the options dump received streams in a file. (it
> will create a different file with a different filename every time).
> - run a small bash script in the background that detects the presence of a
> new file and then does a "cat <file> | nc <ip-address-server> <port>" to
> send it to the modem to play it out.
>
>
Ah, I actually like the unix way of things. Where you write a tool to do a
specific job then chain it with others to make a complete program "circuit"
so to speak.
Peter - M6DGI.
------------------------------------------------------------------------------
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
