hamlib-developer

[Hamlib-developer] hamlib_ts2k

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

Stephane:

1) hamlib_ts2k:    I had already stated I wouldn't commit into hamlib,
    but only to hamlib_ts2k.  Maybe you are just repeating your
previous?
    Thanks for setting this up!  Yes, I'll review the CVS as what I've
been
    using is an old doc and there are newer more readable ones out now.

    I have my own CVS repository set up.  Thanks for your concern about
    overwriting stuff though.  I also keep regular tarball backups.  I'm
only
    a little paranoid.

2) RIG_RPT_SHIFT_1750:  Yes, this is the Europe style 1750Hz and I
    only know how to turn it on.  The ts2k displays '+" for
RIG_RPT_PLUS,
    '-' for RIG_PRT_MINUS, and '=' to use the European 1750 style.
    Since I don't know of any repeater that uses this, I can't test or
confirm.
    For what it's worth, it is the "os3;" command with menu  44 on.
    (TS-2000 Instruction Manual pages: 33, 131)  Easiest for me is for
this
    to just go away, but I figured some Non-(U.S.A./Canada) Ham
    would complain eventually.  Entirely your call as this don't affect
me.

3) channel->lock:    This was one of my first changes to rig.h.  I
    like the channel->flag better.  Please allocate something like
    RIG_CHFLAG_LOCK or some such to set it with (even a bit field
    will do if you want to go that far.  More specifically it is a
"skip"
    during "group scan" for any memory having this True.  Also,
    nice would be a READONLY bit to prevent Hamlib from over-
    writing certain memories (my group 9 is emergency/rescue and
    is not to be touched!)

4) tone_t tone; On my HT and the TS2K the CTCSS and Tone are
    separate and set individually.  However, only one may be enabled,
    but both may be read and will yield different values if set
differently.
    Calling this CTCSS is like calling SSB, AM.  Similar functions,
    different critters.  Your call.

5) RIG_MTYPE_*:  As I understand it, the MTYPE describes available
    and accessible memories for a rig.  The Setup is what I intended for

    Kenwood's "Programmable Memories".  There are 0-5 available
    which a simple view would be to say the rig has its own
    rig_save_channel() which saves 1) Main VFO's, 2) Sub VFO,
    (as well as the memory pointers I believe) and 3)Both of the Menus
    (A and B).  What I'm calling Menu (we use menus on the rig to
    change them) you are calling conf.  I use P.M. 0 ,MenuA as my
    VHF and repeater setups, whereas P.M. 0, MenuB is my HF
    and simplex setups.  I haven't defined (my) uses of PM's 1-5
    yet.  In rig.h I defined RIG_MTYPE_MENU for MenuA/B,
    RIG_MTYPE_SETUP for P.M.'s 0-5.

    The PM's save everything excluding Memories (mem, tmp, sat,
    pct).  So, yes, they save frequencies, but also modes, shifts, menu
    options (A and B) etc...

    I added RIG_MTYPE_PCT for the Packet Cluster Tune feature.
    These are very similar to Temporary Memory but are only set
    by receiving P.C.T. data.  I have not found any simple, clean, or
    easy way to read this since only the panel may select these.  Thus,
    I have recently found they are not accesible to software.  It is
very
    cool but the code for this isn't currently available.  I'm hoping to

    upgrade my rig's embedded software and see if this is fixed, but I
    doubt it.

6) EXCLUDE():    This macro is my compulsion to simplify things
    that get repeated.  (This is why I wrote the ts2k memory backup,
    restore and setup routines in the first place.)  If useful, keep it,

    otherwise discard it.

Hope this helps.

Sorry I can't easily copy previous messages.  I use different stuff
for send and receive and have to transfer by hand and that isn't
going to change.

7)  Only two question have come up recently.  Why does
    src/rig.c::rig_save_channel()/rig_restore_channel()  try to
    handle the rig directly?  Should this not be like all others and
    simply check valid parameters call the backend?  It may be
    nice to provide this "feature" for those who don't want to
    write it or whatever.  Wouldn't it be much better and more
    correct (as well as more standard) to rename this to a
    pseudo but functional backend and call it?  My suggestion
    would be generic_save_channel(), generic_restore_channel().
    If the backend's pointer for this function is NULL or to "generic"
    call the generic, otherwise, call the correct Backend function.

