Skip to content

RFC: BLE support #423

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
7 tasks
igrr opened this issue Jun 7, 2017 · 134 comments
Closed
7 tasks

RFC: BLE support #423

igrr opened this issue Jun 7, 2017 · 134 comments
Labels
Type: Feature request Feature request for Arduino ESP32

Comments

@igrr
Copy link
Member

igrr commented Jun 7, 2017 •
edited
Loading

This ticket is opened to discuss possible approaches to implementing BLE wrappers, desired API and implementation choices.

Note: please don't use this issue to express your desire/need to have BLE support in the form of "+1" comments, questions on schedule and such. Instead, please use "Subscribe" button on the right to receive email updates on the discussion.

Prior art

Support for ESP32 BLE in other frameworks

Resources

Action list

  • Decide which existing library to choose as a base for the API
  • Design of advertising API
  • Design of Peripheral/server API
  • Design of Central/client API
  • Implementation of advertising API
  • Implementation of Peripheral/server API
  • Implementation of Central/client API

Everyone is welcome to offer suggestions and comments about API design. Contributing actual code is also a great way to move this issue forward; however please post the proposed API for comment before starting implementation.
@igrr igrr mentioned this issue Jun 7, 2017
Closed
@igrr igrr added the Type: Feature request Feature request for Arduino ESP32 label Jun 7, 2017
@igrr
Copy link
Member Author

igrr commented Jun 7, 2017

Having taken a look at the existing libraries and their example code, i like the way sandeepmistry/arduino-BLEPeripheral is designed. The chip-specific part is separated reasonably well to attempt shoehorning ESP32 support into that library. The way adding services and characteristics works in this library will probably play nice with GATT table APIs in the ESP-IDF.
Would be nice if someone else would have a brief look at the code and examples to see if there are any things which will make porting problematic.

@WALLTECH
Copy link

WALLTECH commented Jun 7, 2017 •
edited
Loading

FWIW, having worked with the Curie BLE libraries they are a pleasure to use and I vote for that. Obvious preference to under the hood ease of conversion and time of course. My needs are in a central role too. Compatibility would also be good in the Arduino community.

@me-no-dev
Copy link
Member

Probably the only major missing piece for me (in IDF) is the ability to properly pair with a device and hold that key, so the same device can reconnect again without peering. The rest I somewhat understand and have working. Have not tried to be gatt client and server at the same time also. I wonder if that is possible or we need to figure out a safeguard to prevent it. Properly connecting an item in the gatt server table to id so you can alter that item is also not so clear. Using human logic I can get to it, but that could not work in code ;)

@zencuke
Copy link

zencuke commented Jun 7, 2017

Thank you. "Other frameworks:" I've been prototyping my central mode app in Xcode/OSX mostly because I know Xcode environment for command line apps and Apple's Core BLE library is well documented. There are lots of example projects. That works as a self education process but a proprietary closed library example is obviously less helpful for this project. I mention it for completeness. It is a working ble library.

@kriswiner
Copy link

We're using Nordic's SDK (not well) to enable both central and peripheral roles for custom nRF52 devices. I think BLEPeripheral cannot accomodate central role specification at the moment. I would just say that this is a serious deficiency and I would encourage the BLE API developers to take the need for both central and peripheral roles into account in the design of the ESP32 BLE API.

I do like the syntax BLEPeripheral has chosen to specify services and characteristics and this would be a good choice for the ESP32 to emulate. I have found this much easier to use than mbed BLE.

@skateone
Copy link

i am also trying to get the esp32 to communicate with a Nordic nRF52 device. in my case we try setup the esp32 with a GATTs server hosting services and characteristics and try use the Nordic to discover the ESP32. for some reason we can only see the device from the ESP32 and non of the services.

@S3ler
Copy link

S3ler commented Jun 19, 2017

I started thinking of a Bluetooth Central API Implementation for the nRF5 Chips. It is a good Idea to use overall the same API so i participate here.
I agree with sandeepmistry to use the CurieBLE API. It provides both API for Central, Peripheral and is already used in an Arduino project.

@copercini copercini mentioned this issue Jun 29, 2017
Closed
@lemio lemio mentioned this issue Jul 10, 2017
Closed
@copercini
Copy link
Contributor

copercini commented Jul 16, 2017 •
edited
Loading

I really love @nkolban C++ implementation:
https://www.youtube.com/watch?v=WGozJXuQ8dY&feature=youtu.be
https://github.com/nkolban/esp32-snippets/tree/master/cpp_utils

