BluetoothLowEnergy development

Hmm but if i remove the content of my question it does allow me to post!

I have been working on an app using the new CIQ BluetoothLowEnergy functions using the nRF52840 dongle, and CIQ simulator for Fenix 5 plus.
My target is a BLE device under development and could potentially need some changes.
So far i am able to scan, pair, connect and read from the target BLE device and can query various information within the SDK.

I am not having success in writing to the BLE device. If i wait for notification it returns STATUS_WRITE_FAIL = 14.
I am able to write to it using tools on IOS such as a BLE utility 'TI SensorTag'.
When i read back values written with CIQ i only see the values put there by IOS, not those written within the SDK.
I have looked over all the CIQ examples i can find, but it seems they all only read and do no writes to characteristics.

It appears the information in BleScanResult relates to information obtained during the scan. I can read some of this, however i cannot seem to get much information about the services this way.
getServiceUuids() returns good information, however i keep getting null from getServiceData(). I tried getRawData which returns 20 bytes, but not sure how to interpret any of it.
In it's place i can see some data using IOS tools like BLE utility 'TI SensorTag', 'BlueLight'. They however tend to interpret the hex to english words and so i cannot see the hex values.
The Garmin SDK has very few constants defined so i expect i would need to set any descriptors using hex values.

Meanwhile the information Ble.Sevice/Characteristic/Descriptor is related to the definition i put in registerProfile. For descriptors i have been using Ble.cccdUuid() per the examples, but perhaps that needs change.

So looking for some clues.
- is anyone else doing writes to a BLE device?
- could incorrect profile definition cause the write errors?
- can more information about the services be obtained within CIQ?
- it appears the CIQ SDK is designed to be master to a slave BLE device. Am i correct that the reverse is not supported, where the watch is slave to another master device?
In this case i believe I would need a way to define what is to be advertised by the watch.

and it allows me to post my question as a reply

When you are writing are you using WRITE_TYPE_WITH_RESPONSE or WRITE_TYPE_DEFAULT?  I've written to a few devices and characteristics.  The samples I posted for the raspberry pi do both reads and writes if you want to see the code..

Have you tried things on a real device vs the sim?

When you do a BLE profile, you have to include everything you'll use.  It wont discover other things when you pair.

CIQ connets/pairs to a device.  The device connecting to CIQ isn't possible.

With the writes, another thing it could be is what you're writing could be invalid it's expecting 2 bytes and you're sending 1 or 4.  The endian could be wrong, so the values aren't valid.

One thing to try is read the characteristic and send back exactly what was read in the same format (read the byte array and send that byte array back with no change)

Thanks Jim, So far i do not have a real device that supports BLE so for now just the simulator.
My profile defines the services i will use. I am less certain about the descriptors i need for them, and I am wondering however if the descriptors are perhaps wrong might cause an issue.
I have tried both DEFAULT and WITH RESPONSE. Default does not return any error, but the data does not get written. If i wait for the response i can see the failure code mentioned.
Will try your suggestion re format of data. It appears i have little control of the format, the write function simply accepts a byte array.
I presume the length sent is based on the length of the array provided. This and endian info is something i was wondering about and considering if my descriptor definitions need to reflect this in some way,
right now descriptors are just Ble.cccdUuid().
Thanks i had not seen your post, will have a look over this next.
forums.garmin.com/.../would-you-like-some-raspberry-pi-with-your-connect-iq

I think you mean the characteristics, and not descriptors.  You'll write to the characteristics in most cases.  The one time I write to descriptors is if I'm turning on/off notify for a characteristic.

If you write DEFAULT or WITH RESPONSE, the callback in the delegate will get called, so I'm guessing that's where you see the status.

Sounds like you want to use DEFAULT, but something in your data is wrong.

encodeNumber and decodeNumber number are really useful when it comes to encodeing/decoding things in the byte array, as you can specific the # of bgytes, signed vs unsigned and endian. but a good first step is just write exactly what you read.  Then maybe just change the value of a single byte in what was read and send that back, but keep everything else the same.

Hmm, well your ideas gave me a clue, but perhaps not as expected.
My target device has a test characteristic of 20 bytes. I should be able to write to it and then read back.
I have not concerned myself with how to encode data within it, it is simply a byte array i hard code as a constant with 20 byte values (eg. const x =[1,2,3,4...]b).
I am now finding that changeing the first byte effects it. Some values work, others not.
Is there anything specific required by the BLE or CIQ that might explain this?
My guess is more likely something in the target BLE device is interpreting the data to cause the error?

I realize that mainly the characteristics are where things should be written. However i anticipate the descriptors describe the characteristics, as you mention re notify, but perhaps other aspects can be controlled here?
I was guessing that i would need to have the correct descriptor in my profile in order to describe how the characteristic operates. If this was wrong perhaps it would explain write failures.

Correct, i am seeing the status in the callbacks.

This were finding a spec for BLE on the device is really handy. Anything is possible. You can see what's there, what format it's in, what's valid, etc.  Here's an example for the thingy52 - you can see where there are multiple values in the same read/writes, and their format - you'll notice some things are fixed point ("16Q16").  by just doing a println in the app when you do a read, endian is easy to see for multi-byte numbers

https://nordicsemiconductor.github.io/Nordic-Thingy52-FW/documentation/firmware_architecture.html

When I first started looking at BLE on the pi, the sample I found actually returned json data on some reads.  A byte array which each byte a character, so I converted the byte array into a string to make sense of it.

As I did more on the pi, I had a real advantage where I defined that end myself as far as characteristics and how the data was sent/received.

With your test characteristic, it could be that certain bytes are used for certain thing, and only certain values are valid.  That again is where a spec would really help.  It could be the characteristic is used to actually test certain things on the device for example.

Using tools on iPad/iPhone i can see other iPad/iPhone and the services they advertise. I do not however see them in the  scanresults with CIQ. Is it likely that they perhaps block out the phone from the scanresults - perhaps to avoid interference with what garmin connect IOS app is doing? I think the IOS side can also see more devices beyond this also. One thought i had is perhaps standard (older) bluetooth vs BLE - and that the CIQ only shows BLE?