What does status code 13 in onCharcteristicRead mean?

Former Member over 4 years ago

I'm trying out BLE using the CIQPi example as a model. I'm trying to connect to a Raspberry Pi but with an application written in C++ using the bluez bluetoothd rather than nodejs. Whenever I try to read the characteristic onCharacteristicRead is called with error code 13, not STATUS_READ_FAIL which is 12. What does this error code mean?

The characteristic can be read fine using nRF connect on Android. If I switch the UUIDs I can read successfully from the CIQPi nodejs application or from a Nordic Semi Thingy. Writing a characteristic also works although onCharacteristicWrite doesn't seem to be called.

It looks as though the problem is in getting the result back from the Pi to ConnectIQ since my callback on the Pi is called, although it seems to be called four times for each request in the simulator. There's nothing in the logs on the Pi to suggest an error. Has anyone succeeded in using ConnectIQ to interact with an application on a Raspberry Pi using, say Python, rather than nodejs?

Any help would be appreciated.

0 jim_m_58 over 4 years ago

Are you using the proper UUID on the pi end? Is it defined to be a "Read" type characteristic? You get the characteristic back in onCharacteristicRead and is a match found?

With CIQ, everything in the profile things there have to match the other end. Nothing new is learned after the paring.

This sounds to me like the UUIDs aren't matching between the two ends. What do you see when the read request in CIQ is made on the pi end? Is it getting to the code for the characteristic you want to read?

0 Former Member over 4 years ago in reply to jim_m_58

Thank you for your response. I've now figured out what the problem was but only by monitoring the low-level bluetooth communications with btmon.

My Pi application worked with nRF connect on Android and gatttool on Linux so I couldn't work out why it wouldn't work with Connect IQ. It turns out that Connect IQ issues both a Read Request followed by a Read Blob Request. Read Blob is intended for reading portions of a string that is too large to fit in a single packet. It carries an offset and Connect IQ was passing an offset that was the size of the string that my application had returned in response to the first read. Both the Read Request and the Read Blob Request end up in the ReadValue method of a DBUS application but the Read Blob includes the offset in the dictionary argument. My application was ignoring this and returning the original string again. The solution was to return an empty string if offset was present in the dictionary.

I don't know why Connect IQ is calling Read Blob; it is intended for use only if the length of the string is greater than the MTU. The other applications I'd tried didn't do this.

I'm spelling what I found in case this is useful to anyone else. I suspect that anyone writing a python application would have the same problem since that also uses the DBUS interface.

Thank you once again for respnding.