{"action":"created","issue":{"url":"https://api.github.com/repos/spark/firmware/issues/1150","repository_url":"https://api.github.com/repos/spark/firmware","labels_url":"https://api.github.com/repos/spark/firmware/issues/1150/labels{/name}","comments_url":"https://api.github.com/repos/spark/firmware/issues/1150/comments","events_url":"https://api.github.com/repos/spark/firmware/issues/1150/events","html_url":"https://github.com/spark/firmware/issues/1150","id":186046166,"number":1150,"title":"Low Power Modes API","user":{"login":"technobly","id":2249224,"avatar_url":"https://avatars.githubusercontent.com/u/2249224?v=3","gravatar_id":"","url":"https://api.github.com/users/technobly","html_url":"https://github.com/technobly","followers_url":"https://api.github.com/users/technobly/followers","following_url":"https://api.github.com/users/technobly/following{/other_user}","gists_url":"https://api.github.com/users/technobly/gists{/gist_id}","starred_url":"https://api.github.com/users/technobly/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/technobly/subscriptions","organizations_url":"https://api.github.com/users/technobly/orgs","repos_url":"https://api.github.com/users/technobly/repos","events_url":"https://api.github.com/users/technobly/events{/privacy}","received_events_url":"https://api.github.com/users/technobly/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2016-10-29T00:02:14Z","updated_at":"2016-10-29T17:13:05Z","closed_at":null,"body":"## **Goal:** \r\n>propose a Low Power Modes API that is intuitive, hardware/device agnostic as possible, camelCase and easy to remember.\r\n\r\n**This issue is related to these issues pertaining to different low power modes:**\r\n#xxxx - Wi-Fi Eco mode\r\n#xxxx - Cellular Eco Mode\r\n#xxxx - System Eco mode\r\n#922  - Wi-Fi powersave mode on Photon/P1\r\n#935  - Low Power Run mode\r\n\r\n| API | What it does |\r\n|:--|:--|\r\n| WiFi.enableEco() | Turns Eco mode on with a 500ms[1] throughput delay by default |\r\n| WiFi.enableEco(10) | Turns Eco mode on with a throughput delay of 10 milliseconds (drops to low power mode 10 milliseconds after TX/RX), pass a 0 for no throughput delay. |\r\n| WiFi.disableEco() | Turns Eco mode off, resets any currently set throughput delay |\r\n| WiFi.ecoEnabled() | Return if Eco mode is on, off or on with throughput delay |\r\n| Cellular.enableEco() | Turns Eco mode on |\r\n| Cellular.disableEco() | Turns Eco mode off |\r\n| Cellular.ecoEnabled() | Return if Eco mode is enabled |\r\n| System.enableEco() | Put system in Eco mode, until System.disableEco() is called. |\r\n| System.enableEco(60) | Put system in Eco mode for 60 seconds or until System.disableEco() is called, code can still execute, limited peripherals |\r\n| System.disableEco() | Put system back in full power operation mode |\r\n| System.ecoEnabled() | Return if Eco mode is enabled |\r\n\r\n| Future API | What it does |\r\n|:--|:--|\r\n| System.setSpeed(clockSpeed) | Sets the system clockSpeed, e.g. CLOCK_SPEED_120MHZ |\r\n| System.enablePeripheral(systemPeripheral) | Enable the systemPeripheral, e.g. PERIPHERAL_SPI. Only takes effect if System.ecoEnabled() is true |\r\n| System.disablePeripheral(systemPeripheral) | Disable the systemPeripheral, e.g. PERIPHERAL_SPI. Only takes effect if System.ecoEnabled() is true |\r\n| System.setConfig(SystemConfig& profile) | Change the default configuration used in System.enableEco() to enable/disable other | clock/peripheral settings. This API that combines the use of other future APIs: System.setSpeed() and System.enable/disablePeripheral() as a single command |\r\n| System.getConfig(SystemConfig& profile) | Retreive the currently set system configuration |\r\n\r\n>[1] 500ms subject to change.  This will be based on typical roundtrip TCP message times with an additional factor of padding to ensure maximum throughput speed by default.\r\n\r\nThere is no Network.enableEco() proposed because the operation of each Eco mode for each device type may behave a bit differently as follows:\r\n\r\nBehind the scenes, WiFi Eco mode has a unique concept of an optional throughput delay which keeps the system in high speed operation after the transmission is complete, for the duration of the delay.  This is useful if responses are expected and full performance is desired.  After delay, the WiFi will be set back in Eco mode automatically.  There is a minimum delay associated with exiting Eco mode automatically when transmissions begin again, but it's neglagable as it's less than 1ms (_double check this value_).\r\n\r\nBehind the scenes, Cellular Eco mode does not have a optional throughput delay, but will automatically enter and exit Eco mode when the modem is used for communication.  A 20ms delay is automatically applied before each new AT command sent to the modem when Eco mode is enabled.  This delay is required to allow the modem to transition from Eco mode to normal operation mode again.  After the command is processed the modem will automatically re-enter Eco mode.  This will slow down the operation of the modem a bit during all system commands as well (about _add percentage here_), with the benefit of improved power efficiency.\r\n\r\nBehind the scenes, System Eco mode drops the STM32 processor clock speed to _XX_ MHz and disables all peripherals except (_name the peripherals required for simple timing and GPIO_).  Code continues to execute in this mode at a slower pace based on the system clock speed.  Some commands are not functional when the clock speed is this low (_provide a table of available commands_).\r\n\r\n---\r\n\r\nCompleteness:\r\n- [x] Minimum test case added\r\n- [x] Device, system and user firmware versions stated\r\n- [x] Particle confirmed"},"comment":{"url":"https://api.github.com/repos/spark/firmware/issues/comments/257103565","html_url":"https://github.com/spark/firmware/issues/1150#issuecomment-257103565","issue_url":"https://api.github.com/repos/spark/firmware/issues/1150","id":257103565,"user":{"login":"m-mcgowan","id":2465470,"avatar_url":"https://avatars.githubusercontent.com/u/2465470?v=3","gravatar_id":"","url":"https://api.github.com/users/m-mcgowan","html_url":"https://github.com/m-mcgowan","followers_url":"https://api.github.com/users/m-mcgowan/followers","following_url":"https://api.github.com/users/m-mcgowan/following{/other_user}","gists_url":"https://api.github.com/users/m-mcgowan/gists{/gist_id}","starred_url":"https://api.github.com/users/m-mcgowan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/m-mcgowan/subscriptions","organizations_url":"https://api.github.com/users/m-mcgowan/orgs","repos_url":"https://api.github.com/users/m-mcgowan/repos","events_url":"https://api.github.com/users/m-mcgowan/events{/privacy}","received_events_url":"https://api.github.com/users/m-mcgowan/received_events","type":"User","site_admin":false},"created_at":"2016-10-29T17:13:05Z","updated_at":"2016-10-29T17:13:05Z","body":"I'm not sure we need to be ruthlessly consistent about this.  But if we do, my take is to only deprecate `Wire.setSpeed()` if it's also deprecated in the Arduino SDK since that's our baseline. \r\n\r\nThe system config has the potential to cover different types of config that have different persistence needs.  We already have System.set()/System.get() for feature flags - should these be rolled into the config API too? I believe we should, and then there are cases where some settings are persisted to flash, others to backup RAM while others are only stored in RAM.  This is why I feel system config should be nothing more than a data-driven way to call all our other APIs, so that each API can document it's persistence characteristics, and what it does.  To put another way, I feel there should be no setting in the system config that you cannot also set via some other API `System.setXXXX()`, and the API is the source of truth, behavior and documentation for that setting. "}}
{"actor":{"display_login":"m-mcgowan"}}