read_value() fails due to dbus InProgress error

[crfrancis]

I have a sketch running on an Arduino 101 which exposes one service (laserService) with 5 characteristics. One of these is write, 2 are notify and 2 are read characteristics.

The write and notify characteristics work exactly as I expect, but I have problems with both the read characteristics.

I'm using Raspian, and have updated Bluez to 5.46 (bluetoothd reports this, while bluetoothctl reports 5.45, which I installed earlier, if I remember well). For what it's worth, if I check the status of bluetooth I get bluetoothd failed, due to the name already in use in dbus.

I establish the characteristics with code like this: const std::string BT_UUID_LASER_FIRMWARE = UUID_CHARACTERISTIC_LASER_FIRMWARE; std::unique_ptr<BluetoothGattCharacteristic> laserFirmware = laserService->find(const_cast<std::string*>(&BT_UUID_LASER_FIRMWARE));

Later on in the code I have std::vector<unsigned char> response = laserFirmware->read_value();

Although this has worked once or twice, it usually results in a dbus error: GDBus.Error:org.bluez.Error.InProgress: In Progress

The hellotinyb example works fine with a SensorTag.

Any help or guidance would be welcome! cheers, Richard

[petreeftime]

Are you doing the reads in a loop? If so, do you have a wait between two reads?

[crfrancis]

No I'm not. The reads are in response to a user input (actually a button push in a GUI which communicates with the software in question by TCP). The GUI, which is also in development, lists the commands it sends so I know there is no multiple command sent.

cheers, Richard

[crfrancis]

I have some fresh data. My problems with read-value() have continued, and of course I have another potential culprit in the Arduino 101 code too. To address this I loaded one of the examples from Arduino and was able to read characteristics with an iOS app on my phone (LightBlue). So I concluded the issue was with my Arduino code.

I also could not read the values from my Arduino code from the iPhone app, which seemed to confirm this.

I then used gatttool on the Raspberry Pi to try to understand the issue and could see the characteristics, but not read them (as usual).

However, I have just now tried installing my "failing" code onto a fresh Arduino 101 and, without yet connecting any hardware, tried that one. Gatttool worked! I could read the characteristics. However, after connecting the hardware and running my program which uses read_value(), I again get a time-out. And now Gatttool times out too. I can't read the characteristics any more.

So, either my hardware is messing things up (which seems unlikely) or somehow read-value() is messing up the dbus such that the relevant channel is permanently blocked.

I'm going to try connecting my hardware to a third Arduino 101 now to try it with gatttool to investigate that possibility. In the interim I have tried the original Arduino 101 without hardware, and with the same code it already had, and still can't see read the characteristics with gatttool.

cheers, Richard

[crfrancis]

After much changing code and other investigations, I'm now at the point that the error is a timeout.

In the meantime, I've become convinced the problem is in my Arduino code, although quasi-identical code runs fine on another Arduino, with read-value() working as expected (and yes, I did switch the two Arduinos to verify it isn't an issue with one, which took quite a bit of cache-clearing).

What I'm now finding frustrating is that the timeouts cause a device disconnect, which is rather annoying as it it tends to cut investigations rather short.

Is there a way to avoid this disconnect on timeout?

thanks, Richard

[Makalov]

Did this ever get resolved?