mirror of
https://github.com/meshtastic/meshtastic.git
synced 2025-02-21 03:25:51 -08:00
Merge pull request #387 from meshtastic/updated_device_confi
Delete page all about power states that are gone, update display config
This commit is contained in:
Garth Vander Houwen
GitHub
commit
80c2c27aea
|
|
@ -103,7 +103,7 @@ values={[
|
|||
<br />
|
||||
|
||||
:::warning
|
||||
Some of these boards contained the wrong component in the LiPo battery charging circuit allowing the battery to be overcharged. While this does appear to have been fixed, please see the [warning](https://www.thethingsnetwork.org/community/berlin/post/warning-attention-users-of-ttgo21-v16-boards-labeled-t3_v16-on-pcb-battery-exploded-and-got-on-fire) on The Things Network for more information.
|
||||
Early versions of some of these boards contained the wrong component in the LiPo battery charging circuit allowing the battery to be overcharged.
|
||||
:::
|
||||
|
||||
[<img src="/img/hardware/lora-v2.1-1.6.png" alt="LILYGO® TTGO Lora V2.1-1.6" style={{zoom:'25%'}} />](/img/hardware/lora-v2.1-1.6.png)
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ sidebar_label: Display
|
|||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
The display config options are: Screen On Duration, Auto Carousel Interval, and GPS Format. Display config uses an admin message sending a `Config.Display` protobuf.
|
||||
The display config options are: Screen On Duration, Auto Carousel Interval, Always Point North and GPS Format. Display config uses an admin message sending a `Config.Display` protobuf.
|
||||
|
||||
## Device Config Values
|
||||
|
||||
|
|
@ -17,6 +17,11 @@ How long the screen remains on after the user button is pressed or messages are
|
|||
### Auto Carousel Interval
|
||||
|
||||
Automatically toggles to the next page on the screen like a carousel, based the specified interval.
|
||||
|
||||
### Always Point North
|
||||
|
||||
If this is set, the compass heading on the screen outside of the circle will always point north. This feature is off by default and the top of display represents your heading direction, the North indicator will move around the circle.
|
||||
|
||||
### GPS Format
|
||||
|
||||
The format used to display GPS coordinates on the device screen.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ sidebar_label: WiFi
|
|||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
The WiFi config options are: AP Mode, Hidden AP, SSID and Password. WiFi config uses an admin message sending a `Config.WiFi` protobuf.
|
||||
The WiFi config options are: Enabled, SSID, Password and WiFi Mode. WiFi config uses an admin message sending a `Config.WiFi` protobuf.
|
||||
|
||||
:::info
|
||||
Enabling WiFi will disable bluetooth. Only one connection method will work at a time.
|
||||
|
|
@ -19,6 +19,10 @@ You can [force the device to boot into SoftAP mode](#software-access-point) by r
|
|||
|
||||
## WiFi Config Values
|
||||
|
||||
### Wifi Enabled
|
||||
|
||||
Enables WiFi.
|
||||
|
||||
### WiFi SSID
|
||||
|
||||
In [SoftAP](#software-access-point) mode, this is the SSID broadcast to access your device's WiFi. In [Client](#wifi-client) mode, this is your WiFi Networks SSID. This string is case sensitive.
|
||||
|
|
@ -27,19 +31,15 @@ In [SoftAP](#software-access-point) mode, this is the SSID broadcast to access y
|
|||
|
||||
In [SoftAP](#software-access-point) mode, this is the password to access your device's WiFi. In [Client](#wifi-client) mode, this is your WiFi Networks password. This string is case sensitive.
|
||||
|
||||
### Software Access Point (AP)
|
||||
### WiFi Mode
|
||||
|
||||
A boolean value that toggles the [Software Access Point](#software-access-point)
|
||||
#### Acceptable values
|
||||
|
||||
Acceptable values are `true` or `false`
|
||||
|
||||
### Hidden Access Point (AP)
|
||||
|
||||
A boolean value that toggles the hidden access point
|
||||
|
||||
Acceptable values are `true` or `false`
|
||||
|
||||
If set, the node AP will broadcast as a hidden SSID
|
||||
| Value | Description |
|
||||
| :-------: | :--------------------------: |
|
||||
| `client` | Client |
|
||||
| `accessPoint` | [Software Access Point](#software-access-point) |
|
||||
| `AccessPointHidden` | Software Access Point (Hidden) |
|
||||
|
||||
:::tip
|
||||
The first time your device restarts after enabling the WiFi access point, it will take an additional 20-30 seconds to boot. This is to generate self-signed SSL keys. The keys will be saved for future reuse.
|
||||
|
|
@ -78,18 +78,19 @@ No WiFi config options are available in the python CLI.
|
|||
|
||||
| Setting | Acceptable Values | Default |
|
||||
| :-----------: | :---------------: | :-----: |
|
||||
| wifi.ap_mode | `true`, `false` | `false` |
|
||||
| wifi.ap_hidden | `true`, `false` | `false` |
|
||||
| wifi.enabled | `true`, `false` | `false` |
|
||||
|
||||
| wifi.psk | string | `""` |
|
||||
| wifi.ssid | string | `""` |
|
||||
| wifi.mode | `client`, `accessPoint`, `accessPointHidden` | `client` |
|
||||
|
||||
```shell title="Enable / Disable SoftAP"
|
||||
meshtastic --set wifi.ap_mode true
|
||||
meshtastic --set wifi.ap_mode false
|
||||
```shell title="Enable / Disable WiFi"
|
||||
meshtastic --set wifi.enabled true
|
||||
meshtastic --set wifi.enabled false
|
||||
```
|
||||
|
||||
```shell title="Make Access Point Hidden"
|
||||
meshtastic --set wifi.ap_hidden false
|
||||
meshtastic --set wifi.mode accessPointHidden
|
||||
```
|
||||
|
||||
```shell title="Set WiFi SSID"
|
||||
|
|
@ -181,4 +182,4 @@ You should then be able to connect to the node using either the displayed IP add
|
|||
|
||||
### Disable WiFi
|
||||
|
||||
To disable WiFi completely, set `wifi.ap_mode` to `false`, and both `wifi.ssid` & `wifi.psk` to an empty string `""`.
|
||||
To disable WiFi completely, set `wifi.enabled` to `false`.
|
||||
|
|
@ -20,4 +20,4 @@ Meshtastic config is now broken into 6 sections. [Device](settings/config/device
|
|||
|
||||
## Module Config
|
||||
|
||||
Meshtastic includes the following modules: Canned Messages, External Notification, Range Test, Serial, Store & Forward and Telemetry (sensors).
|
||||
Meshtastic includes the following modules: [Canned Messages](settings/moduleconfig/canned-message), [External Notification](settings/moduleconfig/external-notification), [Range Test](settings/moduleconfig/range-test), [Serial](settings/moduleconfig/serial), and [Telemetry (sensors)](settings/moduleconfig/telemetry).
|
||||
|
|
@ -60,13 +60,13 @@ GPIO Pin Value (1-39) For encoder port B
|
|||
|
||||
GPIO Pin Value (1-39) For encoder Press port
|
||||
|
||||
### Input Broker Event CW
|
||||
### Input Broker Event Clockwise
|
||||
|
||||
Generate input event on CW of this kind.
|
||||
Generate the rotary cloockwise event.
|
||||
|
||||
### Input Broker Event CCW
|
||||
### Input Broker Event Counter Clockwise
|
||||
|
||||
Generate input event on CCW of this kind.
|
||||
Generate the rotary counter cloockwise event.
|
||||
|
||||
### Input Broker Event Press
|
||||
|
||||
|
|
@ -251,12 +251,12 @@ Replace each `GPIO` (x3) below with the GPIO numbers from your hardware setup.
|
|||
:::
|
||||
|
||||
```shell title="Canned Message Module - Required Rotary Encoder Module Settings"
|
||||
meshtastic --set canned_message.rotary1_pin_a GPIO
|
||||
meshtastic --set canned_message.rotary1_pin_b GPIO
|
||||
meshtastic --set canned_message.rotary1_pin_press GPIO
|
||||
meshtastic --set canned_message.rotary1_event_cw KEY_UP
|
||||
meshtastic --set canned_message.rotary1_event_ccw KEY_DOWN
|
||||
meshtastic --set canned_message.rotary1_event_press KEY_SELECT
|
||||
meshtastic --set canned_message.inputbroker_pin_a GPIO
|
||||
meshtastic --set canned_message.inputbroker_pin_b GPIO
|
||||
meshtastic --set canned_message.inputbroker_pin_press GPIO
|
||||
meshtastic --set canned_message.inputbroker_event_cw KEY_UP
|
||||
meshtastic --set canned_message.inputbroker_event_ccw KEY_DOWN
|
||||
meshtastic --set canned_message.inputbroker_event_press KEY_SELECT
|
||||
meshtastic --set canned_message.rotary1_enabled True
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -11,8 +11,6 @@ import TabItem from '@theme/TabItem';
|
|||
|
||||
Power settings on a Meshtastic device can be set like other user-define settings with the `--set` command see ([see Meshtastic-python](/docs/software/python/python-cli)). Some of these options are implicit in other commands. For example, when you set the device to router mode using `is_router true`, it is implied that deep sleep is disabled and we want to constantly listen for messages. Below is a list of all user-definable settings and the acceptable values that these settings can use.
|
||||
|
||||
For a description and more information on what exactly all of these mean, please refer to [Power Management State Machine](/docs/software/other/power)
|
||||
|
||||
## Settings
|
||||
|
||||
| Setting | Acceptable Values | Default |
|
||||
|
|
@ -200,7 +198,7 @@ Configuring this setting is not yet available for the selected platform. If this
|
|||
|
||||
### ls_secs
|
||||
|
||||
Power management state machine option. See the [power page](/docs/software/other/power) for details. 0 for default of 3600.
|
||||
0 for default of 3600.
|
||||
|
||||
#### Configure ls_secs
|
||||
|
||||
|
|
@ -237,7 +235,7 @@ Configuring this setting is not yet available for the selected platform. If this
|
|||
|
||||
### mesh_sds_timeout_secs
|
||||
|
||||
Power management state machine option. See the [power page](/docs/software/other/power) for details. 0 for default of two hours, use the MAXUINT or 4294967295 to disable.
|
||||
0 for default of two hours, use the MAXUINT or 4294967295 to disable.
|
||||
|
||||
#### Configure mesh_sds_timeout_secs
|
||||
|
||||
|
|
@ -278,7 +276,7 @@ Configuring this setting is not yet available for the selected platform. If this
|
|||
|
||||
### min_wake_secs
|
||||
|
||||
Power management state machine option. See the [power page](/docs/software/other/power)for details. 0 for default of 10 seconds.
|
||||
0 for default of 10 seconds.
|
||||
|
||||
#### Configure min_wake_secs
|
||||
|
||||
|
|
@ -352,7 +350,7 @@ Configuring this setting is not yet available for the selected platform. If this
|
|||
|
||||
### phone_timeout_secs
|
||||
|
||||
Power management state machine option. See the [power page](/docs/software/other/power) for details. 0 for default of 15 minutes.
|
||||
0 for default of 15 minutes.
|
||||
|
||||
#### Configure phone_timeout_secs
|
||||
|
||||
|
|
@ -389,9 +387,6 @@ Configuring this setting is not yet available for the selected platform. If this
|
|||
|
||||
### screen_on_secs
|
||||
|
||||
Power management state machine option. See the [power page](/docs/software/other/power) for details.
|
||||
|
||||
|
||||
- Greater than Meshtastic 1.3 - 0 for default of 10 minutes
|
||||
- Less than Meshtastic v1.3 - 0 for default of 1 minute
|
||||
|
||||
|
|
@ -430,7 +425,7 @@ Configuring this setting is not yet available for the selected platform. If this
|
|||
|
||||
### sds_secs
|
||||
|
||||
Power management state machine option. See the [power page](/docs/software/other/power) for details. 0 for default of one year.
|
||||
0 for default of one year.
|
||||
|
||||
#### Configure sds_secs
|
||||
|
||||
|
|
@ -467,7 +462,7 @@ Configuring this setting is not yet available for the selected platform. If this
|
|||
|
||||
### wait_bluetooth_secs
|
||||
|
||||
Wait number of seconds for Bluetooth - Power management state machine option. See the [power page](/docs/software/other/power) for details. 0 for default of 1 minute.
|
||||
0 for default of 1 minute.
|
||||
|
||||
#### Configure wait_bluetooth_secs
|
||||
|
||||
|
|
|
|||
|
|
@ -1,101 +0,0 @@
|
|||
---
|
||||
id: power
|
||||
title: 1.2 Power Management State Machine
|
||||
sidebar_label: 1.2 Power Management
|
||||
---
|
||||
|
||||
i.e. sleep behavior
|
||||
|
||||
## Power measurements
|
||||
|
||||
Since one of the main goals of this project is long battery life, it is important to consider that in our software/protocol design. Based on initial measurements it seems that the current code should run about three days between charging, and with a bit more software work. A battery life of eight days should be quite doable. Our current power measurements/model is in [this spreadsheet](https://docs.google.com/spreadsheets/d/1ft1bS3iXqFKU8SApU8ZLTq9r7QQEGESYnVgdtvdT67k/edit?usp=sharing).
|
||||
|
||||
## States
|
||||
|
||||
From lower to higher power consumption.
|
||||
|
||||
- Super-deep-sleep (SDS) - everything is off, CPU, radio, Bluetooth, GPS. Only wakes due to timer or button press. We enter this mode only after no radio comms for a few hours, used to put the device into what is effectively "off" mode.
|
||||
onEntry: setBluetoothOn(false), call doDeepSleep
|
||||
onExit: (standard bootup code, starts in DARK)
|
||||
|
||||
- deep-sleep (DS) - CPU is off, radio is on, Bluetooth and GPS is off. Note: This mode is never used currently, because it only saves 1.5mA vs light-sleep
|
||||
(Not currently used)
|
||||
|
||||
- light-sleep (LS) - CPU is suspended (RAM stays alive), radio is on, Bluetooth is off, GPS is off. Note: currently GPS is not turned
|
||||
off during light sleep, but there is a TODO item to fix this.
|
||||
NOTE: On NRF52 platforms (because CPU current draw is so low), light-sleep state is never used.
|
||||
onEntry: setBluetoothOn(false), setGPSPower(false), doLightSleep()
|
||||
onIdle: (if we wake because our led blink timer has expired) blink the led then go back to sleep until we sleep for ls_secs
|
||||
onExit: setGPSPower(true), start trying to get GPS lock: gps.startLock(), once lock arrives service.sendPosition(BROADCAST)
|
||||
|
||||
- No Bluetooth (NB) - CPU is running, radio is on, GPS is on but Bluetooth is off, screen is off.
|
||||
onEntry: setBluetoothOn(false)
|
||||
onExit:
|
||||
|
||||
- running dark (DARK) - Everything is on except screen
|
||||
onEntry: setBluetoothOn(true)
|
||||
onExit:
|
||||
|
||||
- serial API usage (SERIAL) - Screen is on, device doesn't sleep, Bluetooth off
|
||||
onEntry: setBluetooth off, screen on
|
||||
onExit:
|
||||
|
||||
- full on (ON) - Everything is on, can eventually timeout and lower to a lower power state
|
||||
onEntry: setBluetoothOn(true), screen.setOn(true)
|
||||
onExit: screen->setOn(false)
|
||||
|
||||
- has power (POWER) - Screen is on, device doesn't sleep, Bluetooth on, will stay in this state as long as we have power
|
||||
onEntry: setBluetooth off, screen on
|
||||
onExit:
|
||||
|
||||
## Behavior
|
||||
|
||||
### events that increase CPU activity
|
||||
|
||||
- At cold boot: The initial state (after setup() has run) is DARK
|
||||
- While in DARK: if we receive EVENT_BOOT, transition to ON (and show the bootscreen). This event will be sent if we detect we woke due to reset (as opposed to deep sleep)
|
||||
- While in LS: Once every position_broadcast_secs (default 15 mins) - the unit will wake into DARK mode and broadcast a "networkPing" (our position) and stay alive for wait_bluetooth_secs (default 60 seconds). This allows other nodes to have a record of our last known position if we go away and allows a paired phone to hear from us and download messages.
|
||||
- While in LS: Every one hour, when we wake to send our position we \_also\* broadcast our owner. This lets new nodes on the network find out about us or correct duplicate node number assignments.
|
||||
- While in LS/NB/DARK: If the user presses a button (EVENT_PRESS) we go to full ON mode for screen_on_secs (default 30 seconds). Multiple presses keeps resetting this timeout
|
||||
- While in LS/NB/DARK: If we receive new text messages (EVENT_RECEIVED_TEXT_MSG), we go to full ON mode for screen_on_secs (same as if user pressed a button)
|
||||
- While in LS: while we receive packets on the radio (EVENT_RECEIVED_PACKET) we will wake and handle them and stay awake in NB mode for min_wake_secs (default 10 seconds)
|
||||
- While in NB: If we do have packets the phone (EVENT_PACKETS_FOR_PHONE) would want we transition to DARK mode for wait_bluetooth secs.
|
||||
- While in DARK/ON: If we receive EVENT_BLUETOOTH_PAIR we transition to ON and start our screen_on_secs timeout
|
||||
- While in NB/DARK/ON: If we receive EVENT_NODEDB_UPDATED we transition to ON (so the new screen can be shown)
|
||||
- While in DARK: While the phone talks to us over BLE (EVENT_CONTACT_FROM_PHONE) reset any sleep timers and stay in DARK (needed for Bluetooth sw update and nice user experience if the user is reading/replying to texts)
|
||||
- while in LS/NB/DARK: if SERIAL_CONNECTED, go to serial
|
||||
- while in any state: if we have AC power, go to POWER
|
||||
|
||||
### events that decrease CPU activity
|
||||
|
||||
- While in POWER: if lose AC go to ON
|
||||
- While in SERIAL: if SERIAL_DISCONNECTED, go to NB
|
||||
- While in ON: If PRESS event occurs, reset screen_on_secs timer and tell the screen to handle the mess
|
||||
- While in ON: If it has been more than screen_on_secs since a press, lower to DARK
|
||||
- While in DARK: If time since last contact by our phone exceeds phone_timeout_secs (15 minutes), we transition down into NB mode
|
||||
- While in DARK or NB: If nothing above is forcing us to stay in a higher mode (wait_bluetooth_secs, min_wake_secs) we will lower down to LS state
|
||||
- While in LS: If mesh_sds_timeout_secs (default 2 hr) are exceeded we will lower into SDS mode for sds_secs (default 1 yr) (or a button press).
|
||||
- Any time we enter LS mode: We stay in that until an interrupt, button press or other state transition. Every ls_secs (default 1 hr) and let the Arduino loop() run one iteration (FIXME, not sure if we need this at all), and then immediately reenter lightsleep mode on the CPU.
|
||||
|
||||
TODO: Eventually these scheduled intervals should be synchronized to the GPS clock, so that we can consider leaving the LoRa receiver off to save even more power.
|
||||
TODO: In NB mode we should put CPU into light sleep any time we really aren't that busy (without declaring LS state) - i.e. we should leave GPS on etc...
|
||||
|
||||
# Low power consumption tasks
|
||||
|
||||
General ideas to hit the power draws our spreadsheet predicts. Do the easy ones before beta, the last 15% can be done after 1.0.
|
||||
|
||||
- don't even power on the GPS until someone else wants our position, just stay in LoRa deep sleep until press or rxpacket (except for once an hour updates)
|
||||
- (possibly bad idea - better to have LoRa radio always listen - check spreadsheet) have every node wake at the same tick and do their position syncs then go back to deep sleep
|
||||
- lower BT announce interval to save battery
|
||||
- change to use RXcontinuous mode and config to drop packets with bad CRC (see section 6.4 of datasheet) - I think this is already the case
|
||||
- have mesh service run in a thread that stays blocked until a packet arrives from the RF95
|
||||
- platformio sdkconfig CONFIG_PM and turn on modem sleep mode
|
||||
- keep CPU 100% in deepsleep until irq from radio wakes it. Then stay awake for 30 secs to attempt delivery to phone.
|
||||
- use https://lastminuteengineers.com/esp32-sleep-modes-power-consumption/ association sleep pattern to save power - but see https://github.com/espressif/esp-idf/issues/2070 and https://esp32.com/viewtopic.php?f=13&t=12182 it seems with BLE on the 'easy' draw people are getting is 80mA
|
||||
- stop using loop() instead use a job queue and let CPU sleep
|
||||
- measure power consumption and calculate battery life assuming no deep sleep
|
||||
- do the lowest sleep level possible where BT still works during normal sleeping, make sure CPU stays in that mode unless LoRa rx packet happens, bt rx packet happens or button press happens
|
||||
- optionally do LoRa messaging only during special scheduled intervals (unless nodes are told to go to low latency mode), then deep sleep except during those intervals - before implementing calculate what battery life would be with this feature
|
||||
- see section 7.3 of https://cdn.sparkfun.com/assets/learn_tutorials/8/0/4/RFM95_96_97_98W.pdf and have hope radio wake only when a valid packet is received. Possibly even wake the ESP32 from deep sleep via GPIO.
|
||||
- never enter deep sleep while connected to USB power (but still go to other low power modes)
|
||||
- when main CPU is idle (in loop), turn CPU clock rate down and/or activate special sleep modes. We want almost everything shutdown until it gets an interrupt.
|
||||
Loading…
Reference in a new issue