2017년 3월 23일 목요일

Using the BLE Extension I want to access both characteristics of a Service


I am using AI2 with BLE extension to access BLE services on a BBC micro:bit.

The Button Service has 2 characteristics - Button A and Button B. Both return 0 = not pressed, 1 = short press, 2 = continuous or long press.

It's straightforward to create an App to read EITHER Button A OR Button B, but I can't see a way of being able to read the state of both buttons.

Can anyone help, please?

--
It seems to me that this is not possible. If you want both values returned together, then there must be a characteristic that provides this. This should be a string, I think. Can you create your own custom characteristic for the micro:bit? Otherwise you can maybe cannibalize one of the existing ones. In any case you must program something at the micro:bit side, AI can just try to make sense of what you send it.

--
I agree - It's not possible at the moment - I think it should be. There ought to be a way of linking a read command to a corresponding when changed or when read event, perhaps by allowing the embedded byte, or int, or string variable to be changed by the programmer?

Not feasible to to do anything on the micro:bit side.

-- 
This is a kind of philosophical problem. A characteristic is what programmers think of as an attribute. So reading a characteristic is the same as getting an attribute of some software object.
The problem comes from the notification of changes. And this would apply to any BLE device with several services and serveral characteristics for each, not just the micr:bit.
For the micro:bit, If you ask for the Accelerometer, magnetometer, button A, button B, IO-pins... How could any client, not just App Inventor, know what is being sent to it?
That said, at least for the buttons it would have been better if there was only one characteristic, which in its value would say which button is meant, not unlike the IO-pins, for which there is only one characteristic and for which io-pin-number, value pairs are sent.
-- 
I understand the point you are making, but there must be something extra at play which the BLE extension is not taking into account.

Martin Woolley has written two publicly available Apps to look at micro:bit BLE services:

microbit Blue, which allows each service to be looked at individually (if loaded in the micro:bit program, of course) With the button service it monitors BOTH buttons - ie two characteristics of one service - simultaneously, just like I am trying to do in AppInventor.

Bitty Datalogger monitors and records up to 3 Service/Characteristic pairs - temperature, accelerometer and magnetometer in NOTIFY mode. When the Appreceives data, how does it know which Service/Characteristic pair has sent it? Li9ke I said - there must be something else going on which BLE extension is missing.

I assume that Nordic's nRF Connect can do something similar, but I haven't tried it - I will, tomorrow - and report back.

-- 
This is important to find out! Is the source code also available?

--
I doubt if the source code for Martin Woolley's apps will be available.

However, as promised, I have checked the BBC micro:bit services  with nRF Connect, which has NO in-built knowledge of the BLE profile.

Here are my observations:

1.nRF connect sorts out which Characteristics belong to which Services - something I asked about in another thread - AI can't do this!
2. nRF can enably Notify on BOTH A and B Characteristics of the Button Service and report changes to both Button states correctly
3. nRF can enable Notify on Value Charactersitics of both Temperature Service and Accelerometer Service and report the values at the relevant Notify periods - 1000mS for temperature and 640mS for Accelerometer - I set these period values previously to simplify inspection of the nRF Connect Log File.

I think this demonstrates conclusively that AppInventor BLE extension is not doing everything it can and not fully utilising the capabilities of the Android BLE API.

I am attaching an extract from the nRF Connect log file


-- 
Thanks for this effort! I totally agree with you that work needs to be done on the BLE extension. I know the devolopers know, but I will try to add these specific points to their list.

-- 
FYI with some extremely tortuous AppInventor coding I have succeeded in correctly reading the Accelerometer data from the BBC micro:bit.
It requires 6 separate INT reads with offsets 0 to 5, little endian conversion and 2s complement arithmetic!!!
The 6 reads are a nightmare to program. However, at the moment the results are only meaningful the first time you access after starting the AI companion and it's so desperately slow as to be of little practical value!!

-- 
Neil, I heard that a new version including better support for this kind of thing will be available in about 2 months, with hopefully a beta version before that, so instead of torturing yourself, I hope you can have some patience. In any case you will have been instrumental in getting some of the improvements right.
--
There is a  great deal of satisfaction gained from solving each problem - whether caused by my own lack of knowledge, or the limitations of the AppInventor BLE extension.

Since I started my work on the BBC micro:bit, the limitations of the BLE extension  have forced me to explore coding techniques in AppInventor which I have never used before, and for that I am very grateful.

I will continue to explore!!!!!!!

It's not torture but a growth process!

I look forward to a new version and sincerely hope I can gain access to a Beta version.

-- 
I've added your name to the list of potential beta testers. I think we've addressed a lot of the challenges you been facing. We'll be reaching out once we're ready to start testing externally.

-- 
Thanks very much! Looking forward to starting!

Best wishes

-- 

댓글 없음:

댓글 쓰기