Can't write BLE second message on a Edge 530

Hi all,

I've written a Connect iQ DataField app to talk to a sensor using BLE serial protocol so that data from the sensor can be displayed in a data field. The sensor requires that a sequence of configuration messages get written to it without response in order to initialize it so that it can stream data back to the Garmin device. It works fine on devices like the Garmin Fenix 6 and the Edge 540. However, on the Edge 530 device, I am only able to write the first message of the initialization sequence successfully and then the next message in the sequence throws an " Operation already in Progress" exception upon calling requestWrite, despite the fact that the first write has already been completed successfully (ie onCharacteristicWrite has been invoked with STATUS_SUCCESS). Successive calls to requestWrite all result in the Operation already in Progress message. What could cause this to happen?

Thanks in advance!

0 jim_m_58 2 months ago

Are you queueing your requests so there is only one active at a time? I wrote this a few years backm and lokk at comqueue,mc and how it;s used, It also handles timeouts,

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/would-you-like-some-raspberry-pi-with-your-connect-iq

There's queueing in the nordic thingy52 samples, but it's harder to see,

I' generally use WRITE_TYPE_WITH_RESPONSE when writing multiple things.

0 7635915 2 months ago in reply to jim_m_58

Thanks very much for the quick response! I have looked at your CIQpi project. Thanks for sharing that.

I'm not queueing my requests per se because there's a fixed sequence so I just use a state machine to trigger the next response. Also, because it's a data field I don't have access to the Timer api. I can use the compute method of the DataField to trigger the writes after the onCharacteristicWrite has completed but that doesn't seem to help either. I am ensuring that I'm only writing one at a time by waiting for the onCharacteristicWrite to be received before I proceed with the next requestWrite invocation and there are no other outstanding requests in progress.

As for the WRITE_TYPE_WITH_RESPONSE my understanding was that was determined by the receiver and in my case the sensor expects asynchronous WRITE_TYPE_DEFAULT messages. I suppose I could try this to see if it helps but I suspect it will just time out because the peripheral doesn't write anything back to the central.

0 jim_m_58 2 months ago in reply to 7635915

I use WRITE_TYPE_WITH_RESPONSE pretty much all the time, with various sensors. I'd give that a try.

You need to know the 1st write is complete before you send off the second one.

If not, that would explain your "Operation already in Progress"