Feat ble prototype example#331
Conversation
- Added Bluetooth Files - Made edits to EmotiBit.h+.cpp - This build goes into bluetooth mode, does not stream
Update LEDS
WalkthroughAdds ESP32 BLE support and integrates it into EmotiBit core: new Possibly related PRs
🚥 Pre-merge checks | ✅ 2 | ❌ 3❌ Failed checks (1 warning, 2 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 21
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
EmotiBit.cpp (3)
4045-4050: sendModePacket() always sends over WiFi, ignoring BLUETOOTH mode.When in BLE mode, this won’t reach the client and unnecessarily wakes WiFi code paths.
void EmotiBit::sendModePacket(String &sentModePacket, uint16_t &packetNumber) { createModePacket(sentModePacket, packetNumber); - // ToDo: This should probably be over TCP in response to specific messages from Host (but will require writing TCP ingest) - _emotiBitWiFi.sendData(sentModePacket); // Send packet immediately to update host + // Send over the active transport + if (getPowerMode() == PowerMode::BLUETOOTH) { + #ifdef ARDUINO_FEATHER_ESP32 + _emotiBitBluetooth.sendData(sentModePacket); + #endif + } else { + _emotiBitWiFi.sendData(sentModePacket); + } _outDataPackets += sentModePacket; // Add packet to slower data logging bucket }
2261-2273: Bitwise precedence bug causes incorrect overflow detection.
status & BufferFloat::ERROR_BUFFER_OVERFLOW == ...is parsed asstatus & (A==A). You’re effectively testing LSB of status.- if (status & BufferFloat::ERROR_BUFFER_OVERFLOW == BufferFloat::ERROR_BUFFER_OVERFLOW) { + if ((status & BufferFloat::ERROR_BUFFER_OVERFLOW) == BufferFloat::ERROR_BUFFER_OVERFLOW) {This affects reliability of overflow handling.
3995-4042: Add BLUETOOTH power mode case to createModePacket() using existing MODE_BLUETOOTH.The BLUETOOTH power mode case is missing from createModePacket(). EmotiBitPacket::TypeTag::MODE_BLUETOOTH already exists in the codebase and is actively used elsewhere (e.g., line 1601), so use it directly without a temporary string placeholder.
else if(getPowerMode() == PowerMode::WIRELESS_OFF) { payload += EmotiBitPacket::TypeTag::MODE_WIRELESS_OFF; } + else if (getPowerMode() == PowerMode::BLUETOOTH) + { + payload += EmotiBitPacket::TypeTag::MODE_BLUETOOTH; + } else if (getPowerMode() == PowerMode::HIBERNATE)EmotiBit.h (1)
266-274: Add PowerMode::BLUETOOTH handling to createModePacket().The
createModePacket()function (EmotiBit.cpp:3994-4042) handles NORMAL_POWER, LOW_POWER, MAX_LOW_POWER, WIRELESS_OFF, and HIBERNATE modes (lines 4017-4036), but lacks a case for PowerMode::BLUETOOTH. When the device is in BLUETOOTH mode, no MODE_BLUETOOTH tag is emitted, causing the host/UI to be unaware of the actual power state. Additionally,sendModePacket()(line 4048) always transmits via WiFi regardless of mode, which won't reach clients connected only over Bluetooth.Add this condition in createModePacket() before the final
dataCount++:else if (getPowerMode() == PowerMode::BLUETOOTH) { payload += EmotiBitPacket::TypeTag::MODE_BLUETOOTH; }Also review
sendModePacket()to ensure Bluetooth-connected clients receive mode updates (the ToDo comment at line 4047 hints at this broader design need).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (6)
EmotiBit.cpp(10 hunks)EmotiBit.h(5 hunks)EmotiBitBluetooth.cpp(1 hunks)EmotiBitBluetooth.h(1 hunks)EmotiBit_stock_firmware/EmotiBit_stock_firmware.ino(1 hunks)board_feather_esp32.ini(1 hunks)
🧰 Additional context used
🪛 Clang (14.0.6)
EmotiBit.cpp
[note] 960-960: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[note] 967-967: +1, nesting level increased to 1
(clang)
[warning] 960-960: redundant boolean literal supplied to boolean operator
(readability-simplify-boolean-expr)
[note] 1525-1525: +1, including nesting penalty of 0, nesting level increased to 1
(clang)
[note] 1601-1601: +1, nesting level increased to 3
(clang)
[note] 3227-3227: +5, including nesting penalty of 4, nesting level increased to 5
(clang)
[warning] 3860-3860: if with identical then and else branches
(bugprone-branch-clone)
[note] 3867-3867: else branch starts here
(clang)
[warning] 3860-3860: redundant boolean literal supplied to boolean operator
(readability-simplify-boolean-expr)
[warning] 3873-3873: repeated branch in conditional chain
(bugprone-branch-clone)
[note] 4452-4452: +1, nesting level increased to 2
(clang)
[note] 4451-4451: end of the original
(clang)
[note] 4453-4453: clone 1 starts here
(clang)
🪛 GitHub Actions: Build EmotiBit FeatherWing Firmware
EmotiBit.cpp
[error] 1601-1601: EmotiBitPacket::TypeTag does not contain MODE_BLUETOOTH. Compilation failed due to invalid enum value usage.
🔇 Additional comments (3)
board_feather_esp32.ini (1)
11-12: Partition change: confirm trade-offs.huge_app.csv reduces SPIFFS/OTA space. Verify this is acceptable for your SD/FTP flows and that no OTA or on-device FS is relied upon elsewhere.
EmotiBit_stock_firmware/EmotiBit_stock_firmware.ino (1)
13-24: BLE/Wireless Off toggle logic LGTM.The button toggles between BLUETOOTH and WIRELESS_OFF when Bluetooth is enabled; otherwise WiFi path toggles as before. Clear and consistent.
EmotiBitBluetooth.cpp (1)
31-33: I'm unable to locate EmotiBitBluetooth.cpp in the public repositories despite multiple attempts. Without access to the actual codebase, I cannot verify:
- Which BLE stack is in use (ESP32 Arduino Bluedroid vs NimBLE-Arduino)
- The current implementation at lines 31-33 and 112-121
- Whether security infrastructure is already configured elsewhere
- Whether the
MyCallbacksimplementation properly handles securityHowever, the web search results confirm that the review comment's suggested API patterns are accurate:
- For ESP32 Arduino (Bluedroid): Use
setAccessPermissions(ESP_GATT_PERM_WRITE_ENCRYPTED)orsetAccessPermissions(ESP_GATT_PERM_WRITE_ENC_MITM)after creating the characteristic- For NimBLE-Arduino: Use
NIMBLE_PROPERTY::WRITE_ENCwhen callingcreateCharacteristic()Both approaches require security/pairing infrastructure to be enabled on the device.
The security concern raised in the review comment is valid — writable BLE characteristics should require encryption and ideally MITM authentication to prevent unauthorized control writes.
There was a problem hiding this comment.
I think our future selves may be significantly less disappointed in our present selves if we refactor setPowerMode to correctly handle BT. I've made suggested changes in the branch feat-blePrototype-Example-fix-setPowerMode
Make sure to highlight in your PR which data integrity tests have been run on SD card data using wifi (normal use-case) in addition to BLE situations.
Please also specify in the PR the battery life when using wifi (and wifi->wireless off) modes.
| } | ||
|
|
||
| if (getPowerMode() == PowerMode::BLUETOOTH) { | ||
| #ifdef ARDUINO_FEATHER_ESP32 |
There was a problem hiding this comment.
Can we remove this #ifdef ARDUINO_FEATHER_ESP32?
If we got here, can't we just assume it's a BT compatible board?
There was a problem hiding this comment.
Removing the ifdefs here breaks m0
| // Battery LED | ||
| if (battIndicationSeq) | ||
| { | ||
| led.setState(EmotiBitLedController::Led::YELLOW, true); |
There was a problem hiding this comment.
Why do we need to have the Led::YELLOW and Led::RED controls duplicated for PowerMode::BLUETOOTH and not? Seems like one source of truth could be enough.
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 13
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3750fc8d-8fef-4688-8647-37cda11fbc8b
📒 Files selected for processing (9)
EmotiBit.cppEmotiBit.hEmotiBitBluetooth.cppEmotiBitBluetooth.hEmotiBit_stock_firmware/EmotiBit_stock_firmware.inoREADME.mdWORKFLOWS_AND_SCRIPTS.mdboard_feather_esp32.inilibrary.properties
| if (emotibit.getPowerMode() == EmotiBit::PowerMode::BLUETOOTH) | ||
| { | ||
| emotibit.setPowerMode(EmotiBit::PowerMode::WIRELESS_OFF); | ||
| Serial.println("PowerMode::WIRELESS_OFF"); | ||
| } | ||
| else | ||
| { | ||
| emotibit.setPowerMode(EmotiBit::PowerMode::BLUETOOTH); | ||
| Serial.println("PowerMode::BLUETOOTH"); |
There was a problem hiding this comment.
Only log a mode switch after setPowerMode() succeeds.
setPowerMode() now returns bool, but these branches print the target mode unconditionally. If BLE init fails or the transition is rejected, the stock sketch reports a state change that never happened.
🔧 Suggested pattern
- emotibit.setPowerMode(EmotiBit::PowerMode::WIRELESS_OFF);
- Serial.println("PowerMode::WIRELESS_OFF");
+ if (emotibit.setPowerMode(EmotiBit::PowerMode::WIRELESS_OFF))
+ {
+ Serial.println("PowerMode::WIRELESS_OFF");
+ }Apply the same guard to the other three setPowerMode(...) calls in this handler.
Also applies to: 29-37
| @@ -1,5 +1,5 @@ | |||
| name=EmotiBit FeatherWing | |||
| version=1.14.3 | |||
| version=1.14.4 | |||
There was a problem hiding this comment.
Keep the runtime firmware string in sync with the package version.
library.properties now publishes 1.14.4, but Line 61 in EmotiBit.h still reports firmware_version = "1.14.3". That leaves serial output, factory-test metadata, and host-side version checks out of sync with the release you're shipping here.
🔧 Cross-file fix
- String firmware_version = "1.14.3";
+ String firmware_version = "1.14.4";There was a problem hiding this comment.
Worth bringing up in review to fix
| ## Developer Documentation | ||
| - [GitHub Workflows and CI/CD](WORKFLOWS_AND_SCRIPTS.md) - Detailed documentation on automated builds, releases, and bash scripts |
There was a problem hiding this comment.
Add a blank line after the heading to satisfy markdownlint.
MD022 is triggered because the list starts immediately after the heading.
Suggested patch
## Developer Documentation
+
- [GitHub Workflows and CI/CD](WORKFLOWS_AND_SCRIPTS.md) - Detailed documentation on automated builds, releases, and bash scripts📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ## Developer Documentation | |
| - [GitHub Workflows and CI/CD](WORKFLOWS_AND_SCRIPTS.md) - Detailed documentation on automated builds, releases, and bash scripts | |
| ## Developer Documentation | |
| - [GitHub Workflows and CI/CD](WORKFLOWS_AND_SCRIPTS.md) - Detailed documentation on automated builds, releases, and bash scripts |
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 20-20: Headings should be surrounded by blank lines
Expected: 1; Actual: 0; Below
(MD022, blanks-around-headings)
| - [Test Scripts](#test-scripts) | ||
| - [Development Process](#development-process) | ||
| - [Dependency Management Approaches](#dependency-management-approaches) | ||
| - [Configuration Files](#configuration-files) | ||
| - [Requirements Summary](#requirements-summary) | ||
| - [Maintenance Notes](#maintenance-notes) |
There was a problem hiding this comment.
Fix broken Table of Contents anchors.
The TOC links for Test Scripts, Configuration Files, Requirements Summary, and Maintenance Notes point to sections that do not exist in this file, so navigation is broken. Either add those sections or remove these TOC entries.
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 12-12: Link fragments should be valid
(MD051, link-fragments)
[warning] 15-15: Link fragments should be valid
(MD051, link-fragments)
[warning] 16-16: Link fragments should be valid
(MD051, link-fragments)
[warning] 17-17: Link fragments should be valid
(MD051, link-fragments)
| ``` | ||
| EmotiBit FeatherWing Dependency Report | ||
| Generated: [timestamp] | ||
|
|
||
| LibraryName1: version (git_commit_hash) | ||
| LibraryName2: version (git_commit_hash) | ||
| ... | ||
| ``` |
There was a problem hiding this comment.
Add language identifiers to fenced code blocks.
These fenced blocks are missing a language tag (MD040), and this will keep markdownlint failing. Use text (or bash where appropriate) and keep fence spacing consistent.
Suggested patch
-```
+```text
EmotiBit FeatherWing Dependency Report
Generated: [timestamp]
LibraryName1: version (git_commit_hash)
LibraryName2: version (git_commit_hash)
...@@
- +text
- Create feature branch from dev
- Make code changes
- Push to GitHub → automatic build runs
- Download artifacts from Actions tab to test
- Iterate on changes (each push triggers new build)
- Create pull request to dev
- Merge after review and successful build
@@
-```
+```text
1. Update version in library.properties and merge featire branch to dev branch
2. Push changes → automatic build runs
3. Verify build succeeds on dev
4. Manually trigger "Create Release" workflow
5. Review draft release:
- Check binaries are correct
- Review auto-generated dependency information
- Add/edit release notes as needed
6. Publish release when ready
</details>
Also applies to: 292-300, 303-313
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.22.0)</summary>
[warning] 131-131: Fenced code blocks should be surrounded by blank lines
(MD031, blanks-around-fences)
---
[warning] 131-131: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
<!-- fingerprinting:phantom:triton:hawk:5aa04d8b-5029-4e1f-89a2-989397d8c65c -->
<!-- This is an auto-generated comment by CodeRabbit -->
|
|
||
| **Preparing a Release:** | ||
| ``` | ||
| 1. Update version in library.properties and merge featire branch to dev branch |
There was a problem hiding this comment.
Correct typo in release instructions.
Line 304 says featire; it should be feature.
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (14)
library.properties (1)
2-2:⚠️ Potential issue | 🟡 MinorKeep the runtime firmware version in sync with this release.
library.propertiespublishes1.14.4, butEmotiBit.hline 60 still reportsfirmware_version = "1.14.3", so runtime metadata will disagree with the packaged release.🔧 Cross-file fix
- String firmware_version = "1.14.3"; + String firmware_version = "1.14.4";EmotiBit.h (2)
285-287: 🧹 Nitpick | 🔵 TrivialKeep the BLE transport member private.
_emotiBitBluetoothis still publicly mutable, so external code can bypassEmotiBit’s mode/lifecycle invariants. Prefer moving it toprivateand exposing only narrow methods needed by the sketch layer.
438-438: 🧹 Nitpick | 🔵 TrivialAvoid exposing the Bluetooth mode flag as public mutable state.
_bluetoothEnabledcan be toggled externally without coordinatingPowerMode, BLE startup, or Wireless Off state. Keep it private and expose a read-only accessor or controlled setter if sketch code needs it.WORKFLOWS_AND_SCRIPTS.md (2)
5-17:⚠️ Potential issue | 🟡 MinorFix the broken Table of Contents anchors.
The TOC entries for
Test Scripts,Configuration Files,Requirements Summary, andMaintenance Notespoint to sections that do not exist in this file. Add those sections or remove the links.
131-138:⚠️ Potential issue | 🟡 MinorAdd code-fence languages and fix the release typo.
These fenced blocks are missing language identifiers, and line 304 says
featireinstead offeature.📝 Suggested doc fix
-``` +```text EmotiBit FeatherWing Dependency Report Generated: [timestamp] @@ ...@@
-+text
- Create feature branch from dev
@@- Merge after review and successful build
@@ -``` -1. Update version in library.properties and merge featire branch to dev branch +```text +1. Update version in library.properties and merge feature branch to dev branch 2. Push changes → automatic build runs @@ 6. Publish release when ready</details> Also applies to: 292-300, 303-313 </blockquote></details> <details> <summary>README.md (1)</summary><blockquote> `20-21`: _⚠️ Potential issue_ | _🟡 Minor_ **Add a blank line after the heading.** Markdownlint still flags `MD022` because the list starts immediately after `## Developer Documentation`. <details> <summary>📝 Suggested doc fix</summary> ```diff ## Developer Documentation + - [GitHub Workflows and CI/CD](WORKFLOWS_AND_SCRIPTS.md) - Detailed documentation on automated builds, releases, and bash scriptsEmotiBitBluetooth.h (2)
36-47: 🧹 Nitpick | 🔵 TrivialMake BLE lifecycle state private.
pServer, characteristic pointers,deviceConnected,_bluetoothOff,_bluetoothReconnect,_connId, and receive buffers are all publicly mutable. External mutation can break connection lifecycle assumptions; expose only narrow read-only accessors if needed.
64-66: 🧹 Nitpick | 🔵 TrivialMark the characteristic callback override explicitly.
Declare
onWriteunderpublic:and addoverrideso signature drift againstBLECharacteristicCallbacksis caught at compile time.♻️ Proposed header cleanup
class MyCallbacks : public BLECharacteristicCallbacks { - void onWrite(BLECharacteristic *pCharacteristic); +public: + void onWrite(BLECharacteristic *pCharacteristic) override; };EmotiBitBluetooth.cpp (3)
28-30:⚠️ Potential issue | 🔴 CriticalGuard
pServicebefore dereferencing it.
createService()is still used without checking the returned pointer; line 30 dereferencespServiceimmediately. Also reset partial BLE state on any init failure so a laterbegin()does not treat an incompletepServeras initialized.🛡️ Proposed init guard
BLEService* pService = pServer->createService(EMOTIBIT_SERVICE_UUID); + if (!pService) + { + Serial.println("ERROR: Failed to create BLE service"); + pServer = nullptr; + return 1; + } pDataTxCharacteristic = pService->createCharacteristic(EMOTIBIT_DATA_TX_CHARACTERISTIC_UUID, BLECharacteristic::PROPERTY_NOTIFY);
73-80:⚠️ Potential issue | 🟠 MajorBuffer incoming writes in
onWrite()instead of dropping them.The TODO describes the production bug: the callback copies
rxValuelocally and then discards it, so back-to-back writes can overwrite the characteristic beforereadControl()polls it. Capture each write into the instance buffer or a small queue here.🔧 Directional fix
-//ToDO: Current polling aproach can drop back to back writes since the characteristic only holds the last value. void EmotiBitBluetooth::MyCallbacks::onWrite(BLECharacteristic *pCharacteristic) { std::string rxValue = pCharacteristic->getValue(); if (rxValue.length() > 0) { - //Serial.print("Received: "); - //Serial.println(rxValue.c_str()); + // Append to an EmotiBitBluetooth-owned buffer/queue here. + // This callback needs a pointer/reference to the parent instance. } }Do you want me to generate the complete header/callback refactor to pass the parent
EmotiBitBluetooth*intoMyCallbacks?
132-176:⚠️ Potential issue | 🔴 CriticalPreserve partial and subsequent control packets.
readControl()drains_receivedControlMessageinto a localtempPacket; if no delimiter is present, the partial packet is lost. When a delimiter is found, line 160 clears the entire buffer, dropping any packets received after the first delimiter. This breaks fragmented BLE writes and multi-packet bursts.🐛 Proposed parser fix
uint8_t EmotiBitBluetooth::readControl(String& packet) { - uint8_t numPackets = 0; packet = ""; - if (deviceConnected) + if (deviceConnected && pDataRxCharacteristic != nullptr) { std::string rxValue = pDataRxCharacteristic->getValue(); if (!rxValue.empty()) { @@ pDataRxCharacteristic->setValue(""); } - String tempPacket = ""; - while (_receivedControlMessage.length() > 0) - { - int c = _receivedControlMessage[0]; - _receivedControlMessage.remove(0, 1); - - if (c == (int)EmotiBitPacket::PACKET_DELIMITER_CSV) - { - numPackets++; - packet = tempPacket; - tempPacket = ""; - _receivedControlMessage = ""; - return numPackets; - } - else - { - if (c == 0) { - // Throw out null term - } - else - { - tempPacket += (char)c; - } - } - } + int delimiterIndex = _receivedControlMessage.indexOf((char)EmotiBitPacket::PACKET_DELIMITER_CSV); + if (delimiterIndex >= 0) + { + packet = _receivedControlMessage.substring(0, delimiterIndex); + _receivedControlMessage.remove(0, delimiterIndex + 1); + return 1; + } } - return numPackets; + return 0; }EmotiBit.cpp (2)
1523-1527:⚠️ Potential issue | 🔴 CriticalDrain WiFi and BLE control queues independently.
This
A || Bstill skips BLE whenever WiFi returns a packet, and BLE’sreadControl()has different semantics than WiFi: it can consume the RX buffer and return only the first packet. Bursts of BLE control packets can be starved or dropped. Extract the packet-processing body and call it from separate WiFi and BLE drain loops. SeeEmotiBitBluetooth.cpp:132-172vsEmotiBitWiFi.cpp:435-475.
3846-3899:⚠️ Potential issue | 🟠 MajorSend mode acknowledgements over the active transport before teardown.
WIRELESS_OFFends BLE/WiFi before the trailingsendModePacket()runs, andsendModePacket()still sends immediately through WiFi only. A BLE requester won’t receive the mode acknowledgement, and a Wireless Off acknowledgement is attempted after the active radio is already down. Route by the previous active transport, and forWIRELESS_OFF, create/send the mode packet before callingend().Also applies to: 4057-4062
EmotiBit_stock_firmware/EmotiBit_stock_firmware.ino (1)
13-37:⚠️ Potential issue | 🟠 MajorOnly print the mode change after
setPowerMode()succeeds.These branches still log the target mode unconditionally. If BLE init fails or a transition is rejected, the sketch reports a state that was not entered.
🔧 Proposed fix pattern
- emotibit.setPowerMode(EmotiBit::PowerMode::WIRELESS_OFF); - Serial.println("PowerMode::WIRELESS_OFF"); + if (emotibit.setPowerMode(EmotiBit::PowerMode::WIRELESS_OFF)) + { + Serial.println("PowerMode::WIRELESS_OFF"); + }Apply the same guard to the other
setPowerMode(...)calls in this handler.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: b4ce63be-6618-41f3-adc2-7a62c610617b
📒 Files selected for processing (9)
EmotiBit.cppEmotiBit.hEmotiBitBluetooth.cppEmotiBitBluetooth.hEmotiBit_stock_firmware/EmotiBit_stock_firmware.inoREADME.mdWORKFLOWS_AND_SCRIPTS.mdboard_feather_esp32.inilibrary.properties
| //void setPowerMode(PowerMode mode); | ||
| bool setPowerMode(PowerMode mode); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Remove the stale commented-out signature.
The old void setPowerMode(...) declaration can be dropped now that the public API is bool setPowerMode(...); leaving both in the header makes the intended contract less clear.
3 participants
Description
This PR enables Bluetooth Low Energy (BLE) on the EmotiBit, adding the following functionality:
ARDUINO NOTE: If you are on Arduino, please set the partition table to Huge App
NOTE: This build does NOT have time syncing enabled so all data received does not account for start time/adjustments due to latency.
This PR allows users to press the side button on start up (same time frame to get into the debug mode) to switch the EmotiBit into bluetooth mode, which is signified by a faster blinking light. A synopsis of each change is outlined in the notes for reviewer. This code was built out with this arduino example here as an example.
Requirements
Issues Referenced
Fixes #345
Documentation update
None - we are not publicly releasing this PR
Notes for Reviewer
EmotiBitBluetooth.h/.cpp
This is where all the bluetooth specific functions will live and was built with EmotiBitWifi as a blueprint.
EmotiBit.h/.cpp
EmotiBit_stock_firemware.ino
board_feather_esp32.ini
Setup Flow
Bluetooth Connections Flow
LED Speeds
Testing
All tests were run with Bluefruit Connect or nRF Connect which can be downloaded on the app store.
Results
Testing included the following feature tests. I also ensured that record begin/end would work as well.
Feature Tests
Shared files
Firmware binary:
1.14.3.Feat ble prototype example.0 .zip
Other files.
Checklist to allow merge
masterDIGITAL_WRITE_DEBUG= false (if set true while testing)Screenshots: