This page is for jotting down design ideas.
Musings on TX
The next and final part of the basic functionality is the TX capability. To state the blindingly obvious, TX and RX are quite different animals. The RX side for a start is more complex, has more things that can be done with it, especially when sub-receivers are considered. There has been talk about full duplex operation and while its not yet possible with current hardware/firmware the software should assume it is and cater for it.
My first thoughts are therefore to completely separate TX and RX paths. This is pretty straight forward to do in Acorn at the expense of a few more processes. I'm thinking aloud and working out what needs to be done. While doing that, writing it down always seems to help the thought process. These are initial thoughts, it's not set in stone.
- The Acorn system is defined by interfaces. When I look at those interface definitions they largely reflect how the nodes interact for a receiver. Of course some interfaces (such as life_cycle) or parts of interfaces (such as part of the DSP interface) are revelevent to both. The first change therefore should be to define a complete set of interfaces for both TX and RX.
- Rather than try to combine a GUI to cater for both TX and RX I envisage a separate RX and TX GUI. The current GUI is composed of two parts, the main window which includes all the usual interactors and the options panels, and the graphic display for metering and panadapter etc. The main display can be cloned to cater for viewing options separately and to have separate windows for each receiver. This dosn't fit terribly well with the requirements of the TX side. The plan therefore is to strip all the TX controls from this interface which currently just get greyed out if the radio capability db says no TX. Another similar but smaller main window will carry all the TX interactors including the TX options. This will be accompanied by a TX display so that both incoming and outgoing displays are available if working duplex.
- To manage these multiple windows I might upgrade the bootstrap process to be a kind of dashboard rather then have clone and display buttons on the main windows as this won't extend well to having a TX window and display. An advantage of this is that the system can be restarted much more quickly with a different profile if the bootstrap is still running.
- As well as a separate TX GUI and display there should be a separate DSP. This is simply a clone of the existing one but with the TX rather than RX interfaces. Having two processes, one running RX and one TX full duplex will be possible but it will also allow faster switching.
- There will still only be one process that controls the hardware, whatever the hardware might be. It will however, support separate interfaces for TX and RX and do what it needs to do manage the hardware correctly.
- The model I will probably keep as a single model as there is some cross-over between TX and RX and some common state.
- What about the interactions between TX and RX. Capabilities will say RX or TX\RX. If TX capable then TX capabilities could say simplex/half-duplex/full-duplex. I've not thought through the semantics of these yet but I think essentially simplex will lock the TX frequency, mode and filter to same for the RX. In fact I think the TX GUI will disallow changes and the RX is in charge. I guess one has to allow IRT/ITT on these but nothing else. The other modes will unlock and allow free movement of the TX in relation to the RX. If the mode in half-duplex then any split frequency should be allowed. If the mode is duplex then there must be adequate separation between TX and RX frequencies before transmission is allowed.
Interfaces
First stab at the new interface set:
Existing Interfaces | Comments |
life_cycle | To
control the life-cycle of a node. Not all nodes understand the concept
of starting and stopping so they may no-op these but terminate must be
implemented as this is used to close the system down.
|
command | Currently used as the command interface to hardware so generally implemented by any node that connects to hardware.
|
dsp | The superset of possible dsp commands.
|
persist | Manages the profiles, getting and setting data and saving the current state of the in-memory structures to the database files.
|
streamin | Manages an incoming IQ audio stream.
|
streamout | Manages an outgoing L/R audio stream.
|
update | This
namespace actually has two interfaces, update and config. Update is
used to update anyone interested in presentation state such as a GUI or
a CAT node. Config is used to notify configuration changes that should
be implemented immediately.
|
New Interfaces | |
mic_in | A new interface to support mic data from the hardware to the tx_dsp. |
iq_out | A new interface to support transmit IQ audio. |