hamlib-developer — hamlib developers forum

[Hamlib-developer] DCS, TONE, CTCSS, 1750; Who knows what else...

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

Robert,

On the U.S.A. version of the TS-2000 the 1750 Hz tone to
open the repeater is an option you may enable using the
menu.  Here in the Washington State I don't know of any
repeater that uses it.  Likewise, I don't know of any repeater
that uses DCS, or CTCSS.  All the repeaters I've accessed
use only "Tone" and fail to work if you use CTCSS or DCS.

To my limited knowledge, CTCSS is a Motorola proprietary
format for tone encoding.  (Don't quote me.)  As far as the
+/-600kHz offset for TX/RX when accessing the repeater
that I believe is identical in all systems.  The exact shift used
may vary somewhat but otherwise is the same.

When I select tone the ts2k displays 'T'.  When I select
CTCSS the rig displays "CT", and for DCS it displays
"DCS".  Only one may active at a time but always have
a value if read.

Thanks for your info on the 1750Hz.  I think I under-
stand now.  (Not really, but hopefully enough to kill
this issue.)

As far as the 1750Hz initiation/activation pulse I'm
beginning to suspect that it is an issue that is transparent to
the operator of any rig.  The only time it will  be an issue
if the rig is transported to another country.  Since this is
a menu item, let's make it go away by leaving it to the
menu unless somebody knows a reason to do otherwise.

The ts2k does "lock" a memory.  But when it is locked it
only "skips" it on scans but it can be deleted (as I found
out).

My reasoning for Hamlib performing the lock is that a
particular application may not understand or care about
my desire to have certain memories untouched.  Just like
the Linux kernel enforcing read-only file protection, I
feel Hamlib should perform more than just reading the
rig.  I don't want to take this too far, but I think we should
make provisions for it.  Also, it is not something that I am
expecting to be functional real soon.  Too much other
stuff going on...

73's

Dale

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.

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-----

[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] Re: gnuradio and Hamlib

[Matt E. <ma...@et...>]

>
> Well, not really. Hamlib can be seen as a utility library. It does not
> need to control the main loop. However, the user application linked
> against Hamlib may want to control it, e.g. grig or any GUI.
> That's why it would be nice if the gnuradio backend would not require
> to grab the main loop.
> And this is possible, provided gnuradio library is compiled with -DTHREAD.

....
> > > * questions: is gnuradio pthread-safe (I've seen -D_REENTRANT, what about
> > >   the code itself)? does gnuradio use pthread by itself in constructors?
> > >   It looks like yes (VrMultiTask), but it is working fine?
> >
> > some of it is thread-safe.  It should all be, eventually.
>
> Good.
> IMHO, we should use -DTHREAD for gnuradio, this would simply remove the
> need to call m->process(), no more main loop, and everyone is happy.

This is way more complex than you think.  Several Master's and PhD theses were
written on the scheduling and threading in GNURadio's progenitor,
Spectra/pspectra.  It was designed to be multithreaded, but certain operations
are single-threaded only, like the scheduler.  Only actual processing is
multithreaded.  Additionally, many of the processing blocks must run in order on
the data (like IIR filters), but not all (FIR filters do not suffer from this). 
At this point, the threading is disabled so there is one less thing to worry
about.

I guess the main point is that gnuradio is many things, to many people :)  We
don't want to change gnuradio internals to be able to use hamlib in one
gnuradio-based app.  Conversely, I wouldn't want you to change hamlib's
internals to support gnuradio.

> > I'd like to be able to [easily] have my gnuradio-based app receive commands
> > from, and return status to a hamlib-based frontend program, like GRig.  Basic
> > stuff like change frequency, volume, mode, etc.
>
> Alright, seems pretty feasible. Since you're going to be first "user",
> what is your FI source ? Is it the MC4020+microtune_eval_board ?

I'm not sure what FI stands for, but yes, I have the microtune and MC4020 combo.
 That would be a great demo.

> I understand that you will most probably not use only this source,
> and the backend will serve as a lab rat, but Hamlib needs at least
> to release some working skeleton. So which ever is fine. Then we'll
> be able to clone this "model" (i.e. source) to other models
> within the backend.
> If this terminology sounds obscure to you, don't worry, as soon as code
> will show up, this will make sense.

ok.  And yes, it does sound obscure to me :)

> Note: there's missing some checking against fftw existence in configure.in

Thanks.  i'll check into that.

> Okay, I'll try to put it another way.
> Imagine you have everything in binary form, the user application, the Hamlib
> (frontend + backend), the gnuradio library. Now, someone develops
> some code to support a new FI source. Does gnuradio has an abstraction
> interface (at binary level) to support this new FI by just dropping the new
> "lib" with recompiling everything.

[I'm assuming FI means some sort of IO device, like the MC4020 here...]  That's
a tough one.  I'm more of a DSP and comms guy, so I don't know the intricacies
of shared libraries, linking, plugins, etc.  I'm pretty sure it hasn't been done
yet, but I don't know how hard it would be.  There's not much motivation,
though, since the source code is free.

>
> Hmm. Please correct me if I'm wrong. IOW, you're not gonna use Grig right
> out-of-the-box. Your idea/need is to take Grig as a base, and hack it
> specifically for gnuradio extension, in such a way that may not work
> with a stock GRig. Right?
> (I'm a bit exagerating, but this is to better understand what interfaces
> will be needed in the backend).

My intention was that GRig could be used unmodified.  I'd like the user not to
be able to tell whether they are using a ft-1000 or gnuradio-based SDR.


Thanks again,
Matt

P.S.  If anyone is interested, I will be giving a talk and demos for gnuradio at
TAPR's DCC this year.  See http://www.tapr.org

[Hamlib-developer] Re: gnuradio and Hamlib

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

On Mon, Jul 01, 2002, Matt Ettus wrote:
> The main difficulty, as I see it, is that both environments want to control the
> main loop.

Well, not really. Hamlib can be seen as a utility library. It does not 
need to control the main loop. However, the user application linked
against Hamlib may want to control it, e.g. grig or any GUI.
That's why it would be nice if the gnuradio backend would not require 
to grab the main loop.
And this is possible, provided gnuradio library is compiled with -DTHREAD.

 
> > * question: what is your expection about gnuradio in hamlib?
> >   IOW what do you want to do (goal to achieve)?
> >   This will help in the design.
> 
> I'd like to be able to [easily] have my gnuradio-based app receive commands
> from, and return status to a hamlib-based frontend program, like GRig.  Basic
> stuff like change frequency, volume, mode, etc.

Alright, seems pretty feasible. Since you're going to be first "user",
what is your FI source ? Is it the MC4020+microtune_eval_board ?

I understand that you will most probably not use only this source, 
and the backend will serve as a lab rat, but Hamlib needs at least 
to release some working skeleton. So which ever is fine. Then we'll 
be able to clone this "model" (i.e. source) to other models
within the backend.  
If this terminology sounds obscure to you, don't worry, as soon as code 
will show up, this will make sense.

> > * Can you show me sample code for init (with no GUI support)
> >   is gnu/examples/fm_demod2_no_gui.cc a good start  ?
> 
> That is a good example of a program with no gui, but it requires hardware you
> don't have.  The best code to try without special hardware would be audio_scope,
> chirp_fft, and mixer.  All of those have gui code, though.

I've ran them, nice. The code is pretty simple, and I can see what's the
essential part. I should be able to make a initial draft out of it.

Note: there's missing some checking against fftw existence in configure.in

> > Note about gnu/examples/fm_demod2_no_gui.cc: the second FM demodulation may
> > appear as a SUB band controller?
> 
> Not sure of the question here.  The program can demodulate 2 different FM
> stations at the same time.

In high-end rigs, there can be two indepedant receivers, a MAIN controler 
and a SUB band controler. Hamlib has support for such rigs.
So the question is not really a question. gnuradio will fit nicely, 
cool :^)


