hamlib-developer — hamlib developers forum

forthcoming release was: Re: [Hamlib-developer] Here is kenwood_set_level

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

On Sun, Jan 20, 2002, Alexandru Csete wrote:
> Sure, no problem. I think it is a good idea and it is my impression that
> hamlib-1.1.3 is very close, am I right?

You're right Alex. I think we need a 1.1.3 release soon.
However, there's no release date yet. Let's just say the coming weeks.
Nate is working on the documentation, and on my side I'd like
to do the following:
- add new calls: rig_srch_ctcss, rig_srch_dcs, rig_get_bandscope,..
- add new rotator caps and calls (can I have your feedback Francois?)
- update hamlib.m4 (which can then be used by grig and kontakt)
- test kenwood/th backend on my TH-F7E, provided my level converter works
- merge ft-100 support from Alex KC2IVL and/or Kenenth
- define new capability to advertise what can be stored/restored in a
  memory channel.
- update README,TODO,etc.
- ...

Any wishes for 1.1.3?

Note: rigctl is now able to display the content of a memory channel 
('h' command). Let me know how it works for you!


Cheers,
  Stephane F8CFE

[Hamlib-developer] IC-756, XBasic, and beta-testing

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

Hi John!

I've Cc: my reply to the hamlib-developer mailing list. So information
circulates. And you're not the first one to use Hamlib with an IC-756.

On Wed, Jan 23, 2002, John Simmons wrote:
> Thanks for the help on getting rigctl running.
> I did not find any read me file that explained how to get
> rigctl started and one of the mistakes that I was making was
> entering -c 50 when it should have been -c 80 dec to
> indicate 50 hex.

You're right, nowhere it was mentionned it is decimal. This is now fixed
in the cvs repository: rigctl(1) man page mentions it, and rigctl now
accepts -c 80 or -c 0x50, whichever you prefer.

>  I have look at the CVS and it is a bit confusing as to just
> what file I will need to down load to compile  the  current
> developement version.    I am not familiar with compiling
> such large program from scrach.    

Okay, this is good to say what's missing. I tend to overlook some bits,
because I spend maybe too much time on the code.

> When I tryed running some of the commands such as get_mode
> command "m" the order of the command line does not seem to
> match what I am seeing in my manual. With the rig set to
> USB.
> Rig command: m
> TX 7 bytes
> 0000     ff fe fe 50 e0 04 fd   ...P...
> RX 7 bytes
> 0000     ff fe fe 50 e0 04 fd   ...P...
> RX 6 bytes
> 0000     fe fe e0 50 04 01      ...P..
> RX 1 bytes
> 0000     01     .
> RX 1 bytes
> 0000     fd     .
> Mode: 4
> Passband: 2400
>  My manual says that the command line should be 
> 'fe fe e0 50 Cn Sc data fd
> e0 is the Controller's address.
> 50hex is the IC-756 address
> The reply from the rig was 'fe fe e0 50 04 01 01 fd'
>  I a assuming that 'e0' is the command and '04' is the sub
> command.   Is sub command '04' a undocument command?

The first reply from the rig is actually exactly what Hamlib sent. This is
because according to the CI-V spec, the TXD and RXD signals are
tighed together. So you have to expect this kind of echo.
Now, the 'fe fe e0 50 04 01 01 fd' break down into:

  fe fe: preamble
  e0: destination address, i.e. the controller
  50: send address, i.e. the transceiver
  04: "Cn" read display mode, here the response
      there's no "Sc" sub command
  01 01: the data area, here USB, normal operation

What is confusing is the ouput of rigctl from version 1.1.2.
Newer version now displays "USB" instead of the Hamlib internal 
constant 4, and passband width is simply 2400 kHz.

>  Using the M: set_mode also gives starange results.
> 
> Rig command: M
> Mode: 01
> Passband: 8000
> TX 8 bytes
> 0000     ff fe fe 50 e0 06 02 fd        ...P....
> RX 8 bytes
> 0000     ff fe fe 50 e0 06 02 fd        ...P....
> RX 6 bytes
> 0000     fe fe e0 50 fb fd      ...P..
> The command '06' and '02' would be correct to set the rig in
> AM mode which it does and the 8000 sets the passband to 15k
> (no AM filter)  The '01' command should set the rig to USB.

Sorry for the lack of documention which lead you to confusion.
First of all, rigctl is tool that knows absolutly nothing about 
a rig protocol and the specific values in use by this protocol.
Historically, rigctl was just to a unitary test tool for Hamlib functions.
So, to make it quick to develop, arguments were read as integer in
internal representation of Hamlib. Hence, mode 01 is actually RIG_MODE_AM,
as defined in include/hamlib/rig.h. That's why the rig was set to AM.
And passband is expressed in Hz. In that case, it looks like Hamlib
decided to select closest passband.

This was version 1.1.2. The code in the cvs rep now accepts modes as "AM",
"USB", etc. instead of obscure numbers only known by developers...

> This may have been fixed in later versions or this command
> structure may be based on the 756pro or 756proII.   If it
> would help I can copy the command table for the 756 and send
> it as a attachment.

This might help anyway, to check if the icom backend supports all the
features of your 756.

> On XBasic i belive that if I 'Include' the lib as external
> files in the prolog of the program I can make calls to the
> lib files.   The question is if I make the calls does the
> data have to be entered as BCD code as stated in the manual
> or do the lib's make the conversion for dec. or hex?   I

Think simple, think easy. The whole philosophy behind Hamlib is to hide
the gory details of protocols to the library user. Forgot about BCD code
and such, this is all taken care of in the icom/ subdirectoy.
Keep in mind that any application using Hamlib becomes able to control
*any* rig supported by Hamlib. Some rigs have BCD code, some others use an
ASCII protocol. Whatever, this is all hidden to the application, which has
better to concentrate on by the way.
So how do I specify mode AM for example when changing mode? would you ask.
This is achieved through constants, defined in rig.h include file.
Here it is in C:

	rig_set_mode(my_rig, RIG_VFO_CURR, RIG_MODE_AM, 15000);

