Allow use of the datalogging feature when using BLE and a tablet

[jaustin]

At the moment, the log API is only useful to someone with a USB connection to their micro:bit. This means it doesn't work well for people on iOS or Android (or people using webUSB exclusively)

In order to resolve this, I think we should introduce

• a way for code on the micro:bit to read back the log data
• a BLE service for the log data that is built into pairing mode by default and optional by user choice when building with Bluetooth

So, to extract the data even if also using radio, the user can activate pairing mode and ‘copy off’ their data.

For consistency, I’d like to also copy the HTML header and load the HTML file so that the experience is the same across browsers/systems - this might affect the way we expose the data in the log, or it may be something that the file itself does. I suspect from a user PoV it makes most sense to have a way to get data (say, also useful for working with webUSB access to the data, or doing some data processing on the board), and a separate way to get the whole HTML file.

@finneyj and @martinwork this I hope roughly lines up with separate conversations I've now had with both of you! Note that @martinwork has already filed #156 which I think is a good precursor to this.

[martinwork]

Thanks @jaustin. I'll close #156 as this issue takes the subject to the next level!
As dataStart is really an implementation detail, my thought there had evolved to:

class MicroBitLog 
{ ...
    uint32_t getDataLength();
    int readData(uint32_t index, const void *data, int len);
}

[jaustin]

Questions:

• Should this always be present (perhaps in pairing mode?)
• What is the impact on flash consumption?
• Should we make it contingent on using data logging?
• How would people know it exists?
• How do we provide a consistent experience between the Bluetooth and non Bluetooth experience?

[martinwork]

@jaustin

Please see martinwork@e65ba17
I created this a few days ago and was updating the iOS app to test it, but had to move over to other things.

I've added functions to MicroBitLog and created a BLE service to use them. I've named the BLE service "Utility", thinking it could be extended for other purposes, to avoid the RAM consumption of multiple separate services.

My working copy of the iOS app is able to download the HTML file and display it in a webkit view to support sharing the CSV via the HTML buttons, but I'm thinking it might be better for the app to download the CSV and create the display locally, either using a local version of the HTML or natively. The HTML header is an overhead for the download.

Should this always be present (perhaps in pairing mode?)

For the BLE service, I have created separate config macros for inclusion in pairing & application mode (default yes & no).
The service could also be created by user code. I have assumed it would be a singleton, and created static getShared and createShared functions.

What is the impact on flash consumption?

I don't understand. Which flash?

Should we make it contingent on using data logging?

I expect the MicroBitLog additions would always be there, but the BLE service could be created as required.
Maybe the most friendly approach is: always in pairing mode, and created by the user code in application mode.

How would people know it exists?

A user program can check for the BLE service with getShared() and create it with createShared.
A BLE mobile app can discover services.

How do we provide a consistent experience between the Bluetooth and non Bluetooth experience?

Should MicroBitLog have a synchronous function to dump the entire CSV to serial?
Should the BLE service have a command to dump the CSV to the BLE UART?
Would output in MakeCode "write value" format be useful?

[Darshnik253]

I am making project smart in that i have combined bluetooth and usb serial communication code. But if i run both simultaneously then its not working(getting error 020 sad icon). so could you help in that?

[microbit-matt-hillsdon]

I am making project smart in that i have combined bluetooth and usb serial communication code. But if i run both simultaneously then its not working(getting error 020 sad icon). so could you help in that?

Hi @Darshnik253, please get in touch with support via https://support.microbit.org. See this support article for details on the 020 error.

[martinwork]

Hello @Darshnik253. Posting the same request in multiple places is not helpful. Please create a new issue for your problem and give more details, especially sample code that shows it going wrong, what micro:bit (V1 or V2), etc.. Please pick an appropriate repo for the programming environment you are using (makecode, python, C++). If C++ then DAL for micro:bit V1 or here for V2 or both.

[martinwork]

Created #177 with basic functions to allow access to the data, test program etc.

[martinwork]

Created #178 with BLE service to read data.

I don't know how to choose service and characteristic ID to add to the micro:bit base UUID.

[microbit-carlos]

@JohnVidler would you be able to review these PRs for 0.2.38?

[martinwork]

#177 only exposes the data to other code in micro:bit. We need something like the BLE service in #178 as well.

[JohnVidler]

I'm going to move this to 0.2.42, which is increasingly looking to be the 'DAPLink and Blutooth update' :)

I'd rather spend the time getting this all correct and tested than rush it out right now for 0.2.41

[microbit-carlos]

Work being currently carried out in:

• MicroBitUtilityService - replaces PR 178 #287

[jaustin]

@JohnVidler I thought this had been merged but in latest MakeCode with the alpha iOS app I still can't access the UtlityService. @martinwork can't either.

Did we perhaps add the service but not configure it to build?

[microbit-carlos]

As far as I know the BLE service has not been added (#287) yet, only the data-logging updates (#177) to be able to read the data from the interfacechip:

• Add MicroBitLog::readData #177
• MicroBitUtilityService - replaces PR 178 #287

Do you need this to be re-prioritise to an earlier tag, like v0.2.57?

[microbit-carlos]

This has been shipped in the v0.2.56 tag, but still need to test this, so will keep this issue open until we know we are good to enable it by default as indicated in:

• MICROBIT_BLE_UTILITY_SERVICE_PAIRING defaults for MakeCode & MicroPython #354

[microbit-carlos]

No more changes are required in the CODAL source code, so I'll close this as resolved and then any changes to the defaults or MakeCode/MicroPython will be covered in:

• MICROBIT_BLE_UTILITY_SERVICE_PAIRING defaults for MakeCode & MicroPython #354