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