It's clean and already works with ESP32, so just need a minimal effort to make an Arduino port

@ouki-wang
Copy link
Contributor

Do you decide which api to use? I vote for curieBLE.

@jcmojj
Copy link

jcmojj commented Jul 17, 2017 via email

@ayavilevich
Copy link

Sandeep's library is very easy to work with and a nicely designed API, but as mentioned above it doesn't support Central roles or running Central at the same time as running Peripheral. I would like to see a library that is as easy to understand as Sandeep's but can support Central with many Peripherals and Central and Peripheral roles at the same time.

Naturally, it makes sense to get an initial version out quickly, even if it is only Peripheral. Thanks.

@d3cline
Copy link

d3cline commented Jul 21, 2017 •
edited
Loading

CurieBLE is my personal vote as far as an API to emulate, Intel has been pushing the Arduino 101 and the curie chip a lot recently, giving away a bunch on hackster (i got one) The API is nice once you understand it. Having the same basic code between platforms would be nice.

@WALLTECH
Copy link

I agree, and it's ok to update the library as features become available rather than holding off until it's done. Different people need different features and as they come out people should be able to use them.

@gesaleh
Copy link

gesaleh commented Jul 23, 2017

I agree for the Sandeep's library easy to use, even if i had some issue with RB blend 2,
if there is any progress I would like to test it. for now I need only the Peripheral (sending sensors from ESP to Pi) that would be a great start

@tijnkooijmans
Copy link

I also like the CurieBLE API.

@scramble45
Copy link

CurieBLE API +1

@copercini
Copy link
Contributor

So, Intel has announced the end-of-life timeline for the Intel Curie module, and will discontinue manufacturing Arduino 101: https://communities.intel.com/thread/116434

@WALLTECH
Copy link

WALLTECH commented Jul 25, 2017 •
edited
Loading

@copercini this doesn't change the simplicity and suitability of the CurieBLE library. The hardware cost and misjudging the market for hardware needs was what's closing it down. They will leave their github up too to use.

@MarosValter
Copy link

I vote for CurieBLE

@nkolban
Copy link

nkolban commented Jul 26, 2017

Howdy folks,
I have been tinkering with a BLE API in C++ on the ESP32 that exposes an API that I came up with ... see:

https://esp32.com/viewtopic.php?f=13&t=2330

Is anyone actively working on a different/alternate encapsulation of ESP32 BLE support?

I see discussion of desire for a BLE API that matches that provided as described here:

https://www.arduino.cc/en/Reference/CurieBLE

Is there a designated sub-project leader for the technical discussion described in this Github issue? What would be a shame is if we all went in separate directions and perform individual work as opposed to a collaborative effort. I'll be delighted to pitch in in some way. It may be as simple as taking my existing library of BLE C++ functions are re-exposing the interfaces to match those of CurieBLE or maybe there is a design proposal that starts from scratch?

@d3cline
Copy link

d3cline commented Jul 26, 2017

I am waiting to see what the official decision is by espreiff and igrr. I wish I could provide more feedback from the hardware end. I need a little boiler plate to run with and I am willing to help debug and provide more feedback. I am anxious to start coding with Kotlin, BLE, and ESP32. The arduino code I already have which was for Arduino-101 and what will be similar in future projects just needs to send a JSON string. Basically waiting to see what will happen before I see what/if any assistance I can lend beyond debugging.

@wekhrozomedo
Copy link

CurieBLE API

@gmag11
Copy link

gmag11 commented Jul 30, 2017 •
edited
Loading

I'm following tutorials from @nkolban and trying to replicate same code on Arduino. The problem is that included precompiled IDF is behind main esp32-idf repository development, and many of the functions there are not implemented here.

Anyway I find his implementation simple enough (on the interface) and close to esp32 capabilities.

I'd vote to see his work integrated on arduino-esp32.

@jcmojj
Copy link

jcmojj commented Jul 30, 2017 via email

@dineshjoshi
Copy link

I like CurieBLE as well.

@WALLTECH
Copy link

@jcmojj Of course CurieBLE can do signal strength. Use .rssi() on a BLEDevice object to get it.

int BLEDevice::rssi() const
{
return BLEDeviceManager::instance()->rssi(this);
}

@me-no-dev
Copy link
Member

@haosheng-huang use good usb cable and stable power supply. The error means that the supplied voltage dropped too low. Could be a bad LDO, since you did not say what board exactly you are using.

