Various python side work items to enable PowerMon reporting and analysis.
DONE: Talk to a RD6006
DONE: Set voltage for test
DONE: set a low current limit
DONE: Do the PowerMon power logging per requirements, generate slog file
let the python side talk to PowerStress service on the device. Use that service to turn the PM messages on or do various stress algoritms
add a power mon logging enabled bool in the flash config. default off.
New command line options
--slog-out filepath|'default' - stores our slog data in the specified path or an automatically selected location if 'default'
--slog-in filepath - Instead of talking to actual hardware, just use a preexisting structured log file as our input. Mostly used for post-hoc debugging and regression testing
--power-voltage 3.3 - Turn on the power supply with the given voltage WARNING, you can damage hardware if you pick this number incorrectly. Be very careful, especially when switching between boards.
--power-rigol portname - connect to a rigol power supply for any required power data
--power-ppk2 - connect to an NordicSemi "Power Profiler Kit II" power supply for any required power data
--power-log intervalmsec | 'auto' - set power sampling rate (but even if not set, we will always include power readings in the slog if a power meter is configured
--auto-test alg-num - talks to the unit under test and asks it to do a predictable/repeatable set of tests.
--reporting - generate Pandas based power reports - both graphically and as text
Structured logging (slog)
If structured logging is used, we will generate a .slog file for the session. We will also store the full device config data (as JSON) and metadata about the log file in a .mlog file.
Auto-test algorithms
Currently these tests are only used for power testing. Eventually this mechanism could be used for other automated tests that require interaction from outside of the UUT (eventually even things like automated CI testing of our protocol using portduino and multiple simulated nodes).
1: Walks through a series of states emitting special logs before/after each state. Runs the state long enough to collect power data for that state
2: Normal-operation config - runs the node for 30 minutes to get a picture of normal operation. Includes enough log data so we can have stats on % and total for: lora-rx, lora-tx, gps-on, screen-on, sleeping, channel utilization,gps lock statistics etc...
3: Router config - same as 2 but configured as a screenless router with GPS mostly off
4: Tracker config - same as 2 but a headless send only GPS beacon every N minutes.
5: Supply test - Puts hw in an unchanging config, with periodic PM messages, so that the python tool can ramp voltage down slowly and we can find when brownout occurs and also detect if the buck converter on the UUT has degenerate behavior.
0: normal config - it is possible that auto-tests might change config settings that affect board behavior. this 'test' undoes those changes and then exits.
Various python side work items to enable PowerMon reporting and analysis.
New command line options
--slog-out filepath|'default' - stores our slog data in the specified path or an automatically selected location if 'default'
--slog-in filepath - Instead of talking to actual hardware, just use a preexisting structured log file as our input. Mostly used for post-hoc debugging and regression testing
--power-voltage 3.3 - Turn on the power supply with the given voltage WARNING, you can damage hardware if you pick this number incorrectly. Be very careful, especially when switching between boards.
--power-rigol portname - connect to a rigol power supply for any required power data
--power-ppk2 - connect to an NordicSemi "Power Profiler Kit II" power supply for any required power data
--power-log intervalmsec | 'auto' - set power sampling rate (but even if not set, we will always include power readings in the slog if a power meter is configured
--auto-test alg-num - talks to the unit under test and asks it to do a predictable/repeatable set of tests.
--reporting - generate Pandas based power reports - both graphically and as text
Structured logging (slog)
If structured logging is used, we will generate a .slog file for the session. We will also store the full device config data (as JSON) and metadata about the log file in a .mlog file.
Auto-test algorithms
Currently these tests are only used for power testing. Eventually this mechanism could be used for other automated tests that require interaction from outside of the UUT (eventually even things like automated CI testing of our protocol using portduino and multiple simulated nodes).