Simulator read request fails.

Debugging BLE in the simulator using nRF52DK.
If you look at the read request response, the status code is 13.
It seems that the read request failed due to lack of resources.
However, when I put this into the actual device, it succeeds.
Why is this?

SDK: v4.1.6
nRF52 DK FM: developer.garmin.com/.../connectivity_2.0.1_115k2_with_s132_5.0.zip

0 jim_m_58 over 1 year ago

First thing is update your SDK. There have been 6 versions since 4.1.6 was released, with the current version being 6.2.0

Then the question is, when you read the characteristic, how large is the response? There's a limit of about 20 bytes. Could be in one case you see the error if the response is too large, and in the other, it just gets truncated. Also, which device are you using/simulating?

Also, remember you need to queue requests. Say you want to do two reads. You can't issue them at the same time. You need to issue the first one, and after you get a response, issue the second one. Also, you don't want to do any reads/writes until after you see the device is paired in onConnectedStateChanged. Here I have a queue which also handles timeouts. Say it takes too long to pair of do a read, the code handles it.
connect iq, ble, raspberry pi - News & Announcements - Connect IQ - Garmin Forums

0 3236862 over 1 year ago in reply to jim_m_58

The response returned by the request is 20 bytes.
The device being simulated is Venu2Plus.
The actual device used is also Venu2Plus.
We send a read request after sending multiple write requests, but we send the next request after receiving the response with a delegate.

It works fine on the actual device, but does not work on the simulator only.

I have raised the sdk version to the latest 6.2.0 in sdkmanager, but I get the following error

Please re-run the Monkey C Compiler with logging enabled and file a report with the Connect IQ support team ([email protected]).

0 jim_m_58 over 1 year ago in reply to 3236862

Are you queueing the write requests? What you could be seeing is a timing issue, where the sim runs faster than a real device.

0 3236862 over 1 year ago in reply to jim_m_58

I create something called a send queue and have a list of requests we want to send there in list form.
These are all in dictionary form, containing the UUID, the method of the request (write or read), and if it is a write request, the data you want to send.
Loop this send queue, send the request with index number 0, if the response is successful, delete the 0 data, send the request with index number 0 again, and repeat.

There is no problem with write requests.