This page details the model and how it is configured. The implementation is quite simplistic at present and may be extended for future requirements.
the persistence service
The persistence service is a node that supports the requirements of getting and setting model data, interrogating the model in defined ways and persisting the model. A simple scheme has been chosen for the model. This scheme is possible mainly because the language can be scripted and therefore actual source files can be treated like confiiguration files are in compiled languages.
The model has to meet three main criteria;
- to be performant,
- to be persistent and
- to support versioning.
The service must;
- abstract away the details of how the model is represented, accessed and stored, and
- enable the model to be extended easily as frequent changes are required.
in-memory representation and persistent store
The in-memory representations are python dictionaries. There are a number of dictionaries involved which are detailed later. The in-memory structure could really be as complex as required, there are no limitations, these are objects and not rows in a relational table or text in an XML file. The data of course must be accessible through the service interface in a simple way, i.e. it must be well abstacted from the representation. Storage of these structures is performed through the object serialisation capability of Python which is supported by the pickle module. There are few things that can't be serialised, hence the statement that the structure can be as complex as required.
The dictionaries in the persistent service modules contain initialisation values for the data. This is like setting up a database then loading it with default data. The startup process is as follows.
- Attempt to read the database files into memory.
- If a file is present on disc then compare its version number with that in the initialisation data (there can be several versions numbers in a dictionary). If the version of the initialisation data is later then use that data else use the disc version.
- If the file is not present on disc then write out a new file using the initialisation data, then read it back in and use it as the working data.
There are two ways to change data.
- Add the new data, or edit existing initialisation data in the python files and then either up the version number or delete the database files.
- Bring the system up and use the options panel to change data. Note that not all the data in the system is currently available through the options panels.
the model scheme
The model consists of three parts.
A running radio has exactly one of each part. The bootstrap process which is the first screen you see queries the persistence service for the profiles and then offers a user selection of the available profiles. Each radio configuration must have a separate profile. A profile has exactly one capability set. The capabilities define which features the radio has so that the GUI properly models the radio. Capabilities can be shared, so several profiles might have the same capability. Finally there must be exactly one dynamic set of data with the same name as the profile. The dynamic data is the state of the radio whereas the profile is more to do with static data, such as might be set by the options panels.
This is an example of the profile and associated initialisation data for a radio that supports Ozy and DttSp. The objective here is not to explain the data, that will be done in a configuration section TBD, but rather to show how things link together.
The profile contains static data like paths and the nodes to start up for the radio. In this instance it can be seen that there are three nodes (plus the event service and persistence node) to run a local HPSDR Ozy/Mercury system. The Ozy driver itself, a DSP, in this case DttSp and a single GUI. Although this is primarily static data some of it can be dynamic. The rate and frames for example can be changed live through the options panels but most changes require a restart..
'OZY/DttSp - Local':
'version' : 0,
'description': 'Standard local profile for HPSDR using Mercury and Penelope with DttSp.',
# Note, no spaces in process list
The capability is a link to cap#3 which is a DttSp capability with VFO capable hardware.
# DttSp with HPSDR
It is quite likely that more stuff will go into the capabilities as things progress. At present 'tx' is off because I have not implemented the tx path.
Dynamic (dynamic.py)The dynamic set is very depemndent on the capabilities. In the example there are 4 sets of data for the main radio and 3 sub-receivers. If the capability multirx was false then only one set of data would be expected. The dynamic set will change as more of the project evolves
'OZY/DttSp - Local':
'version' : 0,
# One of vfoa,vfob,offseta,offsetb
'gain' : 50,
TBD. This section will contain a description of every variable in the configuration files.