[Ts2k-interface-developers] Getting Started & Current status.

[Dale E. E. <de...@w-...>]

Hi all,

Good to see things are progressing so quickly.  Sourceforge is doing
things quicker than I've seen
in the past as well.

1) I program almost exclusively in c/c++.  It has worked so well for so
long and it is quite standard.
I'm open to new stuff as long as it provides a benefit.  Then, I'll do
all I can to get up to speed.
My original tools for the ts2k are written in C++.  The stuff I've done
within the hamlib library is
in C (no choice).  I use the GNU C/C++ compiler and tools running the
Linux operating system.
I use the Slackware distribution as a base and recompile and reconfigure
everything from there.

2) My software for the ts2k is in three parts.
    a) C++ modules that are only complete enough to save/restore memory
and send basic ts2k
          command scripts to the rig for resetting.
    b) ts2k scripts which are text commands that when transferred to the
rig will cause it to interpret
        them. I have some ts2k scripts to do basic setup of the rig
after a full reset.
    c) C modules that I've written from scratch as part of the hamlib
project.  I retain the copyright
        etc...  There are some modules I've modified and a couple I've
written entire functions for and
        have clearly demarked the new stuff I've written.  The hamlib
project is under GNU license
        there is no problems with using it.  My stuff is also under GNU
license and likewise has no
        restrictions (except you can't package and sell it without
providing the source code to the
        end user--standard GNU licensing).

3) Hamlib.  The idea behind hamlib is most excellent.  The
implementation is suprisingly good.
    The actual ts2k control really sucks.  I took to modifying the ts2k
module but hamlib was much
    too limited in certain areas.  I've made all the corrections I felt
was needed to make everything
    work well but wasn't allowed to keep the code in the mainline code.
branch_ts2k was created
    for my work to go into until such a time as the two may be merged.

    The standard hamlib control for the ts2000 is broken as far as I'm
concerned.  I suggest we use
    branch_ts2k.  If we do this we don't have to abandon our software if
we change to another
    rig.  I'm fairly unwilling to spend hours and hours working on a GUI
for rig control and have to
    throw it all away if I decide the ts2k just isn't what I want or
need.  It's quite the cool rig but it is
    the only rig I've owned and would like to try others (provided they
may be remotely controlled).

    The software I talk about that I have is yet another version of
hamlib I call hamlib-kd7eni.  This
    is the bleeding edge stuff I develop on.  I have my own CVS
repository where I maintain this code.
    Every once in a while I merge branch_ts2k from sourceforge with my
hamilb-kd7eni.  I also have
    merge new stuff from the hamlib Mainline code to keep things
current.  This is a whole lot of work
    and I don't do it often.  I recently moved and the Mainline code is
probably quite a ways out of
    sync with both branch_ts2k and hamlib-kd7eni.

    The hamlib has not only control of the serial port but uses an RPC
interface which allows one
    to connect a machine via a network to a machine connected to the rig
and control it as if he
    were there in the room.  We'd have a hard time just extracting the
few bits we need.  Let's just
    use hamlib.  If it doesn't suit us, we have the source code and can
change anything we wish.

4) I haven't found a good GUI that uses hamlib yet.  There are a few
startup projects though.  We can
    use one of these as a base to get started with or we can start from
scratch.  Either alternative is
    going to take a bit of work.

5)The bottom line is that I want to have a viable and working system by
the time we release a
    working version of our software.  I want it to have as much or more
functionality than the ts2k.
    I won't attach a PC to my rig and accept some lame excuse of a
control program.  With the
    assistance of a programmable PC, the ts2k should be really awesome!
Not just an expensive
    and oversized HT.

6) I think we should use hamlib in its entirety including non-kenwood
rigs.  I don't think we should
    attempt to maintain them but should keep our version current with
the mainline as oftem as
    is practical as long as they don't break our version.

    Then we should "adopt" an existing framework GUI and do the same
thing.  In our case we'll
    be molding them to fit our needs, rather than accepting something
more bland.  This work can
    be sent back to the originating groups which can merge or reject our
updates.

    Also, all of the Kenwood specific scripts and tools we create will
be here.  The standalone memory
    save is a good tool.  I'll never discard it but I'm not doing a lot
of new work on it.  Everybody should
    be able to use this tool regardless of the computer they have.
There are several others that can
    be created for simple tasks especially when hamlib and a GUI are
over kill.  In short, we need to
    write several more tools.  Most will be standalone but many should
have a hamlib version.  We should be
    the TS-2000 resource that rivals the Kenwood website by a long shot.

    Well, I'm sure I've "timed out the repeater".  We'll need more
discussion before we actually create
    the repository and start throwing in code.  We'll have more than one
project I suspect but again, this
    is something that we need to discuss:    Standalone Tools,  Kenwood
library (hamlib-ts2k), GUI.
    And of course supplimental documentation (I'm not on the documents
commitee--Hi!).

    73's for now.

    Oh yea!  I just completed the command functions.  I'm switching to
the testing phase which should
    be complete enough to show to you guys this weekend.  It'll take a
while to debug them all (the header
    and source are each approx. 30k bytes)  This will be good for
standalone as well as hamlib use!

    On a personal note, I was able drive my truck today.  I'll be moving
slow this weekend, but I'll likely not
    be staying home!

    73
    Dale
    kd7eni