Bluetooth GATTSCharacteristic GPy

[shanefowler25]

Hello all,

I'm using Bluetooth with my GPy board and I am setting an advertisement with a service and characteristic. I am able to use my phone as a client and connect to my board using a BLE app so I can write a character event so that I can print to the console. My code is as follows:

from network import Bluetooth

bluetooth = Bluetooth()
bluetooth.set_advertisement(name='GPy', service_uuid=b'1234567890123456')
bluetooth.advertise(True)

srv1 = bluetooth.service(uuid=b'1234567890123456', isprimary=True)
chr1 = srv1.characteristic(uuid=b'ab34567890123456', value=5)

def readBluetooth(chr):
    events = chr.events()
    if events & Bluetooth.CHAR_WRITE_EVENT:
        write = chr.value().decode('ascii')
        #print(write)
        if(write == 'open'):
            print('Open')
        elif(write == 'close'):
            print('Close')

char1_cb = chr1.callback(trigger=Bluetooth.CHAR_WRITE_EVENT, handler=readBluetooth)

My question is how can I get the result of my callback, char1_cb, and use it in a while loop? For example, if write equals open in my code how could I use that result within a while loop to break the loop to go to the next task in code?

If anyone could help me resolve this that would be greatly appreciated, I tried to print(char1_cb) but the result to the console was always None and again I'm not sure why or how it might change if the handler in the callback is executed properly.

[shanefowler25]

Essentially, I would try and do something similar to this article with an arduino and Bluetooth module:

https://create.arduino.cc/projecthub/mayooghgirish/arduino-bluetooth-basic-tutorial-d8b737

Is there a way I can replicate something like this? Is it possible use bluetooth over serial communication with pycom? Again, any help is greatly appreciated!

[shanefowler25]

I figured out how to pass data via bluetooth in my program, but now sometimes when I do so I get a core dump and my board restarts. My code is as follows:

from network import Bluetooth

bluetooth = Bluetooth()
bluetooth.set_advertisement(name='GPy', service_uuid=b'1234567890123456')
bluetooth.advertise(True)

srv1 = bluetooth.service(uuid=b'1234567890123456', isprimary=True)
chr1 = srv1.characteristic(uuid=b'ab34567890123456', value=5)

machine.pin_deepsleep_wakeup(pins = ('P13','P23'), mode = machine.WAKEUP_ANY_HIGH, enable_pull = False)

while True:

  if Bluetooth.CHAR_WRITE_EVENT:
        write = chr1.value().decode('ascii')
        if(write == 'open'):
            openUserScan()
            break
        elif(write == 'turn off'):
            break

sleep(2)
print("Going to sleep")
machine.deepsleep()

This code runs sometimes, but then other times it gives me a core dump with a whole lot of characters and I'm not sure why. There isn't much documentation on Bluetooth or on the Core Dump so I'm not really sure how to fix this issue. Has anyone else run into this problem before?

[andreas]

@shanefowler25 said in Bluetooth GATTSCharacteristic GPy:

Has anyone else run into this problem before?

@poesel has been hit by te same thing.

• https://forum.pycom.io/topic/5358/1-20-0rc13-guru-meditation
• https://community.hiveeyes.org/t/investigating-core-panics-with-ble-on-pycom-devices/2715

[shanefowler25]

@andreas Thank you for responding. So after reading the threads from those links you posted, currently there is no solution for this issue? There is a problem with Pycom's software?

[andreas]

@shanefowler25 I wouldn't say it's a problem with the Pycom firmware, so there's no reason for blaming. The problems can arise from very deep within the ESP32 silicon and the Espressif SDK with interaction between different subsystems.

The issue tracker [1] over there is full of stuff where problems might come from running WiFi and Bluetooth in parallel and beyond. This is called the "WiFi/Bluetooth coexistence" issue [2], also known as "coexist" or just "coex". While this is an evergreen on the issue tracker and should apparently be fixed already, it still keeps popping up from users on different versions of the ESP-IDF. I would like to encourage you to try without WiFi as a last thing we could test here.

Otherwise, I am totally out of ideas and we will probably have to wait until a newer ESP-IDF has been released and incorporated into Pycom MicroPython where these bugs have been hopefully resolved.

In the meanwhile, it might help others to look into that issue if we can provide the core developers with a minimum reproducible example.

Saying all this, I will be more than happy to learn otherwise about things we might have missed on this.

[1] https://github.com/espressif/esp-idf/issues
[2] https://github.com/espressif/esp-idf/search?q=coexist&type=Issues

[shanefowler25]

@andreas Again, thank you for your answer that gave me a lot of information! I’m using the GPy board, you mentioned the issue may arise from WiFi/Bluetooth running in parallel. If I use cellular as opposed to WiFi, would that solve my issue?

Ultimately, I will be using cellular for my application. I’ve only been using WiFi right now so that I don’t keep using/paying for data.

[andreas]

Dear @shanefowler25,

@shanefowler25 said in Bluetooth GATTSCharacteristic GPy:

