Enables UPSV=1 low power mode for R510 when idle for >=9.2s

[technobly]

⚠️ NOTE: First MERGE referenced MUXER PR, then before merging this PR, REBASE WITH MUXER master checked out and pulled.

Problem

• R510 modem consumes more power than R410 modem by design. This is unexpected behavior for some customers migrating from R410 to R510.

Solution

• Reduce power consumption for R510 based devices by enabling UPSV=1 mode which will automatically reduce power consumption after 9.2s of being idle. Note: Some extreme cases of the modem requiring over 2 minutes to drop into a low power state have been observed and are being investigated. Typically though, if the AT interface is idle, the modem will automatically reduce power consumption.

Steps to Test

• Compile APP=tinker-serial1-debugging and observe after device is idle, power consumption drops from 30-38mA avg. down to 8-12mA avg.
• Integration test - device-os-test run bsom wiring/no_fixture_long_running -v -- -fixture
• Integration test - device-os-test run boron wiring/no_fixture_long_running -v -- -fixture
• Integration test - device-os-test run esomx wiring/no_fixture_long_running -v -- -fixture

References

• reset keepalive timeout when period set/changed gsm0710muxer#11

---

Completeness

• User is totes amazing for contributing!
• Contributor has signed CLA (Info here)
• Problem and Solution clearly stated
• Run unit/integration/application tests on device
• Added documentation
• Added to CHANGELOG.md after merging (add links to docs and issues)

[scott-brust]

Tests passed for me when I ran them locally on a boron:

device-os-test --test-dir ~/develop/device-os/user/tests/integration --device-os-dir ~/develop/device-os run wiring/no_fixture_power_saving boron -v -- -fixture
Test directory: /Users/scottbrust/develop/device-os/user/tests/integration
Device OS directory: /Users/scottbrust/develop/device-os
Firmware binaries directory: /Users/scottbrust/develop/device-os/build/integration
Generating test matrix
Initializing API client
URL: https://api.particle.io
Authenticating with access token
Signed in as device-os-ci@particle.io
Subscribing to device events
Initializing device manager
Enumerating USB devices
Retrieving devices from the cloud
Device pool:
e00fce6801bbf404f387daf9 (scott-us-brn404x-dvt3-mxic-1)
No fixtures configured
Running tests


  No fixture power saving
    boron
    Target device: e00fce6801bbf404f387daf9 (scott-us-brn404x-dvt3-mxic-1)
    Flashing application: no_fixture_power_saving.bin
    Getting device tests
      systemThread=disabled
        Initializing device test suite
        Running device test: POWER_SAVING_00_setup
        Device test passed
        ✓ POWER_SAVING_00_setup (7.1s)
        Running device test: POWER_SAVING_01_particle_publish_publishes_an_event_after_low_power_active
        Device test passed
        Waiting cloud event: my_event_low_power
        ✓ POWER_SAVING_01_particle_publish_publishes_an_event_after_low_power_active (44.2s)
        Running device test: POWER_SAVING_02_register_function_and_connect_to_cloud
        Device test passed
        ✓ POWER_SAVING_02_register_function_and_connect_to_cloud (37.6s)
        Running device test: POWER_SAVING_03_call_function_and_check_return_value_after_low_power_active
        Device test passed
        ✓ POWER_SAVING_03_call_function_and_check_return_value_after_low_power_active (1.5s)
        Running device test: POWER_SAVING_04_check_function_argument_value
        Device test passed
        ✓ POWER_SAVING_04_check_function_argument_value (5.9s)
        Running device test: POWER_SAVING_05_system_sleep_with_configuration_object_ultra_low_power_mode_wake_by_network
        Device test notified about expected reset
        Device test passed
        ✓ POWER_SAVING_05_system_sleep_with_configuration_object_ultra_low_power_mode_wake_by_network (85.4s)
        Running device test: POWER_SAVING_06_check_function_argument_value
        Device test passed
        ✓ POWER_SAVING_06_check_function_argument_value (5.9s)
        Running device test: POWER_SAVING_99_cleanup
        Device test passed
        ✓ POWER_SAVING_99_cleanup
      systemThread=enabled
        Initializing device test suite
        Running device test: POWER_SAVING_00_setup
        Device test passed
        ✓ POWER_SAVING_00_setup (7.2s)
        Running device test: POWER_SAVING_01_particle_publish_publishes_an_event_after_low_power_active
        Device test passed
        Waiting cloud event: my_event_low_power
        ✓ POWER_SAVING_01_particle_publish_publishes_an_event_after_low_power_active (75s)
        Running device test: POWER_SAVING_02_register_function_and_connect_to_cloud
        Device test passed
        ✓ POWER_SAVING_02_register_function_and_connect_to_cloud (36.6s)
        Running device test: POWER_SAVING_03_call_function_and_check_return_value_after_low_power_active
        Device test passed
        ✓ POWER_SAVING_03_call_function_and_check_return_value_after_low_power_active (2.4s)
        Running device test: POWER_SAVING_04_check_function_argument_value
        Device test passed
        ✓ POWER_SAVING_04_check_function_argument_value (5.9s)
        Running device test: POWER_SAVING_05_system_sleep_with_configuration_object_ultra_low_power_mode_wake_by_network
        Device test notified about expected reset
        Device test passed
        ✓ POWER_SAVING_05_system_sleep_with_configuration_object_ultra_low_power_mode_wake_by_network (85.5s)
        Running device test: POWER_SAVING_06_check_function_argument_value
        Device test passed
        ✓ POWER_SAVING_06_check_function_argument_value (5.9s)
        Running device test: POWER_SAVING_99_cleanup
        Device test passed
        ✓ POWER_SAVING_99_cleanup
    Resetting device


  16 passing (7m)

I also saw the device go into power save mode with the Otii power measurements

How did you observe the CTS1 pin when in power save mode? Did you do testing on an EVK? I think the only board of ours that I might be able to probe is an esomx...

[scott-brust]

I probed an ESOMX and can see the CTS pulses in power save mode 👍

[avtolstoy]

Just the R410 waitResponse() thing is a bit worrying.