my_rig is a handle, obtained after rig_init and rig_open.
RIG_VFO_CURR is a constant indicating you want the mode set is to take
	place on the current VFO.
RIG_MODE_AM an interger constant for AM mode.
15000 is an integer specifying a passband of 15kHz.

> guess I am going to have to learn to read C a little better
> in order the understand the structure of the calls and what
> the calls are looking for.   I need a hint on what files i
> should 'include' to start up the serial ports and get the
> rig initalized.  Also what lib's should be included.
> Xbasic has it own io , math Gui and drawing  lib.

Hamlib is using the libc io and math lib, and is standalone.
However, there's no Gui in Hamlib, because this is the upper
level/application duty.
As I told you, I don't know how Xbasic binding works. However,
you'll most probably have to #include <hamlib/rig.h>  somewhere,
and link against libhamlib-1.1.3.so.0

There's a very basic C program using Hamlib in the tests/testrig.c 
of the source package. Once you get the logic, you will find more calls in
include/hamlib/rig.h or from http://hamlib.sf.net in manual section.

> I am guessing I  will need to be able to setup and compile
> the current version of the file to get all the current
> upgrades to the code.   The zip and rpm file dated the in
> Sept. may not be current enough.   Any help such as a list
> of file and which make , make install file or possibly point
> me in the direction of the proper Readme file.   

Ah, another thing missing. So here it is. 
Please feel free to comment on it, fix english mistakes, add or tell
me what's still missing or not clear, and tips of yours.
I'll then turn it later into a README.betatester


* Why does Hamlib need beta-testers?
Hamlib is developed by a team of enthusiasts around the world, for fun,
much in the spirit of hamradio. (Note that it is not restricted for ham
usage only). There's a great deal of protocols and rigs around the
developers may not own. However, protocols may be available, so backends
can be implemented, but cannot always be tested by developers.
That's where beta-testers are so precious. On top of that, I've been
told that there's no such sure thing like bug free code. 
Feedback and improvement requests are also valuable.

* Okay, you volunteer as beta-tester, how to proceed?
First of all, you can start testing official releases. They are easier to
test because they come in precompiled and packaged (.rpm, .deb).
Reports from these versions are still very appreciated, on
ham...@li... mailing list.

However, the development of Hamlib is still very active, 
so it's better to test from latest cvs version of the code.
And depending on feedback you made, developers can commit a fix
of a patch, so you can try out the change right after, without
waiting for the next official version.
So to proceed, you will have first to check out latest sources from cvs,
then rebuild the Hamlib package and finally test it with your rig.
Don't worry, it's much simpler than what it looks, despite the size of the
package.
Pre-requisite:
 - live internet access
 - cvs
 - gcc toolchain
 
So here we go:

* anonymous (pserver) cvs checkout:

  cvs -d:pserver:ano...@cv...:/cvsroot/hamlib login
  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/hamlib co hamlib

When prompted for a password for anonymous, simply press the Enter key.
The check out has only to be done the first time. In the case you don't
have cvs access through your firewall, but http gets through, daily
cvs snapshots are available. The previous commands can be replaced
by the following:

	wget http://cvs.sf.net/cvstarballs/hamlib-cvsroot.tar.gz
	tar zxvf hamlib-cvsroot.tar.gz
	mv hamlib hroot
	export CVSROOT=`pwd`/hroot
	cvs co hamlib

After the initial retrieval, whenever you want to update your local
version, issue the following command in the root directory of hamlib.

  cvs -z3 -d:pserver:ano...@cv...:/cvsroot/hamlib update -d

Tip: 
I use the following alias:
alias hcvs='cvs -z3  -d:pserver:ano...@cv...:/cvsroot/hamlib'
This way, I just have to do "hcvs update -d" whenever I want to keep to
date.

For the braves who want to peruse the contents, here's what all the
subdirectories are for:

alinco,aor,icom,
jrc,kachina,kenwood,
pcr,tentec,uniden,
winradio,yaesu:		rig backends
rpcrig:			special networked rig backend (through RPC)
rpcrot:        		special networked rotator backend (through RPC)
easycomm:		rotator backends
dummy:			virtual dummy rig and rotator, for developer's use.
c++,tcl,kylix:		C++, tcl, and Kylix bindings
lib:			library for functions missing on your system
libltdl:		wrapper for shared module loader
debian:			debian package scripts
doc:			documentation base and scripts to extract from src
include:		exported header files go there
src:			Hamlib frontend source directory
tests:			rigctl/rotctl and various C programs for testing

* build
Reading the INSTALL file in top directory will explain you more verbosely
to do the following commands

	./configure --disable-static --prefix=/some/where
	make
	make install

The prefix argument is optionnal. The --disable-static speeds up
compilation if you don't plan to use static libraries.

* testing Hamlib

Don't attempt to test Hamlib from source directory unless you're a
developper and you understand what are the side effect of *not* installing
freshly generated objects.

So here we go. First of all, identify your rig model id.
Make sure /some/where/bin is in your PATH, rigctl has to be reachable.
Run "rigctl -l"  to get a list of rigs supported by Hamlib.
If you cannot find yours in the list, please report to the 
hamlib-developer mailing list. Protocol manual and rig specification may
help a lot.
You found your id? good! You're almost ready to use rigctl.
Have a quick look at its manual page:
	man -M /some/where/man rigctl
Or simply:
	rigctl --help

Let's say you own an Icom IC-756:
	rigctl -vvvv -r /dev/ttyS0 -m 326

