hamlib-developer — hamlib developers forum

[Hamlib-developer] Re: Packaging Hamlib for Debian

[Jaime R. <ja...@kd...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Martes, 1 de Abril de 2003 19:22, Joop Stakenborg escribi=F3:

Don't try to install my hamlib package yet... as it does not installs any l=
ib=20
O:-)

=2D --=20
Un saludo,
	Jaime Robles
	ja...@kd...
	Coordinador KDE-es - KDE Spanish Translation Team
	http://www.kde.org/es  - http://es.i18n.kde.org
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+icuvER46oL+8yYURAvuLAJ96smXgx6xqbhvkzjaRRXwd2NSrxwCePBZr
wf/SErT0nwzFoF4NKqDDLQk=3D
=3DmGz2
=2D----END PGP SIGNATURE-----

[Hamlib-developer] Re: Packaging Hamlib for Debian

[Jaime R. <ja...@kd...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Martes, 1 de Abril de 2003 19:22, Joop Stakenborg escribi=F3:

> Use "./configure --without-cxx-binding". Hamlib-1.1.3 C++ bindings won't
> compile with gcc-3.2. So you can't build the C++ classes.
That's what i've done.
You download and test hamlib-1.1.3 for Debian unstable from:
http://jaime.robles.nu/debian/hamlib

I cannot try it as i don't use any hamlib hardware yet.... i want to build =
an=20
interface for my brand new IC-7400 :-)''
=2D --=20
Un saludo,
	Jaime Robles
	ja...@kd...
	Coordinador KDE-es - KDE Spanish Translation Team
	http://www.kde.org/es  - http://es.i18n.kde.org
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+icnmER46oL+8yYURAlL3AJ9XyC5BuKKbnbGxrOtQzo61QvbnSQCfVQ9D
VS2SJ9JpFYOJdq2p+UB5UAM=3D
=3DPp3N
=2D----END PGP SIGNATURE-----

[Hamlib-developer] Re: Packaging Hamlib for Debian

[Joop S. <pa...@de...>]

Jaime Robles wrote:

>Hello all,
>Some days ago i wrote an email to Terry, who is the Debian packager of HamLib 
>asking for tha package of the new version and i have not received any answer.
>
>As i am packaging KTrack i need hamlib 1.1.3 packaged so i have started to 
>package hamlib-1.1.3 too.
>I am not trying to "steal" the hamlib package, just packaging for myself as i 
>understand it's Terry's package.
>
>Ok, once i have done my disclaimer i would like to make a question as in the 
>packaging process i got this message in the compilation.
>It may be caused due to  the new gcc-3.2 as i have not any problem compiling 
>in Debian testing/stable and the problems are in a unstable (with gcc3.2).
>Any idea?
>
>Thanks!
>====================================================
>In file included from /usr/include/c++/3.2/backward/iostream.h:31,
>                 from ../include/hamlib/rigclass.h:225,
>                 from rigclass.cc:37:
>/usr/include/c++/3.2/backward/backward_warning.h:32:2: warning: #warning This 
>file includes at least one deprecated or antiquated header. Please consider 
>using one of the 32 headers found in section 17.4.1.2 of the C++ standard. 
>Examples include substituting the <X> header for the <X.h> header for C++ 
>includes, or <sstream> instead of the deprecated header <strstream.h>. To 
>disable this warning use -Wno-deprecated.
>rigclass.cc:366: default argument given for parameter 2 of `void
>   Rig::setRptrShift(rptr_shift_e, int = 0)'
>../include/hamlib/rigclass.h:99: after previous specification in `void
>   Rig::setRptrShift(rptr_shift_e, int = 0)'
>rigclass.cc:371: default argument given for parameter 1 of `rptr_shift_t
>   Rig::getRptrShift(int = 0)'
>../include/hamlib/rigclass.h:100: after previous specification in 
>`rptr_shift_t
>   Rig::getRptrShift(int = 0)'
>rigclass.cc:380: default argument given for parameter 2 of `void
>   Rig::setRptrOffs(long int, int = 0)'
>../include/hamlib/rigclass.h:101: after previous specification in `void
>   Rig::setRptrOffs(long int, int = 0)'
>rigclass.cc:385: default argument given for parameter 1 of `shortfreq_t
>   Rig::getRptrOffs(int = 0)'
>../include/hamlib/rigclass.h:102: after previous specification in `shortfreq_t
>   Rig::getRptrOffs(int = 0)'
>rigclass.cc:394: default argument given for parameter 2 of `void
>   Rig::setTs(long int, int = 0)'
>../include/hamlib/rigclass.h:103: after previous specification in `void
>   Rig::setTs(long int, int = 0)'
>rigclass.cc:399: default argument given for parameter 1 of `shortfreq_t
>   Rig::getTs(int = 0)'
>../include/hamlib/rigclass.h:104: after previous specification in `shortfreq_t
>   Rig::getTs(int = 0)'
>rigclass.cc:408: default argument given for parameter 2 of `void
>   Rig::setCTCSS(unsigned int, int = 0)'
>../include/hamlib/rigclass.h:106: after previous specification in `void
>   Rig::setCTCSS(unsigned int, int = 0)'
>rigclass.cc:413: default argument given for parameter 1 of `tone_t
>   Rig::getCTCSS(int = 0)'
>../include/hamlib/rigclass.h:107: after previous specification in `tone_t
>   Rig::getCTCSS(int = 0)'
>rigclass.cc:422: default argument given for parameter 2 of `void
>   Rig::setDCS(unsigned int, int = 0)'
>../include/hamlib/rigclass.h:108: after previous specification in `void
>   Rig::setDCS(unsigned int, int = 0)'
>rigclass.cc:427: default argument given for parameter 1 of `tone_t
>   Rig::getDCS(int = 0)'
>../include/hamlib/rigclass.h:109: after previous specification in `tone_t
>   Rig::getDCS(int = 0)'
>rigclass.cc:436: default argument given for parameter 2 of `void
>   Rig::setCTCSSsql(unsigned int, int = 0)'
>../include/hamlib/rigclass.h:111: after previous specification in `void
>   Rig::setCTCSSsql(unsigned int, int = 0)'
>rigclass.cc:441: default argument given for parameter 1 of `tone_t
>   Rig::getCTCSSsql(int = 0)'
>../include/hamlib/rigclass.h:112: after previous specification in `tone_t
>   Rig::getCTCSSsql(int = 0)'
>rigclass.cc:450: default argument given for parameter 2 of `void
>   Rig::setDCSsql(unsigned int, int = 0)'
>../include/hamlib/rigclass.h:113: after previous specification in `void
>   Rig::setDCSsql(unsigned int, int = 0)'
>rigclass.cc:455: default argument given for parameter 1 of `tone_t
>   Rig::getDCSsql(int = 0)'
>../include/hamlib/rigclass.h:114: after previous specification in `tone_t
>   Rig::getDCSsql(int = 0)'
>rigclass.cc:465: default argument given for parameter 3 of `void
>   Rig::setFunc(long long unsigned int, bool, int = 0)'
>../include/hamlib/rigclass.h:83: after previous specification in `void
>   Rig::setFunc(long long unsigned int, bool, int = 0)'
>rigclass.cc:470: default argument given for parameter 2 of `bool
>   Rig::getFunc(long long unsigned int, int = 0)'
>../include/hamlib/rigclass.h:84: after previous specification in `bool
>   Rig::getFunc(long long unsigned int, int = 0)'
>rigclass.cc:619: default argument given for parameter 2 of `void
>   Rig::setBank(int, int = 0)'
>../include/hamlib/rigclass.h:121: after previous specification in `void
>   Rig::setBank(int, int = 0)'
>rigclass.cc:624: default argument given for parameter 2 of `void
>   Rig::setMem(int, int = 0)'
>../include/hamlib/rigclass.h:122: after previous specification in `void
>   Rig::setMem(int, int = 0)'
>rigclass.cc:629: default argument given for parameter 1 of `int 
>Rig::getMem(int
>   = 0)'
>../include/hamlib/rigclass.h:123: after previous specification in `int
>   Rig::getMem(int = 0)'
>make[1]: *** [rigclass.lo] Error 1
>make[1]: Leaving directory `/paquetes/hamlib-1.1.3/c++'
>make: *** [all-recursive] Error 1
>kha:/paquetes/hamlib-1.1.3#
>====================================================
>

Use "./configure --without-cxx-binding". Hamlib-1.1.3 C++ bindings won't 
compile with gcc-3.2. So you can't build the C++ classes.

Hamlib-1.1.4 won't have this problem, it will arrive in a couple of 
weeks. So it might be worthwile waiting for the new release.

Terry, can we do an effort to resolve the current issues around the 
hamlib debian package? I am hereby offering my help. Maybe we can work 
out something like a dual maintainership, if this is OK with you. This 
way we can keep hamlib updated when you can't find the time to work on it.

>- -- 
>Un saludo,
>	Jaime Robles
>	ja...@kd...
>	Coordinador KDE-es - KDE Spanish Translation Team
>	http://www.kde.org/es  - http://es.i18n.kde.org
>  
>

Regards,
Joop

[Hamlib-developer] Packaging Hamlib for Debian

[Jaime R. <ja...@kd...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello all,
Some days ago i wrote an email to Terry, who is the Debian packager of HamL=
ib=20
asking for tha package of the new version and i have not received any answe=
r.

As i am packaging KTrack i need hamlib 1.1.3 packaged so i have started to=
=20
package hamlib-1.1.3 too.
I am not trying to "steal" the hamlib package, just packaging for myself as=
 i=20
understand it's Terry's package.

Ok, once i have done my disclaimer i would like to make a question as in th=
e=20
packaging process i got this message in the compilation.
It may be caused due to  the new gcc-3.2 as i have not any problem compilin=
g=20
in Debian testing/stable and the problems are in a unstable (with gcc3.2).
Any idea?

Thanks!
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
In file included from /usr/include/c++/3.2/backward/iostream.h:31,
                 from ../include/hamlib/rigclass.h:225,
                 from rigclass.cc:37:
/usr/include/c++/3.2/backward/backward_warning.h:32:2: warning: #warning Th=
is=20
file includes at least one deprecated or antiquated header. Please consider=
=20
using one of the 32 headers found in section 17.4.1.2 of the C++ standard.=
=20
Examples include substituting the <X> header for the <X.h> header for C++=20
includes, or <sstream> instead of the deprecated header <strstream.h>. To=20
disable this warning use -Wno-deprecated.
rigclass.cc:366: default argument given for parameter 2 of `void
   Rig::setRptrShift(rptr_shift_e, int =3D 0)'
=2E./include/hamlib/rigclass.h:99: after previous specification in `void
   Rig::setRptrShift(rptr_shift_e, int =3D 0)'
rigclass.cc:371: default argument given for parameter 1 of `rptr_shift_t
   Rig::getRptrShift(int =3D 0)'
=2E./include/hamlib/rigclass.h:100: after previous specification in=20
`rptr_shift_t
   Rig::getRptrShift(int =3D 0)'
rigclass.cc:380: default argument given for parameter 2 of `void
   Rig::setRptrOffs(long int, int =3D 0)'
=2E./include/hamlib/rigclass.h:101: after previous specification in `void
   Rig::setRptrOffs(long int, int =3D 0)'
rigclass.cc:385: default argument given for parameter 1 of `shortfreq_t
   Rig::getRptrOffs(int =3D 0)'
=2E./include/hamlib/rigclass.h:102: after previous specification in `shortf=
req_t
   Rig::getRptrOffs(int =3D 0)'
rigclass.cc:394: default argument given for parameter 2 of `void
   Rig::setTs(long int, int =3D 0)'
=2E./include/hamlib/rigclass.h:103: after previous specification in `void
   Rig::setTs(long int, int =3D 0)'
rigclass.cc:399: default argument given for parameter 1 of `shortfreq_t
   Rig::getTs(int =3D 0)'
=2E./include/hamlib/rigclass.h:104: after previous specification in `shortf=
req_t
   Rig::getTs(int =3D 0)'
rigclass.cc:408: default argument given for parameter 2 of `void
   Rig::setCTCSS(unsigned int, int =3D 0)'
=2E./include/hamlib/rigclass.h:106: after previous specification in `void
   Rig::setCTCSS(unsigned int, int =3D 0)'
rigclass.cc:413: default argument given for parameter 1 of `tone_t
   Rig::getCTCSS(int =3D 0)'
=2E./include/hamlib/rigclass.h:107: after previous specification in `tone_t
   Rig::getCTCSS(int =3D 0)'
rigclass.cc:422: default argument given for parameter 2 of `void
   Rig::setDCS(unsigned int, int =3D 0)'
=2E./include/hamlib/rigclass.h:108: after previous specification in `void
   Rig::setDCS(unsigned int, int =3D 0)'
rigclass.cc:427: default argument given for parameter 1 of `tone_t
   Rig::getDCS(int =3D 0)'
=2E./include/hamlib/rigclass.h:109: after previous specification in `tone_t
   Rig::getDCS(int =3D 0)'
rigclass.cc:436: default argument given for parameter 2 of `void
   Rig::setCTCSSsql(unsigned int, int =3D 0)'
=2E./include/hamlib/rigclass.h:111: after previous specification in `void
   Rig::setCTCSSsql(unsigned int, int =3D 0)'
rigclass.cc:441: default argument given for parameter 1 of `tone_t
   Rig::getCTCSSsql(int =3D 0)'
=2E./include/hamlib/rigclass.h:112: after previous specification in `tone_t
   Rig::getCTCSSsql(int =3D 0)'
rigclass.cc:450: default argument given for parameter 2 of `void
   Rig::setDCSsql(unsigned int, int =3D 0)'
=2E./include/hamlib/rigclass.h:113: after previous specification in `void
   Rig::setDCSsql(unsigned int, int =3D 0)'
rigclass.cc:455: default argument given for parameter 1 of `tone_t
   Rig::getDCSsql(int =3D 0)'
=2E./include/hamlib/rigclass.h:114: after previous specification in `tone_t
   Rig::getDCSsql(int =3D 0)'
rigclass.cc:465: default argument given for parameter 3 of `void
   Rig::setFunc(long long unsigned int, bool, int =3D 0)'
=2E./include/hamlib/rigclass.h:83: after previous specification in `void
   Rig::setFunc(long long unsigned int, bool, int =3D 0)'
rigclass.cc:470: default argument given for parameter 2 of `bool
   Rig::getFunc(long long unsigned int, int =3D 0)'
=2E./include/hamlib/rigclass.h:84: after previous specification in `bool
   Rig::getFunc(long long unsigned int, int =3D 0)'
rigclass.cc:619: default argument given for parameter 2 of `void
   Rig::setBank(int, int =3D 0)'
=2E./include/hamlib/rigclass.h:121: after previous specification in `void
   Rig::setBank(int, int =3D 0)'
rigclass.cc:624: default argument given for parameter 2 of `void
   Rig::setMem(int, int =3D 0)'
=2E./include/hamlib/rigclass.h:122: after previous specification in `void
   Rig::setMem(int, int =3D 0)'
rigclass.cc:629: default argument given for parameter 1 of `int=20
Rig::getMem(int
   =3D 0)'
=2E./include/hamlib/rigclass.h:123: after previous specification in `int
   Rig::getMem(int =3D 0)'
make[1]: *** [rigclass.lo] Error 1
make[1]: Leaving directory `/paquetes/hamlib-1.1.3/c++'
make: *** [all-recursive] Error 1
kha:/paquetes/hamlib-1.1.3#
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D

=2D --=20
Un saludo,
	Jaime Robles
	ja...@kd...
	Coordinador KDE-es - KDE Spanish Translation Team
	http://www.kde.org/es  - http://es.i18n.kde.org
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+ia3yER46oL+8yYURAolzAJ0e6mJAJNGnVE64Hb3ng94OS2qLQQCfVTPV
5y1UQWPQu2s6QIhbvC6XAZ8=3D
=3DEP0K
=2D----END PGP SIGNATURE-----

Re: [Hamlib-developer] Tuner frontend functions

[Nate B. <n0...@ne...>]

* Stephane Fillod <f8...@fr...> [2003 Mar 28 16:19 -0600]:
     
>     Rig command: \dump_caps

Yup.  Right there in the man page had I bothered to look...

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

Re: [Hamlib-developer] Tuner frontend functions

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

On Thu, Mar 27, 2003, Nate Bargmann wrote:
> As well, you may have noticed that I replaced the character for Dumpcaps
> and a few others by numbers.  The reason is that in my EN_us locale, all
> I got on the display was "?" characters.  As we go along I'm wondering
> if two character commands could be added?

These 8bit characters do not display well here too. Actually, they're
only used as unique ID in the array for long format option. 
Here follows an example on how to use 'dump_caps' when one-char short command
is not available. Long format-only is okay with seldomly used commands.

    (fillods@charybde:tests)$ ./rigctl -vvvvvv
    rigctl, Hamlib version 1.1.4cvs
    Report bugs to <ham...@li...>
    
    rig:rig_init called
    rig: loading backend dummy
    dummy: _init called
    rig_register (1)
    dummy_init called
    rig:rig_open called
    dummy_open called
    dummy_get_vfo called: VFOA
    Opened rig model 1, 'Dummy'
    Backend version: 0.2, Status: Beta
    
    Rig command: \dump_caps
    Caps dump for model 1
    Model name:     Dummy
    Mfg name:       Hamlib
    Backend version:        0.2
    Backend copyright:      LGPL
    [...]

Cheers,
Stephane

Re: [Hamlib-developer] Tuner frontend functions

[Nate B. <n0...@ne...>]

* Stephane Fillod <f8...@fr...> [2003 Mar 27 17:45 -0600]:
 
> absolutely right. This is fixed now, commit should follow. Let me know
> if there're other flaws or mistakes.

Oh, you know me!  I'm not afraid to fire off an email.  :-)

> yes, that would be cool, but being too smart add complexity. 
> It's better to keep the KISS approach.

It was a thought.  KISS is best, and this kind of behavior results in a
lot work for the application using Hamlib, which we don't want to do.

> In that case, I would recommand the use of rig_get_channel, with
> an optimized backend.
> 
> > The downside of this idea is that only ON/OFF values may be reported.
> > How would we report multiple AGC values, for instance?
> 
> rig_get_channel and levels.

Hmmm, another thing to go off and learn...another day!

> BTW Nate, your idea of allowing vfo target in rigctl is very good for
> testing purpose. I took the liberty of extending it to other commands.
> Just pass "-o" to rigctl when you want to specify the VFO. VFO_CURR will
> apply otherwise.
> I've also allocated 'Z' and 'z' to set_xit/get_xit.

Sheepish grin.

I didn't really intend for my private copy of rigctl to get out, but I
had copied it over there for another reason and had forgotten it.  That
said, I've been able to exercise my backends with direct VFO access.
The command option is an excellent implementation since both behaviors 
are now available.

As well, you may have noticed that I replaced the character for Dumpcaps
and a few others by numbers.  The reason is that in my EN_us locale, all
I got on the display was "?" characters.  As we go along I'm wondering
if two character commands could be added?

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

Re: [Hamlib-developer] Tuner frontend functions

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

On Mon, Mar 24, 2003, Nate Bargmann wrote:
> In looking at the docs and the code for rig_set_func and its companion
> rig_get_func, there is some minor confusion.  In both function
> declarations, func is a type setting_t, which is a long long int, and
> status is an int.  So far, so good.  While the rig_set_func docs talk
> about using status to pass a 1 or 0 (activate, de-activate the
> function), the rig_get_func talks about setting bits and the inference
> is that status is a bit map analog of setting_t, which currently isn't 
> possible.

absolutely right. This is fixed now, commit should follow. Let me know
if there're other flaws or mistakes.

> However, this does raise an interesting thought.  If status were also
> type setting_t, then multiple functions could be set in one call to
> rig_set_func.  For example, if func is set to RIG_FUNC_TUNER, then
> checking bit 30 of status would reveal the requested action.  Likewise,
> the application could send an or'ed func value consisting of
> RIG_FUNC_TUNER|RIG_FUNC_NB and the backend would need to test status
> bits 30 and 1 for the resulting rig command.

yes, that would be cool, but being too smart add complexity. 
It's better to keep the KISS approach.

> Conversely, rig_get_func could return multiple bit values in status.
> The Yaesu rigs, at least, return a number of flag bytes with one
> command.  It seems to me that the computer running Hamlib can sort
> through multiple flags and assemble a bitmap much faster than repeated
> polls through the library to the rig.  This increases efficiency.

In that case, I would recommand the use of rig_get_channel, with
an optimized backend.

> The downside of this idea is that only ON/OFF values may be reported.
> How would we report multiple AGC values, for instance?

rig_get_channel and levels.


BTW Nate, your idea of allowing vfo target in rigctl is very good for
testing purpose. I took the liberty of extending it to other commands.
Just pass "-o" to rigctl when you want to specify the VFO. VFO_CURR will
apply otherwise.
I've also allocated 'Z' and 'z' to set_xit/get_xit.

Cheers,
Stephane

Re: [Hamlib-developer] Intro

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

Hi Wolf,

First of all, welcome onboard!

On Wed, Mar 26, 2003, Wolf-Ruediger Juergens wrote:
> I'm new to the list, but if its possible I will work on the support for  
> Elecraft K2 in hamlib. I've just installed hamlib 1.1.3 and there are
> some problems with controlling the rig. Take a look into the sources
> and could not see anything related to the K2. I think I can make
> a extra lib based on Kenwood sources for the K2. 

Basic support for the K2 has only been introduced recently.
Try the latest snapshot from http://hamlib.org/bleeding-edge/
or better, checkout current development version from the CVS repository.
The README.betatester and README.developer files will should you for that
matter.

The K2 protocol documentation is available on the web, and the kenwood
backend does not implement all the K2 feautres yet.

Contribution and patches are welcome :)

> privat:
> 47 years old, working as programmer for embedded solutions.
> At home I'm using Debian/Knoppix ( testing ) as platform. 
> Linux since the early days of Kernel 1.1x. :-)
> So far I'm using Kpsk and gMFSK and try to work with tlf. 

I'm a bit younger (20 less than you), working in same field, 
running unstable (well, as far as my distrib is concerned),
been in Linux since the early days of 0.99pl15
So we're kind of having similar culture :-)
Hope to "see" you in the contests!

73,
Stephane

[Hamlib-developer] Intro

[<WJu...@t-...>]

Hi,
I'm new to the list, but if its possible I will work on the support for  
Elecraft K2 in hamlib. I've just installed hamlib 1.1.3 and there are
some problems with controlling the rig. Take a look into the sources
and could not see anything related to the K2. I think I can make
a extra lib based on Kenwood sources for the K2. 
Hope thats ok?

privat:
47 years old, working as programmer for embedded solutions.
At home I'm using Debian/Knoppix ( testing ) as platform. 
Linux since the early days of Kernel 1.1x. :-)
So far I'm using Kpsk and gMFSK and try to work with tlf. 

73 de Wolf, DL2WRJ

Re: [Hamlib-developer] Tuner frontend functions

[Nate B. <n0...@ne...>]

* Stephane Fillod <f8...@fr...> [2003 Mar 24 17:16 -0600]:
 
>     rig_set_func(rig, vfo, RIG_FUNC_TUNER, 1);	/* enable auto-tuner */

In looking at the docs and the code for rig_set_func and its companion
rig_get_func, there is some minor confusion.  In both function
declarations, func is a type setting_t, which is a long long int, and
status is an int.  So far, so good.  While the rig_set_func docs talk
about using status to pass a 1 or 0 (activate, de-activate the
function), the rig_get_func talks about setting bits and the inference
is that status is a bit map analog of setting_t, which currently isn't 
possible.

However, this does raise an interesting thought.  If status were also
type setting_t, then multiple functions could be set in one call to
rig_set_func.  For example, if func is set to RIG_FUNC_TUNER, then
checking bit 30 of status would reveal the requested action.  Likewise,
the application could send an or'ed func value consisting of
RIG_FUNC_TUNER|RIG_FUNC_NB and the backend would need to test status
bits 30 and 1 for the resulting rig command.

Conversely, rig_get_func could return multiple bit values in status.
The Yaesu rigs, at least, return a number of flag bytes with one
command.  It seems to me that the computer running Hamlib can sort
through multiple flags and assemble a bitmap much faster than repeated
polls through the library to the rig.  This increases efficiency.

The downside of this idea is that only ON/OFF values may be reported.
How would we report multiple AGC values, for instance?

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

Re: [Hamlib-developer] Tuner frontend functions

[Nate B. <n0...@ne...>]

* Stephane Fillod <f8...@fr...> [2003 Mar 24 17:16 -0600]:
 
>     rig_set_func(rig, vfo, RIG_FUNC_TUNER, 1);	/* enable auto-tuner */
>     ...
>     rig_set_func(rig, vfo, RIG_FUNC_TUNER, 0);	/* disable auto-tuner */
>     ..
>     rig_vfo_op(rig, vfo, RIG_OP_TUNE);		/* "user"-start tune */
>     ..

Looks good, Stephane.

> It's in the cvs repository.

Yeah, I finally found the definitions for set/get_func in settings.c, I
now know there are other files around.  Doh!

What do you think of a couple of more convenience definitions in rig.h:

#define 	OFF	0
#define		ON	1

Perhpas as well:

#define		FALSE	0
#define		TRUE	1

I like definitions like these since it makes more human readable code
and doesn't leave a bunch of numeric constants scattered about.  Perhaps
they need to be prefixed with RIG_ to avoid conflicting with similar
definitions in other projects.  Of course, that rather negates their
convenience...

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

Re: [Hamlib-developer] Tuner frontend functions

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

On Mon, Mar 24, 2003, Nate Bargmann wrote:
> > What about creating RIG_FUNC_TUNE to turn the auto-tuner on and off, and
> > a RIG_OP_TUNE to start the tuner?
> 
> That's what I forgot.  State constants.
> 
> I'm guessing these will be used in new functions for the purpose, or
> will they be used with a set of existing functions?

    rig_set_func(rig, vfo, RIG_FUNC_TUNER, 1);	/* enable auto-tuner */
    ...
    rig_set_func(rig, vfo, RIG_FUNC_TUNER, 0);	/* disable auto-tuner */
    ..
    rig_vfo_op(rig, vfo, RIG_OP_TUNE);		/* "user"-start tune */
    ..

It's in the cvs repository.

Note (not related):
I've made a cleanup: RIG_FUNC_LMP is gone, use RIG_PARM_BACKLIGHT instead.


Cheers,
Stephane

Re: [Hamlib-developer] Tuner frontend functions

[Nate B. <n0...@ne...>]

* Stephane Fillod <f8...@fr...> [2003 Mar 24 05:51 -0600]:
 
> What about creating RIG_FUNC_TUNE to turn the auto-tuner on and off, and
> a RIG_OP_TUNE to start the tuner?

That's what I forgot.  State constants.

I'm guessing these will be used in new functions for the purpose, or
will they be used with a set of existing functions?

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

Re: [Hamlib-developer] Tuner frontend functions

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

On Sun, Mar 23, 2003, Nate Bargmann wrote:
> After looking through rig.h I haven't found an obvious candidate such as
> rig_set_tuner to turn the auto-tuner on and off.  There also should be a
> function to start the tuner.

What about creating RIG_FUNC_TUNE to turn the auto-tuner on and off, and
a RIG_OP_TUNE to start the tuner?


73
Stephane

[Hamlib-developer] Tuner frontend functions

[Nate B. <n0...@ne...>]

I guess I'm dense tonight.

After looking through rig.h I haven't found an obvious candidate such as
rig_set_tuner to turn the auto-tuner on and off.  There also should be a
function to start the tuner.

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

Re: [Hamlib-developer] IC-736 backend status and converter power

[Andrea B. <bo...@st...>]

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

Stephane Fillod wrote:


> Have a look at the last pages of the IC736 user manual. You should see a
> table with supported commands. This is all your Icom can do, nothing more.

Ehr, that's exactly the problem: there's no such table in the manual.
All I see in the manual is a generic listing of frequencies and 
operating modes, but no mention of specific commands.

Anyone with an IC-736 who can shed some light into the matter?

TIA,
Andrea.

- -- 
Undergraduate student of Computer Science @ University of Bologna
Key fingerprint: 4037 9711 85C6 F9F9 A505  FA0A BB62 3A3C F7BA 9B13
ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+eX49KhgqEyuO+p4RAr3jAKCIRCRDDJzr7rOHW+XrD+Z411mHtgCePpeP
xijcDbZZZcO8bXvBkkEnhiw=
=ylpS
-----END PGP SIGNATURE-----

new vfo_t feedback, Re: [Hamlib-developer] Re: Hamlib-developer digest, Vol 1 #342 - 3 msgs

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

On Wed, Mar 12, 2003, Dale E. Edmons wrote:
> 1)  My rig has two independent memory pointers.  If someone calls:
>         rig_set_vfo(rig, RIG_VFO_MEM)
> I presume I treat this just like RIG_VFO_CURR but set mem mode rather than

no, RIG_VFO_CURR means "don't change vfo" (ie. a no-op for rig_set_vfo) while 
RIG_VFO_MEM means switch to memory mode (recalling last selected #).

Rem:
all the vfo_t problems lie with the fact that some so-called VFO's are
actually control bands, and some others are just "glorified" memories.
Sometimes it's not clear how they should be interpreted.
Let see if we can make it as designed for now. Otherwise, a new
proposal will have to come up.

> vfo mode.  This is probably okay.  But, now, what do I do on rig_get_vfo()?
> It would be pointless to return RIG_VFO_MEM just as it would be pointless
> to return RIG_VFO_CURR (the rig is *always* in the current configuration).

It is pointless for rig_get_vfo() to return RIG_VFO_CURR, however it is
NOT pointless to return RIG_VFO_MEM.

> Either of the following would have meaning and would be useful:
>     RIG_VFO_MEM | RIG_VFO_C
>     RIG_VFO_MEM | RIG_VFO_MAIN
> But is this defined?

yes, RIG_VFO_MEM | RIG_VFO_C is valid.
RIG_VFO_VFO implicitly applies to RIG_VFO_CURR
RIG_VFO_MEM implicitly applies to RIG_VFO_CURR
for most backends, RIG_VFO_VFO | RIG_VFO_N will be nothing more than RIG_VFO_N
RIG_VFO_MEM | RIG_VFO_N is okay

RIG_VFO_MEM | RIG_VFO_MAIN is not valid because no "real vfo" is defined.

For me, RIG_VFO_MAIN and RIG_VFO_SUB are aliases, and the way some rigs
define them is misleading. That's why it's better not to use them.
Besides, RIG_VFO_MAIN and RIG_VFO_SUB would provide only 2 control
bands, which is not enough in the case of SDR, where each vfo 
IS independant wrt other control channels.

> 2) I can also directly access memory.  This is useful for memory backup
> restore type routines.  For example if one calls rig_get_channel() and
> sets the channel_num to the desired memory, it may be retreived without
> accessing either of the memory pointers.  Alternatively, one may wish to
> do rig_get_channel() using either one of the pointers.  RIG_VFO_MEM
> tells me only one piece of the information I need.  Again, either:
>         RIG_VFO_MEM | RIG_VFO_A
>         RIG_VFO_MEM | RIG_VFO_MAIN
> etc.... would do the trick for the pointers.  Then, I could use RIG_VFO_MEM
> to imply direct access if the caller has properly set channel_num.

I am not very keen on the RIG_VFO_MAIN for the previous reason, but
your remark is worth adding in the rig_get_channel API documentation.
Backends will have to be modified to follow this behaviour.

> >
> > RIG_VFO_VFO     VFO mode (last selected VFO), used by set_vfo,
> >                 as opposed to Memory mode
> 
> Is this supposed to turn memory mode off using the vfo_t?

yes, rig_set_vfo(RIG_VFO_VFO) would turn memory mode off, selecting last
previously VFO for this control channel.

> > * Split combinations are not to be handled here. We need to
> >   create (or modify) an API call like the following:
> >   rig_set_plit_vfo(RIG*, vfo_t rx_vfo, split_t split, vfo_t tx_vfo);
> >   What do you think?
> 
> With one small change to vfo_t you can avoid  changing the API
> (which is bound to not be binary compatible).  Add RIG_VFO_REV
> to the vfo_t definitions.  Then a split may be defined in one vfo_t:
>         rx_vfo = RIG_VFO_A;
>         tx_vfo = RIG_VFO_B;
>         vfo = rx_vfo | tx_vfo;    // A/B split
> 
>         vfo |= RIG_VFO_REV;    // B/A split
>         // This works for all n in RIG_VFOn.
> 
> Either will require changes to the backends, but the API will be unchanged.

Adding new calls is not a problem. Your RIG_VFO_REV proposal is too
hackish to my taste, and it would prevent setup of a channel being memory
and the other not.

> The RIG_VFO_REV is also handy to have for specifing the REV on a
> repeater, and similar items.

see RIG_FUNC_REV instead

> > * Call channels should be accessed through a forged memory channel,
> >   unless they are truly plain VFO. I would recommand to go the memory way
> >   anyway, because memory channels are saved by application whereas
> >   VFO channels aren't (they're kind of temprorary working area).
> 
> VFO channels could be saved as easily as memory.   If the channel_t has
>     chan->vfo = RIG_VFO_A;
> then shouldn't we save freq, mode, etc... into the chan from VFO_A?  This
> way, memory<->vfo operations will be more transparent.

This is the way the API is designed already. Have a look at the
rig_get_channel comments, and generic_save_channel in src/mem.c

When I was saying "..whereas VFO channels aren't", I meant they aren't
saved by application because even though it can, it is pointless for 
the application, unless you want to setup your rig to the exactly 
the same state when you left your application.

> 
> > However, a new field will have to be created
> >   in the caps to describe what frequency band is exclusive to which one,
> >   determining if full-duplex is possible or not.
> 
> I don't think I understand this.  Would this be similar to saying, "My rig will do
> 
> A/B, split or B/A split, but not A/C or C/A split"?

I was not thinking this case, with "VFO" split incompatibilities, but it
will have to be modelled.

I was thinking of the case were VFOA can be tuned to either VHF or UHF
band, and VFOB can be tuned to either VHF or UHF band too. However, VFOA
and VFOB can NOT use the same band at the same time in full-duplex mode,
which leaves only the following possibilities: VFOA:VHF/VFOB:UHF or
VFOA:UHF/VFOB:VHF in my example.

> Please add something like the following:
>     /** \brief Reverse */
>     #define RIG_VFO_REV    ((vfo_t) (1<<24))

I'd prefer not to.

> > Application developers, please let me know if this new design does not let
> > you do what you want.
> 
> Can we specify RIG_VFO_A etc... as a target in rig_get_channel().  This
> would be very nice for MEM<->VFO operations.

it's already there, as long as backends honors the news vfo_t.


73's
Stephane

Re: [Hamlib-developer] vfo_t rewrite

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

On Tue, Mar 11, 2003, Chuck Hemker wrote:
> Looks interesting, but I'm slightly confused about how this would work with a
> satellite rig.
> And you asked for comments. :)
> I hope this makes sense and I didn't give you too many. :)