@haosheng-huang
Copy link

@me-no-dev thks,But I already use power supply only. I use this board.

1e038497-7f1f-479e-ad52-0dbacba01c97

@Spritetm
Copy link
Member

@haosheng-huang Can I ask you to start a new issue (or post on the esp32.com forum) for this? It has nothing to do with the BLE/Arduino discussion in this issue.

@ArcadeMachinist
Copy link

@MarosValter ,
Exactly the same "abort() was called at PC 0x400d880b on core 0" happens with my board.
After calling BLEServer *pServer = new BLEServer(); from sample.
If I would comment everything out and try enabling code line-by-line:
ble.init("MyESP32"); - works fine
call to new BLEServer(); - makes the board to panic

@nkolban
latest Arduino, latest ESP32_BLE.zip built from github
Board is "WeMOS" Wifi+Bluetooth+Battery (with wroom-32)

@nkolban
Copy link

nkolban commented Sep 21, 2017

@Alexkirillov
For problems, issues, enhancements and other code related items on the BLE C++ classes for Arduino as delivered by the "cpp_utils" project, can I ask that you raise an issue here:

https://github.com/nkolban/esp32-snippets

This thread/issue is about "What should we do for BLE support for ESP32 Arduino" and not so much defect hunting/chasing on a given implementation. Currently the options for BLE support for ESP32 Arduino" are:

  1. Continue with the BLE C++ classes for Arduino as delivered by cpp_utils with existing API.
  2. Continue with the BLE C++ classes for Arduino as delivered by cpp_utils with alternate API.
  3. Create another implementation of BLE C++ classes based on ESP-IDF as an alternate for the delivered by cpp_utils.
  4. Something else ...

That thinking is still on-going and for the time being (1) exists and is gaining more users who are using it (and breaking it) in interesting ways. This has possibly taken the pressure off making a "formal" decision but one should assume that as time passes ... a community broad decision will likely be made.

@vanilla-thunder
Copy link

Imho, BLE API should be easy to use and understandable for newbies, so people could actually concentrate on building awesome IOT devices instead of researching and studying GATT and GAP services.
I might be a bit spoiled by JavaScript or PHP, but it seems wrong to me, if you need to copy-paste hundred(s) of cryptic code lines just to get a "hello world" program running.
After comparing example code for CurieBLE, BLEperipheral and mbed BLE, my favorite is CurieBLE.

@vshymanskyy vshymanskyy mentioned this issue Oct 4, 2017
Closed
@d3cline
Copy link

d3cline commented Oct 10, 2017

I noticed an upstream change has broke BLE we had. I still feel this should be something the chip manuf cares about if they want the chip to live. I know if I was a rival chip manuf I would do everything I could to provide a sane arduino BLE stack to kill it because its clear the demand is here. Also I have the WiMos Battery and have beaten them up, I notice it has issues with the same brownout error as people are describing if the battery is low. Try removing the battery to see if this solves it, if so use a better battery and make sure it has a decent charge.

@d3cline
Copy link

d3cline commented Oct 10, 2017

nkolban/esp32-snippets#82 :(

@d3cline
Copy link

d3cline commented Oct 10, 2017 •
edited
Loading

To be quite blunt, why don't the people who work on the IDF pay attention to customer demand? With a little communication they could have had this built in no time. You know lots of other hardware manufactures ignored what people wanted and wasted tons of time and money on boondoggles too, they all failed. If I can order some nordic chips and have them working before this is fixed I likely will never buy another espreiff chip again. You may take this as rude, but it is just the nature of the beast and I am being honest.

@kriswiner
Copy link

kriswiner commented Oct 10, 2017 via email

@SReichmann
Copy link

I have mixed feelings about this, on the one hand: The few devs expressif pays to build the software seem to do a great job and the esp32 is one hell of a value for money beast which works pretty well on arduino, except BLE of course. As i heard the IDF 3.x is on the rise (my IDE of choice platformio still uses IDF 2.2x for arduino programming) so there might be some changes to the new IDF BLE part which may have delayed the arduino BLE work until the new IDF BLE APIs are stable? Just a guess from my side...

On the other hand: Well.. BLE was one of the main features why i decided to use this uc in my projects. My workaround is to use external components for BLE support until the arduino BLE API is ready. That may not be a perfect solution but at least i can work on other parts in the meantime while using the same communication interface.

