Home of the G3UKB Acorn-SDR project

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. The model I will probably keep as a single model as there is some cross-over between TX and RX and some common state. 
  7. 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.


First stab at the new interface set:

Existing InterfacesComments
life_cycleTo 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.

  • This interface remains as is but may be extended.
commandCurrently used as the command interface to hardware so generally implemented by any node that connects to hardware.

  • This will be split into RxControl and TxControl to allow two frequencies and separate control  of TX and RX. In general Tx commands will come from the TxGUI and Rx from the RxGUI.
dspThe superset of possible dsp commands.

  • There will be two and possibly more dsp processes running. The correct commands must be sent to the correct dsp and therefore this interface will be split into RxDsp and TxDsp with an appropriate command set. A dsp will know what it is when instantiated. In general Tx commands will come from the TxGUI and Rx from the RxGUI.
persistManages the profiles, getting and setting data and saving the current state of the in-memory structures to the database files.

  • This interface will remain as is as there should only be one model.
streaminManages an incoming IQ audio stream.

  • This interface accepts receive IQ samples from the hardware. This will be renamed to iq_in. The rx dsp will implement iq_in.
streamoutManages an outgoing L/R audio stream.

  • This interface outputs L/R audio data to the hardware. This will be renamed to rx_out. The hardware output node will implement rx_out. The current hardware nodes are Ozy and streamout. The streamout node may also have a name change.
updateThis 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.

  • Updates will now be generated by the hardware node and the dsp. However, updates will be relevent to Rx or Tx and in some cases both. It may be necessary to split this three ways to support the updates and keep them properly partitioned. Some nodes may generate both rx and tx updates depending on the circumstances.
New Interfaces
mic_inA new interface to support mic data from the hardware to the tx_dsp.
iq_outA new interface to support transmit IQ audio.