The -vvvv is very important since this will increase verbosity, and give
precious traces to developpers if something goes wrong. At this level, 
the protocol data exchanged will also be dumped.
Unless some problem shows up, you should be presented with a menu
like "Rig command: ". Enter "?" followed by return to have the list 
of available commands. 'Q' or 'q' quits rigctl immediately.

Most wanted functions to be tested are:
'_'	get misc information on the rig
'f'	get frequency
'F'	set frequency, in Hz
'm'	get mode
'M'	set mode (AM,FM,CW,USB,etc. and passband width in Hz)
'v'	get vfo
'V'	set vfo (VFOA, VFOB, etc.)

NB: some functions may not be implemented in the backend of
simply not available on this rig.

When reporting to hamlib-developer mailing list, please include traces and
also comments to tell developers if the action performed correctly on the
rig.

Tip: traces can be hard to cut and paste sometimes. In that case,
	there's a handy tool for you:  script(1). It will make
	a typescript of everything printed on your terminal.

	$ script my_rig_traces.txt
	Script started, file is my_rig_traces.txt
	$ rigctl -vvvv -r /dev/ttyS0 -m 326
	rig:rig_init called
	rig: loading backend icom
	icom: _init called
	rig_register (309)
	rig_register (326)
	rig:rig_open called
	Opened rig model 326, 'IC-756'

	Rig command: q
	rig:rig_close called
	rig:rig_cleanup called
	$ exit
	exit
	Script done, file is my_rig_traces.txt
	$

And then send my_rig_traces.txt to hamlib-developer.


Okay fellows, test as much as you can, in the weirdest situations if
possible. There is a special prize for those who find 'Segmentation fault'
and other nasty bugs.
Needless to say, patchs are also very welcome :-)


>[snip]  By the way I have the Kenwood TS 790A
> also.  I have not checked into that but if I am successful
> with this project I would probably try to get something
> going on the Kenwood.   I have the manuals and the manual on
> the serial interface for the kenwood but since the rig was
> purchased used I don't know if the serial option was
> installed.      

I just commited the TS-790 description to cvs. So if you have the IF-232
cable or box, you're ready to play with it!
BTW, I would be very interrested to have a copy of the manual on the
serial interface for the kenwood, specially the protocol spec.
Can you scan it and send files attached to f4...@fr...? Thanks.

Cheers,
Stephane F8CFE

Re: [Hamlib-developer] Support for Yaesu FT-100D?

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

On Sat, Jan 19, 2002, Kenenth E. Marks wrote:
> Hello Developer's group.  I apologize in advance if this is not the proper group
> to mail this question to.  Anyways,  is the Yaesu FT-100D supported with this
> set of drivers?  My understanding is that the FT-817 is similar to the FT-100.  If
> you have any information that might be of use I would be grateful.

That's the right group Ken. As far as I know, there's no FT-100D support
in Hamlib. However, if you're saying the FT-817 has the same protocol,
that's going to be pretty easy. Chris (AA1VL) wrote the FT-817 support.
Chris, do you have some insight on the FT-100D?
Anyway, everything you need is the manual of your rig with the protocol
documentation, and a fresh checkout of the hamlib cvs repository.
Have a look in the yaesu/ directory, especially yaesu/ft817.c.
Check if protocols are the same, and try at best to share code among rigs.
Provided you have created yaesu/ft100.c, tweaked yaesu/Makefile.am and
rebuild everything, testing with "rigctl -vvvv -m 121" should lead you on
the path of rig control. And let us know how it works out, and we're there 
to help with the code or understanding it if needed.

Cheers,
 Stephane F8CFE

Re: [Hamlib-developer] Here is kenwood_set_level

[Alexandru C. <al...@if...>]

On Sat, 2002-01-19 at 20:01, Stephane Fillod wrote:
> Alex, please let me know before releasing grig, we may release
> hamlib-1.1.3 first to ease testing.

Sure, no problem. I think it is a good idea and it is my impression that
hamlib-1.1.3 is very close, am I right?


Alex OZ9AEC


-- 
------------------------------------------------------------------------
 Alexandru Csete <al...@if...>       Office : 520-332
 Institute of Physics and Astronomy      Web    : www.ifa.au.dk/~alexc
 Ny Munkegade, Building 520              Phone  : (+45) 8942 3622
 University of Aarhus                    Cell.  : (+45) 2962 4317
 Denmark                                 HF-CW  : 7010kHz +/- QRM
------------------------------------------------------------------------

[Hamlib-developer] Support for Yaesu FT-100D?

[Kenenth E. M. <ken...@ch...>]

Hello Developer's group.  I apologize in advance if this is not the =
proper group
to mail this question to.  Anyways,  is the Yaesu FT-100D supported with =
this
set of drivers?  My understanding is that the FT-817 is similar to the =
FT-100.  If
you have any information that might be of use I would be grateful.

Thanks in advance,

- Ken Marks

Re: [Hamlib-developer] Here is kenwood_set_level

[Joop S. <jo...@ya...>]

On 19 Jan 2002 16:00:16 +0100
Alexandru Csete <al...@if...> wrote:

> I'm glad to hear that Gnome RIG also works for others than me... We were
> very close to make an early release, then a deadline on my thesis
> prevented me from doing any coding for the last ten days or so. But I'll
> be back during the next week.
> 
> 

Hi Alex,

the CVS version is quite suited as an alpha or even beta release.
I like the work you have done so far!

> Alex, OZ9AEC
> 
> 
> PS: the LCD digits are stolen from the IC-746.
> 

Must be a cool looking rig....

Joop PA4TU

Re: [Hamlib-developer] Here is kenwood_set_level

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

On Sat, 19 Jan 2002 20:01:40 +0100
Stephane Fillod <f4...@fr...> wrote:

> On Fri, Jan 18, 2002, Joop Stakenborg wrote:
> > This patch will add rig_set_level for kenwood.
> > I have only added RIG_LEVEL_AF,RF and SQL. More later.
> 
> Good stuff. commited. 
> Btw Joop, I know you're not very fond of cvs over a modem, 
> but would you like a cvs write access to the repository?
> 

Okay, since it's only small changes every time, cvs write access
would be do-able.
I am about 2 months away from a high speed internet connection
anyway, at last they have decided to offer ADSL in the small town
I live.

> 
> > Stephane, you might want to update kenwood/README.kenwood,
> > since we now have some basic kenwood stuff working...
> 
> Oops. Yep, will add to the TODO list, as well as doc/NOTES, and virtually
> all the README's and such ... (patch welcome :)  ...
> 

I'll have a look at the kenwood stuff.

> 
> Cheers,
>  Stephane F8CFE
> 

Regards,
Joop PA4TU

Re: [Hamlib-developer] Here is kenwood_set_level

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

On Fri, Jan 18, 2002, Joop Stakenborg wrote:
> This patch will add rig_set_level for kenwood.
> I have only added RIG_LEVEL_AF,RF and SQL. More later.

Good stuff. commited. 
Btw Joop, I know you're not very fond of cvs over a modem, 
but would you like a cvs write access to the repository?

> I have tested it with Gnome RIG, part of the groundstation software
> suite, see http://groundstation.sourceforge.net/?grig,
> code is available through CVS.

I got to give it a shot. Last time I checked it out, nothing was told to
work. It's going to be interessting.
Alex, please let me know before releasing grig, we may release
hamlib-1.1.3 first to ease testing.

> Stephane, you might want to update kenwood/README.kenwood,
> since we now have some basic kenwood stuff working...

Oops. Yep, will add to the TODO list, as well as doc/NOTES, and virtually
all the README's and such ... (patch welcome :)  ...


Cheers,
 Stephane F8CFE

Re: [Hamlib-developer] Here is kenwood_set_level

[Alexandru C. <al...@if...>]

I'm glad to hear that Gnome RIG also works for others than me... We were
very close to make an early release, then a deadline on my thesis
prevented me from doing any coding for the last ten days or so. But I'll
be back during the next week.


Alex, OZ9AEC


PS: the LCD digits are stolen from the IC-746.

On Fri, 2002-01-18 at 20:17, Joop Stakenborg wrote:
> This patch will add rig_set_level for kenwood.
> I have only added RIG_LEVEL_AF,RF and SQL. More later.
> 
> I have tested it with Gnome RIG, part of the groundstation software
> suite, see http://groundstation.sourceforge.net/?grig,
> code is available through CVS.
> 
> Grig is a great tool for testing some basic functions. You get a
> cool LCD display (better looking than on my TS870) and settable audio,
> RF level, modes and more. You can tune the rig by clicking with either
> left or right mouse button on the LCD display. Tuning is digit based.
> 
> Stephane, you might want to update kenwood/README.kenwood,
> since we now have some basic kenwood stuff working...
> 
> Regards,
> 
> Joop PA4TU
-- 
------------------------------------------------------------------------
 Alexandru Csete <al...@if...>       Office : 520-332
 Institute of Physics and Astronomy      Web    : www.ifa.au.dk/~alexc
 Ny Munkegade, Building 520              Phone  : (+45) 8942 3622
 University of Aarhus                    Cell.  : (+45) 2962 4317
 Denmark                                 HF-CW  : 7010kHz +/- QRM
------------------------------------------------------------------------

[Hamlib-developer] Here is kenwood_set_level

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

This patch will add rig_set_level for kenwood.
I have only added RIG_LEVEL_AF,RF and SQL. More later.

I have tested it with Gnome RIG, part of the groundstation software
suite, see http://groundstation.sourceforge.net/?grig,
code is available through CVS.

Grig is a great tool for testing some basic functions. You get a
cool LCD display (better looking than on my TS870) and settable audio,
RF level, modes and more. You can tune the rig by clicking with either
left or right mouse button on the LCD display. Tuning is digit based.

Stephane, you might want to update kenwood/README.kenwood,
since we now have some basic kenwood stuff working...

Regards,

Joop PA4TU

Re: [Hamlib-developer] Kylix binding for Hamlib

[<ro...@st...>]

Hello all,

On Mon, 14 Jan 2002, Stephane Fillod wrote:

> Quoting Francois Retief <fgr...@su...>:
>
> > I committed a binding for Borland's Kylix to the CVS.
>
> Great! I used to be a Turbo Pascal fan, from the 4.0 version and onwards.
> That's fun to see this clear language still alive.

I did some Turbo Pascal stuff with DOS a long time ago and wanted to
try Kylix, but I haven't done so yet. And then I read
http://slashdot.org/article.pl?sid=02/01/12/1832223 and the link to
http://freshmeat.net/articles/view/369/ .

Heise.de also has a report on it and notes that since the license is not
available before installation, parts of it might not have legal binding
(here in Germany).

Just for opening your eyes...

73, Robert
-- 
Robert Steinhaeusser, DL1NC / N9KBK                        dl...@da...
http://1409.org                                 ro...@st...

[Hamlib-developer] Re: Kylix binding for Hamlib

[Francois R. <fgr...@su...>]

Hello Stephane,

Stephane Fillod wrote:
> > Included in the tests/ directory is a small demo/test program.
> > It can select a rigs and open a very primative frequency display
> > dialog box.  Will improve later..
> 
> Sorry, I won't be able to give it a try real soon, cause I don't
> have Kylix installed yet. Somehow, I have not seen any Makefile.am
> in your commit. Do you think it's too early to put it into dist?
> Since there's no support in automake for .pas sources, you'll have
> to specify the build process in the Makefile.am, unless this is all
> handled by Kylix itself.

Hmm, forgot about the Makefile.am.  Kylix has also has a command-line
compiler, but I have not used it yet.   Kylix handle it's own build 
process. The user has to include the hamlib_*api.pas files in his
project to use the binding.

> You're right. Hamlib is not checking for non-null rig pointers.
> But this is a tread-of. It depends how deep we trust the programmer
> using the library. Hamlib can very well not check for any error at all.
> However, we implicitly decided to test for initialization errors
> caused by null pointers, catching most probable bug.
> IMHO, verifying non-null rig pointer is a little bit paranoic,
> were are not in the Linux kernel.
> Anyway, it's fast, it's the C language. Adding code to check everything
> with C would advocate for rewritting Hamlib in Java.
> But we like to live dangerously, and avoid breeding bugs in our code :)
> 
> Hamlib only means to check for this:
> 
>         my_rig = rig_init(RIG_MODEL_DUMMY);
>             /* imagine malloc failed, my_rig==NULL */
> 
>         rig_open(my_rig);  /* seg fault... */
> 
> ..and not for random memory corruption within the RIG opaque structure.
> If the user program messes to much with it, it'll get what ít's looking for.
> 
> Now, thinking of it twice (sorry folks, I sometimes happen to not think twice
> when I write code :), Hamlib is not checking the right thing.
> It should check for rig_state.comm_state, preventing for example an app
> from doing rig_set_freq() on a rig handle that was not rig_open'ed.
> What do you all think?

I agree that the magic number testing is going a bit overboard, but 
it is helpfull during testing. I'll keep a seperate patch for testing.

> Btw Francois, you told me earlier you have a patch for the easycomm rotator.
> Is it spinning already? Do you have any plan to commit it before 1.1.3?
> I was thinking also that the rotator API lacks some capabilities,
> like the angular speed of the rotator (what units are best?),
> and also a call like rot_get_destination, useful when the rotator
> is still on its way.

Yes, it is working. Got a little distracted by the Kylix binding. 
Will submit it tonight. 


Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

Re: [Hamlib-developer] Kylix binding for Hamlib

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

Quoting Francois Retief <fgr...@su...>:

> I committed a binding for Borland's Kylix to the CVS.

Great! I used to be a Turbo Pascal fan, from the 4.0 version and onwards.
That's fun to see this clear language still alive.

> Included in the tests/ directory is a small demo/test program.
> It can select a rigs and open a very primative frequency display
> dialog box.  Will improve later..

Sorry, I won't be able to give it a try real soon, cause I don't
have Kylix installed yet. Somehow, I have not seen any Makefile.am
in your commit. Do you think it's too early to put it into dist?
Since there's no support in automake for .pas sources, you'll have 
to specify the build process in the Makefile.am, unless this is all 
handled by Kylix itself.

> One problem I found while testing the binding was that there is no
> way to verify that a non-null rig pointer is pointing to a valid 
> rig structure.  During testing I solved this by adding a magic 
> numbers to the rig structure.

You're right. Hamlib is not checking for non-null rig pointers.
But this is a tread-of. It depends how deep we trust the programmer
using the library. Hamlib can very well not check for any error at all.
However, we implicitly decided to test for initialization errors
caused by null pointers, catching most probable bug.
IMHO, verifying non-null rig pointer is a little bit paranoic,
were are not in the Linux kernel.
Anyway, it's fast, it's the C language. Adding code to check everything
with C would advocate for rewritting Hamlib in Java.
But we like to live dangerously, and avoid breeding bugs in our code :)

Hamlib only means to check for this:

        my_rig = rig_init(RIG_MODEL_DUMMY);
            /* imagine malloc failed, my_rig==NULL */

        rig_open(my_rig);  /* seg fault... */

..and not for random memory corruption within the RIG opaque structure.
If the user program messes to much with it, it'll get what ít's looking for.

Now, thinking of it twice (sorry folks, I sometimes happen to not think twice 
when I write code :), Hamlib is not checking the right thing.
It should check for rig_state.comm_state, preventing for example an app
from doing rig_set_freq() on a rig handle that was not rig_open'ed.
What do you all think? 


Btw Francois, you told me earlier you have a patch for the easycomm rotator.
Is it spinning already? Do you have any plan to commit it before 1.1.3?
I was thinking also that the rotator API lacks some capabilities, 
like the angular speed of the rotator (what units are best?),
and also a call like rot_get_destination, useful when the rotator
is still on its way.


Cheers,

Stephane

[Hamlib-developer] Kylix binding for Hamlib

[Francois R. <fgr...@su...>]

Hello All,

I committed a binding for Borland's Kylix to the CVS.

Included in the tests/ directory is a small demo/test program.
It can select a rigs and open a very primative frequency display
dialog box.  Will improve later..


One problem I found while testing the binding was that there is no
way to verify that a non-null rig pointer is pointing to a valid 
rig structure.  During testing I solved this by adding a magic 
numbers to the rig structure.

Thus instead of

	if (!rig || !rig->caps) {
		return -RIG_EINVAL;
	}

we also check the magic numbers.

	if (!rig || rig->magic != RIG_MAGIC) {
		return -RIG_EINVAL;
	}
	if (!rig->caps || rig->caps->magic != RIG_MAGIC_CAPS) {
		return -RIG_EINVAL;
	}

Should we add magic numbers to the rig structures?  I can submit 
a patch if there is a need.

-- 
Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

[Hamlib-developer] Re: perl bindings, was Re: ft-817

[<si...@al...>]

Hi Stephane,

