Bluetooth LE GATT Profile question, using Monkey.Robotics

XamarinN00b1056364XamarinN00b1056364 USMember
edited October 2015 in Xamarin.iOS

Hey there.

I have a project that's some day to be cross-platform, but currently only iOS is taken care of, and since the problem I'm facing is perhaps iOS specific (platform implementation of the BLE library), I post this here.
So I have a workspace with the iOS specific project and the cross-platform, Xamarin.Forms based project where the bulk of the program is implemented.
Using Monkey.Robotics for cross-platform Bluetooth LE connectivity, I stumbled upon some weird problems which I will describe later.
But as the Robotics lib has beta status, first, I have this simple question:

Is it known by experience that Robotics works with BLE profiles more complex than in the examples? E.g. more than 1..2 characteristics?

More specifically:
Can anybody confirm that a BLE device with a GATT profile similar to the described one, worked flawlessly together with an iPhone running a Xamarin project using Monkey.Robotics?

  • Embedded device is BLE server, with following GATT profile: (read/write roles from the perspective of the phone, payload in bytes e.g. [20] )
  • 1 service, containing characteristics:
    • 1x control messages, write-no-response [5]
    • 2x data, write-no-response [20]
    • 1x control messages, notify [5]
    • 2x data, notify [20] (in Robotics BLE, notify or indicate are called "Update")
      i.e. this example has 6 characteristics, 3 in each direction

The phone (client) sends massive amounts of data, chunked, over the 20-byte characterisrics and is supposed to get a notification on a 5-byte one after those 2 had been written.

To know that people have gotten this to work properly would be helpful, in that it makes it more probable for the problem to be at the end of the BLE server device, and not a bug in Robotics that didn't surface so far because only simpler use cases (like in the examples) have been tested.

For the curious, some additional info:
Originally we used, next to the control characteristics, 4 data characteristics in each direction, then 2, and even 1, to test whether it made a difference, which it didn't.
I got a simpler profile to work, e.g. 1 bidirectional 5-byte and 1 bidirectional 20-byte characteristic, where bidirectional means it's write-no-response and notify.
But more complex than that, I get weird behavior. It could as well be on the side of the custom embedded device, but so far neither I nor a support guy for the embedded device have detected any spec violations (GATT or capabilities of the specific device) in the more complex profile described.
The behavior is that, 1) notifications on those big characteristics just don't work, but on the one small one, they do. And 2) whenever an actual notification on the small one has been sent, I also receive bogus notifications with a NULL reference for the Value array on all of the 1...4 big characteristics which are configured as "notify".

__

Sign In or Register to comment.