Loading...
Searching...
No Matches
PLAN

    Here is a non-exhaustive list of things IMO to keep in mind while
    developing 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 heuristics)
    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 remotely 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 overridden)
    o Write some memory channel handling (name, mode, freq/vfo, duplex, split, ..)

    Any other ideas?

    Frank Singleton
    Stephane Fillod