hamlib-developer — hamlib developers forum

[Hamlib-developer] cvs tree structure

[Frank S. <vk...@ix...>]

Hi,

I was thinking of adding a new directory to the
cvs tree eg: "generic" or "frontend" to     hold
the generic front end code. I will place it at
the same level as "common". ie: just under "hamlib".


Comments ??

/Frank
-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

Re: [Hamlib-developer] hamlib design?

[Frank S. <vk...@ix...>]

Hi,


Welcome aboard, its no fun sending emails to myself ;-)

See comments below...

/Frank

Stephane Fillod wrote:
> 
> Okay, I started to code a generic rig API layer (kinf of frontend),
> based on Frank's code and ideas in the air. This will lead to a generic
> framework, making it even easier to develop rig backend seamlessly.
> However, I have a few questions:
> 
> 1) Should we assume any rig has no more than 2 VFOs ? Do you have examples?

**
should get from hardware capability structure -- see below
yaesu have at least 3 in some cases

**
Rig lib should return actual and symbolic info.

eg: no. of VFO's and their symbolic
meaning. ie: generic VFO-0 is Main or VFO-A or Sub VFO on rig xxx

eg: 3rd RX is sattelite RX ?


> 
> 2) Is a rig able to notify asynchronously the "host" any event (like a key has been depressed on the panel, main VFO freq changed, etc.) ? Examples?

**
Hmmm, rig callbacks, lets start an api for it anyway - event based, 

hmmm.. rig deamon  (server) send a IP packet to client for example 

I am not aware of yaesu doing it, but we should code for it.  


> 
> 3) Should cmd_set_freq_main_vfo_hz() set both freq and mode or should we split in two separate functions?

**
Some rigs may behave differently,  lets cover both !!


> 
> Here is a non-exhaustive list of things IMO to keep in mind when
> developping the hamlib library.
> 
> Plan:
> ----
> o develop the library as a shared/static library   * yes
> o portable (not only Linux, but UN*X, Win32 using cygwin,etc.  -> autoconf?) - * yes, gtk for GUI 
> o generic (any rig made, any model) - yes
> o wrappable (Java, perl module, Python module, etc.) - * yes java wrappers and some jni stuff ok
> o support serial ports, IrDA ports, USB ports, network ports (w/ a daemon) - * yes, and  client / server also
> o thread safe (reentrant) would be a must - * yep, posix threads here we come !!
> o support preference file (eg. /etc/hamlibrc, ~/.hamlibrc ) - * yes, read from /etc then home
> o written in C (C++ would have been more appropriate, but C is okay) - * i kind of like C and java :-)
> o support more than one rig per application (ie. generic code) - * ok
> o support more than one rig per serial port (ie. Icoms) - *ok
> o handle serial retransmission and timeouts would be nice - * yep, threaded read/writes are good
> o i18n support if applicable - ok
> o software compensation for the actual radio oscillator frequency errors
> o if avail., support events sent by the rig (eg. main freq has been changed,..) - event notifaction
> o maybe add some misc functions like PTT signaling (through serial/parallel..)
> o ...


****
A few more functions / addons

- software scanning (and huristics)
- s/w squelch
- real time spectral analysis and digital modes ( I have written some
working code for this)
  it does 40 frames / sec and no load, really cool to see time and
spectral info !!
  I have based it on generic data engine and plugins !! output also to
small gtk window.
  ie: DSP API


- doppler compensation in tracking mode
- ie: let real time signal analysis drive freq/modes/etc....
- software controlled hopping (poor mans GSM frequency hopping)
   also, must output hopping sequence to other rig to be useful

- networked rigs, provides realtime (global) spectral analysis to
  find (a common) quiet part of the band for a qso between 2 parties

- 

