Display logged data from micro:bit

[Jaqster]

Feature request to add the ability to view logged data from the micro:bit in MakeCode.

Right now, customers need to open their File Explorer, navigate to the MICROBIT USB drive and double click on the MY_DATA.HTM file to read the data off the micro:bit (https://support.microbit.org/support/solutions/articles/19000127398-my-data-htm).

We believe that by adding MakeCode functionality to access the data file from the micro:bit will improve discoverability and usability of collecting data with the micro:bit.

Note that there is a CODAL dependency for this work.

[martinwork]

Related PR: https://github.com/lancaster-university/codal-microbit-v2/pull/177

[jaustin]

There is also the work that @danielstl has done with filesystems and data log web USB access that should be relevant. @finneyj @JohnVidler could you please point us to that work?

The key CODAL dependency, I think, is establishing one common channel over USB for this.

@martinwork I think if there's going to be a mechanism in MakeCode to read back the file, the ideal interface in the app would be for this to work over Bluetooth too, so there doesn't need to be a separate Ux for desktop vs app, one connects with BLE and one with USB. Does that sound realistic?

[martinwork]

The service https://github.com/lancaster-university/codal-microbit-v2/pull/178, is aimed at doing the same as a double-click on MY_DATA as fast as possible. If the micro:bit were to send data via bluetooth uart or HF2 service calls, the iOS micro:bit app can already pick that up and convert it to serial messages in MakeCode. Connecting to Bluetooth is by long press on the back chevron.

[jaustin]

so @martinwork if we could trigger that 'connect' from inside the MakeCode UI (say, the data view page) could we then modify the app to also take the UtilityService data and push it into the app for MakeCode?

[martinwork]

@jaustin Yes, I guess it could generate serial messages from the data. I can't remember right now if the MakeCode serial message could take it in one go.

[jaustin]

@martinwork in conversation with the MakeCode team last week we think it's better for there to be a new message type a bit like serial that is scoped to the data logger data. Microsoft are going to look at taking the same UI used to trigger a connection over web USB to also trigger a BLE connection by messaging the webview host, and then you can poke data back in via similar messaging to the serial stuff. This will just be for getting the actual logged data, to build a presentation very similar to the simulated data log.

There will not be a way to extract the entire MY_DATA.HTM from MakeCode in this release, so it will be necessary to make that file available via Monitor and Control or another UI in the app.

This may mean MicroBitUtilityService should support incremental updates to the log via BLE notifications, if it doesn't already.

[martinwork]

@jaustin How will the app know whether to start sending datalogging data and/or UART data? The same applies to WebUSB serial, I suppose. When the user switches away from MakeCode or backgrounds the app, the app automatically disconnects Bluetooth. If the MakeCode UI changes according to whether BLE is connected, that might need to be synchronised.

We have implemented a page in the alpha micro:bit app that looks very similar to MYDATA in a browser, but we haven't finalised how that page gets launched.

The service currently implements reading the data length, and reading a block of data from anywhere in the file, though it's intended to support adding other requests. https://github.com/lancaster-university/codal-microbit-v2/blob/1982f2492abc730f669627d38eba9355f31c0376/inc/bluetooth/MicroBitUtilityTypes.h#L30

So, for example, we should be able to poll the length, and transfer new data, if we remember where we were up to. Will MakeCode send messages to control what data is requested and transferred?

[abchatra]

Blocked on codal changes

[finneyj]

Thanks @abchatra. I'll take control of this one so we can get it done in time for this year's MakeCode release. I think there are still a few design questions we need to resolve here. Would be great to have MakeCode perspectives if you any of your team can spare the cycles.

Implementation discussion issue on codal-microbit-v2: https://github.com/lancaster-university/codal-microbit-v2/issues/271

[abchatra]

Thanks @finneyj. Lets discuss tomorrow, happy to brainstorm. @jwunderl -fyi

[bsiever]

I've been doing BLE work built off of @martinwork's readData too. It's useful to also provide requests for: a) current micro:bit time (to associate entries to wall-clock time) and b) the percentage of log that's used (can be shown in the UI).

That being said, wall-clock time calculation is sensitive to reboots. I inject a timestamp of 0 in the log when the micro:bit starts (only if the log already has data). This allows calculation of wall-clock timestamps back until the last restart.

Here's an example of what I've got working:

• Demo that logs accel x, accel y and temperature every 1s: https://makecode.microbit.org/_f6mWTWebEFCU
  • The extension repo: https://github.com/bsiever/microbit-pxt-blelog
• A webpage that will retrieves the logs, save them to .csv files, and shows some other info: https://bsiever.github.io/microbit-webblelog/
  • It provides two types of CSV: raw (the one you'd get from the file-based approach) and an augmented one that includes wall-clock time, a column indicating when reboots happened, and the micro:bit's name.
  • That page / repo is mainly to test out a library to retrieve the data. A team of students is prototyping a simple UI for graphing that uses the library. Hopefully future work will continue to expand the UI.
  • Repo for the JavaScript library: https://github.com/bsiever/microbit-webblelog

These are low priority hobby things to me. I didn't have much time and both are kind of hacky. I'd appreciate a warning if all my current work will be redundant with other efforts (I'd focus time elsewhere). Otherwise, I'd like to do a decent mobile app this summer.

[finneyj]

@abchatra @jwunderl

Please see updates here: https://github.com/lancaster-university/codal-microbit-v2/issues/271

Hopefully this should unblock you guys until I get back off holiday! Let me know how you get on...

[finneyj]

@bsiever - That's a nice idea. We can look to integrate other APIs lack that once we've had chance to test through if the principle works out ok!

[abchatra]

We have decided to put on hold this release and think about few alternatives and user testing before proceeding.

Main concern is the user flow into the editor and new project will lead the existing data file to be erased if they click on download which is the primary button.

[bsiever]

@abchatra Can you/someone explain the sequence of actions that would cause data to be deleted? (Would it only happen with a new project that uses the datalogger blocks?)

[jwunderl]

Any program being flashed (except, possibly, the exact same hex file -- have to double check) will result in the log being cleared. When a webusb connection exists this is only one click away (one a very prominent button) at any time.

[finneyj]

Hmm... yes. There is indeed a policy in place to do precisely that - to ensure any historic logged data is fully erased when one child has finished using a micro:bit (for both data privacy and usability reasons).

Definitely sounds like it could benefit from discussion!

Pretty sure a reflash even with the same HEX file will initiate a reset @abchatra, unless explicitly prevented on the MakeCode side by verifying hashes etc.

[bsiever]

Why not just have Editors/MakeCode check the size of the log at connection and warn users before erasing any logged data? When developing code for a data logging application it could be a little annoying to be asked about it every time one updates code, but an "ignore this" that is limited for a certain time (1 hour) or session (until the project/tab is closed) might be a reasonable experience. And in non-logging applications it really won't be a distraction.

It's already easy to erase the data via reprogramming (assuming the micro:bit is paired). Is the concern just about the change in user expectations if they are intentionally using MakeCode to view the log?

[jaustin]

A further reason not to have the data view as part of the coding interface is that once you've been out into the world collecting data, there's a high likelihood you wont have the same program open in the editor

So, not only might you accidentally overwrite your data, but you also might get quite confused by stale code in the editor. If we're encouraging people not to update the code on the micro:bit, then we'll be showing 'logged data' alongside code that didn't create that data, which I think is also confusing.

So, finding a place to put the reading of the data that isn't in the code would be good.

I still think finding a good way to tell the users where the my_data.htm file is when they start using data logging would be nearly as valuable.

[bsiever]

All editors that display serial data (including MakeCode) already have that sort of synchronization concern (that is, the ambiguity of whether the current code generated the contents of the serial console).

With serial (and probably with logging) the integration in the editor can be helpful for debugging and to have a single place to go for development and interaction with data.

Maybe use some sort of hash or timestamp to confirm the code on the micro:bit is synchronized with the editor? Both the editor's button to access the data view data and editor's data display could change to indicate that data was not from the current version of code (i.e., "Serial Console (Device)" button changes color and has a warning icon; show a banner over live data panes in the serial console warning about the issue). The same approach could be used with both serial data and data logger data.