What i would really appreciate is some kind of feedback from the BLE arduino devs, just to see how work is going on... is the work on hold? Is development done while we are speaking? Or do you even have some kind of release date in mind? If work is on hold or delayed, what are the reasons? Are there some parts where we could even help?

@d3cline
Copy link

d3cline commented Oct 11, 2017

The issue is explained by nkolban at nkolban/esp32-snippets#121 (comment) Although I understand 'things take time' things in IT die quick, and there are always new solutions popping up, or cheaper old solutions, rivals trying to beat you to the punch (which if you are an independant app dev is the worst). Having something break like this is also frustrating. Why not base arduino on a stable release? When will this IDF development which breaks everything stop? ESP32 was supposed to be 'the 8266 + BLE' otherwise all the great things it can do can mostly be done by the 8266 (touch and audio is alright, but not even close to BLE). I would have never known or cared who espressif was if the 8266 wasn't so arduino friendly. So far it isn't that, and based on the track record for this issue it won't ever be that by the time it matters. And I think that is what upsets me, realizing this chip has a lot of potential which may be ignored because it will be obsolete by the time it is done, and all this time and effort I spent waiting for this solution when I should have just gave up on it months ago and used a nordic working solution. That this could be easily fixed if there was some kind of communication or priority to make BLE stable and functioning with a simple API. The functionality is there, it's just a pain to get to, I tend to feel the people who wrote those functions could easily write some wrappers but its 'community software' so why bother. Just because arduino is a community project should not mean it has the last priority. The licensing from my point of view is just as commercial as their IDF, more since I can rapidly develop things as a lone developer. The bottom line is if they care about selling chips and maintaining customer trust they might want to fix this and stop breaking it, make BLE a priority or expect we will move on.

@kriswiner
Copy link

kriswiner commented Oct 11, 2017 via email

@edcasati
Copy link

edcasati commented Oct 11, 2017 via email

@kriswiner
Copy link

kriswiner commented Oct 11, 2017 via email

@kriswiner
Copy link

kriswiner commented Oct 11, 2017 via email

@carlkyu carlkyu mentioned this issue Oct 14, 2017
Closed
@ibaranov-cp
Copy link

Bit of a conflict of interest there @kriswiner , recommending your own products.. ;)

@kriswiner
Copy link

kriswiner commented Oct 20, 2017 via email

@me-no-dev
Copy link
Member

@kriswiner I could agree that sticking a competitor’s product in our face here is the least not nice ;) but whatever :D BTW @nkolban ’s BLE is now included ;)

@kriswiner
Copy link

kriswiner commented Oct 21, 2017 via email

@Nakul93
Copy link

Nakul93 commented Nov 14, 2017

How to increase the stack size I am using Wifi + BLE but when I use the wifimanager library it crashes. So I have to either comment wifi setup or ble setup. Please help

@MartyMacGyver
Copy link
Contributor

@Nakul93 I'd think adjusting the stack values in hardware/espressif/esp32/tools/sdk/include/config/sdkconfig.h might help. bt.h seems to use that and hardware/espressif/esp32/tools/sdk/include/esp32/esp_task.h as a basis for setting up their stacks. I'm not sure which stack value might be causing you problems though.

@haarislabs
Copy link

Is it still the same case ?? My team is planning to use Esp32 for a biomedical product in which reliability is a major factor, so @kriswiner do you still think esp32 is not ready for consumer products?
As of now I was testing all the features of esp32 (wifi,ble) using idf sdk and testing if everything would work for a quick prototype.

@kriswiner
Copy link

kriswiner commented Jul 16, 2018 via email

@beegee-tokyo
Copy link
Contributor

Same as @kriswiner , I tried to test all features, but using Arduino framework. Most of the stuff is working reliable now. Wrote some blogs about it ESP32

Working a customer project right now where we will use I2C to poll a sensor and send the data over BLE every 5ms. But because it (hopefully) will be a commercial product, we do not use Arduino framework for it, instead I program everything using directly ESP-IDF. First prototype code is working now. (Surprised that we could achieve the 5ms update rate over BLE).

@aster94
Copy link

aster94 commented Mar 16, 2019

I am not sure if you already made a decision about which API to use
if not: arduino's official API (curieBLE) 👍
if yes: please update the first post to prevent comment like this 😅

@atanisoft
Copy link
Collaborator

@me-no-dev I think this one can be closed since there is a BLE lib in arduino-esp32 already

@igrr igrr closed this as completed Jun 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Feature request Feature request for Arduino ESP32
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests