| |
PA2AGA > HDDIG 19.12.99 16:31l 199 Lines 7470 Bytes #-9645 (0) @ EU
BID : HD_99_320E
Read: DL6KCF GUEST
Subj: HamDigitalDigest 99/320E
Path: DB0AAB<DB0PV<DB0MAK<DB0SON<DB0SIF<DB0AIS<DB0ME<DB0OVN<PI8JOP<PI8ZAA<
PI8GCB<PI8HGL<PI8VNW
Sent: 991219/1217Z @:PI8VNW.#ZH2.NLD.EU #:35190 [HvHolland] FBB7.00g $:HD_99_32
From: PA2AGA@PI8VNW.#ZH2.NLD.EU
To : HDDIG@EU
Received: from pa2aga by pi1hvh with SMTP
id AA26278 ; Sun, 19 Dec 99 10:11:08 UTC
Received: from pa2aga by pa2aga (NET/Mac 2.3.67/7.5.3) with SMTP
id AA00017270 ; Sat, 18 Dec 99 16:09:36 MET
Date: Sat, 18 Dec 99 15:42:45 MET
Message-Id: <hd_99_320E>
From: pa2aga
To: hd_broadcast@pa2aga
Subject: HamDigitalDigest 99/320E
X-BBS-Msg-Type: B
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==----
-
>.
------------------------------
Date: Fri, 17 Dec 1999 14:23:32 -0500
From: "Rob" <NoEmail@NoWay.com>
Subject: Kenwood Control program that runs on Liunx AND Windows!!!!!
Hi Jeff,
Many thanks for the info.
I am thinking of writing a terminal program for the SCS PTC II controller
(using its host mode). There are very few that use the host mode.
Perhaps, I should learn and use tcl/tk. That way I can provide the program
for both Linux and Windows. In the near future, I think a lot more Hams
will be using Linux.
I understand that JAVA is not completely portable (vis-a-vis the way JAVA
handles serial ports). Perhaps Tk/TCl is the same.
Do you know of anyone who has written any kind of terminal communications
program using tk/tcl?
Rob
"Rich" <spamhater@ucesucks.nouce.com> wrote in message
news:slrn85kqb9.1rq.spamhater@localhost.localdomain...
> On Fri, 17 Dec 1999 11:31:07 -0500, Rob <NoEmail@NoWay.com> wrote:
> >Hi Jeff,
> >
> >Thanks for info on TCL/TK.
> >
> >Why did you choose to use TCl/TK over JAVA which seems to be more popular
> >and provide the same functionality (i.e. code that is portable over many
> >platforms)?
> >
>
> At this point in time, Java's portability and performance are still
> way, way overrated. Heck, if you want true portability with
> rich functionality across *many more* platforms than Java, you're
> better off using Perl.
>
> - Rich
>
>.
------------------------------
Date: Fri, 17 Dec 1999 19:05:48 GMT
From: nomail@pe1chl.demon.nl (Rob Janssen)
Subject: Kenwood Control program that runs on Liunx AND Windows!!!!!
Dana H. Myers <Dana.Myers@West.Sun.Com> wrote:
>The real challenge to defining a general radio control protocol
>(or API) is developing a syntax which adequately enumerates and
>provides control and status for radio features. If done properly,
>a general-purpose UI framework could be built, which configures
>itself after enumerating radio features. Actual details of radio
>control are handled at the server, perhaps through the use of
>Java servlets.
It is also important to have a usable multiplexing mechanism.
Yeasu (and I believe Kenwood as well) radios need a separate serial
port per controlled device, so it would be practical to load a separate
server process per serial port = per radio, and do the multiplexing at
the interface to the server, e.g. using a separate port per server.
But Icom radios can be put on a single bus controlled from a single
serial port. So, you will have a single server process controlling
all your Icom radios, and possibly talking to several different user
programs that each want to control a single radio.
(of course the single server could listen on multiple ports to serve
multiple radios)
The above may seem theoretical, but in practice I have encountered this
situation when setting up an automated amateur satellite station. Then
you sually have at least two transceivers to control.
Another important aspect: the server should be able to talk to multiple
user programs at the same time. Each user program may be controlling
a different subsystem in the radio, or they may even be trying to
control the same parameters and pass on the "advice" or "results" of
this control between eachother.
Examples: a satellite tracking program may be passing information
to the radio to compensate for doppler shift, while a user interface
program controlling all functions of the transceiver is running to
assist the operator.
Or: some digital-signal-processing application may generate tuning
info that needs to be passed to the transceiver, while another program
is used for general control.
The server process should multiplex these different sources of control
information onto the single serial interface, and be able to report
back results.
Having a usable mechanism for this in the server avoids the situation
that anything written to control a radio needs to be a do-it-all program,
as is so common with existing software. It should be possible to
write a dsp modem that automatically tunes the receiver, without having
to write a fullblown graphical transceiver control program in case the
user wanted to have that (and cannot run it concurrently with your dsp
modem)
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1chl@amsat.org | WWW: http://www.knoware.nl/users/rob |
| AMPRnet: rob@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
>.
------------------------------
Date: 18 Dec 1999 07:39:38 GMT
From: Hamish Moffatt <hamish@rising.com.au>
Subject: Kenwood Control program that runs on Liunx AND Windows!!!!!
In rec.radio.amateur.digital.misc Jeff Pierce <piercej@preferred.com> wrote:
> switch $tcl_platform(os) {
> {Linux} {set comPort /dev/cua1}
Can I suggest /dev/ttyS0? The cuaX devices are obselete and may not
be supported by the linux kernel for much longer. (I'm not even sure they
are supported in 2.2.)
Hamish VK3SB
--
Hamish Moffatt Mobile: +61 412 011 176 hamish@rising.com.au
Rising Software Australia Pty. Ltd. http://www.risingsoftware.com/
Phone: +61 3 9894 4788 Fax: +61 3 9894 3362 USA: 1 888 667 7839
>.
------------------------------
Date: Wed, 15 Dec 1999 00:28:31 -0800
From: "Cathryn Mataga" <cathryn@junglevision.com>
Subject: Kenwood Control program that runs on Liunx AND Windows!!!!!
"Dana H. Myers" <Dana.Myers@West.Sun.Com> wrote in message
news:385A4CC8.DB965D07@West.Sun.Com...
> Cathryn Mataga wrote:
> >
> > > I also am thinking about with the winter time coming to devise a
> > > proposal for a common radio command protocol. This could be used by the
> > > control program which talks to a server which translates to and from the
> > > actual radio.
> >
> > Oh, yes, this is a good idea, in my humble opinion. Something like
> > a libradio for Unix and a radio.dll for windows. Ideally something
> > open source, maybe even BSD-licensed, so that Radio manufacturers
> > could take this code, make a few changes and ship a driver with their
radios.
>
> I believe there's a difference between a protocol specification (which
> is what was proposed) and an API (which is what you're apparently
> describing). A properly designed protocol is both designed and
> specified in platform-neutral terms, and describes the exchange of
> messages between agents. In the case of a remotely-controlled
> radio, the server and the client may be on different systems,
> in the case of a locally-controlled system, the server and the
> client may be on the same host. Either way, the same functionality
> could be available.
>
> Once a protocol is defined, client libraries which provide APIs
> would follow, as well as servers.
>
> > Me, I'd prefer as thin a wrapper as possible, and as simple as
> > an interface as is possible, probably with caps bits. In the API, though
To be continued in digest: hd_99_320F
Read previous mail | Read next mail
| |
