BLE communication is too slow and crashes on timeout

Former Member
Former Member

Hi,

I'm working on an application to communicate with a device I created (for BLE I use a BM71 module from Microchip). However, the application only works occasionally on the watch and reading values is also very slow. The value can only be read once every 7 seconds. 

Don't know what can cause it?

or how to use BLE with fast response?

PS: I'm using Fenix 6 Pro Solar

Thank you for your answers

  • How does it work in the sim?

    Are you using notify, or are you just reading the characteristics? With some characteristics, notify is based on time (you get notified every x seconds instead of when things change)

    for example, the Air Quality on the thingy52 only notifies every 10 seconds by default, but it can be changed to every second or every minute if I recall.

    I suspect the issue isn't with the watch, but with the other end.

  • Another possibility could be is your sensor is sending data too fast and the watch can't keep up.

    If you can't run in the sim, the Nordic dongle that works with CIQ is $10-$15 US and believe me, well worth the cost as you can debug right in the sim without doing sideloads all the time.  It will pay for itself in an hour!

  • Former Member
    0 Former Member over 4 years ago in reply to jim_m_58

    In simultion, scan is little bit faster then on watches, but reading is slow too.

    In this iteration i'm using request read method. specifically I do this:

    ->start application
    -> start scan 
    -> waiting for start scan done (onScanStateChange)
    -> placing scan results to array (like in nordic thingy example, but without filtering anything)
    -> select Scan result (from gui)
    -> set scan off
    -> waiting for scan off done (onScanStateChange)
    -> pairing with scan result
    -> waiting for connection state change handler
    -> geting service and characteristic object from device object
    -> requesting characteristic read
    -> waiting for characteristic read handler
    last two steps are in cycle

  • Former Member
    0 Former Member over 4 years ago in reply to jim_m_58

    For debug im using nrf52-dk

  • Former Member
    0 Former Member over 4 years ago in reply to jim_m_58

    i was tested device (bm71 module on my device) with nrf connect app, and with microchip connect app on cell phone. This side is working really well. There is minimal latency in manual reading, even in notified readings (it works with few milliseconds latency)

  • How often are you trying to read?  is it based on a timer?

  • What I do, is just start scanning when the app starts, and when I find a good UUID, I stop scanning and connect.  I usually also check for an RSSI above a certain level to insure a solid connection.

    Then when connected, for a given characteristic, I turn on notify (if available) and do a read.  The read is in a case where the notify might not occur for some time (air quality on the thingy is an example)

  • A couple of things that occured to me.  After you get the onCharacteristicRead(), are you doing somthing like a Ui.requestUpdate() so onUpdate() is called to update the display?

    And when you communicate, are you using a queue?  You can't just read characteristic A, then characteristic B, and have both work.

    you need to do something like 

    read characteristic A

    wait for the onCharacteristicRead() then

    read characteristic B

  • Another thing I do in my apps is I set a timer when I do something like a read.

    If the timer expires before onCharacteristicRead() is called, I consider the connection dead, disconnect and reconnect.

  • Former Member
    0 Former Member over 4 years ago in reply to jim_m_58

    kind like timer, i have timer with 500ms period and in callback i'm waiting while last read is done. After that i request next read.