ByteArray empty during BLE onCharacteristicRead() call, unsure how to correct the issue.

Had to break the post up due to two screenshots, sorry. This is a continuation of the original post.

When the app is ran within the simulator the Debug Console shows the following:

Both number formats have been attempted, although there is confidence the NUMBER_FORMAT_* is 32-bit signed int.  Within the firmware the target characteristic was verified as set to "read and notify".  The firmware was also tested in nRF connect to verify a value was associated with the characteristic.  May have overlooked something here of course, but have been unable to located where the issue is with reading (or receiving) the characteristic value.

This isn't the final location in the app where these characteristic value are to be located.  The goal was just to get this code running properly to understand what was being received and how to work with the values effectively.

Any ideas on where the issue may be would be appreciated.

It crashed on the line with "value is a numeric SINT32.." correct?

The size=0 and the decodeNumber for an SINT32 needs the size to be >=4 is my guess.  Check the size before you call decodeNumber. 

Not sure why your sensor is sending 0 bytes and you probably want to check the code there.  Maybe something like it's dealing with the read before it has any data - a startup thing..

Also, remember with CIQ you can only read 20 bytes.  Weird things can happen if you are sent more than that.

Add the check for a size .>= 4 and see if that ever happens. In rfConnect, see how many bytes it reads (there isn't a limit of 20 bytes there).

jim_m_58 correct.  This is the line where the failure occurs (or the line before if it gets commented in)

Unsure why value.size() is returning zero.

Will look into your suggestions and continue to troubleshoot.

While I work with a few different sensors, I can say I've ever seen a size of 0 on reads or notifies, but if I did, I'd just ignore it.  In my code, I first get the size and then act based on that.  My last/current project, I started out by sending 2 bytes, while I was still working out the additional 8 bytes, but the two bytes were enough to get going.

var sz=value.size();

...

if(sz>=2) {

...

}

what are you seeing for status in the callback?

Would having a descriptor in my registration profile play any role here?

I have been sifting through the documentation but haven't been able to find where the problem may be.

Cant see how..  Here's the full PM is use with BLE HRMs:

class HrPM {
    var HR_SERVICE = Ble.longToUuid(0x0000180D00001000L, 0x800000805F9B34FBL);
	var HR_CHAR    = Ble.longToUuid(0x00002a3700001000L, 0x800000805F9B34FBL);    

    private var hrProfileDef = {
        :uuid => HR_SERVICE,
        :characteristics => [{
            :uuid => HR_CHAR,
            :descriptors => [Ble.cccdUuid()]
        }]
    };
       

    function registerProfiles() {
		try {      
        	Ble.registerProfile( hrProfileDef );
		} catch(e) {
			System.println("e="+e.getErrorMessage());
		}
    }
}

When Garmin announced the BLE support, everyone in the breakout left with a pre-flashed dongle and DK, as well as a Thingy52.  I hadn't done anything with BLE before that, so the first thing I did was study the NordicThingy52 sample in the SDK, then develop my own version, with additional services and characteristics.  I could test with something known - the thingy52 - and learned a great deal in the process.  This is probably one of the more complex things in CIQ 

I've also built apps for the Raspberry Pi and ESP32, and for those I've also done the code on the "other end", and seeing what the pi or ESP sees also helps.

Again, what are you seeing for the status passed to onCharacteristicRead()?  is it non-zero?

Other thoughts.

As you are doing reads, how often are you doing the read?  If the characteristic has notify, I send to use that, so I'm not hitting the "other end" with read requests all the time and I get data only when the "other end" has the need.

Are you are doing multiple requests at the same time in your code?  Say read one characteristic and turn on notify on another characteristic, do you have a queueing mechanism?. See CommQueue.mc in the code I posted for interfacing with a pi.

Right now the app does not have an onCharacteristicChanged() function written.  This is the first and only characteristic 'read' written into the app, as was looking to just understand the values received first, before writing further code.  Also, for similar reasoning, no queue functionality has been written yet.

I have reviewed the BLE sample apps as well as your RaspPi app for references. 

Current suspicion is on the Uuids chosen in the registerprofile(), since they are just copy/paste from the thingy52 sample apps and look to be pre-defined within nRF Connect.  Investigating this route currently.

I notice you chose a different route for uuid selection in your RaspPi app.  Was there a convention you were following here or a reasoning behind this that you are able to shed light on? 

mmcleod said:

Current suspicion is on the Uuids chosen in the registerprofile(), since they are just copy/paste from the thingy52 sample apps and look to be pre-defined within nRF Connect.  Investigating this route currently.

The UUIDS match those on the "other end"?  They must.

Are you paired before you attempt the read?  You must be paired.

Another note,  it looks like you're trying to get air pressure (maybe more like this later?)

The thingy52 is a neat little device, battery powered, that goes to sleep after a bit if nothing is connected, where you can get that and more Here's one of my test apps using it.

To wake it up. all you have to do is move it.