don't worry, feedback is always welcome!

> With a radio like the IC-970:
> 
> The radio has two radio modules that can each be tied to any of the band
> modules (but with the IC-970 not the same band)
> 
> main transceiver with optional transmit offset (or is it a split)
> sub receiver
> 
> Common uses:
> cross band satellite (full duplex):
> main is the transmitter
> sub is the receiver
> 
> other uses (half duplex):
> main is the transceiver with optional transmit offset
> 
> -
> 
> Now from my reading of your description:
> 
> RIG_VFO_MAIN and RIG_VFO_SUB don't necessarily have anything to do with the
> vfo's the radio calls main and sub.

RIG_VFO_MAIN and RIG_VFO_SUB have to do with the radio vfo's.
The backend developer is responsible for mapping RIG_VFO_MAIN and RIG_VFO_SUB
to the so-called vfo's of the radio.
RIG_VFO_MAIN and RIG_VFO_SUB are only to be used by humain (through a
GUI), since their definition is quite vague, and may change from one rig
to another.
Most propably, what you intend to use instead, is RIG_VFO_TX and 
RIG_VFO_RX, the uplink and downlink in satellite world.

> RIG_VFO_TX for the sub receiver would the the main

up to you (and the IC970)

> RIG_VFO_TX for the main would be the main transmit offset?
> or would this be a split which is set with rig_set_split_vfo?
> Is RIG_VFO_TX_VFO part of the radio description or settable by the user?
> What happens when you turn split on and off?

good question. Here you will have to handle 2 split modes.
The first one is the full-duplex case, with separate VFO's.
The second one is the half-duplux case, with transmit offset.

I don't know what the IC970 protocol looks like. If you want a bit of
help on this topic, let me know where I can have a glance over the
manual.

> I don't think it matters that much to me because my software has a config file
> that you set up ahead of time that has lists of transmitter and receiver pairs
> that you can select between.
> I can deal with transmit on radio 1 on RIG_VFO_1 and receive on radio 2 on
> RIG_VFO_2.

You mean using 2 different radios? i.e. a simple and expensive way of make a
full-duplex transceiver out of 2 half-duplex rigs.
IIRC, ktrack is doing the same.

> For the medium/long term, I'm thinking it would be nice to have some sort of
> searchable extended capabilities database (I'm not sure if it should be a hard
> coded in a structure, stored in a file, or something else) with things like:
> name radio calls vfo (left, right, main, sub, vhf, uhf, ...)
> transmit range
> receive range
> various other info
> 
> so I could do a query something like:
> what vfos should I use to transmit on vhf, receive on uhf, preferably full
>  duplex?  And does the radio need to be in a special mode and/or setup?

I see what you mean.
Right now, all the capabilities are stored in C structures, with various
hacks to describe everything. It would have been neat to have some kind
of database (xml file?) and an automatic database-to-C-structure
program instead. But the C structures are not firmed up yet, so the C
way is easier for now.

But you can do the other way around. Generate a database out of
the C structures.
Have a look at http://f8cfe.free.fr/ham/hamlib/rigmatrix.html 
if it's still there. This is an extract of rigs capabilities.
It's done in C. I plan to rewrite it in perl one day. Generating an
export to XML (or any other db format) would fairly easy.

> If you had enough info in there, then someone could write a piece of software
> that could do fairly complicated things to the radio without a lot of special
> configuration.  On the other hand, a lot of software probably only has to worry
> about RIG_VFO_CURR because alot of things that you can do with the front panel
> can just as easily be done with software using hamlib.  (eg. for memories, the
> things I can think of you would want to do to them are backup, restore, and
> editing.  You don't really need to use them in hamlib)

yep, it makes little sense to use memories in Hamlib, yet it is
possible. Like you said, most often usage will be backup/restore and
editing. I'm really surprised not such application does exist yet,
it's so easy with get_channel/set_channel. Using the perl binding, it's
a piece of cake.

> However, this would take alot of thinking to try to come up because it seems
> they are adding all sorts of different modes to the new high end radios for
> different uses.  And how what modes share hardware and/or software vfo's with
> other modes.  

the task is not easy, but we'll try to keep up..

> And then with the software defined radios you could have multiple receivers
> active in the dsp up to the speed of the dsp.  (Either different modes or
> different frequencies inside of the IF passband)  (vfo1 is spectrum display
> across the IF passband, vfo2 is one frequency in USB, vfo3 is a slightly
> different frequency in PSK31, ...)

Talking about SDR (software defined radios), I have a pretty good idea
since I currently develop the gnuradio backend, which is a SDR.
The API may have to be adapated again, but so far, it's not too bad.
BTW, a lot of backends will have to be updated to the new vfo_t design.


Cheers,
Stephane

Re: [Hamlib-developer] IC-736 backend status and converter power

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

On Wed, Mar 19, 2003, Andrea Borgia wrote:
> I don't know what I changed, but now hamlib is working, more or less. 

excellent news!

> Many commands in rigctl, however, return "not available"; how can I tell 
> whether a given command is really supported by the radio or not?

Have a look at the last pages of the IC736 user manual. You should see a
table with supported commands. This is all your Icom can do, nothing more.
Trying functions not in table will make Hamlib return "not available".
Rem: if you get a "not available" but the function IS in the table, then
Hamlib has to be fixed :)

73's
Stephane

Re: [Hamlib-developer] IC-736 backend status and converter power

[Andrea B. <bo...@st...>]

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

Chuck Hemker wrote:


> As promised, here is my ideas for improved error checking for icom_transaction
> and icom_decode.

I don't know what I changed, but now hamlib is working, more or less. 
Many commands in rigctl, however, return "not available"; how can I tell 
whether a given command is really supported by the radio or not?

Andrea

- -- 
Undergraduate student of Computer Science @ University of Bologna
Key fingerprint: 4037 9711 85C6 F9F9 A505  FA0A BB62 3A3C F7BA 9B13
ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+eEpVKhgqEyuO+p4RAvfHAJ4i32C4SdFhbmQCOmN8B2k+ACi+4gCgocBo
cm8XTwSE9xb8jSX5X3RNcpQ=
=U+3z
-----END PGP SIGNATURE-----

