BLERead event handler called twice?

[kk7ds]

I'm using an Arduino Nano RP2040 Connect with the NINA module. I've got a service that exposes some string characteristics that I want to feed a different value to each time they're read. I've set an eventhandler for BLERead, which is called. However, it seems to always be called twice on each read. I thought maybe this was a problem with the mobile app I'm writing, but I tried a BLE test/scanner app and each time I read the characteristic, the event handler is called twice.

Surely this is not intentional right? Am I doing something wrong that causes me to be called twice? I've looked through the AndroidBLE code a bit and I don't see any indication that I should be called twice. Even if I don't change the value, the handler is called twice.

Here's roughly what I'm doing:

void iter_temp_log(BLEDevice *central, BLECharacteristic c) {
    Serial.println("CALLED!");
}

void setup() {
    BLE.setLocalName("Remote Level");
    BLE.setAdvertisedService(levelservice);
    levelservice.addCharacteristic(templog);
    BLE.addService(levelservice);
    BLE.advertise();
    templog.setEventHandler(BLERead, iter_temp_log);
}

[kk7ds]

@per1234 Does the imperfection label mean "yes, that's a thing"? I've been bashing my head in the last 24 hours trying to figure out why I'm missing log records, so I'm happy to have realized the problem. If it's a library thing I'll hack around it and be happy, I just want to make sure I'm not doing something wrong.

[per1234]

No. It means "the reporter perceives this to be a defect in some component of the project". This is purely a classification of the type of the report, used to organize the issue tracker.

We classify reports into "imperfection" (essentially bug reports, but we avoid the term "bug" because that is specific to code, while a defect might also be in other components such as documentation or infrastructure), and "enhancement" (feature request).

At some time in the future a developer will investigate this report to determine whether it is "a thing".

If you need help with your project now, please post over on the Arduino forum:

https://forum.arduino.cc/

[kk7ds]

Okay, for normal characteristics that return the "current" value always, it wouldn't be a big deal. So I figured maybe "imperfection" was acknowledgement that this is not critical, but superficial.

I guess I can ask in the forum, but I figured the developers here would be the ones to know whether or not the behavior is expected.

Thanks!

[paulvha]

Could it be that the String length is longer than the MTU size and as such 2 reads are necessary (and thus 2 x call back ?)

[kk7ds]

My string length is a fixed and constant 26 chars. I dunno what the MTU for BLE is, but I would have assumed I was safely below it... Even if that is the issue, it's very inconvenient to be called twice for one logical read, because any side effects will be duplicated.

[paulvha]

Default MTU is 23 bytes ( 3 bytes are used for overhead (handle etc) as such 20 bytes is max. A debug : Try a short String to see whether that works.

[kk7ds]

Eesh, okay. Now that you mention it, I have one other string characteristic which just happens to be 20 chars and I don't think I see it read twice in the logs. That one has no side effect so it doesn't matter if it is read more than once. I'll go confirm for sure.

Is there something in the BLE stack that can be used to avoid calling the handler for the subsequent reads? If not, I guess some documentation so at least it's visible as an issue.

[paulvha]

Think I have a fix/ bypass.

I added a bool (_Enable_BLEread_Callback) that is set during Writevalue(). In Readvalue () it is checked and if set it will look for a BLEread callback. If so that will be performed and _Enable_BLEread_Callback will be reset. Hence you get a callback only once after each WriteValue(). I can not test it that quickly.

In the attached zip 2 files.

• Close down ArduinoIDE
• goto the folder in ArduinoBLE/src/local
• Make a safety copy first if you want of BLELocalCharacteristic.CPP and BLELocalCharacteristic.h
• copy the attached files from the zip to this folder

restart ArduinoIDE and recompile. Look forward to whether that works.

BLELocalCharacteristic.zip

[kk7ds]

I'm using platformio, FYI. But, it seems like with this in place, my handlers only ever get called once after uploading the sketch. Not even a reset will cause them to be called again, which seems strange. And, it seems like they're still getting called twice on the initial round.

[paulvha]

I have made a change now. Instead of reacting on the first readValue(), it should now be calling the callback when ALL data that was written before has been read. It might have caused your issue.

BLELocalCharacteristic.zip

[kk7ds]

Hmm, nope, still getting a successful call post-flash and then never again on the long-string characteristics.

Reading from the long-string characteristic fires the handler on the first read, and then never again on subsequent reads. With the updated code, it only calls the handler once instead of twice for that initial read, but never again. The short-string characteristic also seems to be only ever called once, until a write is performed (it is BLERead | BLEWrite), after which it will be read once only (until the next write).

I've only got one BT-enabled device to do this testing with and it's already integrated into a working project, so I probably need to get another one where I can write a much simpler sketch to test with and avoid disturbing my actual workload.

[paulvha]

pfffff.. different try. in the previous version, I did a reset to _Enable_BLEread_Callback = false AFTER the callback. This might be undoing the writeValue() setting to true. Now changed that to do an _Enable_BLEread_Callback = false; JUST before the call back..
BLELocalCharacteristic.zip

[kk7ds]

This version restored the short string characteristic so it reads every time again. The long one still only reads once and then the callback is never called again.

Are you reproducing this locally and are these changes working for you?

I really have to put this back into service, so I can't test any more until I get another device I can debug things with.

Thanks for your help, hopefully this can get resolved. My workaround to skip every other call at least lets my project continue, and now that I know it's related to the length of the string, I can also change my format to sneak in under the length limit, at least until a real fix is available.

[paulvha]

Too bad..sorry I can't make it to work as I can't check locally at this moment. I will try tomorrow at my (day) time. As you say we at least know the root cause which is normally 50% of the solution. In previous sketches/solutions, I broke down the data to send in blocks of max 20 bytes. In the first block of the new message, data[0] was a magicnumber (0xcf), the data[1] being the length. So the central/client would know to synchronize and how much data to expect.
To make sure I can repo your situation locally the long string is 26 bytes and the short one is 20 or less?