Initial spectrum scope support

[mikaelnousiainen]

This PR adds initial abstraction for retrieving and adjusting spectrum scope data from rigs. This implementation is based on documentation for Icom (IC-7300, IC-7610, IC-785x, IC-705, IC-9700 and IC-R8600) and Kenwood (TS-890S, TS-990S) rigs, where common features have been implemented as standardized levels/funcs and as an abstraction for the spectrum data structures.

The actual implementation to read and parse spectrum data exists only for Icom rigs and has been tested only on an IC-7300 (via serial port connection). The rest of the Icom implementations are based on documentation only. It is necessary to test this on other rigs that support Ethernet connectivity, as the format for spectrum data is slightly different with a single line of spectrum data delivered in a single CI-V frame instead of being split into multiple frames -- the parser should support this already.

The spectrum data is parsed in decode_event functions (like icom_decode_event), as the data is pushed by the rig once the feature is enabled. Reading the spectrum data requires Hamlib transceive function to be enabled via A ON command.

The actual data is delivered to a new spectrum_event callback that is currently simply wired to print out the spectrum line in ASCII format, as the multicast server implementation #695 that should output the data is not finished yet.

The implementation supports multiple spectrum scopes, as rigs with multiple receivers, like the Kenwood ones and IC-7610, IC-785x and IC-9700, allow choosing and enabling output of spectrum data for one or both of the Main/Sub spectrum scopes.

This PR adds the following funcs and levels:

• RIG_FUNC_TRANSCEIVE - Enable transceive functionality in rig to push state changes automatically to computer. Added the command for multiple Icom rigs. Should be extended to all models supporting this. Enabling transceive mode is NOT needed for spectrum support, but it was easy to add this level, as we will be using the transceive mode soon for the multicast server.
• RIG_LEVEL_SPECTRUM_MODE - Spectrum scope mode: CENTER, FIXED, CENTER_SCROLL or FIXED_SCROLL
• RIG_LEVEL_SPECTRUM_SPAN - Spectrum span in Hz (in CENTER mode)
• RIG_FUNC_SPECTRUM_HOLD - Pause spectrum updates
• RIG_LEVEL_SPECTRUM_SPEED - Spectrum speed
• RIG_LEVEL_SPECTRUM_REF - Spectrum reference level in dB
• RIG_LEVEL_SPECTRUM_AVG - Spectrum scope averaging
• RIG_LEVEL_SPECTRUM_EDGE_LOW - Spectrum scope low edge in Hz (in FIXED or the SCROLL modes)
• RIG_LEVEL_SPECTRUM_EDGE_HIGH - Spectrum scope high edge in Hz (in FIXED or the SCROLL modes)
• RIG_LEVEL_SPECTRUM_ATT - Spectrum attenuator, supported only by Kenwood rigs and IC-785x

Additionally, the following Icom-specific ext levels have been implemented:

• SPECTRUM_DUAL - Single/Dual spectrum scope choice
• SPECTRUM_TX - Spectrum scope enabled during TX
• SPECTRUM_CENTER - Spectrum center position regarding filter width
• SPECTRUM_VBW - Video Band Width for scope
• SPECTRUM_EDGE - Currently selected frequency edge number (in FIXED or SCROLL modes)
• SPECTRUM_RBW - Resolution Band Width for scope (only IC-7610)

The Icom rigs implement the FIXED/SCROLL mode edges in a slightly complex way by storing 4 edge freq presets for each frequency range. This has been simplified so that the RIG_LEVEL_SPECTRUM_EDGE* levels simply pick the current edge number and the frequency range based on the current frequency and modify that frequency range automatically. Kenwood rigs seem to have a simpler way of setting the edge frequencies directly without many presets.

NOTE: This implementation is not yet ready for "production use" and needs changes in other parts of Hamlib. The constant spectrum data stream pushed by the rig seems to interfere with responses expected for other commands. It may also be that the flushing of serial port might remove some of the spectrum data accidentally. We will need to refactor the way commands expect responses as the rig may output transceive / spectrum data at any moment.

[mdblack98]

One thing we'll need to do for supporting transceive mode is remove the rig_flush
I just posted a patch to misc.c that will allow you to turn off flushing.
Change the #undef RIG_FLUSH_REMOVE in misc.c now to #define and see how it behaves
It's probably going to take more than this but this is a first step.
There's some code in icom.c looking for transceive packets and pausing to allow it to be flushed after a frequency change. Could read there or maybe do an async read.

retval = icom_transaction(rig, cmd, subcmd, freqbuf, freq_len, ackbuf,
                          &ack_len);
hl_usleep(50 * 1000); // pause for transceive message and we'll flush it

#define RIG_FLUSH_REMOVE
int HAMLIB_API rig_flush(hamlib_port_t *port)
{
#ifdef RIG_FLUSH_REMOVE
rig_debug(RIG_DEBUG_TRACE, "%s: called for %s device\n", func,
port->type.rig == RIG_PORT_SERIAL ? "serial" : "network");

if (port->type.rig == RIG_PORT_NETWORK
        || port->type.rig == RIG_PORT_UDP_NETWORK)
{
    network_flush(port);
    return RIG_OK;
}

if (port->type.rig != RIG_PORT_SERIAL)
{
    rig_debug(RIG_DEBUG_WARN,
              "%s: Expected serial port type!!\nWhat is this rig?\n", __func__);
}

return serial_flush(port); // we must be on serial port

#else
return RIG_OK;
#endif
}