Hello Jcaron, I don't think that anything in terms of extra hardware added should have any effect on the UART speed. I have seen this the first time and this comes on irrespective of the firmware revision which makes me wonder. If no one has ever faced this problem then it has to be something on my HW design. Kind Regards Subham Joshi

I have made the test with scan intervals and scan windows equal to 10 ms. static esp_ble_scan_params_t ble_scan_params = { .scan_type = BLE_SCAN_TYPE_ACTIVE, .own_addr_type = BLE_ADDR_TYPE_PUBLIC, .scan_filter_policy = BLE_SCAN_FILTER_ALLOW_ALL, .scan_interval = 0x10, .scan_window = 0x10 }; The results are better but still not as good as v1.20.3.b0 Beta Firmware was. With the new values, I raised up to 60% of advertisement frames catched. Always with the same conditions and 500 ms as advertisement interval.

Hi Fredrik, First of all, CHAR_NOTIFY_EVENT works well on FiPy. Could you tell me which version you are using? I tried my example on different versions and I haven't seen a missing descriptor error. You can try the examples below. Please let me know about your experiment. BR, Meric Subscribe_Event def chr1_handler(chr, data): global battery global update events = chr.events() print("events: ",events) if events & (Bluetooth.CHAR_READ_EVENT | Bluetooth.CHAR_SUBSCRIBE_EVENT): chr.value(battery) print("transmitted :", battery) if (events & Bluetooth.CHAR_SUBSCRIBE_EVENT): update = ~update bluetooth = Bluetooth() bluetooth.set_advertisement(name='FiPy 45', manufacturer_data="Pycom", service_uuid=0xec00) bluetooth.callback(trigger=Bluetooth.CLIENT_CONNECTED | Bluetooth.CLIENT_DISCONNECTED, handler=conn_cb) bluetooth.advertise(True) srv1 = bluetooth.service(uuid=0xec00, isprimary=True,nbr_chars=1) chr1 = srv1.characteristic(uuid=0xec0e, value='read_from_here') #client reads from here chr1.callback(trigger=(Bluetooth.CHAR_READ_EVENT | Bluetooth.CHAR_SUBSCRIBE_EVENT), handler=chr1_handler) def update_handler(update_alarm): global battery global update battery-=1 if battery == 1: battery = 100 if update: chr1.value(battery) update_alarm = Timer.Alarm(update_handler, 1, periodic=True) Notify_Event def char_notify_callback(char, arg): char_value = (char.value()) print("New value: {}".format(char_value)) bt = Bluetooth() bt.start_scan(-1) adv = None while(True): adv = bt.get_adv() if adv: try: if bt.resolve_adv_data(adv.data, Bluetooth.ADV_NAME_CMPL)=="FiPy 45": conn = bt.connect(adv.mac) try: services = conn.services() for service in services: time.sleep(0.50) chars = service.characteristics() for char in chars: c_uuid = char.uuid() if c_uuid == 0xec0e: if (char.properties() & Bluetooth.PROP_NOTIFY): char.callback(trigger=Bluetooth.CHAR_NOTIFY_EVENT, handler=char_notify_callback) print(c_uuid) break except: continue except: continue bt.stop_scan() bt.disconnect_client()

@Eric73 I updated the firmware to 1.18 too and it works now. Thank you very much for your precious help and time!

Hi @pvstejeswar , did you figure it out ?

Dear @jcaron, Bringing 0x2901 CUD support to the Pycom BLE stack You would need to modify the code you pointed out in [3] to add another descriptor for the description (it currently adds a 0x2902 CCC and you want to also add a 0x2901 CUD).   For each descriptor, you need to use esp_ble_gatts_add_char_descr then wait for xQueueReceive, apparently.   You would also have to add the user description as an allowed argument (line 1192) and process that like the other optional parameters.   [3] https://github.com/pycom/pycom-micropython-sigfox/blob/4d3322a60501cac1a06558a0c5c816e198570888/esp32/mods/modbt.c#L1276-L1290 Thanks for outlining the procedure in detail how to go forward on this. While I might feel like I could eventually accept this challenge while receiving further guidelines from folks more fluent with C++ as well as FreeRTOS, the ESP-IDF and the Bluetooth Softwarestack incorporated into the Firmware, we are currently a bit swamped between different other things. Saying this, we are humbly asking members from the Pycom core team here if adding this feature could be worth the effort? We can assure you we will kindly be the first betatesters of added functionality in this regard. Maybe @semireg (@caylanlarson) and @husigeza who worked together [1] on the important improvement re. processing the Bluetooth.CHAR_SUBSCRIBE_EVENT might add their thoughts here? Thanks already and with kind regards, Andreas. [1] https://github.com/pycom/pycom-micropython-sigfox/pull/121

@misterlisty s = "".join(["%02X" % b[i] for i in range(len(service) - 1,-1,-1)]) resulting in: DEEDAAFB000000000000000000000001 sm = s[:8] + "-" + s[8:12] + "-" + s[12:16]+"-"+ s[16:20] + "-" + s[20:] resulting in: DEEDAAFB-0000-0000-0000-000000000001 Which is however on letter longer than the string above. So check whether in the second group it is really three 0's. Edit: for the second step, you can also write: sm = "-".join([s[:8], s[8:12], s[12:16], s[16:20], s[20:]])

i have lopy4 that advertisers temperature data every 30minutes and want to consume this data when it's available. At the moment, I'm creating another lopy just to continually scanner for this characteristic and then forward it though mqtt. Would tyhis be the correct way to achieve this?

Any update or information about this topic?

I have the same opinion as @jcaron . MTU size is something that has to be configurable. We should be able to set MTU size of Pycom. Changing is not going to break anything in case of good implementation (I've already tried it with Pycom). @Emmanuel-Florent the reason I've started this topic is that I've experience with ESP32-DevKitC and BLE MTU size changing, on that size everything worked fine, so I'm just requesting the same functionality on Pycom if possible.

Cool, I need it the other way around. I would like to send login data from my mobile phone to my Wipy/Lopy. Can you help me with how to proceed?

@johand Thanks for the answer this work prefect

Im not the correct person to answer your BLE queries. but if you let me know what they are Ill get them infront of someone who can and get you answers :) Otherwise. Awesome work :D

@jcaron, ah, that is a shame - but thank you for letting me know. I was hoping this could be done passively, without having to build an iOS app. Basically, I am trying to get the Pycom board to search through the advertising BLE devices on startup to determine if a specific one, my phone in this case, is present or not. Then the board will take one of two actions depending on if the phone is present or not. In standard Bluetooth, there is the process of pairing, where two devices can in effect remember each other. I was hoping there would be an equivalent for BLE.

Any news?

In case someone else comes along looking for a solution to this problem. Simply add this callback before the while loop: def char_notify_callback(char): char_value = (char.value()) print("Got new char: {} value: {}".format(char.uuid(), char_value)) And update the char condition: if ((char.properties()) & (Bluetooth.PROP_NOTIFY)): characteristic.callback(trigger=Bluetooth.CHAR_NOTIFY_EVENT, handler=char_notify_callback, arg=None)