I have a sketch on a 101 with one (custom) service and 5 characteristics. Of these, one is a write characteristic, 2 are notify and 2 are read. The sketch controls a laser obstacle detection system.
I am interacting with this from a Raspberry Pi running a C++ program which uses the tinyb library. This in turn uses TCP to talk to a GUI app written in Xojo.
The write and notify characteristics work perfectly, but both the read ones cause problems, either time-outs or "in progress" errors on the dbus in the Raspberry Pi (which would normally mean another interaction was on-going, but it's not the case).
Since I can use an equivalent C++ program to read values from a TI SensorTag with no problem I assume that the root cause of the problem is in the Arduino code.
Here are relevant snippets for one of the characteristics:
A bit more information: when I use an iPhone app such as LightBlue or nRF Connnect, I can see all 5 characteristics. I can write to the writable one, but I cannot read the readable ones.
If I load other CurieBLE examples, like BatteryMonitor or ButtonLED, then I can read the characteristics.
My code is based on ButtonLED and uses precisely the same function calls in setup and loop, except for there being 5 characteristics and much more other code in addition.
I'm making some progress on this, but it's non-obvious what's happening.
I have another sketch now, based on the IMU Accelerometer sketch, which I modified to give roll and pitch values over BLE. I'm using these on several different Arduino 101's by the way, and I can switch between them -- the problems follow the sketch.
This new sketch works nicely and as expected, with a firmware version readable characteristic initialised in setup() (just like the other sketch), a notify value for the readings and a writable value for the update interval. All work fine.
I have simplified the misbehaving sketch enormously in a test version so that functionally it is just the same as this working sketch, but still no luck.
On a whim, I decided to include the one missing part -- the call to CurieIMU.begin() (with the library inclusion obviously).
Now it starts to work!!!
This is weird -- there is no usage of the IMU functions in this sketch, but this seems to do the trick.
But it's not consistent -- some times it doesn't work again. But about 50% of attempts do.
I've been working on this issue for weeks now, but today made a breakthrough, with a reproducible cause.
It's analogRead() which is to blame. I tried all 6 pins and the result is the same. If I make a call to analogRead(), then reading characteristics doesn't work.
In the same code, commenting out the call to analogRead() makes the problem goes away.
crfrancis:
it seemed quite reasonable to re-post the issue with more information and a more relevant title.
Wrong. You can edit your title, you can bump your post, but don't cross post.
crfrancis:
After almost a month with no flicker of response
Well it doesn't help your cause when people need to go to a separate website, download a .zip file, then look through 300 lines of unnecessarily complex code just to try to help you. That's why I said:
Post the minimum complete sketch that demonstrates the problem.
I posted my shortened code on github in response to a remark by facchinm:
facchinm: @drmpf,
have you already opened an issue on the 101 github? We are collecting a series of "difficult" sketches to improve our regression test suite, if you could post a sketch exposing the problem it would be a great help! Thanks
Since this has all the appearances of being a bug, I thought it would be helpful. Particularly since I identified the one line in the code which, if removed, eliminated the problem.
You'll notice that not only did you get no response here on the forum other than my chastising, you also have not received any response or action on your issue report.
If it takes a minimum of ~300 lines of code to demonstrate a bug then the bug is most likely with the code. If you know the line of code that causes the problem then surely you can produce a more minimal sketch that will reproduce the problem. This is an extremely valuable technique for troubleshooting, asking for support, and producing tests. I do this whenever I run into a bug I'm having difficulty solving or finding the cause for and almost always by the time I have shrunk it down to the absolute minimum I've either found the error I made or I understand the issue much better and am able to submit a very specific bug report that allows the developers to get right to work fixing the bug rather than wasting a lot of time doing the "grunt work" that I'm just as qualified for. That means the bug gets fixed faster and the developers have more time to fix all the other bugs.
What you don't get is that I'm not just being uptight here, I'm trying to help you. Doing this is in your best interest as well as everyone else's.
pert:
What you don't get is that I'm not just being uptight here, I'm trying to help you.
Since you say so I will accept this. You must admit, however, that your earlier posts give quite the opposite impression.
pert:
… This is an extremely valuable technique for troubleshooting, asking for support, and producing tests. I do this whenever I run into a bug …
Thanks for the tutorial, though I have to point out that since I've been writing software since 1971, as well as managing industrial software development contracts (many being mission-critical, such as satellite on-board software) I do actually know this. The version I posted is about 300 lines long, compared to the 750 lines of the full version. It's true that it can be further reduced, which I will now do.
As always, thanks for positive contributions,
Richard
Commenting out line 35 enables or disables the bug (read characteristic not being readable). It can be seen using LightBlue on iPhone.
Just like I posted before.
pert:
You'll notice that not only did you get no response here on the forum other than my chastising, you also have not received any response or action on your issue report.
If your logic expressed here is correct, may I now expect some non-polemic contribution?
I have prepared a code of 37 lines which demonstrates a bug in the Arduino 101, such that using analog read prevents read characteristics from working. Apparently the code has been downloaded 21 times, yet nobody has any further comment.
Worse, there seems to be no indication that a solution may be on the horizon.
This bug disables quite a lot of applications, so I would have imagined it would be of some interest.
Can anybody give me some hope that it may be fixed one day?