Acknowledged
11 months ago

Bluetooth ultra high latency since CIQ7 upgrade

We're reaching out to report a critical issue impacting Bluetooth connectivity on Garmin devices updated with the latest firmware based on CIQ7.

Issue:

We've observed an extreme slowdown in Bluetooth data transfer between Garmin wearables and our ENGO peripheral. Data transmission experiences delays of up to one minute, significantly hindering functionality.

Observations:

  • The problem seems to be related to the Bluetooth stack behavior. It appears data gets flushed or communication stalls.
  • Interestingly, exiting any idle mode on the watch (tapping the screen or pressing buttons) appears to reset the Bluetooth performance, restoring proper operation.

Impact:

This issue severely affects the user experience of our ENGO Eyewear functionality. Making the eyewear unusable.

Question:

Are there any known fixes or workarounds planned to address this Bluetooth slowdown introduced with the latest CIQ7 firmware?

We kindly request your urgent attention to this matter, as it significantly impacts our application's performance for a large number of users.

Thank you for your time and support.

Syro
  • 11 months ago

    In our case we have quite a continuous stream of data to update the remote display so waiting for response can impact the overall experience and latency. Are you aware of any change on the BT engine on Garmin side that could explain that WRITE_TYPE_DEFAULT commands are not passing at all in some cases ?

  • 11 months ago in reply to Syro

    I generally always use WRITE_TYPE_WITH_RESPONSE,as that way I know the write was handled.  Using WRITE_TYPE_DEFAULT has cased me issues, even with the queueing in my app, as the device I'm talking to might not be ready and the write gets lost.

    Can you try changing your app to always use "with response" and wait for the callback before you do anything else?

  • 11 months ago in reply to jim_m_58

    Hey. Thanks that helps. It happens some display commands are 'with response' some others are 'default'. And interestingly the freeze appears only on the ones 'without response', and in some certain states of the watch only. Some sort of 'wakeup' of the device appear to enable again the 'write_type_default' kind of commands. Would you confirm that some things have changed recently on the way the BT stack is handled on this topic. That would help confirm we are digging in the right direction. 

    Thanks again for your help. Situation is quite critical.

  • 11 months ago

    When you are sending data, are you using WRITE_TYPE_WITH_RESPONSE or WRITE_TYPE_DEFAULT?

    When you write, are you waiting for the onCharacteristicWrite(char, status) callback before writing something else?  What's the status you see?

    In CIQ Ble you have to do your own queueing.  Doing multiple requests at the same time without queueing can cause issues.