iOS Question Any recent change to iBLE library?

[Turbo3]

Have there been any changes made to the iBLE Library in the last couple of days?

Just recompiled code that was released on TestFlight and it does not work the same. No data being received after I sent some data out. TestFlight version works but today's compile does not. Exact same code as it was zipped after uploading to iTunes.

Looks like manager.WriteData is not working anymore for me.

 

[Turbo3]

After more testing I found that one of the two BLE adapters I have still works with the recompiled code (each adapter from a different vendor). The only thing I see now is a slightly different timing in responses.

I know I asked for the debug messages to be removed but I wonder if that is what is causing the difference now.

Can you please re-enable the debug messages for the iOS version of iBLE that you had in before and I can do some testing to see if that gets things working again. That won't be the ultimate fix just a way to collect more data on the issue.

 

[Erel]

WriteData was changed due to an issue discussed in another thread (https://www.b4x.com/android/forum/t...issue-with-tinysine-module.61215/#post-386545).

It now writes without expecting a result. I don't think that it should cause any issue. It will only makes things go faster.

Which issue did you encounter?

 

[Turbo3]

I need a WriteData that works the old way. When I write data I expect a response. That is the way the device works. Please add this back.

My app was working fine with the original WriteData. The app has already been released with it and it works fine. With the change you made I can no longer create a working app. I need it back.

For one device the characteristic I am writing to is "FFE1" which is a vendor unique one. It is defined as Read/Write/Notify. I have another device that uses "FFF1" and "FFF2" with notify on "FFF2".

The issue I have is I write data now and don't get a Notify so the app just stops working.

You can call the original one WriteData2.

=========================

In thinking about it I now realize my formal released version is probably defective as it was created and upload on Saturday and the change you made was on Friday. It was my TestFlight version that was released and fully tested by my users that was created about a week ago with the original WriteData.

I will probably have to release my TestFlight version based on the previous library to beat the Dec 22 deadline for submissions this year as I would otherwise need to wait for you to release a new library with "WriteData2".

 

[Turbo3]

While waiting for the new version of iBLE I have been testing with the current one. I was wonder why you needed to do the ReadData to start with and cycle through all the available services as the example iBLE code does. It looks like this is needed so iBLE or the iOS handling BLE can capture all the valid characteristics for each available service.

I validated this by issuing a ReadData for a service I did not intend to use and then tried to send a notify for a characteristic of a service I did intend to use. As expected I got the error message "You must first call ReadData and wait for DataAvailable event." Since I did call ReadData first and the send notify is within the DataAvailable routine this error message seems to make no sense. The error message is not complete. What it should be saying is a ReadData for the Service with the Characteristic being used has not been sent first. You don't actually need to cycle through all the Services with a ReadData for each one. You only need to send a ReadData for the service(s) you intend to use.

Now this brings up another problem I am having. With one device I am actually unable to get the available characteristics list back for the service I need. When I send a ReadData for the the Service I get nothing back, no DataAvailable. But I know there should be some from other Bluetooth LE apps. What is different with this Service is it has two characteristics one for Notify and one for Write Data. Could this be a iBLE library problem. Why don't I get the characteristics list back?

For this device I found that I still need to send a ReadData for this service even though I get nothing back otherwise I will get the above error message when I try to set the Notify. So iBLE or iOS is able to capture the two valid characteristics even if they don't come back in a DataAvailable.

 

[Erel]

The new version is available.

It adds a WriteDataWithResponse and fixes the issue where DataAvaialable is not raised if there are no readable characteristics.
https://www.b4x.com/android/forum/threads/updates-to-internal-libraries.48179/page-2#post-387448

 

[Turbo3]

Actually your fix for no readable characteristics now returns the two missing characteristics. So it seems the code mistakenly thought there were no characteristics when there actually were two. Perhaps the code is only expecting one characteristic so when it sees two it thinks there are none. You might want to look at the code again to see why you thing there are none.

Here is a dump of the "no readable characteristics".

NSMapTable {
[4] FFF1 -> <B4IArray: 0x1555c780>
[13] FFF2 -> <B4IArray: 0x15550910>
}

So you ended up fixed both the problems I was having.

 

[Erel]

So you ended up fixed both the problems I was having.

That's true.

You might want to look at the code again to see why you thing there are none.

This is the correct result. If you check the arrays content you will see that that those are empty arrays.

 

[Turbo3]

The arrays are of no interest. It is the characteristic numbers that are important as those are what are needed to setup the Notify and the Write commands. Without them you can not use the device.

Why did you think you could just skip giving back the characteristic numbers?

 

[Erel]

Maybe I misunderstood your previous post. You see all the characteristics now, right?

 

[Turbo3]

Yes, I see them all now. I was just wondering why you decided to not return them all in your initial iBLE library versions before your released version 1.30.

 

[Erel]

It was a bug.