On 29 May 2012 16:20, Kristoff Bonne <[email protected]> wrote:
> Hi Peter,
>
>
>
> On 29-05-12 10:01, Peter wrote:
>
> On 29 May 2012 07:57, Kristoff Bonne <[email protected]> wrote:
>
>>
>> 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 :)
>
>
> Note that there is another element that will make it difficult to compile
> it on windows.
> On of the functions (ALSA playback) is not just implemented as a normal
> POSIX thread, but actually is clocked at 20 ms by the linux kernel. The
> reason is that this is the most time-critical element in this and I want to
> have something that runs every 20 ms, no matter how much the device is
> charged. (remember that my development platform are ARM boards).
>
> These kinds of kernel-driven interrupts apparently do exist on windows (so
> I have been told) but the API to program them is not that easy; and
> -surely- not done the same way as linux code.
>
> Anycase, I will change the code to disable all ALSA code, based on a
> define in the Makefile.
>
>
Hi Kristoff,
Yep, well it's not urgent. I'll sort something out. But if you can do that
I think it'll make a nice compile path for windows users. For desktop I'm
definitely a windows user. For server stuff I'm linux all the way. I did
have a dual boot setup. But, I used linux so rarely it was constantly out
of date.
>
>
> 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...
>
> It doesn't have to be netcat. Any application that can send or receive TCP
> or UDP traffic can do this.
>
>
> On github, there is also an application "tcpserver" which does the same
> thing as "nc -l ..."; which is about 20 lines of C code and more-or-less a
> textbook example on socket programming.
> (I did it this way as I had problems compiling netcat for my mini2440
> board.
>
>
I'm actually fairly tempted to get a static windows binary somehow, and
write a basic GUI frontend (in my case firing up TX via CI-V). But this
will be waiting until after my friend's wedding. The problem I see here
will be the single sound card options provided by cygwin/minigw
applications. I suppose if I netcatted the gmsk back over the LAN to be
TX'd by my app... Maybe.
Actually as Dave mentioned, if you can get the binary compiled into win32,
then the guy making the fdmdv frontend could probably implement this at the
same time.
>
>
>
>
>
>
>> 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
>
> Well, the code is pretty modular. Everything related to ptt-switching is
> in s_ptt.h
>
> Again, this runs as a seperate thread: just watch some variable in the
> global variables; and -if it is set or not- you perform an action.
> If you want it, you can write your own code to -say- drive the PTT over
> the CAT_interface of the transceiver.
>
>
Aye, another possibility. Like I say it's rather a specific problem with
medium age icom's. Where the HSEND/VSEND are not only on separate pins, but
separate connectors!
I'd not swap the radio for anything though. It's great.
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