8) Within the backend I call other backend functions.  Originally,
    I used ts2k_get_mode() or whatever.  I have changed over
    to calling rig_get_mode() which allows different modules to
    be used (e.g. kenwood_get_mode() -vs- ts2k_get_mode())
    within a single backend.  I presume this is correct and better
    than assuming it is actually a TS-2000 using the functions.

    I've started noting which routines may be *only* for the ts2k.


Sincerely,

Dale E. Edmons, KD7ENI

[Hamlib-developer] hamlib_ts2k

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

Stephane,

The RIG_CHFLAG_SKIP would be prefered.  Either
is needed but not both (unless you are giving me the
RIG_CHFLAG_LOCK so I can use it as READONLY--
hi).

See my response to Robert for more info on READONLY.

The 1750Hz item is a menu option and will be treated as
such unless otherwise notified.  (Again, see my reply to
Robert for more info.)  The "one-shot" is not standard
on my rig  (U.S./Canada version) but is a menu option.

Ignoring the 1750Hz there are three unique tone types:
    1) Tone, 2)CTCSS, 3) DCS.
In my area only 1) is used and 2) and 3) are not, at least
to my limited knowledge.  I have used CTCSS on my
HT to operate my rig via remote control, but if you
accidently enable CTCSS on an actual repeater, you
will not be able to talk on it.  There is no 1750 Hz
activation (again, to my limited knowledge).

Yes, the "Programmable Memories" are different.
The manual only lists the command.  I don't think
it may be accessed via the panel.

The name rig_set_pm() would be wrong but it would
be okay to have ts2k_set_pm().  Maybe we could
write rig_set_state() or rig_set_setup() or even
rig_set_conf() if rig_set_menu() replaces your
previous.

Later, it may be required to backup PM[0:5] and it
would be done (by some application) as follows:
    for( pm=0, pm<=5; pm++) {
    rig_set_conf(rig, pm);
    rig_save_channel(rig, RIG_CTRL_MAIN);
    rig_save_channel(rig, RIG_CTRL_SUB);
    rig_get_menus(rig, MENU_FIRST, MENU_LAST);
    rig_set_menu(rig, MENU_B);
    rig_get_menus(rig, MENU_FIRST, MENU_LAST);
     }
Or something very close to this.

I have begun working on the Menu stuff as it is
important to the user.  I haven't even tried compiling
anything so far but I think I'm on the right track.
Much input will be needed and appreciated.

I don't know what all will be needed for the menu
API.  The backend may need to initialize stuff
which can be called with the mmelter_init().
I've anticipated Hamlib's complete lack of know-
ledge of Menu items and suggest rig_menu_list()
which will return a char * to the menu items
description.  See my ts2k_menu.h if you find
the time.  The ts2k_menu.c is not very far and
will change.  The application will do something
like the following to change a menu item:
    rig_get_menu(rig, MENU(12));
    fprintf(menu, "%s: ", rig_menu_list(rig, MENU(12)) );
     /* read user response and set value */
    rig_set_menu(rig, MENU(12),  value);
Or something vaguely like this.  The application
should be able to setup its own complete menus
so the user may browse the entire set.  I think
we're thinking along the same lines.


My work on the TS440 stopped after I said it
was similar to existing stuff.  I saw you had
some stuff for it and got busy with other stuff.
The same goes with the kenwood_transaction().

P.C.T. is very cool but completely useless if
only the rig can access it.  The user can use
the panel until other things are sorted out.

rig_save_channel() should work as you suggested
but I'll have to see what you write or show you
what I write.  As long as the backend can take
over, life is good.  Any of the channel() stuff
should have a channel_t.  The called function
should always be passed the needed values
of chan_t, or vfo_t, or both in this struct or
as parameters.  The backend can't guess
and setting them in the rig may be the wrong
thing to do.  If needed, the backend can set
them in the rig (or if generic_save_channel()
is called).

Sorry for running on so long again.

73's

Dale
kd7eni

Re: [Hamlib-developer] hamlib_ts2k

