BLETelemetry for esp32 devices implementation #2305
Conversation
|
haha I'll look at this after 3.3 releases, but I'm giving it 5 stars for the sweet command line with multiple awks and a perl too 🤩. I was just thinking Saturday about how thank goodness I never see perl code any more and here we are! |
flux242
changed the title
|
tx16s with internal elrs, using telemetry viewer from googleplay doesn't work , while RomanLut with bluetooth le can finally connected. |
|
Some remarks:
I don't like this random addressing myself but I havent found a way to set a specific BSSID address manually. It would be better to get the public address which is used for BT Joystick and increase/decrease the last byte by one |
COSMETIC: removed unused reference
|
Hello everyone! I flash this pr and it seems to work fine and finally my "abnormal" jjumper aion tx don't freeze & show phantom from a "past life"! Telemetry goes to the phone perfectly and they don't seem to be any bugs yet, although the lua script freezing a little when selecting 500 Hz, but the module itself is fine. Maybe today it will be possible to fly & test in hardcore;) Many thanks to the developers! |
|
Today tested it, so far everything is fine, thanks |
|
Works fine with my RM Zorro, at least on the bench. It even get a more reliable connection than my BT module with Telemetry Mirror. |
src/lib/BLE/devBLETelemetry.cpp
Outdated
|
|
||
| static uint32_t LastTMLLinkStatsPacketMillis = 0; | ||
| static uint32_t LastTLMRCPacketMillis = 0; | ||
| static bool initOnce = false; |
There was a problem hiding this comment.
| static bool initOnce = false; |
delete unused var
src/lib/BLE/devBLETelemetry.cpp
Outdated
|
|
||
| //Set MTU to max packet length + 3 bytes to be able to send packets longer then default 20 bytes. | ||
| //Should be set on both ends - smaller from two is used. | ||
| BLEDevice::setMTU(CRSF_MAX_PACKET_LEN + 3); |
There was a problem hiding this comment.
| BLEDevice::setMTU(CRSF_MAX_PACKET_LEN + 3); | |
| NimBLEDevice::setMTU(CRSF_MAX_PACKET_LEN + 3); |
use correct class
src/lib/BLE/devBLETelemetry.cpp
Outdated
| //we do not want devices which are bound to BLE Joystick to connect to Telemetry service. | ||
| //start BLE Device with random address | ||
| //avoid frequent address changes | ||
| if ( initOnce == false ) | ||
| { | ||
| initOnce = true; | ||
|
|
||
| ble_addr_t blead; | ||
| ble_hs_id_gen_rnd(1, &blead); | ||
| ble_hs_id_set_rnd(blead.val); | ||
| } | ||
| NimBLEDevice::setOwnAddrType(BLE_OWN_ADDR_RANDOM); |
There was a problem hiding this comment.
| //we do not want devices which are bound to BLE Joystick to connect to Telemetry service. | |
| //start BLE Device with random address | |
| //avoid frequent address changes | |
| if ( initOnce == false ) | |
| { | |
| initOnce = true; | |
| ble_addr_t blead; | |
| ble_hs_id_gen_rnd(1, &blead); | |
| ble_hs_id_set_rnd(blead.val); | |
| } | |
| NimBLEDevice::setOwnAddrType(BLE_OWN_ADDR_RANDOM); | |
| //we do not want devices which are bound to BLE Joystick to connect to Telemetry service. | |
| //BLE Joystick is using PUBLIC address | |
| //start BLE Device with RANDOM address | |
| //set RANDOM address as PUBLIC addres with last byte increased by 1 | |
| assignRandomAddress(); |
Use RANDOM address generated from PUBLIC address, so it does not change every time.
src/lib/BLE/devBLETelemetry.cpp
Outdated
| /** Set low transmit power, default is 6db */ | ||
| BLEDevice::setPower(ESP_PWR_LVL_P6); |
There was a problem hiding this comment.
| /** Set low transmit power, default is 6db */ | |
| BLEDevice::setPower(ESP_PWR_LVL_P6); |
Correct function should be called in correct place, see below
src/lib/BLE/devBLETelemetry.cpp
Outdated
| NimBLEDevice::stopAdvertising(); | ||
| NimBLEDevice::deinit(true); | ||
| pServer = nullptr; | ||
| rcCRSF = nullptr; | ||
| vSemaphoreDelete(_mutex); |
There was a problem hiding this comment.
| NimBLEDevice::stopAdvertising(); | |
| NimBLEDevice::deinit(true); | |
| pServer = nullptr; | |
| rcCRSF = nullptr; | |
| vSemaphoreDelete(_mutex); | |
| pServer->setCallbacks(nullptr); | |
| pServer = nullptr; | |
| rcCRSF = nullptr; | |
| NimBLEDevice::stopAdvertising(); | |
| NimBLEDevice::deinit(true); | |
| vSemaphoreDelete(_mutex); |
src/lib/BLE/devBLETelemetry.cpp
Outdated
| pAdvertising->addServiceUUID(rcService->getUUID()); | ||
|
|
||
| pAdvertising->addServiceUUID(dInfo->getUUID()); | ||
| pAdvertising->start(); |
There was a problem hiding this comment.
| pAdvertising->start(); | |
| pAdvertising->start(0, &onAdvertisingStopped); |
Regardles specified timeout value, BLE library stops advertising after ~10 minutes. Add callback and restart advertising when stopped.
|
Please accept proposed changes. They solve the following problems:
|
… stop after 10 min CHANGED: power level set to ~4mW
|
I've just pushed updated code based on @RomanLut comments. There're some parts that I changed though:
Multiple clients connection tested and it works |
|
Flashed to NamimnoRC 2.4 OLED RX and BetaFpv Nano TX. It works, can see telemetry in Telemetry View. Pitch is inverted in artificial horizon though (using ardupilot), must be something else. |
yet another point to not use gemini |
Not really a fair comment. This BT telem PR takes cycles away from the core purpose of the eLRS code - to process packets - in order to route telemetry conveniently via BT. This PR was already known to cause issues with faster packet rates, which was not the fault of the rest of the eLRS codebase. Gemini is processing more packets than traditionally uni-radio TX processing so not surprising that spare CPU cycles are lower with Gemini that other modes. |
your statement is based on tests you performed or on some rumors? If latter is the case then please perform the test and then come back again gemini uses 2 times the bandwidth for no apparent reason which means - less bandwidth for others |
My friend reviewed the system, Gemini works very well. |
right, feel free to tell us what your mum thinks about it too |
I think your comments violate Contributor's Covenant. |
|
I've been using this PR for quite some time and I have to say, I love it. I noticed, however, that sometimes my phone randomly disconnects and I am not able to reconnect again for a couple of minutes. My tx is rm zorro with int elrs. This happened 2-3 times but since I was flying with goggles I couldn't really investigate it. I will try to, but I felt I should let you guys know. |
… a compiler switch. Reason - it won't fit into 20 bytes and setting BLE MTU isn't working for some reason
|
so, Ive investigated a bit deeper and I could reproduce the "disconnect" behavior. After some connect/disconnect repeats it would not connect anymore and then the "ExpressLRS Telemetry" device would appear but with a different MAC address which shouldn't happen because it is supposed to be fixed. I'm not sure why this happens, maybe a bug in the BLE stack. So, if this happens the solution currently is to disable/enable BLE Telemetry in the lua script. |
|
The latest change might solve that "disconnect" problem. At least I couldn't reproduce it by repeatedly connecting/disconnecting the radio. |
|
Hello. |
should work now |
Sank you. It work now |
Works well 👍 thank you |
|
I have fixed a bug that has prevented proper telemetry update. If you're still using this patch please recompile the FW with the latest commit. |
|
Hello. I create bin file with this PR(in main page selected 3.3.2 version). When i try to flash it throw WIFI i see error: Could Not Activate this firmware |
|
What if you try to flash it via USB? |
Yes. Throw usb flashing was sucessful |
|
My ESP32 cannot receive "CRSF_FRAMETYPE_BARO_ALTITUDE = 0x09" telegrams , but the baro value is displayed in the telemetry of the transmitter. All the other CRSF frame type work well. Edit: Altitude is in the Vario Frame |
|
The BLETelemetry contains 12 rc-channels, but 16 were used. |
|
My Antenna Tracking Project ist based ON this Pull requests. I wunder if , or when this pr become part of the Project? I think it will not stay forever as pr? |
|
I know it causes some issues when being used with higher packet rates. Why don't we just disable this feature for these higher rates and call it a day? I don't think racers of freestylers will mind. Or are there any other problems that need to be solved? I've been using this pr for several months and except from the disconnect problem that has been solved it works flawlessly for me. Is there anything we can do to speed up the integration? It's definitely a very useful tool. |
I've started using it recently with the T20, and facing disconnects after ~10 min, but I can't reproduce it on the table, only during flight. Packet rate is 150Hz. Maybe it's of high power of TX? BLE turns off completely, and can be found again only after switching it off/on in the script. |
In my case it turned out to be client related. I was using romam lut's telemetry viewer app and updating it to the latest version solved the issue, at least for me. Since then I didn't have any disconnects even at 30min+ flights |
|
@flux242 Please update the pull request to version 3.4, thanks! |
|
Loaded on Radiomaster Ranger Micro 2.4Ghz- Neither my phone or PC can't finish pairing process. ExpressLRS Telemetry bluetooth device is properly detected, but fail to connect. Restarting the module or bluetooth, and bluetooth function change nothing. |
What program do you use at the client side? |
I wanted to use Android telemetry app by RomanLut, but I didn't went that far- I fail at connecting to bluetooh davice, I don't think that application have anything to do with it. |
No need to pair, just connect through the app |
Ooo, okey. Connection through app worked, everything working fine then on Ranger Micro, great ! |
|
use 2731 |
As long as nobody wanted to finish pull request #2018 I had to do it myself. Basically I implemented all the review comments from PR #2018 on top of the master branch and tested the results.