> 
> -> Christmas is in sight, time for whishlists!
> 
> Good inspiration:
> ----------------
> o SANE, with frontend/backend scheme, dynamic loading, autoconf, etc.
> o struct net_device (Linux kernel) for the void *priv idea
> o any rigctrl sources out there ?
> 
> Capabilities:   - ** this is definitely the challenge
> ------------
> We have to find a way to code capabilities in the hamlib in order
> to let the application know what this rig is able to do (before
> attempting to do it and crash :).
> I think some features can be coded using bit fields and masking.
> 
> Maybe we can distinguish between 3 states :
>   - Don't have this feature,
>   - Have it,
>   - Have it and can control (r/w) it remotly using the backend in hamlib
> 
> o freq ranges supported: rx/mode?, tx/modes/power ?  ->How to code this??
> o number of VFO, operations (set VFO separately, VFO A=B, switch, ..)
> o freq granularity (resolution), tuning steps
> o SCAN functions (start, stop, ..)

> o Split (cross band, duplex, ...)
> o RIT (+- KHz)
> o Memory scheme, what is stored in, quantity, call channels, scan edges
> o ATT, P.AMP, AGC, NB, TONE, TSQL, COMP, VOX, BK-IN, ...
> o Tuner control (internal, external, can control)
> o Meter indication: Squelch condition, S-meter level, ALC, SWR
> o Number of antennas (which band ?) and selection
> o available "set mode" items (ie. rig setup), and provide a way to modify them
> o DSP ? - one of my favorite areas, see comments above
> 
> any other ideas?


Many of above fall into a general "rig function capability structure"


Could be internal data structures populated inside each lib, 
and requested by the app.
Note generic <-> symbolic transforms


any app      generic  (front)       rig lib (backend)
-------      -------                -------

   ----------->
    get caps for 
     rig xxxx

                    get caps
                 -------------->    { internal data structure }


                  caps struct populated
                <--------------

apps knows rigs
capability. now
do something useful.


Also frontend can request 2 modes of commands

- acknowledged / unacknowledged mode

unack
------

eg:

set freq to xxx
--------------->
returns -1 if error
assume ok otherwise


OR

acked mode

set freq to xxx
--------------->
                 set freq
              ------------------------->
                get freq
              ------------------------->
                 freq retuerned
             <-------------------------

            compare requested 
            with actual 

  result
<--------------




I think we are forced to bite the bullet so to speak,
and start some rig capabilities stuff. I have only
scratched the surface with rig.h and rig_caps structure.


Also, each backend must provide a  rigxxx_read and rigxxx_write etc..
inside serial.c. 

frontend only sees read/write


Also, returned data must be uniform accross all rigs.


eg: TX power in dbm, not  0-15 units on yaesu and 0 - 23 units on icom


.... more to come I am sure...



> 
> --
> Stephane
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> http://lists.sourceforge.net/mailman/listinfo/hamlib-developer


Cheers / Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com

[Hamlib-developer] hamlib design?

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

Okay, I started to code a generic rig API layer (kinf of frontend),
based on Frank's code and ideas in the air. This will lead to a generic
framework, making it even easier to develop rig backend seamlessly.
However, I have a few questions:

1) Should we assume any rig has no more than 2 VFOs ? Do you have examples?

2) Is a rig able to notify asynchronously the "host" any event (like a key has been depressed on the panel, main VFO freq changed, etc.) ? Examples?

3) Should cmd_set_freq_main_vfo_hz() set both freq and mode or should we split in two separate functions?


Here is a non-exhaustive list of things IMO to keep in mind when
developping the hamlib library.


Plan:
----
o develop the library as a shared/static library
o portable (not only Linux, but UN*X, Win32 using cygwin,etc.  -> autoconf?)
o generic (any rig made, any model)
o wrappable (Java, perl module, Python module, etc.)
o support serial ports, IrDA ports, USB ports, network ports (w/ a daemon)
o thread safe (reentrant) would be a must
o support preference file (eg. /etc/hamlibrc, ~/.hamlibrc )
o written in C (C++ would have been more appropriate, but C is okay)
o support more than one rig per application (ie. generic code)
o support more than one rig per serial port (ie. Icoms)
o handle serial retransmission and timeouts would be nice
o i18n support if applicable
o software compensation for the actual radio oscillator frequency errors
o if avail., support events sent by the rig (eg. main freq has been changed,..)
o maybe add some misc functions like PTT signaling (through serial/parallel..)
o ...

-> Christmas is in sight, time for whishlists!


Good inspiration:
----------------
o SANE, with frontend/backend scheme, dynamic loading, autoconf, etc.
o struct net_device (Linux kernel) for the void *priv idea
o any rigctrl sources out there ?

Capabilities:
------------
We have to find a way to code capabilities in the hamlib in order
to let the application know what this rig is able to do (before
attempting to do it and crash :).
I think some features can be coded using bit fields and masking.

Maybe we can distinguish between 3 states :
  - Don't have this feature,
  - Have it, 
  - Have it and can control (r/w) it remotly using the backend in hamlib

o freq ranges supported: rx/mode?, tx/modes/power ?  ->How to code this??
o number of VFO, operations (set VFO separately, VFO A=B, switch, ..)
o freq granularity (resolution), tuning steps
o SCAN functions (start, stop, ..)
o Split (cross band, duplex, ...)
o RIT (+- KHz)
o Memory scheme, what is stored in, quantity, call channels, scan edges
o ATT, P.AMP, AGC, NB, TONE, TSQL, COMP, VOX, BK-IN, ...
o Tuner control (internal, external, can control)
o Meter indication: Squelch condition, S-meter level, ALC, SWR
o Number of antennas (which band ?) and selection
o available "set mode" items (ie. rig setup), and provide a way to modify them
o DSP ?

any other ideas?


-- 
Stephane

[Hamlib-developer] hamlib 1.0.3 release

[Frank S. <vk...@ix...>]

Hi,

Well here is the first release of the hamlib libraries.

There is a lot of work to do, but I do have API's
implemeneted for FT747GX and FT847 radios  mostly
implemented. :-)

Examples of test programs to say connect to a radio
and do something usefuly (like change frequency for
example) are in the test directory for each radio
type.  

At the moment the API's are described in each
radio's header file.

eg: ft747.h of ft847.h

Basically you connect to a rig, issue commands, and
then diconnect.

A C code snippet to connect to a FT847 and set
the frequnecy of the main VFO to 439,700,000 Hz ,
using FM as the required mode, would look something 
like this.

<snip>

  int fd;
  
  fd = rig_open(SERIAL_PORT);
  printf("port %s opened ok \n",SERIAL_PORT);
  
  cmd_set_cat_on(fd);		/* cat on */
  cmd_set_freq_main_vfo_hz(fd,439700000,MODE_FM);
  cmd_set_cat_off(fd);		/* cat off */
  
  rig_close(fd);
  printf("port %s closed ok \n",SERIAL_PORT);

<snip>


There are NO GUI's yet, but I mainly wanted to
get the libraries implemented, so people can
start using them for implementing cool stuff.

Perhaps I will even add a GUI section as well if
I get enough volunteers.

If you are interested in joining the crew, let me 
know and I can arrange that.

It mainly helps if you have some type of radio and
a copy of the control docs (eg:  User Manuals).

It is hoped that the API's get documented well enough
for developers to just use this library. In fact I have
made function wrappers for some of the raw "CAT" calls
that make life a bit easier.

eg: You dont have to worry about BCD conversion and
packing data according to the Radio's manual.

Most command can use specify the freq in Hz and mode 
like MODE_FM, MODE_CW etc..

  cmd_set_freq_main_vfo_hz(fd,439700000,MODE_FM);

Any common routines should eventually live in
the "common" directory.


Anyway, take a look around. No fancy web pages yet
(volunteers ??) but the core libraries are being
developed all the time and provide useful
functionality.

If you want to help me out, contact me at the
"Open Discussion Forum" news area at
http://sourceforge.net/projects/hamlib/

-- Frank..

-- 
Frank Singleton				VK3FCS

Email: victor kilo three foxtrot charlie sierra at ix dot netcom dot com