Re: [Hamlib-developer] HamLib help compiling

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

CIAO Fabrizio,

On Sun, Mar 16, 2003, Fabrizio Garino wrote:
> and mny tnx to reading this email.
> 
> I’ve some problem during the process of  RIGCLASS.CC .

you must be compiling the hamlib-1.1.3 with some kind of recent gcc-3.x

> Would you mind to help me?

Sure, try either one of the following solutions:
* compile using gcc-2.95.x
* disable C++ by passing "--without-cxx-binding" to configure script
* or try latest snapshot from http://hamlib.org/bleeding-edge/

BTW, hamlib-1.1.4, which won't suffer these problems, should come out
in a matter of weeks.

73's
Stephane F8CFE

[Hamlib-developer] Rohde & Schwarz EK 070 VLF-HF RX

[Marc B. <ma...@hb...>]

Hi

I own a Rohde & Schwarz EK 070 and I would like to add support (i.e. a 
backend) for it to hamlib.

My only problem is lack of documentation...  Does anybody by incident 
have a description of the serial format used?

Regards,
Marc, HB9SSB

[Hamlib-developer] HamLib help compiling

[Fabrizio G. <fg...@li...>]

Hello,

and mny tnx to reading this email.

I=92ve some problem during the process of  RIGCLASS.CC .

Would you mind to help me?

Mny Tnx in advance

=20

Best Regards & 73s

            Fabrizio IW1DVC

=20

=20

=20

[Hamlib-developer] Re: Hamlib-developer digest, Vol 1 #342 - 3 msgs

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

Stephane,

It's looking better.  Thanks for the effort.

Here's my comments/questions:

> RIG_VFO_MEM     Memory mode (last selected channel), used by set_vfo,
>                 as opposed to VFO mode

1)  My rig has two independent memory pointers.  If someone calls:
        rig_set_vfo(rig, RIG_VFO_MEM)
I presume I treat this just like RIG_VFO_CURR but set mem mode rather than
vfo mode.  This is probably okay.  But, now, what do I do on rig_get_vfo()?
It would be pointless to return RIG_VFO_MEM just as it would be pointless
to return RIG_VFO_CURR (the rig is *always* in the current configuration).
Either of the following would have meaning and would be useful:
    RIG_VFO_MEM | RIG_VFO_C
    RIG_VFO_MEM | RIG_VFO_MAIN
But is this defined?

2) I can also directly access memory.  This is useful for memory backup
restore type routines.  For example if one calls rig_get_channel() and
sets the channel_num to the desired memory, it may be retreived without
accessing either of the memory pointers.  Alternatively, one may wish to
do rig_get_channel() using either one of the pointers.  RIG_VFO_MEM
tells me only one piece of the information I need.  Again, either:
        RIG_VFO_MEM | RIG_VFO_A
        RIG_VFO_MEM | RIG_VFO_MAIN
etc.... would do the trick for the pointers.  Then, I could use RIG_VFO_MEM
to imply direct access if the caller has properly set channel_num.

>
> RIG_VFO_VFO     VFO mode (last selected VFO), used by set_vfo,
>                 as opposed to Memory mode

Is this supposed to turn memory mode off using the vfo_t?

> * Split combinations are not to be handled here. We need to
>   create (or modify) an API call like the following:
>   rig_set_plit_vfo(RIG*, vfo_t rx_vfo, split_t split, vfo_t tx_vfo);
>   What do you think?

With one small change to vfo_t you can avoid  changing the API
(which is bound to not be binary compatible).  Add RIG_VFO_REV
to the vfo_t definitions.  Then a split may be defined in one vfo_t:
        rx_vfo = RIG_VFO_A;
        tx_vfo = RIG_VFO_B;
        vfo = rx_vfo | tx_vfo;    // A/B split

        vfo |= RIG_VFO_REV;    // B/A split
        // This works for all n in RIG_VFOn.

Either will require changes to the backends, but the API will be unchanged.

The RIG_VFO_REV is also handy to have for specifing the REV on a
repeater, and similar items.

> * Call channels should be accessed through a forged memory channel,
>   unless they are truly plain VFO. I would recommand to go the memory way
>   anyway, because memory channels are saved by application whereas
>   VFO channels aren't (they're kind of temprorary working area).

VFO channels could be saved as easily as memory.   If the channel_t has
    chan->vfo = RIG_VFO_A;
then shouldn't we save freq, mode, etc... into the chan from VFO_A?  This
way, memory<->vfo operations will be more transparent.

> However, a new field will have to be created
>   in the caps to describe what frequency band is exclusive to which one,
>   determining if full-duplex is possible or not.

I don't think I understand this.  Would this be similar to saying, "My rig will do

A/B, split or B/A split, but not A/C or C/A split"?

> Here's the relevant part of rig.h:
> ---------------------------------
> /**
>  * \brief VFO definition
>  *

>
> /** \brief VFO A */
> #define RIG_VFO_A RIG_VFO_N(0)
> /** \brief VFO B */
> #define RIG_VFO_B RIG_VFO_N(1)
> /** \brief VFO C */
> #define RIG_VFO_C RIG_VFO_N(2)
>

Please add something like the following:
    /** \brief Reverse */
    #define RIG_VFO_REV    ((vfo_t) (1<<24))

>
> If something is not clear, please ask questions. If documentation is too
> vague, please complain, or better, propose your own comments!

Only the purpose of the new caps entry was vague.

> Application developers, please let me know if this new design does not let
> you do what you want.

Can we specify RIG_VFO_A etc... as a target in rig_get_channel().  This
would be very nice for MEM<->VFO operations.

> Backend developers, please let me know if this new design does not let
> you describe what your rig can do.

These were the issues I first ran into several months ago.  I'm glad to see
things progressing.  This is roughly equivalent to my initial changes to rig.h.


73's

Dale, kd7eni