rpitx-control-dev-0.5

Handling the situation when the filter is not installed

Now, you can tell the program that the filter is not installed on the PCB.

What is it for? For example, you are using the rpitx-expansion-board-SP6T board but have soldered only 3 filters out of 6 since you simply do not need the remaining filters - to highlight that the filters are not installed on the PCB, you can select the "<Not installed>" item when selecting the case type for a specific filter. In this case, the RF path for this filter will be excluded from the activation list, and in the main menu of the application, you will see only those filters that are available for activation.

If you do not select at least one filter that is installed on the expansion board, an appropriate error will be displayed, and you will be returned to the initial menu where you can either create a new or load an existing device configuration. You will not be able to save the configuration of an expansion board that does not have at least one correctly initialized filter.

The changes also affected the display of information about the active expansion board. Now, if the filter is not installed, you will see the corresponding information.

Added information about the current expansion board in the main menu of the application

The information is displayed in the first line in the menu for selecting control actions.

The changelog has been moved to the __init__.py file

Codebase refactoring

Related changes to the whiptail-dialogs library

Fixed a bug with the output of multi-line messages when calling menu() and showlist() functions. This error affected the correct display of the expansion board status in the board actions selection menu.

rpitx-control-dev-0.4

Adding the ability to install an application on the system

Added setup.py file containing information about the ControlApplication package and allowing you to install the application on the system using pipx. It is recommended to install application using pipx, in which case the application will be installed in an isolated environment and will not affect packages already installed on the system.

Installing and launching the application is done as follows:
sudo apt update && sudo apt install git pipx
git clone https://github.com/IgrikXD/rpitx-expansion-board
cd rpitx-expansion-board
pipx ensurepath
pipx install .
rpitx-control

Uninstalling an application:
pipx uninstall rpitx-control

The installation and operation of the application was tested using the following configuration:

Handling the situation of missing CONFIGS_DIR directory

Now, if the CONFIGS_DIR directory does not exist, when you try to load the device configuration, an error message is displayed after which you return to the main application menu:

Previously, such an action would cause an exception and crash the application.

Displaying information about GPIO ports simulation mode

If IS_MOCK_GPIO_USED = True is set, when the application starts, an information message will be displayed stating that GPIO ports simulation is being used. The state of the actual GPIO ports will not be changed during application execution. This mode is used only for debugging the application on devices other than Raspberry Pi.

Changing the configuration creation process

Now, if you accidentally select an incorrect component case, you can go back a step by clicking the Cancel button and select the component case again.

If you click the Cancel button in the component case selection menu, the creation of the device configuration will be aborted and you will be returned to the main menu.
Previously, when you clicked the Cancel button, regardless of whether you were selecting a component case or a specific component model, configuration creation was aborted and you were returned to the main menu.

Avoiding the use of application startup arguments

Application startup arguments are no longer used as this approach is incompatible when using entry_points in setup.py. entry_points initiates the launch of a specific function specified in its parameters. With this launch model, sys.argv contains only the name of the script to be launched; any additional arguments passed are ignored!

Now, to enable debug mode (launch argument --show-debug-info), before installing the application, you need to run the following command, which will set the variable SHOW_DEBUG_INFO = True and activate debug mode:
sed -i 's/SHOW_DEBUG_INFO = False/SHOW_DEBUG_INFO = True/' ControlApplication/main.py

To use MockFactory to simulate GPIO ports (launch argument --use-mock-gpio), before installing the application you need to run a command that will set the variable IS_MOCK_GPIO_USED = True and enable GPIO ports simulation:
sed -i 's/IS_MOCK_GPIO_USED = False/IS_MOCK_GPIO_USED = True/' ControlApplication/main.py

The --help argument is no longer processed by any alternative methods.

Changing the module import process

Modules are now imported relative to the ControlApplication package name. This is necessary for the application to work correctly after installation.

Updating the main README.md file

Updating information about the application installation and uninstallation process.

Updating .gitignore

Excluding directories related to the application installation process.

Codebase refactoring

rpitx-control-dev-0.3

Transferring directories of model files and saved configurations

The FiltersList and AmplifiersList directories have been moved to the ControlApplication directory. Now, dumps of components and configurations of expansion boards are saved taking into account the parent directory in which the application source files are located.

Changing in application execution flow

The application execution order has been changed. Now, when you start the program, you are asked to choose one of two possible actions: creating a new device configuration or loading an existing one.
When creating a new configuration, you are prompted to select the type of device for which the configuration is being created.
When loading an existing configuration, you are prompted to select a configuration file from the list (the board type is determined automatically). If the application does not find information about saved configurations, an information message is displayed, after which you will be returned to the main menu.

Checking for the presence of .csv files of component models

When the program starts, it checks whether .csv files exist in the FiltersList and AmplifiersList directories. These files are used to build a list of available components when creating a device configuration. If it is not possible to load the previously created .pkl dump of the list of components and the necessary .csv files to build the list of components are missing, an error message is displayed in the console and the program ends.

Implementation of the Logger class

Now, logging is performed using a separate Logger class. Logger is initialized when the ComponentsList, RFSwitch, RFSwitchWrapper, and UserInterface classes are created if the class constructors were passed the path to the logging file, by default: log_filename = None (no logging is performed) and the application launch parameter --show-debug-info is used.

Codebase refactoring

rpitx-control-dev-0.2

Changing GPIO state in individual threads

When the activateRFPath() function is called, the activateRFOutput() function is called on a separate thread for each of the RFSwitch objects. This eliminates the problem of sequential switching of GPIO states for each of the RFSwitch objects - first, the input switch was switched, then the output switch. Now, we switch the states of two switches simultaneously.

Creating a list of available components in separate threads

The ComponentsList constructors are now called in separate threads, which allows reading data about filters and amplifiers in parallel rather than sequentially.

Processing .csv files in separate threads

When creating a ComponentsList object, each of the .csv files is now processed in a separate thread.

Logging changes

Added highlighting of application start and stop timestamp using '-' signs.

Whiptail interaction changes:

whiptail_interface.msgbox() is now called with an additional --scrolltext parameter. This is a more correct approach when working with the whiptail library. However, you must use a version of whiptail that supports these changes: https://github.com/IgrikXD/whiptail-dialogs

Updating the main README.md file

Update basic information about the project. Added information on how to use the repository and draft information about expansion boards implementation.

rpitx-control-dev-0.1

rpitx-control console GUI implementation:

To begin, you are asked to select an available expansion board from the list. Devices containing "LNA" in their name, in addition to filters, additionally support built-in switchable LNA.

After which you can either create a new or load an existing device configuration.

When you select the "Load device configuration" option, you will be asked to specify the path to the configuration file that you are going to load.
By default configuration files are saved in (ControlApplication/UserInterface.py:12):
CONFIGS_DIR = "./SavedConfiguration/"

If the device configuration is loaded successfully, a corresponding message is displayed.

If the configuration file you specified does not exist, an error message is displayed, after which you will be asked to correct the name of the configuration file.

When you click the Cancel button, you will be returned to the expansion board selection menu.

If you create a new configuration, you will be prompted to select the case style and the appropriate filter/amplifier depending on the expansion board used.

After creating a configuration for the current expansion board, information about it will be saved:

If you press the Cancel button while creating the device configuration, the configuration creation will be interrupted and you will return to the expansion board selection menu.

What is device configuration? Essentially, this is just a list of filters and amplifiers that are used on your specific expansion board. This information is used for informational purposes only, so that when switching filters you understand which specific filter and with what characteristics you are using without having to write this information somewhere else.

Once a configuration is created or loaded, information about the active configuration is displayed.

After which you are taken to the main menu of the program, where you can activate a specific filter or switch the state of the built-in LNA.

When you enable a specific filter, a message is displayed indicating that the filter has been activated and the status of the active filter is updated. If the selected filter is different from the current one, the state of the GPIO ports will be changed to enable a different RF signal path for the RF input and output switch. When you try to enable an already active filter, the state of the GPIO ports does not change!

When you switch the status of the built-in LNA, information about its new installed status is displayed.

To terminate the program, you need to select the Cancel option, after which the program will be finished.

Added .csv files for filter and LNA models:

To build the filter model we use the following information:
Model Number, Case Style, Description, Filter Type, Passband F1 (MHz), Passband F2 (MHz), Stopband F3 (MHz), Stopband F4 (MHz)
.csv files with information about filters located in (ControlApplication/main.py:12):
FILTER_MODELS_DIR = "./FiltersList"

To build an amplifier model we use the following information:
Model Number, Case Style, Subcategories, F Low (MHz), F High (MHz), Gain (dB) Typ.
.csv files with information about amolifiers located in (ControlApplication/main.py:11):
AMPLIFIER_MODELS_DIR = "./AmplifiersList"

.csv files are processed only when the program is launched for the first time. Based on the extracted information, a list of available filters and amplifiers is created, which is saved in files (ControlApplication/main.py:13-14):
FILTER_DUMP_FILE = "FiltersListDump.pkl"
AMPLIFIER_DUMP_FILE = "AmplifierDump.pkl"
When you run the program again, these files are read and avoid repeated parsing of .csv files, which saves startup time.

Handling command line options:

Added the ability to use MockFactory to simulate real GPIO ports and test the application without physical access to the Raspberry Pi (add the --use-mock-gpio key when launching the application).

Implemented a debugging mode for logging application actions to a text file (add the --show-debug-info key when launching the application).
Default log file (ControlApplication/main.py:16):
LOG_FILENAME = "./ControlApplication/DebugInfo.log"

Information that the program is running in debugging mode is displayed on the UI:

The following actions are logged:

• Application start/stop timestamp.
• Information on loading/saving filter and amp model files.
• Information about loading/saving a device configuration file.
• Information about whether MockFactory is used to simulate GPIO operation.
• Information about initializing RF switches and switching their state.

Added the ability to display help information when starting the application (add the --help switch when launching the application).

Updating the main README.md file

Added basic information about the project.
Added a list and description of expansion boards available for use (the boards are not currently implemented).

Updating .gitignore

Excluding saved expansion board configuration files.
Excluding log files.