[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