Disable BLE_PIN_CODE for E290 companion USB environment - #2561
Closed
willumpie82 wants to merge 126 commits into
Closed
Disable BLE_PIN_CODE for E290 companion USB environment#2561willumpie82 wants to merge 126 commits into
willumpie82 wants to merge 126 commits into
Conversation
…lse airtime calcs. Left update in the startsendraw as a safety, but should not be used under normal circumstances
…angs and handle growth This is a medium-ish refactor to attempt to clean up sensor handling logic both for board stability and future potential growth before the code becomes all spaghetti and meatballs. I'd be curious to see if anyone running sensors out there that knows how to build and flash MeshCore code could give this a try and see how it behaves. It is working fine on my end on multiple nodes. PR notes are gigantic because it is a fundamental behavior repair for sensors, so I wanted to over-explain. Also, if it hadn't been mentioned previously, push-back is always welcome. I'm just spending my time trying to clean up / fix / enhance this corner of the firmware, and want to contribute my improvements back to the project. **Problem:** Current MeshCore code makes no attempt to see what sensors are actually available on the I2C bus at startup and blindly tries to interact with sensors. This has some very bad side-effects, like if a sensor that is unsupported, or has a weird initialization process, the MeshCore node will just hang at boot and never successfully start up and ostensibly looks bricked, or the INA226 and SHT4X both sharing the same address and the code just silently fighting. The current implementation also gloms sensor readouts from the MCU and environment sensors onto the same telemetry channel, with some arbitrary exceptions for incrementing channels based on certain behavioral situations. The MCU temperature and external temperature sensors would appear on channel 1, and it wouldn't be possible to tell which sensor the temperature value was coming from. Per [CayenneLPP](https://github.com/myDevicesIoT/CayenneLPP): *Data Channel: Uniquely identifies each sensor in the device across frames, eg. “indoor sensor”* So this channel division implementation falls inline with what CayenneLPP intended. There are up to 256 channels available. So I tried to model this change in that behavioral style. **Proposed Improvement:** This implementation scans the I2C bus for what devices are present, sets each sensor to its own CayenneLPP channel, and keeps MCU telemetry on channel 1 only. So Channel 1 is always "self" and no confusion can result. Details: - Channel 1 is always the MCU and things about it, so you always know that telemetry is from the board itself. Exception is GPS, GPS stays on channel 1 as well since it is "about the board" even though it's a bit gray-area as GPS can often be a secondary chip. - Each sensor board is allocated to a dedicated CayenneLPP channel, so if you are reading from that channel, you know the data is from that sensor only. (Sensors emitting more than one of the same type of measurement are exceptions.) - `scanI2CBus()` probes addresses 0x08–0x77 with raw `beginTransmission`/`endTransmission`. No sensor library is touched until after this completes. This will prevent sensor-based boot hangs, unknown or unresponsive devices never reach a library init call. - Created `SENSOR_TABLE` a compile-time array that is gated by the existing `ENV_INCLUDE_*` macros. A sentinel `{ 0, nullptr, nullptr, nullptr }` at the end keeps the array non-empty regardless of which sensors are enabled, avoiding zero-length array warnings. - When `begin()` is called, scan first, then loop: skip if address not detected, skip if `init()` returns 0, otherwise register one ActiveSensor entry per sub-channel. - `querySensors()` I replaced the entire #ifdef chain with a 3-line loop. - T1000-E has its own T1000SensorManager, so it should be completely unaffected by this change. - SHT4X quirky initialization behavior is retained. - MLX90614 - git commits around this didn't have any notes as to why it is reporting ambient temperature on a separate channel as well as the object temperature, as the ambient temperature is used internally to compute the object temperature and not really needed for the sensor's purpose - just the same, kept the existing behavior of reporting the ambient temperature one channel above the channel assigned to the sensor - All `bool *_initialized` fields are gone, replaced with `ActiveSensor _active_sensors[16]` (query function pointer and sub-channel index) and `_active_sensor_count. SensorDef` lives entirely in the `.cpp` so the header has no dependency on it. - Details on the INA226 and SHT4X: both default to address 0x44, the old code had a bug and would have both begin() calls fire and they would just fight each other silently. In the new code, the respective sensor code is only called if the device is actually present, however, if both were present simultaneously, SHT4X comes first in the table and would win, and INA226 would return false and be skipped. The INA226 has 16 possible addresses that are configurable in the hardware itself, so in a potential scenario where both sensors would be present, the person implementing that design could take that into account. - BME680 gas resistance will now transmit on the same channel as the rest of BME680 telemetry which is inline with CayenneLPP standards. Coupling this PR with meshcore-dev#2146 streamline the whole sensor telemetry, and with meshcore-dev#2149 will overall improve BME680 handling. The gas resistance sensor actually has a binary library to make it more useful, calibration, accounting for age of sensor, and other improvements, but since that adds more flash consumption, I have omitted that in PRs thus far. - RAK12035 and other current upstream dev branch changes integrated.
Align TX activity LED with LED_BLUE / variant.h after LED definition and power-button pin mapping changes.
T-Echo Lite Non-Shell has no ePaper display, but the existing companion BLE env inherits DISPLAY_CLASS=GxEPDDisplay from the base env. This causes display.begin() to run on non-existent hardware, corrupting BLE initialization and generating a random PIN that cannot be displayed, making BLE connection impossible. Add LilyGo_T-Echo-Lite_non_shell_companion_radio_ble env that: - excludes DISPLAY_CLASS and ePaper-related build flags - removes GxEPDDisplay.cpp and ui-new from build sources - uses static BLE_PIN_CODE=123456 (avoids random PIN generation) Also fix boards/t-echo.json: - add nrfutil to upload protocols list - add use_1200bps_touch=true and wait_for_upload_port=true to enable reliable flashing via PlatformIO upload button
Add Heltec V4 set adc.multiplier functionality
Battery (TechoBoard.h/cpp): Added PIN_VBAT_MEAS_EN (P0.31) — the T-Echo Lite has a gated voltage divider that must be enabled before reading. Also added pinMode(PIN_VBAT_READ, INPUT) before each ADC read to reclaim P0.02 from other peripherals. Pin definitions hardcoded from LilyGo's t_echo_lite_config.h. I2C (variant.h): Corrected SDA/SCL from P0.04/P0.02 to P1.04/P1.02 per LilyGo's IIC_1_SDA/IIC_1_SCL. The old P0.02 mapping conflicted with the battery ADC pin. GPS (variant.h): Corrected all five GPS pin assignments to match LilyGo's config — UART TX/RX, wake, PPS, and power enable were all scrambled. SPI (variant.h): Fixed SPI_INTERFACES_COUNT from _PINNUM(0, 2) to (2). Tested on T-Echo Lite Non-Shell (USB-C, no display). Battery readings match Heltec V4 reference within 10mV.
Implement proper shutdown procedure for R1 neo
…er v2 Should only really be disabled when it causes issues.
Add sanity build for LR1110 and SX1276 too
Fix FEM/LNA enbaled by default for Heltec T096, Heltec Wireless Tracker v2
Fix RAK4631 SX1262 hardware pin config
…ttery Fixes meshcore-dev#1183 — T-Echo Lite incorrect battery voltage
…shell-ble-clean feat(techo-lite): add Non-Shell companion BLE variant
This is for Xiao S3 and a normal Wio SX1262 for Xiao shield.
…cV4-Expansion-Kit-2026-04-16 Added support for Expansion Kit to Heltec V4 OLED repeaters
Add option to disable DS3231 RTC probe
…shell-usb feat(techo-lite): add USB companion radio target for non-shell variant
CustomLFS 0.2.2 adds support for the flash chip in LilyGo T-Echo Card and T-Echo Lite
pin CustomLFS to version 0.2.2
add heltec-mesh-node-t1
…mpulse-plus Add support for LilyGo T-Impulse-Plus
reverted changes to RAK_BOARD and PIN_GPS_EN. setting `RAK_BOARD` would cause radio to stop working and end with RadioLib error -707
revert: "feat: Enable GPS on RAK 1W kit" (meshcore-dev#2401)
new CMD_SEND_RAW_PACKET
Add support for Station G3 and its software configurable LNA/PA1
Reduce dram0_0 usage on older ESP32 boards
Member
|
Hey, thanks for catching that. Please rebase your branch again |
…nect Refactor WiFi auto-reconnect to use non-blocking polling
Removed links to outdated resources and links
Include the 'ver' command for retrieving the firmware version
Remove the hardcoded BLE_PIN_CODE build flag from the Heltec_E290_companion_ble environment. The presence of BLE_PIN_CODE prevents the unit from operating as a USB companion. Commenting it out allows dynamic PIN generation and enables USB companion functionality.
Contributor
Author
|
Sorry for that... |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Remove the hardcoded
BLE_PIN_CODEbuild flag from the Heltec_E290_companion_usb environment. The presence ofBLE_PIN_CODEprevents the unit from operating as a USB companion. Commenting it out enables USB companion functionality.Changes
-D BLE_PIN_CODE=123456invariants/heltec_e290/platformio.iniImpact
This allows the E290 unit to function properly as a USB companion device by removing the hardcoded PIN restriction.