> > * Am I wrong if I assume the output of gnuradio under Hamlib will always be
> >   a sound card?
> >   Or do we have to be output agnostic (and let gnuradio manage that)?
> 
> I wouldn't worry about the output.  Sometimes output will be audio, sometimes
> data, sometimes IF samples, etc.

okay, however this will have to be setup in Hamlib through some kind of
interface. And that's what I try to think forward.
Anyway, I see already how (set_conf).


> > * Would it be possible to hide the different FI sources to Hamlib ?
> >   I mean Is there an abstraction layer in gnuradio that hides these
> >   details, or does the application code has to know about the source?
> >   IOW, do you have to recompile gnuradio/app if you change source?
> 
> Not sure of the question.

Okay, I'll try to put it another way.
Imagine you have everything in binary form, the user application, the Hamlib
(frontend + backend), the gnuradio library. Now, someone develops
some code to support a new FI source. Does gnuradio has an abstraction
interface (at binary level) to support this new FI by just dropping the new 
"lib" with recompiling everything.

Actually, Hamlib is able to do this.

If you're still not sure about the question, don't worry. I'll find the
answer sooner or later by reading the code :)

Note: seeing  eb->set_RF_freq and carrier->setFrequency does not look
	promising :(

> > * questions: is gnuradio pthread-safe (I've seen -D_REENTRANT, what about
> >   the code itself)? does gnuradio use pthread by itself in constructors?
> >   It looks like yes (VrMultiTask), but it is working fine?
> 
> some of it is thread-safe.  It should all be, eventually.

Good.
IMHO, we should use -DTHREAD for gnuradio, this would simply remove the
need to call m->process(), no more main loop, and everyone is happy.


> > * Implementation hints 2:
> >   - gnuradio will be the backend name.
> >   - each different VrSource will be a "rig" model on their own, belonging to
> > this backend.
> 
> This is not really what I was thinking.  I was thinking more along the lines of
> I write a program which may use any number of sources, sinks, and other blocks. 
> In the main loop, between iterations, I can call methods on those blocks to
> change parameters, like frequency (see src/gnu/lib/gr/GrFreqXlatingFIRfilter.h
> for example).  Somehow, the control from the hamlib program needs to cause a
> call to these methods.

Hmm. Please correct me if I'm wrong. IOW, you're not gonna use Grig right 
out-of-the-box. Your idea/need is to take Grig as a base, and hack it
specifically for gnuradio extension, in such a way that may not work
with a stock GRig. Right?
(I'm a bit exagerating, but this is to better understand what interfaces
will be needed in the backend).


-- 
Stephane

[Hamlib-developer] ts2k branch

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

Dale,

I've created the branch, labelled 'branch_ts2k'.
You can go ahead and commit to this branch, and stop checking in the trunk.

To select the branch, change directory to the parent dir, and do
a "cvs checkout -r branch_ts2k hamlib". Be careful as the checkout may
overwrite some of your local files. Either make a backup first or rename
your hamlib directory to perform a fresh checkout.

The 'branch_ts2k' tag is a sticky tag that will automatically be present
in any commands issued under this checkout. So you can commit as usual,
the tag will be there. Read cvs man page for more information.
To resync with trunk, "cvs update -r HEAD <file>", and commit
eventually (to your branch).

*I* will take care of the ts2k merge to the trunk when times will look better.


Meanwhile, I'm analyzing the past commits, and I'm going to cleanup rig.h 
after you answered couple of questions.


* What is  "RIG_RPT_SHIFT_1750      // ts2000 E-type '='" ??
  To me, a shift is either + or -. 1750 sounds like the tone we're using in EU.
  Could it be an automatic shift? Anyway, it's misnamed.


* in  struct channel
  char lock;              /* added, I use this --kd7eni */
  => inefficient. This will be stored in the flags field.

  tone_t tone;            /* added --Dale kd7eni */
  tone_t tone_sql;        /* added --Dale kd7eni */
  => duplicates. These are actually ctcss_tone and ctcss_sql.

* About new RIG_MTYPE's. Tell me why are they needed. Do they store 
  any _frequency_ ?
       RIG_MTYPE_MENU,         /* menus A or B */
       RIG_MTYPE_SETUP,        /* bank 0-5; seems to save only menus */
       RIG_MTYPE_PCT,          /* Packet cluster buffered memories */

* ts2k_menu:
  This is to be implemented by ts2k_set_conf and ts2k_get_conf.
  Combo fields are a must...

* A quick glance at ts2000.c showed me this:

     # define TS2000_PARM_OP (RIG_PARM_EXCLUDE(RIG_PARM_BAT | RIG_PARM_TIME))
                              ^^^^^^^^^^^^^^^^

      This is a wrong approach. Can you imagine the mmelter adding a
      PARM after the ts2k is developped? This doesn't work. Be explicit
      in capabilities definition.



Thanks for your attention,
Stephane

[Hamlib-developer] Re: [ANN] Hamlib 1.1.3 released

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

On Mon, Jul 01, 2002, Riley Williams wrote:
> >	(fillods@charybde:tests)$ ./testloc IN98EC DM33DX
> >	Locator1: IN98EC
> >	Longitude: -0.666667, -1° 40' 0"
> >	Latitude:  48.083333, 48° 5' 0"
> >	Recoded: IN98QC
> >
> >	Locator2: DM33DX
> >	Longitude: -112.750000, -113° 45' 0"
> >	Latitude:  33.958333, 33° 57' 30"
> >	Recoded: DM33PX
> >
> >	Bearing: 8677.35km
> >	Azimuth: 51.782422, 51° 46' 56"
> >
> > Have you noticed ? The recoded locator is broken. 
> 
> Not by my calculation - the recoded locator perfectly matches the
> DMS coordinates given.
> 
> > AFAIR, dec2dms() in src/locator.c is broken, unless it is longlat2locator.
> 
> Looking at the above, there are two obvious bugs:
> 
>  1. dec2dms() is returning the wrong value when given a negative
>     input value. Both negative longitudes are out by exactly 1°,
>     but the positive latitudes are both correct.

okay, thank you for the analisys. Now it should be easy to fix.

> 
>  2. The value labelled "Bearing" is not a bearing, but a distance.

oops, sorry. Looks definitely like english is not my mother-tongue.
I'll have to fix also the comments in the code.
Thank you for that one too!


Cheers,
Stephane

[Hamlib-developer] Re: [Discuss-gnuradio] gnuradio and Hamlib

[Matt E. <ma...@et...>]

Just to clarify a little....

GNURadio is a framework, not really a particular application.  GNUradio is not
just about ham radio done in software.

My goal was to avoid reinventing the wheel (and to avoid writing GUI code...). 
What I was hoping to create was a way for an application to use both GNURadio
and Hamlib.  Hamlib would allow the reuse of user interface frontends, like
GRig.  GNURadio would perform the radio stuff.

The main difficulty, as I see it, is that both environments want to control the
main loop.

Stephane Fillod <f4...@fr...> said:
> Preliminary note: for me, everything that comes from gnuradio tar ball is
> "gnuradio". I don't know enough about it to distinguish between libs and
> stuff yet.

Stuff in the src/gnu/examples directory are basic apps which demonstrate
gnuradio capabilities. The rest is basically library.  Try to stay in the gnu
hierarchy.

> * question: what is your expection about gnuradio in hamlib?
>   IOW what do you want to do (goal to achieve)?
>   This will help in the design.

I'd like to be able to [easily] have my gnuradio-based app receive commands
from, and return status to a hamlib-based frontend program, like GRig.  Basic
stuff like change frequency, volume, mode, etc.

> * Can you show me sample code for init (with no GUI support)
>   is gnu/examples/fm_demod2_no_gui.cc a good start  ?

That is a good example of a program with no gui, but it requires hardware you
don't have.  The best code to try without special hardware would be audio_scope,
chirp_fft, and mixer.  All of those have gui code, though.

>   Something I can test myself would be great (FI source: file or sound
>   card).
>   All we need is objects initialization, source select: acquisition card or
>   sound card, set_freq/change_freq, set_mode_FM.
>   that's enough to start with.

I can try to make a simple example program.  The easiest would be something
llike the mixer program, without the gui.  A simple demo would be to have hamlib
change the frequency instead of the gui.

> Note about gnu/examples/fm_demod2_no_gui.cc: the second FM demodulation may
> appear as a SUB band controller?

Not sure of the question here.  The program can demodulate 2 different FM
stations at the same time.

>
> * Am I wrong if I assume the output of gnuradio under Hamlib will always be
>   a sound card?
>   Or do we have to be output agnostic (and let gnuradio manage that)?

I wouldn't worry about the output.  Sometimes output will be audio, sometimes
data, sometimes IF samples, etc.

> * as far as I understand, gnuradio is only a toolbox/framework. I mean,
>   there's no defined API to select say, FM mode.
>   You have to do it by yourself. So I guess this has to be done in the
>   gnuradio backend unless some third party library already exists?

Right.  GNURadio is just a framework and library for designing signal processing
applications.  Making a radio, in the conventional sense, out of it is only one
possible application.

> * Hamlib backend would be obviously limititative because of API, and no
>   access to fine-tune parameters (rig_set_conf may help though).
>   SDR will only be seen as regular radio (advantage: re-use existing apps)

That's all I'm really looking for -- setting frequencies, volumes, gains, modes,
etc.

> * Would it be possible to hide the different FI sources to Hamlib ?
>   I mean Is there an abstraction layer in gnuradio that hides these
>   details, or does the application code has to know about the source?
>   IOW, do you have to recompile gnuradio/app if you change source?

Not sure of the question.

> * questions: is gnuradio pthread-safe (I've seen -D_REENTRANT, what about
>   the code itself)? does gnuradio use pthread by itself in constructors?
>   It looks like yes (VrMultiTask), but it is working fine?

some of it is thread-safe.  It should all be, eventually.

> * Implementation hints 2:
>   - gnuradio will be the backend name.
>   - each different VrSource will be a "rig" model on their own, belonging to
> this backend.

This is not really what I was thinking.  I was thinking more along the lines of
I write a program which may use any number of sources, sinks, and other blocks. 
In the main loop, between iterations, I can call methods on those blocks to
change parameters, like frequency (see src/gnu/lib/gr/GrFreqXlatingFIRfilter.h
for example).  Somehow, the control from the hamlib program needs to cause a
call to these methods.

>     So far, can you help me list the available VrSource's?
> MC4020+microtune_eval_board
>     Is there already libaudiofile support (reading from file)?  Input from
> sound card?

The VrSource's are irrelevant to this.

> * Have you heard already about soundmodem?
>   This is a software modem by Thomas Sailor for use on AX.25 packet networks.
>   It can make use of MMX, sound input/output: OSS/Free under Linux,
>   /dev/audio under Solaris and DirectSound under Windows
>   http://www.baycom.org/~tom/ham/soundmodem/

Seen it. Very cool, but not nearly as big a scope as what we're doing.

> * note: is it possible to put your doxygen generated documentation on the web?

That would be a good idea.

> * cheap advice (easier to give than to do :)
>   get away from asm code: use some SIMD library (like libSIMD
>   http://libsimd.sf.net )

libSIMD is not at the point of usefulness yet -- not even close.  We have
implemented general C++ code for all functions.  MMX/SSE/3DNOW are only used in
specializations.  We're able to get a tap per cyle

Matt

[Hamlib-developer] Re: [ANN] Hamlib 1.1.3 released

[Riley W. <rh...@In...>]

Hi Stephane.

>>> Hamlib-1.1.3 has finally been released.
>>> Check it out at http://www.hamlib.org !

>> This announcement appears to be premature as the download link from
>> the page specified only shows 1.1.1 as being available. Can somebody
>> clarify that please?

> The web site has not been updated yet. However, tt seems some clever
> guys still managed to find the download page :)

Quite clearly, I'm not one of them...

>>> Note: locator calculation is not working right.

>> What exactly is the problem?

>=09(fillods@charybde:tests)$ ./testloc IN98EC DM33DX
>=09Locator1: IN98EC
>=09Longitude: -0.666667, -1=B0 40' 0"
>=09Latitude:  48.083333, 48=B0 5' 0"
>=09Recoded: IN98QC
>
>=09Locator2: DM33DX
>=09Longitude: -112.750000, -113=B0 45' 0"
>=09Latitude:  33.958333, 33=B0 57' 30"
>=09Recoded: DM33PX
>
>=09Bearing: 8677.35km
>=09Azimuth: 51.782422, 51=B0 46' 56"
>
> Have you noticed ? The recoded locator is broken.=20

Not by my calculation - the recoded locator perfectly matches the
DMS coordinates given.

> AFAIR, dec2dms() in src/locator.c is broken, unless it is longlat2locator=
=2E

Looking at the above, there are two obvious bugs:

 1. dec2dms() is returning the wrong value when given a negative
    input value. Both negative longitudes are out by exactly 1=B0,
    but the positive latitudes are both correct.

 2. The value labelled "Bearing" is not a bearing, but a distance.

> Sorry, I can't fix it right now, I have to look after some prolific
> cvs commiter, but feel free to send us a patch. You're more than
> welcome!

If you can advise where I can download the source from, I will...

Best wishes from Riley.

[Hamlib-developer] kenwood_transaction()

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

Stephane,

It should be easy enough to fix kenwood_transaction().  I only have
to call a common routine that uses it, plus a working version for
reference.  :)


See your private e-mail for details.

73's

Dale

[Hamlib-developer] gnuradio and Hamlib

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

Hi Matt and others,


Here are some thoughts thrown altogether about developping 
a gnuradio backend for Hamlib. For those not aware, Hamlib is a radio
control library, that would serve as a useful middle layer to let nice
GUI control gnuradio.

Preliminary note: for me, everything that comes from gnuradio tar ball is
"gnuradio". I don't know enough about it to distinguish between libs and
stuff yet.


* question: what is your expection about gnuradio in hamlib?
  IOW what do you want to do (goal to achieve)?
  This will help in the design.

* Can you show me sample code for init (with no GUI support)
  is gnu/examples/fm_demod2_no_gui.cc a good start  ?
  Something I can test myself would be great (FI source: file or sound
  card).
  All we need is objects initialization, source select: acquisition card or 
  sound card, set_freq/change_freq, set_mode_FM.
  that's enough to start with.
Note about gnu/examples/fm_demod2_no_gui.cc: the second FM demodulation may
appear as a SUB band controller?

* Am I wrong if I assume the output of gnuradio under Hamlib will always be
  a sound card?
  Or do we have to be output agnostic (and let gnuradio manage that)?

* as far as I understand, gnuradio is only a toolbox/framework. I mean,
  there's no defined API to select say, FM mode.
  You have to do it by yourself. So I guess this has to be done in the
  gnuradio backend unless some third party library already exists?

* Hamlib backend would be obviously limititative because of API, and no
  access to fine-tune parameters (rig_set_conf may help though). 
  SDR will only be seen as regular radio (advantage: re-use existing apps)

* Would it be possible to hide the different FI sources to Hamlib ? 
  I mean Is there an abstraction layer in gnuradio that hides these
  details, or does the application code has to know about the source?
  IOW, do you have to recompile gnuradio/app if you change source?

* questions: is gnuradio pthread-safe (I've seen -D_REENTRANT, what about
  the code itself)? does gnuradio use pthread by itself in constructors?
  It looks like yes (VrMultiTask), but it is working fine?

* Implementation hints:
  - compile gnuradio with -DTHREADS
  -  in gnuradio_init, do some object allocation, etc.
  - in gnuradio_open, do the chain&connect and VrMultiTask->start. -DTHREADS
renders ->process method useless
  - in gnuradio_close: VrMultiTask->stop
  -  in gnuradio_cleanup: delete objects ...

* Implementation hints 2:
  - gnuradio will be the backend name.
  - each different VrSource will be a "rig" model on their own, belonging to
this backend.
    So far, can you help me list the available VrSource's?
MC4020+microtune_eval_board
    Is there already libaudiofile support (reading from file)?  Input from
sound card?

* Have you heard already about soundmodem?
  This is a software modem by Thomas Sailor for use on AX.25 packet networks.
  It can make use of MMX, sound input/output: OSS/Free under Linux, 
  /dev/audio under Solaris and DirectSound under Windows
  http://www.baycom.org/~tom/ham/soundmodem/

* comment: gnuradio will raise some latency issues. Maybe nothing to do much
  with Hamlib, but just to keep it in mind when we encounter FIFO's, etc. 
  It may raise some design issues.

* note: is it possible to put your doxygen generated documentation on the web?

* cheap advice (easier to give than to do :)
  get away from asm code: use some SIMD library (like libSIMD
  http://libsimd.sf.net )


There's no hurry. We have time to devise something that works.


Cheers,
Stephane - F8CFE

Re: [Hamlib-developer] RIG_TRN

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

On Mon, Jun 24, 2002, Dale E. Edmons wrote:
[...]
> Here's how it looks to me:
>         1) somebody enables exception handling and the backend
>         sends the autoinformation on via myrig_set_trn().  (Is the
>         trn parameter like FILE, or RIG?)

Please, try reserving the "exception" word for C++. 
trn is an on/off parameter. Please see rig_set_trn() comments in src/rig.c

>         2) somewhere (I forget where) in rig.c signal exception
>         handling is enabled and the myrig_decode() is installed
>         as the handler.  (Is myrig_decode() supposed to read
>         and decode/parse all incoming commands from the
>         rig?  What is done with the information?)

yes. information is decoded in 3)

>         3) An exception occurs and myrig_decode() is called, which
>         calls myrig_transaction() to read the command. (?)  Now we
>         have the actual command that came from the rig and caused
>         an exception, we decode it to find out what command it it.
>         Now what do we do with it???

myrig_decode then calls the installed callback, if any.
see icom/icom.c: icom_decode_event() for an example

>         4) myrig_decode() returns and the code in rig.c handles all
>         of the messy cleanup etc.

what cleanup are you talking about?

> The big question is in 3).  Taking the most common example from
> the ts2k "sm...;" which gives us the current meter value.  This
> command comes it, we determine it is a particular "op code"
> "sm", it has two parmaters, Sub/Main, and Value.  These are
> easily parsed.  Where do we send the data or what do we do with it?

So far, there's no "meter_changed" event. There's only callbacks for 
freq,mode,vfo,ptt and dcd. Before adding any new ones, please tell me
what events do you want to track.

> Is a previous myrig_transaction() on the stack waiting for
> any response from the rig, which we provide?  I don't know of
> a place in RIG where current values are kept (except vfo_curr).

sorry, I don't understand your question.



Cheers,
Stephane

Re: [Hamlib-developer] rig.h

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

Dale,


Please, please, please, calm down,  you hear me Dale? calm down.
We're going to need to enforce some rules that were implicit.

* First one:  NEVER commit the rig.h file before discussing the patch
  first on the mailing list. And sending a mail without waiting for a
  reply, and commiting the next day is not what I call discussing.
  You have to realize that rig.h IS the API definition. Care should
  be taken to prevent binary compatibility breakage.

* you're free to commit ts2k, or a rig file, especially if you're the
  only one to use it. As soon as the file is shared, you must talk
  first with people in the team using it.

* right now, every one in the list has cvs commit access. It works as
  long as everyone behaves. Some other projects have only one commiter,
  and the developers have to send patches first on mailing list,
  having them reviewed by peers, before the commiter validate.
  This tend to improve quality, since this obliges the contributor to
  think twice before submitting.
  
* when sending contribution, please use unified patches (diff -u old.c
  new.c). It's a way lot easier to read than the whole file.

* don't commit broken stuff. If you know it's broken, work on it.
  We're not on a hurry, fix it, and come back when it's okay.

* If you can't help commiting, create your own branch. We'll merge
  when it's satifactory.


Flooding me won't help the situation, as It will delay further reviews.
And spending a sunday afternoon reading kilometers (if not miles) of
mails does not enjoy me that much. Sorry to be a bit crude, 
but you're not alone.


On Sun, Jun 30, 2002, Dale E. Edmons wrote:
> I added my rig.h to the CVS.  I tried removing the stuff that depended
> upon
> having changes in rig.h but ended up with a rig that just gave
> -RIG_EINVAL
> for just about everything.  Also, you said two things that stuck in my

So, if it's giving -RIG_EINVAL for about everything, don't commit!!
I told you we have to discuss first. god damn it. Do I have to remove
your commit priviledges?

> mind:
>         1) make sure I'm confident of the changes
>         2) CVS will allow us to back out the changes if required.

well, I wanted to be nice with you. I thought you understood that you
should not commit like a cowboy in a movie.

> The stuff I was doing to as work-arounds lowered my confidence in what
> the changes would do.  I have visited all of the backends and I'm almost
> certain there will be little if any effects from my changes.

You may be assuming too much. You should not modifying rig.h so easily.
I haven't reviewed your patches already because of all this blahblah,
and I should calm down myself because I want to stay polite with you,
and I do respect your work.
 
> Let me know if something actually breaks that I didn't expect.  I'll be
> working
> fast a furious to get the stuff I know about matching rig.h.

Can't your both computers even break ? or should I call your wife and
ask her to confiscate them?
Do you ever happen to spend some time on the air, or at least just listing
the bands?


> I'd appreciate it if you give me a chance to fix any problems that may
> arise
> and not just back out the new revisions.  The download stats reported by

Well, I won't back out the new revisions completely, but I'll have to cleanup
a lot. geeeez, I hate to do that kind of work. And yes, *I* will do the
cleanup myself, but asking you first before removing anything.

> SourceForge are fairly low,  you just a new release, and judging by
> the CVS dates there is not a lot of activity at the moment.

You're impossible.
I don't care about statistics, I don't care about activity.
Do you understand that?
All I care is end users, and people developing other software using Hamlib.