I'm using Bluetooth with my GPy board.

@shanefowler25 said in Bluetooth GATTSCharacteristic GPy:

This code runs sometimes, but then other times it gives me a core dump.

Without warranty or too much hopefulness of any kind, we would like to point you to [1]. More details can be found at [2].

Before upgrading to 1.20.1.r1, you will have to reset the flash of the device like pycom-fwtool-cli.exe --port /dev/ttyS1 reset_all [3].

We will be happy to hear about the outcome for you.

With kind regards,
Andreas.

[1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/GPy-1.20.1.r1-0.5.0-vanilla-butterfly-csfix.tar.gz
[2] https://community.hiveeyes.org/t/investigating-core-panics-with-ble-on-pycom-devices/2715/13
[3] https://community.hiveeyes.org/t/installing-the-recent-pycom-firmware-1-20-1-r1-requires-erasing-the-flash-memory-completely/2688

[shanefowler25]

@andreas I was able to successfully upgrade the firmware to the latest version, but now my urequests.py library won't run properly when using wifi.

However, I was able to upload my program successfully while using cellular, but when I tried using Bluetooth to break the loop nothing happens at all now when I try to pass data to my GPy board via bluetooth.

[andreas]

@shanefowler25 said in Bluetooth GATTSCharacteristic GPy:

I was able to successfully upgrade the firmware to the latest version

May I humbly ask which one you are running right now?

@shanefowler25 said in Bluetooth GATTSCharacteristic GPy:

[After upgrading,] my urequests.py library won't run properly when using WiFi.

Did you upgrade from a lower firmware version than 1.20.1 actually? If so, you will have to reset the flash of your device completely in order to get the partition layout right where things regarding WiFi calibration gets stored. Without getting this straight, network connectivity over WiFi breaks for many people completely.

@shanefowler25 said in Bluetooth GATTSCharacteristic GPy:

when I tried using Bluetooth to break the loop nothing happens at all now when I try to pass data to my GPy board via bluetooth

This sounds pretty advanced. Without more details on that, I can't say anything about it. What I can say about it is that Bluetooth also seems to be problematic sometimes [1], even when running at the same time (coexisting) with WiFi on vanilla ESP32 boards.

[1] https://community.hiveeyes.org/t/investigating-core-panics-with-ble-on-pycom-devices/2715

[andreas]

We've just released another bunch of firmware images with hopefully improved robustness, so [1] might make you happy.

[1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/vanilla/GPy-1.20.1.r1-0.6.0-vanilla-dragonfly.tar.gz

[shanefowler25]

@andreas Again thank you for responding to my issue I appreciate your help. I did upgrade from a lower version that 1.20.1, however, the wifi was able to connect, I just wasn't able to do a GET request for my application, but that's okay because I was able to use cellular to do the GET request, which is the network I will be using.

I reset the flash on my device and did an upgrade to the latest firmware, but my program would still crash when I used to Bluetooth to break the while loop of my program. I figured out a workaround that works for the application that I'm trying to do.

Hopefully sometime in the future, there will be another update to the firmware that allows users to use Wifi/Bluetooth or Cellular/Bluetooth, without the program crashing and resetting the board.

[andreas]

Dear @shanefowler25,

@shanefowler25 said in Bluetooth GATTSCharacteristic GPy:

I just wasn't able to do a GET request for my application.

May I humbly ask whether you wanted to connect using SSL here? I'm just asking because we didn't test these details thoroughly with our custom builds yet.

@shanefowler25 said in Bluetooth GATTSCharacteristic GPy:

Hopefully sometime in the future, there will be another update to the firmware that allows users to use Wifi/Bluetooth or Cellular/Bluetooth, without the program crashing and resetting the board.

Issues around this "coexist" thing have even bitten Espressif Systems for quite a while, as outlined above. In this manner, the Pycom firmware is pretty much innocent here as it depends very much on the details coming from the ESP-IDF in this regard.

@shanefowler25 said in Bluetooth GATTSCharacteristic GPy:

My program would still crash when I used to Bluetooth to break the while loop of my program.

While we are avid WiFi users, some people from our community are also approaching BLE these days. @poesel reported his observations on [1] and [2] already, but unfortunately he is currently traveling without being able to confirm our latest build would work better for him. He is using a GPy as well.

@shanefowler25 said in Bluetooth GATTSCharacteristic GPy:

I figured out a workaround that works for the application that I'm trying to do.

Good that you found something that works for you.

As we are currently trying to collect experiences from people affected by this issue on [3], we still ask anyone who could test the latest dragonfly builds. So, if you might find some time for that beyond working on your program, we would be more than happy to hear about the outcome.

Thanks already and happy hacking.

With kind regards,
Andreas.

[1] https://forum.pycom.io/topic/5358/1-20-0rc13-guru-meditation
[2] https://community.hiveeyes.org/t/investigating-core-panics-with-ble-on-pycom-devices/2715
[3] https://community.hiveeyes.org/t/testing-the-custom-dragonfly-builds-on-pycom-devices/2746