Skip to content

Config refactoring#44

Open
zandi wants to merge 4 commits intomeshtastic:masterfrom
zandi:config-refactoring
Open

Config refactoring#44
zandi wants to merge 4 commits intomeshtastic:masterfrom
zandi:config-refactoring

Conversation

@zandi
Copy link
Contributor

@zandi zandi commented Feb 17, 2026

Not as significant as I want, but a good chunk of work to check in. Instead of generating new Config objects in different modules, just use a single Config object created in the lib.config module. This should avoid issues where different modules can operate using different configurations. Later on I'd like to do more refactoring, like reorganizing the config and using more properties so it's less of a giant flat collection of mostly-static values that are directly referenced.

The biggest change is adding a large function test for the discrete simulation. I replicate the simulation that loraMesh.py would do for 10 nodes, as if executing loraMesh.py 10, and compare the results against a "known good" reference run. This is a bit complex and high-level for a unit test, but will be useful for easily checking if any particular change has an impact on the results generated by the simulation. This should help give confidence to make bigger changes that don't change simulation results.

zandi added 4 commits February 8, 2026 22:50
It was possible to use different instances of Config with different values.
Just make a single instance in the config module and have users import that.
Since SLOT_TIME depends on the current preset, which may change at
runtime (although it shouldn't), make a function for this rather than
using a pre-computed variable which may get stale if the preset changes.

Other parts of phy.py call current_preset which allows for this dynamic
behavior, so adapt SLOT_TIME to match, even though the preset really
shouldn't change mid-sim.
This replicates the simulation that executing `loraMesh.py 10` would do,
asserting that we arrive at the expected results. This test may be relatively
fragile, but IMO is important for detecting when a change influences simulation
results. This should help catch any bugs or other unintentional changes that
could impact simulation consistency. But there will certainly be sim
improvements that warrant changing the "known good" reference simulation
results.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant