BLE Notifications corrupted data

0

I'm trying to interact with a custom BLE device that uses notifications. When the notifications are received in Delphi, using the following in Characteristic read

procedure TForm1.BLECharacteristicRead(const Sender: TObject;
                                                                        const ACharacteristic: TBluetoothGattCharacteristic;
                                                                        AGattStatus: TBluetoothGattStatus);

...
       L:=length(ACharacteristic.GetValue);
       HexStr:=' =';

       for I := 0 to L-1
       do begin
          HexStr:=HexStr+inttohex(ACharacteristic.GetValueAsInt8(I),2);
       end;
       LogList.Lines.Add(HexStr);


the data I see is

 =010000010100FFFFFF8002000000FFFFFFC0FFFFFF8E00000000000000
 =020000010200037F000000FFFFFF8022000000FFFFFF80510100

 =2100000121000F00000000FFFFFF8000FFFFFF80000000000000
 =2200000122000F00010000FFFFFF8000FFFFFF80000000000000
 =2300000123000F00020000FFFFFF8000FFFFFF80000000000000
 =2400000124000F00030000FFFFFF8000FFFFFF80000000000000
 

but when I use the BLE tool nRF Connect, I get

Notification received from 15db2002-a532-4c8e-978a-49b768439405, value: (0x) 01-00-00-01-01-00-80-02-00-00-00-C0-8E-00-00-00-00-00-00-00
Notification received from 15db2002-a532-4c8e-978a-49b768439405, value: (0x) 02-00-00-01-02-00-03-7F-00-00-00-80-22-00-00-00-80-51-01-00

Notification received from 15db2002-a532-4c8e-978a-49b768439405, value: (0x) 21-00-00-01-21-00-0F-00-00-00-00-80-00-80-00-00-00-00-00-00
Notification received from 15db2002-a532-4c8e-978a-49b768439405, value: (0x) 22-00-00-01-22-00-0F-00-01-00-00-80-00-80-00-00-00-00-00-00
Notification received from 15db2002-a532-4c8e-978a-49b768439405, value: (0x) 23-00-00-01-23-00-0F-00-02-00-00-80-00-80-00-00-00-00-00-00
Notification received from 15db2002-a532-4c8e-978a-49b768439405, value: (0x) 24-00-00-01-24-00-0F-00-03-00-00-80-00-80-00-00-00-00-00-00

Since I have access to the device firmware, i've been able to confirm that the nRF Connect matches what the device is sending .

What would cause the ACharacteristic to be corrupted?

Responses (2)
  • Accepted Answer

    Tuesday, January 23 2018, 10:43 AM - #Permalink
    0

    I've also discovered that the phantom FFFFFF sequence shows up even when I set characteristic values then read them back

    procedure TForm1.SetTimeClick(Sender: TObject);
    var
      NowTimeStamp:TDateTIme;
      HexStr:string;
      Idx:integer;
    begin
      NowTimeStamp:=now;
      SetTimeChr.SetValueAsInt16(  YearOf(NowTimeStamp),0);
      SetTimeChr.SetValueAsInt8(  MonthOf(NowTimeStamp),2);
      SetTimeChr.SetValueAsInt8(    DayOf(NowTimeStamp),3);
      SetTimeChr.SetValueAsInt8(   HourOf(NowTimeStamp),4);
      SetTimeChr.SetValueAsInt8( MinuteOf(NowTimeStamp),5);
      SetTimeChr.SetValueAsInt8( SecondOf(NowTimeStamp),6);
      SetTimeChr.SetValueAsInt8(DayOfWeek(NowTimeStamp),7);
      SetTimeChr.SetValueAsInt8(                      0,8);
      SetTimeChr.SetValueAsInt8(                      1,9);

      HexStr:='=';
      for Idx := 0 to 9
      do begin
         HexStr:=HexStr+inttohex(SetTimeChr.GetValueAsInt8(Idx),2);
      end;

      lblSETTIME.Text:=HexStr;
      PCM.WriteCharacteristic(SetTimeChr);
    end;

    I see the label set to '=FFFFFFE20701170D2004030001'. I'm not seeing a BLE message on my device after the WriteCharacteristic so don't know what's actually being sent. I know I can write a characteristic as the notifications listed above are triggered by writing three zero bytes to another characteristic

    The reply is currently minimized Show
  • Accepted Answer

    Saturday, January 13 2018, 09:51 AM - #Permalink
    0

     

    I can verify the problem, but I was blaming it on the device (since it is a 3rd party device, I figured it was the devices fault).  I don't have a solution, but my workaround was to be more "flexible" about what IDs I considered to be "correct" by creating & using this function:

     

    function EquivUUID( U1, U2 : TGUID ): Boolean;
    begin
      // BLE sensor seems pretty arbitrary about most of the data in "D1", except for the 3 LSb,
      // so ignore the first three+ bytes when comparing
      U1.D1 := U1.D1 and $00000007;
      U2.D1 := U2.D1 and $00000007;
      result := (U1 = U2);
    end;

     

    I left in my comment blaming my sensor -- but in light of what you said, it seems more likely to be Delphi's fault.

     

    To Add to this, I occasionally (pretty rare -- but it does happen) get an "ACharacterisic" that has null FService and FDescriptors fields -- which crashes (segfaults) my program, regardless of any try...except blocks, when I try to so much as access ACharacteristic.UUID.

    I'm still trying to fix this -- AGattStatus =TBluetoothGattStatus.Success, and ACharacteristic itself is not null, but its FRefCount is ridiculous (~107 million), so something is wrong for sure.  I expect it is deep in Delphi's BLE library code, so it's likely going to be difficult to find and fix, but I'll let you know if I find anything useful.

     

      --R^3

     

    The reply is currently minimized Show
Your Reply

Please login to post a reply