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


Plan:
----
o Hamlib is intended to provide the means to control any capable rig
o develop the library as a shared/static library
o portable (not only Linux, but UN*X, Win32 using cygwin, etc. -> autoconf?)
o be good, be generic (any rig made, any model)
o uniform data types/units (eg. for power, use Watts, not rig specific val)
o wrappable (Java, C++, 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 much 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 nicely serial retransmission and timeouts
o i18n support if applicable
o software compensation for the actual radio oscillator frequency errors(mode?)
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 Well documented API, and Howto write a new rig backend
o ...


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 ?


Applications:
------------
o control your rig from your computer, can be handy if you've relocated 
	your UHF transceiver in the attic, to reduce cable loss.
o edit/backup/restore/extend the memory capacity of your rig
o software scanning (and huristics)
o s/w squelch
o real time spectral analysis and digital modes ( Frank has written some
	working code for this) it does 40 frames / sec and no load, 
	really cool to see time and spectral info !!
	He has based it on generic data engine and plugins !! output also to
	small gtk window.
o doppler compensation in tracking mode (using mtrack satellite tracker?)
o let real time signal analysis drive freq/modes/etc.... (eg. PSK31 tuning)
o networked rigs, provides realtime (global) spectral analysis to
  find (a common) quiet part of the band for a qso between 2 parties
o software controlled hopping (poor mans GSM frequency hopping)
   also, must output hopping sequence to other rig to be useful
o computer assisted scanner
o <add here the application you thought it'd be impossible>


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
o number of VFO, operations (set VFO separately, VFO A=B, switch, ..)
o freq granularity, tuning steps (-> array)
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 ?

o max memory channel
o per rig timeout/retry (can be overriden)
o Write some memory channel handling (name, mode, freq/vfo, duplex, split, ..)

Any other ideas?


Frank Singleton
Stephane Fillod