BLE ....value_changed and ....value_read blocks

[Neil Kenyon]

When the  BLE service only has the option to READ - eg Device Information (Model Number, Serial Number, Firmware Revision), I can access the data using the ....._value_read block. It works for both BYTE and STRING

However, when the BLE service supports both READ and NOTIFY  - eg Temperature, Accelerometer, etc, I can only access the data using the ......_value_changed block, which I believe uses the NOTIFY property.

I want to use the READ property, so that I can access the data on demand, rather than having it constantly updated.

Do I need to send a command to the micro:bit in order to enable READ and/or disable NOTIFY and if so, what?

Any help will be much appreciated.

Neil

[Ghica]

What you can do, is to ignore the values send to you and make them available only when a user presses a button or similar.

What have you running on your micro:bit?
I spent quite some time trying to communicate with it, I can connect just fine, but trying to run an example using Microsoft PXT, it does not seem to work.
Cheers, Ghica.

[Neil Kenyon]

I've tried your suggestion - it doesn't help, but thanks

PXT was deficient in exposing the micro:bit Bluetooth services until about 2 weeks ago, but it's fixed now - I was using the Beta version for a week or so.

So here is my extremely simple micro:bit program:

With this program flashed to the micro:bit I can connect with AppInventor + BLE extension

Using the appropriate UUIDs I can read from the Device Information Service, using the String_value_read blockand get:

• Model Number:           BBC micro:bit
• Serial Number:            2097031393
• Firmware Revisison:   2.0.0-rc4

I can access the temperature service and get the temperature readings at whatever period is set, using  Integer_value_changed block

I can't change the period from within AppInventor, but I can from within nRF Connect app

Similarly, I can't change the Notify status from withing Appinventor, but I can from within nRF connect.

(I sorted the Client Charcteristic Configuration UUID from looking at the nRF Logfile:

00002902-0000-1000-8000-00805F9B34B but it doesn't do anything when I try to disable the Notify status from AppInventor)

If I disable the Notify in nRF Connect then I don't get anything in Integer_value_changed block, as you would expect

BUT neither do I get anything in the Integer_value_read block and this is really what I want to do.

It's clear that you can change the Notify status and the Notify period from the nRF Connect App and these changes can be seen when you connect with AppInventor. But I don't seem to be able to change them from AppInventor, nor to get the ....._value_read blocks to work, except where the service ONLY has a Read characteristic ie Device Information Service.

I hope this is clear!!!!!!

Thanks

Neil

[Neil Kenyon]

Correction:

The Client Charcteristic Configuration UUID was wrong - it should be: 00002902-0000-1000-8000-00805F9B34FB

Now, when I try to read the Notify status in AppInventor I get an GATT error message telling me can't read from a NULL descriptor

However, when I write 0 to the CCC from AppInventor then go into nRF Connect and read it back, I get 0 so it appears that I am changing the Notify status from App Inventor, even though I can't read it ??

Neil

[Ghica]

Neil,
Thanks a lot! I am going to try later tonight.
About the read and changed events: you do a read only once and get the read event only once also. After that you are supposed to see only changed events. My idea was that you would ignore the changed events unless you needed a value.
Keep in mind that the BLE extension is still very experimental. There is work going on to improve it, and supposedly make it into a component, but when exactly I do not know. If you find something that is clearly wrong BLE wise, then it would help as feedback to the development team.
Cheers, Ghica.

[Neil Kenyon]

Ghica

I've tried all sorts of combinations and it only seems possible to get a result from the changed event; not from the read event.

The following blocks don't produce a result:

I included the check on the value of intValue in the hope of getting an indication of whether or not intValueRead event has been triggered. It doesn't do anything and the text set up in the label doesn't get overwritten. either way it doesn't work for me

If I add in a block for intValuechanged event then of course I get the temperature, but if I warm it up, I see the temperature changing every second (default Notify period).

I can't see how to stop the intValuechanged continually updating the display.

All I want to do is get a single reading each time I press the button.

I haven't yet tried it, but I suspect this will be the same with all the micro:bit Bluetooth services that include both Notify and Read characteristics.

I don't know if this is a micro:bit problem or an AppInventor problem. The fact that you can make it ALL work in nRF Connect demonstrates that it works and suggests that it's maybe an AppInventor issue.

I'm glad you've had a go at the micro:bit & hope that together we can resolve this.

Neil

[Neil Kenyon]

Follow Up:

This does what I want:

But this seems unnecessarily convoluted. The simple int_Value_Read event doesn't work at all and isn't necessary in this context

Does this mean that the ...Value_Read event only works when the service characteristic is only READ and not when it's READ/NOTIFY?

Is this what the developers intended?

Neil

[Ghica]

Hi Neil,
I succeeded in making the same app. My AI blocks are slightly simpler than yours. Actually, I wonder whether you would in this case like to read the temperature only when you press a button. In practice you would like to see the temperature updated on the screen automatically. Which it does nicely if you just display the when changed value as it happens.

I have a problem with the micro:bit too. I thought it is good practice to add descriptive values to the services and characteristics. Now you get for all services/characteristics Unknown Service / Characteristic. Or is the microbit too small to hold these?

I will ask developers tomorrow about the missing features in the BLE extension. If you can, would it be possible to make a kind of summary of what you found?
Cheers, Ghica.

[Ghica]

Some more experiments.
I rewrote the AI app, to see if it would be possible to read or write the temperature update period. It seems that I am not able to read or write the update period.
* But what should the period be, for the temperature service to stop notifying?
I made a log of the temperature values read, so you can see in real time what is happening.

I was also considering other services into the app, but it was totally unclear to me how you can distinguish one changed value event from another for another characteristic.
So, my list of questions:

1. How can characteristics be read or written that do not support notification, e.g. the temperature period characteristic of the temperature service.
2. How can read or changed events be related back to a characteristic?
3. What are the offset values to be used, for example sint8 (signed 8 bit int) works gine with offset 0, but uint16, used by the period is unclear to me.
4. Nuisance: the micro:bit profile specification: https://lancaster-university.github.io/microbit-docs/resources/bluetooth/bluetooth_profile.html uses UUID's without dashes, but they need to be added to become valid.

For interested readers, I added the hex file for the micro:bit. You can make your own here: https://pxt.microbit.org/?lang=en
Cheers, Ghica.

[Neil Kenyon]

Ghica

Thanks for all your input. neat solution to my read on demand, but still convoluted; shouldn't have to resort to that approach

I share your frustration with the absence of dashes in the UUIDs in the profile spec

I use nRF Connect as my reference for what can be done, so

1. You can see all the services currently running on the micro:bit - not all are identified by name, but only by UUID, because they are custom, private to the micro:bit and not registered.
2. You can access the Device Information Service & read Model Number, Serial Number and Firmware revision
3. You can access whichever other services you have loaded - using temperature as an example
4. You can read and set the period  - needs to be in little endian, so, for example, 5,000 mS is 88-13
5. You can read and set the Notify Status
6. You can read the data - if you look at the log, if Notify is enabled you get continuous updating at the relevant period, if Notify id disabled you get a reading each time you initiate a read command in nRF.
7. All this suggests to me that if you connect to the micro:bit with a fully functional App (as nRF is!) you can make the micro:bit do what you want.
8. At the moment, using AppInventor you CANNOT create an App which will let you do everything that the micro:bit is capable of doing

The absence of any documentation (that I could find) for the AI BLE extensions has meant I had to make some (I thought reasonable and logical) assumptions about the way things worked. These assumptions proved to be wrong.

1. Initiating a BLUE read from a particular service should do just that - read the current value available from that service on the connected device.
2. That value should then be available from a Gold value_read event for processing
3. If the service has Notify enabled, an updated value should only be available if you Initiate another BLUE read.
4. Given the above, I'm not sure what purpose the Gold value_changed event actually serves!

So, what currently works with AppInventor BLE as currentl implemented?

1. Device Information Service works - it only has Read, not Notify and cannot be written to.
   
2. BUT, reflecting on what you mentioned "How can read or changed events be related back to a characteristic?" , if you want to read all 3 characteristics in 1 App, you have to resort to some messy coding, to keep track of which value belongs to which service:
   

1. The values of services such as Temperature, Acelerometer and, I assume Magnetometer can only be read by the methods discussed earlier - ie using value_changed event
2. Other aspects of these services - period and Notify status cannot be read at all from AI; indeed I got an error message saying the UUID was invalid, when trying to read the Notify Status;
3. I'm sure I managed to change the Temperature period from Appinventor
4. I'm also sure I turned the Notify OFF from AppInventor, but don't think I managed to turn it back on.
5. I can't check these last 2 because my micro:bit (last of 3!) is on the point of death - I have a new one on the way.

Can you discuss my observations with the developers & see what the implications are

Neil

[Ghica]

Hi Neil,
I already sent a message to our power users  forum (I cannot directly discuss, I am just a volunteer in the Netherlands, far away from MIT, but usually subjects brought up there are considered very seriously). I will add a comment there concerning your observations. I know there is considerable work going on, I know MIT knows that there are deficiencies in the BLE extension, I have asked before when we would see something, and the answer was: later.

In defence of the value changed event I should say that the notification period suggests that the micro:bit device should send something at every time the period is elapsed. That is what you see in the value changed event, that is what you see happening if you run my app, and I think that is correct.
Cheers, Ghica.

[Neil Kenyon]

Ghica

I've been pondering a little more and just came online to send you a further thought and found your response!

I apologise!! I was too hasty in trashing the value_changed event! It has a valuable role if you want continuous update, which is what you get from the current Blue read....Value block.

I already use it to read the Button Service - I get instantaneous change when I press the button, but have to resort to extra code to handle both buttons - 2 different UUIDs within the same service.

Actually what we really need are 2 different read...Value blocks:

1. The existing version, perhaps renamed read....ValueContinuous
2. A new one, perhaps called read....ValueOnce, which does what it says - reads the current value of the UUID and then stops.

We also need some way of independently defining the variable which initially captures the value of the read....Value call. This will allow simple management of reads from multiple UUID's in the same service eg the Device Information Service, or even reads from different services, all in the same App

regards

Neil

[Ghica]

I have made some more comments to the developers. We will see.
I would like to add though, that despite the current shortcomings of the App Inventor BLE extension, it is possible to make some cute apps that show the potential of the micro:bit together with App Inventor.
Cheers, ghica.

[Neil Kenyon]

I agree

Even with the current limitations, there's a lot you can do with AppInventor and the micro:bit

Neil