Age | Commit message (Collapse) | Author | Files | Lines |
|
Some components were missing a `nrf_log.h` include. This missing
include was accidentally provided by the SystemMonitor.h header, which
was included by Systemtask.h
|
|
into evergreen22-airplane-mode
Apply a few changes that were requested in the PR during the review.
# Conflicts:
# src/CMakeLists.txt
# src/displayapp/Apps.h
# src/displayapp/DisplayApp.cpp
# src/displayapp/Messages.h
# src/displayapp/screens/settings/Settings.cpp
|
|
into evergreen22-airplane-mode
# Conflicts:
# src/CMakeLists.txt
# src/displayapp/Apps.h
# src/displayapp/DisplayApp.cpp
# src/displayapp/Messages.h
# src/displayapp/screens/settings/Settings.cpp
|
|
|
|
Implements 'Airplane mode' feature to disable and enable bluetooth/ble
Adds airplaneMode as a non-persisted setting
Adds a setting menu for switching airplane mode on and off
Displays an airplane symbol on the Digital watch face and the
PineTimeStyle watch face when airplane mode is enabled
Always enables bluetooth/ble on boot (disable airplane mode)
Alphabetizes the settings menu options
Style cleanups
Closes #632
|
|
Support passkey pairing when requested by the central
Fix a comment and reorder warning
|
|
|
|
|
|
|
|
|
|
Increase BLE task stack +200 and decrease LL task stack -200
more braces!
|
|
Save bond information in the FS after a disconnect or encryption change
if the bond is not already stored. The bond is restored on boot enabling
automatic reconnection to a previously bonded central.
Two consecutive watch reboots with the central out of range (or BLE off)
will remove the stored bond from the watch.
|
|
This commit adds the following:
Passkey pairing - passkey is displayed on watch
Swipe down to clear passkey screen
Connection encryption
Connection bonding
Automatic reconnects to a bonded peripheral
Trusted device on Android
Note that persisting the bond between reboots is NOT included in
this commit. Therefore, rebooting the watch will cause reconnect failures.
You must delete the bond from the phone to reconnect/pair.
|
|
|
|
Don't use relative imports like `../foo.h` as those depend on the
relative position of both files. Rather than that use imports relative
to the `src` directory, which explicitly is part of the include
directories.
|
|
|
|
|
|
only if the host subscribed to them.
|
|
into evergreen22-refactor_adv
# Conflicts:
# src/components/ble/NimbleController.cpp
|
|
* docs: Fix a few typos
There are small typos in:
- doc/versioning.md
- src/components/ble/NimbleController.cpp
- src/libs/mynewt-nimble/CODING_STANDARDS.md
- src/libs/mynewt-nimble/docs/btshell/btshell_GAP.rst
- src/systemtask/SystemTask.cpp
Fixes:
- Should read `milliseconds` rather than `miliseconds`.
- Should read `unnecessary` rather than `uncesseray`.
- Should read `target` rather than `tharget`.
- Should read `project` rather than `projct`.
- Should read `preferred` rather than `prefered`.
- Should read `functioning` rather than `functionning`.
- Should read `forever` rather than `forver`.
- Should read `existing` rather than `exisiting`.
|
|
On power up, advertise aggressively for at least 30 seconds then switch
to a longer interval to conserve battery life. This fast/slow pattern
is designed to balance connection response time and battery life.
When a disconnect event is received restart the fast/slow pattern.
When a failed connect event is received, restart the fast/slow pattern.
When the screen is activated and ble is not connected, restart the fast/slow pattern.
This pattern is consistent with Apple's BLE developer standards (QA 1931).
|
|
This reverts commit c32ba844e04017a3fd31444c384deb3542bd76be.
|
|
Start advertising aggressively when powered on then
slow down linearly over 75 seconds. This will conserve
battery by not advertising rapidly the whole time we
are seeking a connection. The slowest rate is
approximately once every 4.5 seconds to balance
responsiveness and battery life.
We use a fixed advertising duration of 5 seconds and start
with a 62.5 ms advertising interval. Every 5 seconds
(the advertising duration) we step up to a larger
advertising interval (slower advertising). We continue
to increase the advertising interval linearly for
75 seconds from the start of advertising. At 75 seconds
we have an advertising interval of 4.44 seconds which we
keep until connected. A reboot will restart the sequence.
When we receive a disconnect event we restart the sequence
with fast advertising and then slow down as described above.
Note that we are not using the BLE high duty cycle setting to
change the advertising rate. The rate is managed by repeatedly
setting the minimum and maximum intervals.
The linear rate of decrease and the slowest interval size
were determined experimentally by the author. The 5.3 Core
spec suggests that you not advertise slower than once
every 1.2 seconds to preserve responsiveness but we
ignored that suggestion.
|
|
|
|
|
|
|
|
Refactor ble advertising based on ble standards and conventions.
Changes are based on the bleprph example code, bluetooth docs, and nimble docs.
|
|
Refactor battery percent : only use uint8_t to store the battery % remaining.
|
|
variable instead of variables on the heap. We don't need them on the heap as we know their size at build time, it'll reduce memory fragmentation and it'll make memory analysis easier.
|
|
|
|
|
|
- fix conflict
- add a icon for the navigation app.
|
|
|
|
|
|
classes of the services.
|
|
is already established.
|
|
|