> There's not much more I can do to boost my confidence that things will
> work except commit to CVS and start working on kylix as soon as I get
> a little sleep.
> 
> Thank you in advance.  Now that I have things working (from my point
> of view) I can do more towards rewriting and bringing things in-line
> with
> the "standard" code.
> 

Dale, I value you work, really. But please, don't piss me off too much.
Play it nice, play with the team. 


Stephane

[Hamlib-developer] Re: [ANN] Hamlib 1.1.3 released

[Stephane F. <fi...@us...>]

Hi Riley,

On Thu, Jun 20, 2002, Riley Williams wrote:
> > Hamlib-1.1.3 has finally been released.
> > Check it out at http://www.hamlib.org !
> 
> This announcement appears to be premature as the download link from the
> page specified only shows 1.1.1 as being available. Can somebody clarify
> that please?

The web site has not been updated yet. However, tt seems some clever guys 
still managed to find the download page :)

> > Note: locator calculation is not working right.
> 
> What exactly is the problem?

	(fillods@charybde:tests)$ ./testloc IN98EC DM33DX
	Locator1: IN98EC
	Longitude: -0.666667, -1° 40' 0"
	Latitude:  48.083333, 48° 5' 0"
	Recoded: IN98QC
	
	Locator2: DM33DX
	Longitude: -112.750000, -113° 45' 0"
	Latitude:  33.958333, 33° 57' 30"
	Recoded: DM33PX
	
	Bearing: 8677.35km
	Azimuth: 51.782422, 51° 46' 56"


Have you noticed ? The recoded locator is broken. 
AFAIR, dec2dms() in src/locator.c is broken, unless it is longlat2locator.
Sorry, I can't fix it right now, I have to look after some prolific cvs 
commiter, but feel free to send us a patch. You're more than welcome!


Cheers,
Stephane

[Hamlib-developer] rig.h

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

Stephane,

I added my rig.h to the CVS.  I tried removing the stuff that depended
upon
having changes in rig.h but ended up with a rig that just gave
-RIG_EINVAL
for just about everything.  Also, you said two things that stuck in my
mind:
        1) make sure I'm confident of the changes
        2) CVS will allow us to back out the changes if required.

The stuff I was doing to as work-arounds lowered my confidence in what
the changes would do.  I have visited all of the backends and I'm almost

certain there will be little if any effects from my changes.

The kylix (and any file that duplicates rig.h) should be considered
broken.
I've only glanced at the kylix stuff.  Some of it may actually be
unaffected
but I need to go line-by-line and make sure it gets updated (and stuff
like
tcl, etc...).

Everything compiles after checking it back out (had to run automake on
the kenwood directory and check the new Makefile.*'s in).

The only test I could think to perform was rpcrig.   I tried that for
the first time
and it worked perfectly!  I only used 'v', 'F',  and'f' but for a quick
check it
was quite a thrill.  My two computers are connected via ethernet and the

rig on the serial port worked well.

Let me know if something actually breaks that I didn't expect.  I'll be
working
fast a furious to get the stuff I know about matching rig.h.

I'd appreciate it if you give me a chance to fix any problems that may
arise
and not just back out the new revisions.  The download stats reported by

SourceForge are fairly low,  you just a new release, and judging by
the CVS dates there is not a lot of activity at the moment.

There's not much more I can do to boost my confidence that things will
work except commit to CVS and start working on kylix as soon as I get
a little sleep.

Thank you in advance.  Now that I have things working (from my point
of view) I can do more towards rewriting and bringing things in-line
with
the "standard" code.

73's

Dale
kd7eni

RE: [Hamlib-developer] VFO proposal for peer review. (Initial d

[Chuck H. <n2...@am...>]

I'm slightly confused about having RIG_VFO_CURR being treated as an explicit
request to call rig_get_vfo().  With many of the radio protocols (Icom's CI-V
for example) there is a concept of a "current" vfo.  Many of the commands don't
have a place to specify the vfo (a set frequency command sets the frequency of
whatever the radio thinks is the "current" vfo).

I'm thinking a simple program that doesn't care about vfo's can just do
rig_set_freq, rig_get_freq and such with RIG_VFO_CURR.

Now I haven't taken a look at the TS-2000's protocol, if it doesn't have a
concept of a "current" vfo then you will have to handle this by either doing a
rig_get_vfo each time or remembering the "current" vfo from the previous
command.

>         RIG_VFO_CURR:   This should be treated as an explicit request
>                 to call rig_get_vfo() or mmelter_get_vfo() by any
>                 function (except rig_get_vfo()) that receives it.
>                 No function should ever output this value.  It
>                 may only be used for comparison or as a parameter
>                 to rig_get_vfo().
> 
>         RIG_VFO_VFO:    This is similar to RIG_VFO_CURR except that
>                 it eliminates special modes such as MEM, SCAN, and
>                 anything else.  Which ever *single* VFO may be
>                 considered current will be the target.  For example,
>                 rig_set_vfo(rig, RIG_VFO_VFO) will be considered
>                 an explicit request to turn off (or temporarily
>                 disable) MEM, SCAN, SAT, etc... and act the same
>                 as RIG_VFO_CURR after other potential targets are
>                 ruled out.  Functions should never output RIG_VFO_VFO.

[Hamlib-developer] VFO proposal for peer review. (Initial draft)

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

                        *******************
                        Hamlib Standard VFO
                        *******************


-----------------------------------------------------------------
        Author:         Dale E. Edmons, KD7ENI
        Date:           June 28, 2002
        Rev:            0.1
        Revision date:  June 28, 2002

        (C) Copyright 2002 by Dale E. Edmons.  All rights reserved.

        This document may be freely distributed with Hamlib.  For other
        uses contact the author at:     de...@us...

        Hamlib developers may modify this document at their discretion.
        No permission from the author is required.

-----------------------------------------------------------------

Introduction:
        So far Hamlib doesn't seem to have a standardized method of
using
        the vfo_t.  Almost anything will work as long as the backend is
        paying attention and does the right thing.  I've glanced at
*all*
        the backends and the mainline code searching specifically
        for instances of RIG_VFO.

Blah blah...:
        (I recognize that much effort is being made to treat the vfo_t
        in an appropriate manner.  It's just 0400 local and I didn't
        start out too well.  Later revisions will sound a little more
        pleasant.  This is currently first draft with zero revisions.
        FIXME: author tend to get long winded.)

        My work with the TS-2000 (I call it the ts2k) has shown me how
        the current structure needs improvement and restructuring.
        Here are some examples of inconsistant uses of this type:

                1) Some backends use RIG_VFO_VFO as a "target" whereas
                some use RIG_VFO_CURR.  (aor/aor.c, icom/icom.c,
kenwood/th.c
                src/misc.c) (I am vague on these two so feel free
                to correct me here and elsewhere.)

                2) Some code uses vfo_t in a bitmask manner (rig.h,
                tests/dumpcaps.c) while others use integer constants
                in certain instances (rig.h, kylix/hamlib_rigapi.pas)

                3) Most commonly, all that is used is some unique
constant
                to differentiate between cases in a switch statement or
                logical compare (==).

Example:
        With a rig and/or software that has many possible "targets" it
is
        difficult to tell what we're supposed to do in a function.  My
rig
        is quite simple to control.  However, it is not always simple to

        know what is being requested compared to the current status of
the
        rig.  For example, say the mmelter_set_freq() gets called as
follows:

                retval = mmelter_set_freq(rig, RIG_VFO_CURR, 147330000);

        The mmelter_set_freq() tries to do the right thing by calling
        mmelter_get_vfo() and receives RIG_VFO_C.  So, the right thing
to
        do is obviously continue as if parameter 2 had been RIG_VFO_C
        and change that freq to 147330000.  Not trusting the comm link
        we call:

                retval = mmelter_get_freq(rig, RIG_VFO_CURR, &vfo_tmp);

        and when we compare we find they don't match.  This contrived
        example is when some sort of scan mode is in effect.  Yes, we
        should check this and half a dozen other modes.  The fact is,
        that as we are currently using the vfo_t, each function must
        perform its own checks.  Even after mmelter_get_vfo() does its
        checks and determines the proper state, and passes on what the
        current vfo is, mmelter_set_freq() must check again, and the
        mmelter_get_freq(), must check it yet again!  You almost want
        to start creating global status variables!

Blah blah...:
                Even though this example is a bit contrived, it comes
        from doing development on my rig while the rig is active!
        Thus "contrived" is almost "simple".  It gets worse when the
        rig is right next to some Ham's armchair and he/she can just
        reach right over and start twisting dials any time he/she
        pleases (guilty).

                So, obviously, I'm either long winded and like to
        complain (I am a Ham) or I think I've got a solution I'd like
        to impose on everbody (I am a Ham).
        :)

Important stuff:
        Here begins my proposal.  Later revisions will begin around
        here.

        -------------------------------------------------------------

                The following RIG_VFO types are rather generic and
        somewhat undefined.  First, we establish what each is used
        for and how they are treated, and finally "when" they should
        *not* be used.  (All of this should be subjected to and
        revised by the developers list.)  (These are *as proposed*
        not *as used*.)

        RIG_VFO_CURR:   This should be treated as an explicit request
                to call rig_get_vfo() or mmelter_get_vfo() by any
                function (except rig_get_vfo()) that receives it.
                No function should ever output this value.  It
                may only be used for comparison or as a parameter
                to rig_get_vfo().

        RIG_VFO_VFO:    This is similar to RIG_VFO_CURR except that
                it eliminates special modes such as MEM, SCAN, and
                anything else.  Which ever *single* VFO may be
                considered current will be the target.  For example,
                rig_set_vfo(rig, RIG_VFO_VFO) will be considered
                an explicit request to turn off (or temporarily
                disable) MEM, SCAN, SAT, etc... and act the same
                as RIG_VFO_CURR after other potential targets are
                ruled out.  Functions should never output RIG_VFO_VFO.

        RIG_VFO_ALL:    This should never be used.  It is ambiguous
                at best.  (See RIG_VFO_MASK, RIG_VFO_VALID, and
                RIG_CTRL_MASK, for good uses of a similiar psuedo
                target.)

        RIG_VFO_NONE:   I'm unfamiliar with a use or need for this.
                Any feedback would be appreciated.

        The previous #define's are already in use in Hamlib code.
        If we decide to adopt the above usage, some code may require
        minor change.

        The following masks and definitions are new.  Actual running
        code is available (works for me) and seems to require few if
        any modifications to compile (runtime may vary depending upon
        which backend is used).

Definitions:

        Rig Major:      Upper segment [N:n+1] of an N-bit word
                        defined by the vfo_t type definiton.  This
                        field currently has three used bits: Main,
                        Sub, MEM.  These are consistant with the current

                        Hamlib code.

        VFO minor:      Lower segment [n:0] of an N-bit word
                        defined by the vfo_t type definition.  This
                        contains the bits which specify the actual VFO.
                        Currently, bits 0:1 are reserved, and three
                        additional bits for VFO_A to VFO_C are used.
                        (I have good reason for reserving the first
                        two bits.  They will be two bits which are
                        normally treated as a unit but may in many
                        instances be different.  Thus treating them
                        as an integer may at times be desireable and
                        much much simpler if these two bits are kept
                        available.)

#define's:

        RIG_SET_VFO(M,m):       This macro sets the rig Major (M) and
                the VFO minor bits in a vfo_t.  It is intended only for
                use within rig.h but other uses are allowed.  Remember
                that M is shifted n+1 times which could have undesirable

                effects.  This macro replaces RIG_CTRL_MODE(a,b) which
                is made obsolete in this proposal.  These two
definitions
                are incompatible and cannot coexist.  This macro is
                required for this proposal.

        RIG_MINOR:      Sets the shift count for rig Major field.

        RIG_VFO_TEST(v):        This macro is expected to be used any
                where a need to verify a valid vfo arises.  It is the
                only Logical macro defined in this proposal (programmers

                are encouraged to create their own aside from this one
                test).  It simply verifies that (v) has the same mask
                as RIG_VFO_VALID and is defined as:

                        ( ((v) & ~(RIG_VFO_VALID)) == 0 )

                Thus, you could perform the following error check:

                        if( RIG_VFO_TEST(vfo) )
                                return -RIG_EINVAL;

                to guarantee that a received vfo_t contains valid bits.

                This macro is expected to be available to Hamlib users
                and Hamlib Developers alike.

        RIG_VFO_VALID:  This is defined as (RIG_CTRL_MASK |
RIG_VFO_MASK)
                and is used for testing whether a valid value in
                a vfo_t has been received.  Any type of comparison
                or mask may use this value.  Functions should never
                output this value.  It tests both the rig Major and
                VFO minor simultaneously (more on this later).

        RIG_CTRL_MASK:  This is the rig Major portion of the previous
                mask.  It has all zero bits in the VFO minor field.
                It is used for comparison and masks but never output.

        RIG_VFO_MASK:   Same as previous two except is is only the
                VFO minor portion of the mask.  Also used only for
                masks and comparison but never output.

        RIG_VFOn:       As in the existing code, these are the actual
                VFO's availble as targets.  However, these macros
                are intended for use within rig.h and are not for
                general use (though not specifically prohibited,
                general use is highly discouraged).  These are
                strictly VFO minor portions of a vfo_t.

        RIG_CTRL_MAIN:  In dual transceivers (very common nowadays)
                this refers to the primary transceiver.  It is not
                required that this transceiver has any special
                characteristics only that is be distinguishable
                from RIG_CTRL_SUB.  They may in fact be identical
                and simple be left or right etc....  This is strictly
                a Rig Major portion of a vfo_t.

        RIG_CTRL_SUB:   This is the other transceiver.  It may have
                identical or completely unique features compared to
                RIG_CTRL_MAIN.  Generally, it may be considered to
                match RIG_CTRL_MAIN in several respects.  This is
                strictly a Rig Major portion of a vfo_t.

        RIG_CTRL_MEM:   This also is a part of of the Rig
                Major portion of a vfo_t.  It is not as strict as
                MAIN or SUB.  This will be further developed at a
                later date.

        There are are a number of definitions which are standard
        in Hamlib.  These are constants which combine both the upper
        and lower and fully specify a vfo_t:

        RIG_VFO_A:
        RIG_VFO_B:      These two are (RIG_CTRL_MAIN | RIG_VFOn) where
                n is 1 or 2.

        RIG_VFO_C:      Same same as previous except the definition is:
                  (RIG_CTRL_MAIN | RIG_VFOn).  Also n is either
                1 or 3.  I prefer 3 but 1 "should" be okay.

        RIG_VFO_MEM:    Directly access the rigs memories if this is
                available.  If the main or sub receivers have their
                own memory pointer (mine does) which may be accessed
                (mine can) then ORing RIG_CTRL_MAIN will change this
                from direct memory access to Main memory pointer.
                If Main has more than one such pointer use the VFOn
                to select which, otherwise no VFO minor is required
                but not specifically disallowed if used in a con-
                sistant manner (VFO1, then VFO2, etc...)  An example
                of multiple pointers would be regular memory, CALL
                channel memory, temporary memory etc....  (I have
                standard definitions I use and this will be discussed
                at a later date and added to this document.)

        RIG_VFO_CURR:   Defined as RIG_VFO_VALID.  This value is
                not guaranteed to be RIG_VFO_VALID but is guaranteed
                to be unique and distinguishable from other constants
                and "actual" vfo's.  Thus, it is not permitted to
                use RIG_VFO_VALID instead.

        RIG_VFO_NONE:   If kept for regular use in hamlib this will
                have the definition  initial(~RIG_VFO_VALID).  This
value
                is subject to change.

        RIG_VFO_VFO:    This is to be defined as (RIG_VFO_MASK) to
                be consistant with RIG_VFO_CURR.  Likewise, this is
                subject to change and using RIG_VFO_MASK to replace
                this value is strictly forbidden.  This value is
                guaranteed to be unique.  When testing valid, always
                use RIG_VFO_TEST().  This way, changes will not
                affect the program.  Using RIG_VFO_VALID is only
                correct for *real* VFO targets.  It may become
                necessary to use other bits above the rig Major
                to specify this type of constant.  This can easily
                be incorporated into RIG_VFO_TEST but can never
                be guaranteed to work with RIG_VFO_VALID.  (As a
                specific example: if we later define RIG_MAJOR to
                be the last bit in the major a third field will
                be available for other constants.  RIG_VFO_VALID
                is (RIG_CTRL_MASK | RIG_VFO_MASK) and will cause
                these "reserved field" bits to be nulled.  However,
                RIG_VFO_TEST may be extended to include the third
                or more new fields where RIG_VFO_VALID never can.)

        RIG_VFO_MAIN:   defined as RIG_CTRL_MAIN.  These terms are
                synonomous.  RIG_VFO_MAIN is is less obvious.  Use
                RIG_CTRL_MAIN for new code.

        RIG_VFO_SUB:    same as RIG_VFO_MAIN except it is the sub
                receiver.

        This completes this initial draft.  My primary concern now
        is making this available quickly for peer review.  Later
        drafts will shorten the length (I hope) and add any changes
        that are suggested.

        I ask for two types of response: 1) quick initial reaction
        and 2) specific detailed or well thought responses.  Unless
        otherwise noted (e.g. by Stephane) you may post responses
        to the developers list.  You may also e-mail me directly
        with your response.

        The following last item is my much revised exerpt from rig.h
        which I wish to check into CVS.  It is very recent (about
        2+1/2 days old.  Compare it with your own copy in:

                include/hamlib/rig.h

        and post any comments.  (Thank you all in advance.)
        (I've already noticed the difference in RIG_VFO_TEST(v),
        please find more!)

start rig.h exerpt
-----------------------------------------------------------------

/*
 * I've cleaned up the VFO definition to make it easier to change
 * when the MoonMelter is finally released.  Essentially, I've
 * done nothing.        --Dale  :)
 */

/*
 * Upper segment: "rig Major"
 * Lower segment: "VFO minor"
 *
 *      MSB                                              LSB
 *      N                       n+1 n                         0
 *      +-+-+-+-+-+-+-+-+-+-+-+
 *      |                               |                             |
 *                   Rig                         VFO
 *               Major                      minor
 */
typedef unsigned int vfo_t;

#define BIT(a)  ( ((vfo_t) 1) << (a))
//#define BIT(a)        (1L << (a))

#define RIG_MINOR       4
/* M=Major, m=minor */
#define RIG_SET_VFO(M,m)        ((vfo_t) ( ((M) << (RIG_MINOR+1)) | (m)
))
/* Note: prior definition exibited exponential growth in bit count */

#define RIG_VFO_RESERVED        RIG_SET_VFO(0, BIT(0))
#define RIG_VFO_RESERVED2       RIG_SET_VFO(0, BIT(1))

/* VFO Minor */
#define RIG_VFO1        RIG_SET_VFO(0, BIT(2))
#define RIG_VFO2        RIG_SET_VFO(0, BIT(3))
#define RIG_VFO3        RIG_SET_VFO(0, BIT(4))
/*                                         |
 * RIG_MINOR = n :== MAX >-----------------'
 */

/* Rig Major */
#define RIG_CTRL_MAIN   RIG_SET_VFO(BIT(0), 0)
#define RIG_CTRL_SUB    RIG_SET_VFO(BIT(1), 0)
#define RIG_CTRL_MEM    RIG_SET_VFO(BIT(2), 0)

/* Standard VFO's for common use */
#define RIG_VFO_A       (RIG_CTRL_MAIN | RIG_VFO1)
#define RIG_VFO_B       (RIG_CTRL_MAIN | RIG_VFO2)
#define RIG_VFO_C       (RIG_CTRL_SUB  | RIG_VFO1)
#define RIG_VFO_MEM     RIG_CTRL_MEM
/* VFOC should be VFO3 because ambiguities may arise someday */

/* VFO stuff that may be handy. */
#define RIG_VFO_MASK    (RIG_VFO1 | RIG_VFO2 | RIG_VFO3)
#define RIG_CTRL_MASK   (RIG_CTRL_MAIN | RIG_CTRL_SUB | RIG_CTRL_MEM)
#define RIG_VFO_VALID   (RIG_CTRL_MASK | RIG_VFO_MASK)
#define RIG_VFO_TEST(v) (((v) & RIG_VFO_VALID) != 0)

/* The following are for compatibility with existing code! */
#define RIG_VFO_NONE    (~RIG_VFO_VALID)
#define RIG_VFO_CURR    RIG_SET_VFO(0,0)
#define RIG_VFO_ALL     RIG_VFO_MASK
#define RIG_VFO_MAIN    RIG_CTRL_MAIN
#define RIG_VFO_SUB     RIG_CTRL_SUB
#define RIG_VFO_VFO     (RIG_VFO_VALID & ~RIG_VFO_MEM)
/*
 * Ahhh.  Now I can live happy and die free! --Dale
 */

----------------------------------------------------------
end rig.h exerpt

[Hamlib-developer] dejagnu

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

Stephane,

testing:
I'm looking into using expect simply because I've seen it work and have
had problems trying to get dejagnu installed.  Time is starting to
become
a problem but after I get the ts2k stuff working in CVS I plan on
attempting
to automate testing.  My attention span drops to about 2min after about
the second or third command I type into rigctl.  After that is gets real

short!  Hi.  After that, my priority is saving/restoring memories, and
then
the same with initial setup (my own util works on the ts2k, if you
remember
our first discussion).  This will require some type of setup file
(extended
.hamlibrc) which should be perfect for setting up the actual .hamlibrc.
(Maybe that's too ambitious.  A working ts2k.c would be just fine!)

vfo_t:
I'm writing a doc (text) that explains and expounds and runs on about
vfo_t.  Its 0900UTC (0200 local) and I've just finished searching all
the hamlib directories.  I've rewitten rig.h yet again (an found kylix/
hamlib_rigapi.pas much to my dismay).  This time it only addresses
what I feel are bugs and/or inconsistancies.  As a side effect it paves
the way for extended vfo_t operations when we are all running those
MoonMelters with 101 VFO's and 1001 scanning modes.  :)
(Or a barebones ts2000.)

I think you'll find it to be quite acceptable and look forward to
sending
it to the list.  I'll just send the essential RIG_VFO stuff.  (If my
wife
don't chop my laptop up before I get it done! Hi.)

