BLE onCharacteristicRead returning status 13

Hi,

I'm trying to get a Connect Datafield working with BLE. All the connections are happening fine, and I can write data. However, when I perform a read the data is returning as null due to a BluetoothLowEnergy.Status of 13. I'm trying to connect to an iOS app acting as a 3rd party peripheral, and can successfully write data to the app. When a read request is performed I've tried sending a byte array containing a single integer value, a 16 byte array where 15 are 0's, and a 20 byte array where 19 are 0's. I'm able to connect to my fake peripheral and successfully read this using 3rd party apps such as blueFruit and LightBlue, so I'm not sure the setup is incorrect on the iOS side but could be wrong. My setup for the DataField is as follows:

  // Profile definitions
  private const _ProfileDef = {
    :uuid => SERVICE_ID,
    :characteristics => [
      {
        :uuid => DATA_CHARACTERISTIC_ID,
        :descriptors => [BluetoothLowEnergy.cccdUuid()]
      },
      {
        :uuid => WRITE_CHARACTERISTIC_ID
      }
    ]
  };


	  var service = device.getService(SERVICE_ID);
      var readCharacteristic = service.getCharacteristic(DATA_CHARACTERISTIC_ID);
      readCharacteristic.requestRead();

function onCharacteristicRead(char, status, value)
  {
    readInProgress = false;
    System.println("Read value: "+value);
    System.println("Status: "+status);
    System.println("Char: "+char);

    if (value != null && value.size() > 0) {	
      System.println("Read value 0: " + value[0]);
    }
  }

Checking the logs I get the following output:

Read value: null
Status: 13
Char: Obj: 163

Am I missing something with the expected payload for Connect? I can see through many searches that the maximum payload is 20 bytes, the format should be a byte array etc. The weird thing is the Garmin docs don't even show 13 as a potential status code, everything is just so cryptic, so any help would be much appreciated. 


  • I have the same problem here , get also a 13 status value.
    I run a dbus-monitor on my rasp (pi) so I saw the following log entry several times:


    method call time=1727511942.365621 sender=:1.6 -> destination=:1.91 serial=4737 path=/ukBaz/bluezero/service0001/char0001; interface=org.bluez.GattCharacteristic1; member=ReadValue
       array [
          dict entry(
             string "device"
             variant             object path "/org/bluez/hci0/dev_E1_0D_C3_21_1A_13"
          )
          dict entry(
             string "link"
             variant             string "LE"
          )
          dict entry(
             string "mtu"
             variant             uint16 23
          )
       ]
    method return time=1727511942.368788 sender=:1.91 -> destination=:1.6 serial=400 reply_serial=4737
       array of bytes [
          2b 16
       ]
    method call time=1727511942.565903 sender=:1.6 -> destination=:1.91 serial=4738 path=/ukBaz/bluezero/service0001/char0001; interface=org.bluez.GattCharacteristic1; member=ReadValue
       array [
          dict entry(
             string "device"
             variant             object path "/org/bluez/hci0/dev_E1_0D_C3_21_1A_13"
          )
          dict entry(
             string "offset"
             variant             uint16 2
          )
          dict entry(
             string "link"
             variant             string "LE"
          )
          dict entry(
             string "mtu"
             variant             uint16 23
          )
       ]
    


    if I do a test with my mobile and try a single read operation I will get only one entry in the log. 
    Values are exact the same except the addresses of course.

    I guess there is something wrong with the garmin implementation. I found another example and they did it exact the same way as you and I did.
    https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/would-you-like-some-raspberry-pi-with-your-connect-iq

    Maybe we will get a hint from someone else.

    Greetings Jens 

  • I'm the one that wrote the blog post you reference, and still use raspberry pi devices all the time.  The one thing to be careful of is the version of node you use, as the newer ones have issues.  Right now, here's what I use:


    node -v
    v9.7.1


  • I have the same problem here , get also a 13 status value.
    I run a dbus-monitor on my rasp (pi) so I saw the following log entry several times:


    method call time=1727511942.365621 sender=:1.6 -> destination=:1.91 serial=4737 path=/ukBaz/bluezero/service0001/char0001; interface=org.bluez.GattCharacteristic1; member=ReadValue
       array [
          dict entry(
             string "device"
             variant             object path "/org/bluez/hci0/dev_E1_0D_C3_21_1A_13"
          )
          dict entry(
             string "link"
             variant             string "LE"
          )
          dict entry(
             string "mtu"
             variant             uint16 23
          )
       ]
    method return time=1727511942.368788 sender=:1.91 -> destination=:1.6 serial=400 reply_serial=4737
       array of bytes [
          2b 16
       ]
    method call time=1727511942.565903 sender=:1.6 -> destination=:1.91 serial=4738 path=/ukBaz/bluezero/service0001/char0001; interface=org.bluez.GattCharacteristic1; member=ReadValue
       array [
          dict entry(
             string "device"
             variant             object path "/org/bluez/hci0/dev_E1_0D_C3_21_1A_13"
          )
          dict entry(
             string "offset"
             variant             uint16 2
          )
          dict entry(
             string "link"
             variant             string "LE"
          )
          dict entry(
             string "mtu"
             variant             uint16 23
          )
       ]
    


    if I do a test with my mobile and try a single read operation I will get only one entry in the log. 
    Values are exact the same except the addresses of course.

    I guess there is something wrong with the garmin implementation. I found another example and they did it exact the same way as you and I did.
    https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/would-you-like-some-raspberry-pi-with-your-connect-iq

    Maybe we will get a hint from someone else.

    Ok, I just did a test on the device, that is working as expected... so the error is in the Simulator

    Greetings Jens 

  • Like I said, I use node version 9.7.1 on the pi.

    It's been awhile, but i recall newer versions of node didn't work well with bleno, so I just stuck with 9.7.1