| Age | Commit message (Collapse) | Author |
|---|
|
updating.
|
|
|
|
|
|
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.
|
|
* Make firmware updating more foolproof and fix bugs
* No need to manually handle overflow
* Make startTime TickType_t
* Don't process TouchEvents::None
* Fix sleep getting re-enabled issue more directly
|
|
Refactor battery percent : only use uint8_t to store the battery % remaining.
|
|
Also added initializers for previously unintialized members.
|
|
|
|
|
|
|
|
* Retrieve and display bootloader version
- Display bootloader version on System Info screen
- Enable SPI flash sleep mode if bootloader version >= 1.0.0
* Wait for SPI flash to wakeup before starting OTA DFU
|
|
Used a macro for UUID generation, switched from C-style casts to reinterpret_cast, renamed callback
|
|
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.
|
|
|
|
reinterpret_cast, renamed callback
|
|
|
|
|
|
# Conflicts:
# src/displayapp/screens/Notifications.cpp
|
|
- Enable LVGL animation (and disable groups, which were not used), and set the speed.
- Fix disc animation and progress display by initializing lastIncrement at 0 (a random value will be used otherwise, in release build)
|
|
|
|
title and the message separated by a '\0' character.
If the buffer does not contain any \0, the whole buffer is considered to be the message of the notification. A default title will be displayed in the notification app.
|
|
Fix build warnings coming from HR implementation
|
|
|
|
Call functionality with changed UUID for notification event characteristic
|
|
|
|
82153e744833821e20e9a8b0d61c38b2b0dbcfe1
WARNING : heartbeat task is disabled!
|
|
|
|
|
|
Display the call notifications in the Notification app, with buttons to accept/reject the call.
|
|
|
|
|
|
Add categories to AlertNotification
Add new alert notification screens bases
Add Incoming Call
Add Modal
Add event to AlertNotification
Co-authored-by: Robin Karlsson <robin.karlsson@protonmail.com>
|
|
- fix conflict
- add a icon for the navigation app.
|
|
Heart rate sensor
|
|
|
|
|
|
|
|
|
|
|
|
classes of the services.
|
|
is already established.
|