Yep, I was down that road of making direct Perl bindings for hamlib (which
certainly would be useful), but I'm affraid it won't fit in with my
application...  I'd like to have the rig initialized once, then run the
script many times.  I think with direct Perl bindings, the rig would need to
be initialized each time the script were to run.

A-ha!!!  I got it... write a simple C++ "proxy" that implements the C++ rig
interface, but makes all the calls via RPC to rpcrig... then off to Perl xs
to make it a Perl module!

"I'll get right on it" as they say!  :)

Thanks,
-Chris, aa1vl

----- Original Message -----
From: "Stephane Fillod" <f4...@fr...>
To: <si...@al...>
Cc: "Hamlib developers" <ham...@li...>
Sent: Wednesday, January 09, 2002 4:03 PM
Subject: perl bindings, was Re: ft-817


>
> Hi Chris!
>
> On Sun, Jan 06, 2002, si...@al... wrote:
> > I have a quick question for you:  How easy is it to make SUN RPC calls
from
> > Perl?  I'm just learning Perl and know nothing about RPC... but I
thought it
> > would be fun to be able to make Perl scripts that talk to the rpcrig
server
> > you wrote.  Any pointers?
> >
> > I've found perlrpcgen, but it seems pretty defunct (as asserted by
author)
> > .. is it h2xs I need to use?  This doesn't seem to be the path I need
> > (intuitively), but there's plenty of mention of SUN/ONC RPC Perl
extenstions
> > on the h2xs man page.
> >
> > Any pointers you could give would be greatly appreciated.
>
> Sorry, I don't know any, even though the idea looks cute.
>
> However, this gives me another idea: direct Hamlib perl binding. It should
> be quite feasible using perl xs. For more info, see perlxs(1) and
> perlxstut(1). For this purpose, hamlib++ may even be more appropriate to
> map to the OO approach of perl.
> Any takers?
>
>
> Cheers,
> Stephane
>

Re: [Hamlib-developer] here is kenwood_set_func

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

On Wed, Jan 09, 2002, Joop Stakenborg wrote:
> Attached is a patch against CVS which adds kenwood_set_func.
> Works fine on my ts870. I did not want to do 'case RIG_FUNC_FAGC',
> as I can't test it.

Not a problem. Right now, I think, I really test myself less than 10% of
what I write in Hamlib. Thanks to you guys and your efforts, Hamlib will
have less than 9 chances out of 10 to crash :-)

> Stephane, feel free to edit to your needs.

Don't worry, it's excellent, and commited by the way.
May be this will be extended when testing set_func on TH-D7/TH-F7E.

> One thing to think about: some of these functions are not available
> in all modes. For example, if I want to turn the speech processor
> on when the rig is in CW, '?;' is returned. Same for beat cancel
> and notch. Right now, hamlib will silently ignore it.

You're right, Hamlib should prevent this situations. However, it's too
much work for now (to modelize these limitations in capabilities,
implement in frontend, etc.)
However, one thing that can be done is for kenwood_transaction to return
something like -RIG_EINVAL instead of silently ignoring.

> I have also added a get_level for the agc level (0..255).
> 
> So, on to kenwood_set_level.

Good job Joop. Thank you very much. I wish to kick out a hamlib-1.1.3 very
soon so I can give xlog more attention.

Cheers,

Stephane

Re: AOR report, was Re: [Hamlib-developer] Hi

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

Hi John!

There we go! I've fixed couple of things in the aor backend and commited
it to the cvs rep. There's still no func/level/parm support yet, but I
hope the freq/mode/vfo work better.

Quick reminder for anonymous cvs access to hamlib rep: 

cvs -d:pserver:ano...@cv...:/cvsroot/hamlib login
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/hamlib \
	co hamlib

Eventualy, you may have to set LD_LIBRARY_PATH to the directory where the
backend plugins sit.

You can give testrig a shot (with traces sent by mail).
But rigctl is more interresting to me.
Start it with "rigctl -m 501 -vvvv", and then the commands available are
the following:

f,F	get_freq/set_freq	try various (<1MHz, <30Mhz and >1GHz)
v,V	get_vfo/set_vfo		VFOA, VFOB
m,M	get_mode/set_mode	FM, USB, LSB, CW, WFM, etc.
				passband is in Hz (pass 0 for default)
G	vfo_op			UP, DOWN
_	get_info		should give remote Id and firmware vers


Please, let me know also if the commands issued by Hamlib have the
expected effect on the AOR receiver. From your previous traces, it looks
like the rig accepted some, and some others are still a mistery to me...


Cheers,
Stephane

[Hamlib-developer] perl bindings, was Re: ft-817

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

Hi Chris!

On Sun, Jan 06, 2002, si...@al... wrote:
> I have a quick question for you:  How easy is it to make SUN RPC calls from
> Perl?  I'm just learning Perl and know nothing about RPC... but I thought it
> would be fun to be able to make Perl scripts that talk to the rpcrig server
> you wrote.  Any pointers?
> 
> I've found perlrpcgen, but it seems pretty defunct (as asserted by author)
> .. is it h2xs I need to use?  This doesn't seem to be the path I need
> (intuitively), but there's plenty of mention of SUN/ONC RPC Perl extenstions
> on the h2xs man page.
> 
> Any pointers you could give would be greatly appreciated.

Sorry, I don't know any, even though the idea looks cute.

However, this gives me another idea: direct Hamlib perl binding. It should
be quite feasible using perl xs. For more info, see perlxs(1) and
perlxstut(1). For this purpose, hamlib++ may even be more appropriate to
map to the OO approach of perl.
Any takers?


Cheers,
Stephane

[Hamlib-developer] here is kenwood_set_func

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

Attached is a patch against CVS which adds kenwood_set_func.
Works fine on my ts870. I did not want to do 'case RIG_FUNC_FAGC',
as I can't test it.

Stephane, feel free to edit to your needs.

One thing to think about: some of these functions are not available
in all modes. For example, if I want to turn the speech processor
on when the rig is in CW, '?;' is returned. Same for beat cancel
and notch. Right now, hamlib will silently ignore it.

I have also added a get_level for the agc level (0..255).

So, on to kenwood_set_level.

Regards,

Joop PA4TU

AOR report, was Re: [Hamlib-developer] Hi

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

Hi John!

On Mon, Jan 07, 2002, John Ronan wrote:
> Sorry about talking so long to reply... I tried rigctl and no commands
> seemed to complete succesfully.. (hamlib version 1.1.2). I"m travellinga
> lot at the moment... so I do apologise for not haveing more information.

You don't have to apologise, we're all hacking Hamlib on spare time.
There's no hurry, no stress, just fun!
And btw, your report is very interresting. This is the first time ever 
I see Hamlib traces to an AOR receiver. And It's somehow not so bad!
This give me a better idea on the AOR protocol, what works, 
what doesn't :)     I clearly see where some fixes are needed.

Quick question: did testrig succeeded in changeing some paramters (freq,
mode) ?
Also, are you familiar with CVS? This is to know if you can test
directly from cvs checkouts, or if you prefer me to roll you snapshot
tarballs.  You would benefit from (i.e. be able to test) latest fixes
Development version of rigctl works fine, and is much more versatile than
testrig.

Anyway, thank you very much for your report and your time,

Cheers,
Stephane

> ./testrig 501 -vvvv
> testrig:hello, I am your main() !
> rig:rig_init called
> rig: loading backend aor
> aor: _init called
> rig_register (501)
> rig:rig_open called
> Port /dev/ttyS0 opened ok
> rig_set_vfo: error = Feature not available
> TX 12 bytes
> 0000     52 46 30 30 32 38 33 35 30 31 32 35    RF0028350125
> TX 1 bytes
> 0000     0a     .
> fread_block: timedout after 0 chars
> TX 3 bytes
> 0000     4d 44 36       MD6
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     3f     ?
> TX 12 bytes
> 0000     52 46 30 30 32 31 32 33 35 31 37 35    RF0021235175
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> TX 3 bytes
> 0000     4d 44 33       MD3
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> TX 12 bytes
> 0000     52 46 30 30 30 30 37 37 30 30 30 30    RF0000770000
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     3f     ?
> TX 3 bytes
> 0000     4d 44 32       MD2
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> TX 12 bytes
> 0000     52 46 30 30 30 37 32 35 30 31 30 30    RF0007250100
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> TX 3 bytes
> 0000     4d 44 34       MD4
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     3f     ?
> TX 12 bytes
> 0000     52 46 30 30 30 33 39 38 30 30 30 30    RF0003980000
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> TX 3 bytes
> 0000     4d 44 32       MD2
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> TX 12 bytes
> 0000     52 46 30 30 30 31 38 37 35 30 30 30    RF0001875000
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     3f     ?
> TX 3 bytes
> 0000     4d 44 35       MD5
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> TX 3 bytes
> 0000     4d 44 35       MD5
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> TX 12 bytes
> 0000     52 46 30 30 31 34 32 35 30 33 37 35    RF0014250375
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     3f     ?
> rig_set_freq: error = Target VFO unaccessible
> TX 3 bytes
> 0000     4d 44 34       MD4
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> rig_set_mode: error = Invalid parameter
> rig_set_ptt: error = Feature not available
> rig_set_ptt: error = Feature not available
> rig_get_vfo: error =  Feature not available
> TX 2 bytes
> 0000     52 58  RX
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> rig_get_freq: error =  Invalid parameter
> TX 2 bytes
> 0000     4d 44  MD
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     3f     ?
> rig_get_mode: error =  Invalid parameter
> rig_get_strength: error =  Feature not available
> rig:rig_close called
> TX 2 bytes
> 0000     45 58  EX
> TX 1 bytes
> 0000     0a     .
> RX 1 bytes
> 0000     0a     .
> rig:rig_cleanup called
> port /dev/ttyS0 closed ok

Re: [Hamlib-developer] ts870 and rig_get_func

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

On Tue, 8 Jan 2002 01:21:02 +0100
Stephane Fillod <f4...@fr...> wrote:

> On Mon, Jan 07, 2002, Joop Stakenborg wrote:
> > I have tested the ts870 with a couple of buttons (notch, vox, beat,
> > proc, nb, nr, agc and lock) and the rig_get_func function.
> > Tests were done with minicom and a small c program, linked with 
> > hamlib.
> 
> I still have to code in kenwood_set_func...
> 

Maybe I can give you a hand here. I'll have a look at it.

> > RIG_FUNC_FAGC is bit weird on the ts-870.
> > With most kenwood rigs this would be a button (I am guessing),
> > which would return status 0/1 if the fourth character is a '4'
> > (see kenwood.c, line 585).
> 
> NB: part of the protocol documentation I have comes from the TS2000 manual.
>     There may be some differences between rig models..
> 
> > With the ts870 it is not a button, but a knob, which returns a
> > value between 0 and 255. Should I write a private function for
> > this in ts870s.c?
> 
> Not exactly.  There's a RIG_FUNC_FAGC, and a RIG_LEVEL_AGC.
> This is because some rigs only have on/off FAGC, and some others have
> different levels (e.g. fast/medium/slow), or even AGC delay settable in
> milliseconds.
> I'm wondering if GT0 on the TS870S is for FAGC disabled.
> 

So the way to go for this rig is disable FAGC in FUNCTIONS and
write a get_level for the agc level. I'll have a look into this.

> > I think the problems with the hamlib headers, which
> > I described in an earlier mail, are appearing after running
> > automake.
> 
> yep, I noticed you have automake-1.4-p4, and Hamlib requires automake-1.5
> at least.
> 

Ah, I see. debian sid seems to support both automake 1.4 (automake package)
and automake 1.5 (automake1.5 package). I will install the newer one.
Hopefully I won't suffer from compatiblility problems.

> 
> Thanks for the patch and report!
> 

Glad to help out.
I must say that hamlib is nicely written!

> Cheers,
> Stephane F8CFE
> 

Joop PA4TU

Re: [Hamlib-developer] ts870 and rig_get_func

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

On Mon, Jan 07, 2002, Joop Stakenborg wrote:
> I have tested the ts870 with a couple of buttons (notch, vox, beat,
> proc, nb, nr, agc and lock) and the rig_get_func function.
> Tests were done with minicom and a small c program, linked with 
> hamlib.

I still have to code in kenwood_set_func...

> The attached small patch against CVS of januari 7th will add some 
> more functionality for this rig.

okay, commited. see below.
 
> RIG_FUNC_FAGC is bit weird on the ts-870.
> With most kenwood rigs this would be a button (I am guessing),
> which would return status 0/1 if the fourth character is a '4'
> (see kenwood.c, line 585).

NB: part of the protocol documentation I have comes from the TS2000 manual.
    There may be some differences between rig models..

> With the ts870 it is not a button, but a knob, which returns a
> value between 0 and 255. Should I write a private function for
> this in ts870s.c?

Not exactly.  There's a RIG_FUNC_FAGC, and a RIG_LEVEL_AGC.
This is because some rigs only have on/off FAGC, and some others have
different levels (e.g. fast/medium/slow), or even AGC delay settable in
milliseconds.
I'm wondering if GT0 on the TS870S is for FAGC disabled.

> I think the problems with the hamlib headers, which
> I described in an earlier mail, are appearing after running
> automake.

yep, I noticed you have automake-1.4-p4, and Hamlib requires automake-1.5
at least.


Thanks for the patch and report!

Cheers,
Stephane F8CFE

[Hamlib-developer] Kenwood TH-D7 testing

[Francois R. <fgr...@su...>]

Hello Stephane, All.

Stephane I commited the new code for the TH-D7.  Could you please
test it on the TH-F7 and see what is working and/or broken?  

The testtrn program should also work for TH-F7. Enjoy.
 
 
Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za

[Hamlib-developer] ts870 and rig_get_func

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

I have tested the ts870 with a couple of buttons (notch, vox, beat,
proc, nb, nr, agc and lock) and the rig_get_func function.
Tests were done with minicom and a small c program, linked with 
hamlib.

The attached small patch against CVS of januari 7th will add some 
more functionality for this rig.

RIG_FUNC_FAGC is bit weird on the ts-870.
With most kenwood rigs this would be a button (I am guessing),
which would return status 0/1 if the fourth character is a '4'
(see kenwood.c, line 585).
With the ts870 it is not a button, but a knob, which returns a
value between 0 and 255. Should I write a private function for
this in ts870s.c?

I think the problems with the hamlib headers, which
I described in an earlier mail, are appearing after running
automake.

Regards,

Joop PA4TU

[Hamlib-developer] Re: Kenwood backend, etc

[Francois R. <fgr...@su...>]

Hello Stephane

Stephane Fillod wrote:
> 
> Great! We'll have to add the new callbacks to the frontend.
> However, if I remember well, the "AI" command does not send what has changed
> but the complete status of the rig right after the event happened.
> Is it what you noticed on the THD7?
> So the backend would have to remember the previous state, and from the delta,
> find and call only the appropriate callbacks. Is it worth the trouble?

The AI command is only used the switch transceive mode on or off.  
The actual async events is exactly the same as normal commands, 
ie. When the band A/B button is pressed, an 'BC 0' or 'BC 1' is sent,
or when a signal measurement is given, 'SM 0,03', etc.

But when a frequency changed, the complete vfo status is sent, ie
'BUF 0,00145830000,0,0,0,0,,05,,03,00060000,0' which include among
others include the Frequency, VFO, Mode, Split, Tone, CTCSS and 
a few more.  At the moment I only generate an callback event for 
the VFO, Frequency and Mode. The other data is currently ignored.

Do we include an callback for all possible async events? I counted 
almost 30 events that can be send async.  I was thinking of adding
callbacks for the most popular/useful/frequently used events,
ie. Frequency, signal strength, VFO, etc.  and a general purpose
callback that handle all the rest/unhandled events.

Thus a GUI app can hook into the frequency callback for fast 
display updates and hook into a general-purpose callback that signal
stuff like keyboard-lock, lamp on/off, etc.  I think Hamlib should 
not store the state of the radio. It should serve as a control
instrument and an event notifier.

> > I created an account today. login name: fgretief
> > Once created I'll commit my latest changes.
> 
> okay, you're in. happy hacking!
> There's no written down rules, just common sense. Adding stuff is no problem.
> Just ask for discussion on the list if you plan to do major or heavy
> changes on the API/frontend.

Thanks.

> > I have been playing with a Hamlib binding for Borland's Kylix.
> > Should I contribute it to Hamlib?
> 
> Oh yes, sure! please! We have already c++, tcl, and I can see perl
> and python bindings which stand out in the horizon.
> You can create a separate directory, much like c++ and tcl, coming along
> with a simple sample program illustrating the new binding. This will give
> others (starting from me :) envy and a quick start in Borland's Kylix.

Will do.

 
Cheers
  Francois Retief

--
---------------------------------------------------------------------
Electronic Systems Laboratory (ESL)
University of Stellenbosch
South Africa
Tel. +27-21-808-4472

** Developers of the SUNSAT micro-satellite **
http://sunsat.ee.sun.ac.za