FiPy and GiPy Dropping Bluetooth Writes

[Joshua Biggs]

Hi,
I've been facing an issue with both the fipy and gpy where sequential Bluetooth writes are dropped without invoking the declared callback or changing the characteristic's value. For example, my bt client first writes to the first characteristic. Its callback is invoked, and a write response is sent+recieved. The client then writes to the second characteristic, however, this second characteristic neither has its callback called, nor its value changed. This problem persists even if I change their order. The bt client I'm using works with an Arduino nano with an identical implementation (written in C, not the same code), so I'm confident the problem is on the pycom board. The code below exhibits the behavior.

import pycom
from network import Bluetooth

UUID_SRV = b"\x6d\x11\xac\x5e\x3f\xe7\x6f\x86\x76\x4f\x47\x7c\xe1\x2b\x12\xe6"

UUID_CHR_FIRST = (
    b"\x82\xa6\x45\x9e\xdb\x12\x52\xba\xcd\x43\x37\xd2\x9d\x68\xf5\xd4"
)
UUID_CHR_SECOND = b"\x7f\x48\x41\x8b\x46\x33\x56\x80\x3e\x40\x2f\x17\x2c\xb9\x5c\xcb"
UUID_CHR_THIRD = (
    b"\x59\x08\x96\x7a\xc8\x86\x94\xb7\xb4\x4b\xb8\x3e\x8b\x2b\x65\x11"
)


bluetooth = Bluetooth()

bluetooth.set_advertisement(
    name="FiPy",
    service_uuid=UUID_SRV,
)

srv = bluetooth.service(UUID_SRV, isprimary=True, nbr_chars=3, start=True)

def conn_callback(bt_o):
    events = bt_o.events()
    if events & Bluetooth.CLIENT_CONNECTED:
        print("connected")
    elif events & Bluetooth.CLIENT_DISCONNECTED:
        print("disconnected")


bluetooth.callback(
    trigger=Bluetooth.CLIENT_CONNECTED | Bluetooth.CLIENT_DISCONNECTED,
    handler=conn_callback,
)

chr_first = srv.characteristic(
    uuid=UUID_CHR_FIRST,
    properties=Bluetooth.PROP_WRITE,
)

chr_second = srv.characteristic(
    uuid=UUID_CHR_SECOND,
    properties=Bluetooth.PROP_WRITE,
)

chr_third = srv.characteristic(
    uuid=UUID_CHR_THIRD,
    properties=Bluetooth.PROP_WRITE,
)

def cb_first(chr, asd):
    print("one")

# Not invoked, unless it's the first be written to, in which case cb_third is not.
def cb_second(chr, asd):
    print("two")

def cb_third(chr, asd):
    print("three")

chr_first.callback(trigger=Bluetooth.CHAR_WRITE_EVENT, handler=cb_first)
chr_second.callback(trigger=Bluetooth.CHAR_WRITE_EVENT, handler=cb_second)
chr_third.callback(trigger=Bluetooth.CHAR_WRITE_EVENT, handler=cb_third)

bluetooth.advertise(True)

Any help would be much appreciated. Thanks!

[Meriç SARIIŞIK]

@Joshua-Biggs I have the same version on FiPy.
You expect the following result and it doesn't work for you, right?

>>> os.uname()
(sysname='FiPy', nodename='FiPy', release='1.20.2.r4', version='v1.11-ffb0e1c on 2021-01-12', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1', pybytes='1.6.1')

Pycom MicroPython 1.20.2.r4 [v1.11-ffb0e1c] on 2021-01-12; FiPy with ESP32
Type "help()" for more information.
>>> 
>>> connected
two
one
three

Can you try same operations on other firmware versions? Maybe you have another issue?

BR,
Meric

[Joshua Biggs]

@Meriç-SARIIŞIK for sure, here's what I get

>>> os.uname()
(sysname='FiPy', nodename='FiPy', release='1.20.2.r4', version='v1.11-ffb0e1c on 2021-01-12', machine='FiPy with ESP32', lorawan='1.0.2', sigfox='1.0.1', pybytes='1.6.1')

[Meriç SARIIŞIK]

Hi Joshua,

I tried to reproduce the issue you faced, but I haven't seen any problem while experimenting with your code on FiPy and GPy.

Could you please tell me the information printed when you run os.uname() command?

BR,
Meric