[Robert <ro...@14...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Dale E. Edmons wrote:
> 1)
>     I have my own CVS repository set up.  Thanks for your concern about
>     overwriting stuff though.  I also keep regular tarball backups.  I'=
m
> only
>     a little paranoid.

Hehe, reminds me of the saying "just because you're not paranoid doesn't =
mean
you not being followed".

> 2) RIG_RPT_SHIFT_1750:  Yes, this is the Europe style 1750Hz and I
>     only know how to turn it on.  The ts2k displays '+" for
> RIG_RPT_PLUS,
>     '-' for RIG_PRT_MINUS, and '=3D' to use the European 1750 style.
>     Since I don't know of any repeater that uses this, I can't test or
> confirm.

This sounds strange. Here in Germany, repeaters of course use an offset:
- -600kHz on 2m and -7.6MHz on 70cm. I believe in France + or -1.6MHz is =
used
on 70cm. Usually all repeaters are closed and can be opened by sending a
1750Hz tone once. Some can now be opened with subtones as well, but the
1750Hz tone works everywhere. I don't understand why it would be an optio=
n
used _instead_ of the frequency shift.

What I have seen though is a "+-" display on a Kenwood. In this case two
specific memory channels were used to determine TX and RX freq an thus se=
lect
any offset -- more like a "split" operation.

> 3)
> Also,
>     nice would be a READONLY bit to prevent Hamlib from over-
>     writing certain memories (my group 9 is emergency/rescue and
>     is not to be touched!)

I'd say that if a channel is not really *locked* by the TRX, then hamlib
shouldn't lock it, either. Hamlib only mimes the functions supported by t=
he
TRX. Any extras should be handled by the front-end application; it should
provide this read-only feature.

> 4) tone_t tone; On my HT and the TS2K the CTCSS and Tone are
>     separate and set individually.  However, only one may be enabled,
>     but both may be read and will yield different values if set
> differently.
>     Calling this CTCSS is like calling SSB, AM.  Similar functions,
>     different critters.  Your call.

What exactly is the difference between CTCSS and Tone?

> [other topics skipped]

73, Robert DL1NC/N9KBK
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9JYI3o4a8ramwUd8RAodPAJ9Sywyab0X5AlKLvbA1DLeJwLw9TQCfTMkv
BxVBF7nY7TxSU5n5bcTYJNc=3D
=3DX9yO
-----END PGP SIGNATURE-----

Re: [Hamlib-developer] hamlib_ts2k

[Stephane F. <f4...@fr...>]

Quoting "Dale E. Edmons" <de...@w-...>:
> 1) hamlib_ts2k:    I had already stated I wouldn't commit into hamlib,
>     but only to hamlib_ts2k.  Maybe you are just repeating your previous?
>     Thanks for setting this up!  Yes, I'll review the CVS as what I've been
>     using is an old doc and there are newer more readable ones out now.

Good, I'm happy to see you'll use the 'branch_ts2k' on sourceforge. 
This way, everyone can see how the ts2k goes, view easily the difference
with the trunk (cvs rdiff -r ts2k_branch -r HEAD hamlib), etc.
And sooner or later, we'll have to merge.

> 2) RIG_RPT_SHIFT_1750:  Yes, this is the Europe style 1750Hz and I
>     only know how to turn it on.  The ts2k displays '+" for RIG_RPT_PLUS,
>     '-' for RIG_PRT_MINUS, and '=' to use the European 1750 style.

Let's say that until we know what it does really, hence how to design
the API for it, we'll put it aside.

> 3) channel->lock:    This was one of my first changes to rig.h.  I
>     like the channel->flag better.  Please allocate something like
>     RIG_CHFLAG_LOCK or some such to set it with (even a bit field
>     will do if you want to go that far.  More specifically it is a
> "skip"
>     during "group scan" for any memory having this True.  Also,

So we'll have a bit field with RIG_CHFLAG_LOCK and RIG_CHFLAG_SKIP, ... 
other idea anyone?

>     nice would be a READONLY bit to prevent Hamlib from over-
>     writing certain memories (my group 9 is emergency/rescue and
>     is not to be touched!)

IMHO, a READONLY flag would live on the behalf of the user application, 
not Hamlib. Hamlib only tries to map existing feature of rigs.

> 4) tone_t tone; On my HT and the TS2K the CTCSS and Tone are
>     separate and set individually.  However, only one may be enabled,
>     but both may be read and will yield different values if set
> differently.