Gotta go.

73's

Dale

Re: [Hamlib-developer] c++

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

Quoting "Dale E. Edmons" <de...@w-...>:
> New rigctl.c should support comments now by prefixing '#' or ';'
> and are terminated with '\r' or '\n'.  Hopefully, my first check-
> in worked.  :)

good stuff
Can you share with us your "testing" script?
Are you using expect or any test harness (dejagnu?) to automate work?

> Can we write backends in c++ or is only c supported?

The Hamlib frontend API and the backend interface _must_ be in C.
Mainly because on some platforms, the C++ ABI is a pain in the a..
And since we want portability, there was no choice.

Now, if someone is developing a backend he/she does not intend to distribute,
he/she can write in c++, as long as the backend interface remain in C
(don't forget the extern "C" ).

Cheers
Stephane

[Hamlib-developer] c++

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

Hi all,

New rigctl.c should support comments now by prefixing '#' or ';'
and are terminated with '\r' or '\n'.  Hopefully, my first check-
in worked.  :)

Can we write backends in c++ or is only c supported?

Dale

[Hamlib-developer] developers list

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

Stephane,

Thanks!  I should have fetched my e-mail before I sent you my last.
I've already fetched the new CVS, now I'll have to reinstall ssh, etc...

I ran into the problem you mentioned but didn't do the math.  I just
changed the code.  I created a Major and Minor portion for the
vfo.  Main/Sub are in the Major, VFO_A, etc is in the minor.  I think
it'll support everybody with only a little added complexity.  This is
almost exactly how you had it set up anyway.

Once I get access, I'll start checking in my stuff bit by bit.  I'll
rewrite
to match the current hamlib.  I'll either see the light or find a way
to convince you otherwise.  :)

Yes, I agree that one must be careful in certain areas.  I've checked
what I could with my own stuff, but the unexpected is what always
gets you.

I'll be happy to do something with rpcrig if I can get it going.  It's
at
least as interesting as doing the ts2k stuff.  Cool factor is always
high
on the list.  If it works, I'll definitely be willing to write a
rpcrig-howto!

73's

Dale
kd7eni

Re: [Hamlib-developer] Memory Save/Restore (anyrig to anyrig)

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

On Thu, Jun 20, 2002, Dale E. Edmons wrote:
> I've got a version of the hamlib-1.1.3 where I've got the
> rig_get_channel()
> working (partially).  Hamlib needs very little added to support this.

Very good! If only the "memory name" was accessible on my IC706MkIIG :(

> We may need: rig_read_channel(RIG *rig, FILE * file, channel_t chan),
> rig_write_channel().

Well, to my mind, these 2 calls do not belong to the Hamlib library.

> Alternatively, a program like rigctl can just use the existing stuff and
> read and/or write channels as desired them write them in some generic
> file format.

rigctl looks like the right place. Then, anyone would be free to
copy/paste the code to make a nice memory editor GUI.

> The scanner and parser should be easy enough depending on how
> it's implemented.  As you mentioned, XML may make it very
> easy and standard (I need to learn more about XML).

There must be some libxml-dev around. Any takers?


73's
Stephane

Re: [Hamlib-developer] Volunteer tester for AOR8200

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

Hi Mike!

On Mon, Jun 24, 2002, Mike Leary wrote:
> I have just received a new AOR8200 and I am also in the process of
> installing Linux on my PC.  I am also in the middle of getting my masters in
> computer science and would love to test the hamlib software for the AOR8200.
> I also have an ICOM R-7100 and R-71A.  All radios have been previously
> controlled by computer.
> 
> Looking forward to joining your team, if you want me.

Sure! we want you in the team!

Hamlib already knows about the AOR8200 and the IC R-7000. Are there
many differencies between the R-7000 and the R-7100 ?
The R-71A should be no big deal to add in.
Once you're set up with your now Linux box, grab the hamlib-1.1.3 tar ball
and read the README.betatester file. If you're stuck, feel free to ask
on the list. Note: the AR8200 support in Hamlib has never been fully tested,
so your feed back is more than welcome!

Thanks,
Stephane

VFO and split mode, was Re: [Hamlib-developer] CVS checkin

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

On Mon, Jun 17, 2002, Dale E. Edmons wrote:
> I'd like very much if you'd test out my changes if you'd like.  However,
> since
> I've made some pretty extensive changes to things like RIG_VFO_* in
> rig.h,
> rig.c, and rigctl, I'd like the changes to be reviewed before being
> checked
> directly into CVS.

Dale, I'll add you in the developer list tomorrow. Unless you're really
sure of your code, don't commit too quickly, especially if it has an
impact on other rigs. Anything that touch rig.h or the frontend has to
be discussed beforehand. But don't worry, since we're using cvs,
it's safe for everyone.

> The gist of the non-ts2k changes are the addition of numerous VFO types.
> 
> They are as follows:
>            RIG_VFO_AB       // split, RX=VFOA on Main receiver
>            RIG_VFO_BA      // split, RX=VFOB on Main receiver
>            RIG_VFO_MEM_A    // Memory on Main receiver
>            RIG_VFO_MEM_C   // Memory on Sub receiver
>            RIG_VFO_CALL_A    // Call channel on Main
>            RIG_VFO_CALL_C    // Call channel on Sub
> I plan on adding the following:
>            RIG_VFO_A_MEM    // split, RX=VFOA, TX=MEMA
>            RIG_VFO_B_MEM    // split, RX=VFOB, TX=MEMA
> but it requires a little more programming.  (Plus any more that I can.)

I do not agree with all these RIG_VFO definitions.
This is true I never operated a rig as complex as the TS-2000, so I'd
like you to explain me a little. Please keep in mind Hamlib has to
support many many kind of rigs, and code has to be generic.

> The point of these changes is to make it obvious what the exact
> state of the rig is.  I can now put the TS-2000 into any of the above
> states (first six) plus the normal VFOA, VFOB, VFOC.  Just making
> VFOC was a chore without the changes.

In the current Hamlib's design, the rig_set_vfo is a kind of
rig_set_focus. If you want to operate in split mode, then use
rig_set_split. It's better to break down complexity in small pieces.
I'll do the math for you: 3 VFOs plus memories and call channel on each.
This is applicable for main and sub, which gives 5^2 = 25 RIG_VFO
definitions! And now imagine if the new model "Moon melter DSP8500" has
4 VFOs!

Okay, I'm exagerating a bit, and I don't know all the possible combinations
of the TS-2000, like is it possible to mix main and sub in split. 
But I hope you got my point.

In other words, tell me what are the limitations of the current API,
and we'll see how to fix/expand it to cover the TS-2000 and probably
others.

Looks like rig_set_split will have to be reworked...

> A word of caution:  Adding these extra vfo's is really cool in what
> you can do, but right now my _get_freq() doesn't work by default.
> If this is expected behaviour you could say its broken.  The _get_freq()
> now has to do commands to specifically read these other vfo's.
> In actuality, it is better since I won't receive VFOA when the rig
> is on the sub receiver, or MEMA when MEMC is selected.  Other
> developers may have solved this differently or better.

rig_get_freq		is for RX freq
rig_get_split_freq	is for TX freq

The vfo arg gives the ability to query a vfo different than the current
active one. Very few rigs can do this. So most applications use
RIG_VFO_CURR and the frontend emulate the right behaviour otherwise.

 

I'll give a look at your code this week and let you know how it suits to
the Hamlib frontend interface.

73's 
Stephane