Hmm, looks like a problem of vocabulary. Here's what I see:

- on emitting side, tone in CTCSS "standard" -> ctcss_tone
- on receiving side, the CTCSS tone that opens the squelch -> ctcss_sql
- on emitting side, tone in DCS "standard" -> dcs_tone
- on receiving side, the DCS tone that opens the squelch -> dcs_sql

Besides 1750Hz tone burst (which is one shot), is there any other?

> 5) RIG_MTYPE_*:  As I understand it, the MTYPE describes available
>     and accessible memories for a rig.  The Setup is what I intended

To be more precise, MTYPE describes available and accessible memories 
by rig_get_channel/rig_get_channel and rig_get_mem/rig_set_mem.


>     Kenwood's "Programmable Memories".  There are 0-5 available
>     which a simple view would be to say the rig has its own
>     rig_save_channel() which saves 1) Main VFO's, 2) Sub VFO,
>     (as well as the memory pointers I believe) and 3)Both of the Menus
>     (A and B).  What I'm calling Menu (we use menus on the rig to
>     change them) you are calling conf.  

I'm not familiar with "Programmable Memories" concept. Anyway, I start
to grasp the idea thanks your explanations. To me, we will have to create
new calls in the API, something like rig_set_pm/rig_get_pm, or whatever
with better names. The reason is a channel_t cannot cover the need to 
describe the main's and sub VFO, and all parameters.
Actually, the pm struct looks like a set of channel_t.

In fact, rig_save_channel and rig_restore_channel only address the current VFO,
hence the channel_t parameter. So we need rig_set_pm/rig_get_pm and a pm_t
(with better names, feel free to suggest), and these functions would
save the entire state of the rig.

I take also a mental note to add the ability to channel_t to store the content 
of the "Menu" (see below).

>     VHF and repeater setups, whereas P.M. 0, MenuB is my HF
>     and simplex setups.  I haven't defined (my) uses of PM's 1-5
>     yet.  In rig.h I defined RIG_MTYPE_MENU for MenuA/B,
>     RIG_MTYPE_SETUP for P.M.'s 0-5.

To me, the "Menu" are nothing else than a huge list of parameters that Hamlib 
won't be able to account with RIG_LEVEL/RIG_PARM, among the number of rigs.
I have a better view now, and my proposal of rig_[sg]et_conf is not good.
But I was close. Let's create 2 new calls, rig_set_menu/rig_get_menu that 
works exactly like rig_set_conf/rig_get_conf (same data structures), 
and also a mean to browse the list of these "extra" non-standard parameters.
I'll make a proposal, and we'll see if it covers the needs of the
various rigs we have in the wild.

>     I added RIG_MTYPE_PCT for the Packet Cluster Tune feature.
>     These are very similar to Temporary Memory but are only set
>     by receiving P.C.T. data.  I have not found any simple, clean, or
>     easy way to read this since only the panel may select these. Thus,
>     I have recently found they are not accesible to software.  It is very
>     cool but the code for this isn't currently available.  I'm hoping to
>     upgrade my rig's embedded software and see if this is fixed, but I
>     doubt it.

Allow me to be a bit conservative on this one. The idea is good, but until 
we have the protocol specifications for such a memory, let's focus
on others first.


> 7)  Only two question have come up recently.  Why does
>     src/rig.c::rig_save_channel()/rig_restore_channel()  try to
>     handle the rig directly? [snip]

Okay, I see your point, and you're right. 
rig_save_channel/rig_restore_channel were more like internal use calls,
much in the idea of generic_save_channel/generic_restore_channel.
But let's make them evolve.
What about adding a vfo_t paramter (only for VFO usage, not memory) to 
rig_save_channel/rig_restore_channel, plus the ability to call the backend 
implementation if any, as you suggested?


Thanks very much for taking time to discuss,
we're making good progress on the API.

Cheers,
Stephane


PS: Have you done already the TS440? I have the caps done here, ready to commit.