New magnetometer code is broken

[smartyw]

There are two types of magnetometer data available over Bluetooth from the magnetometer service. The
Magnetometer Data characteristic provides X/Y/Z "raw" values. The Magnetometer Bearing characteristic provides a compass bearing in degrees. Both use notifications to transmit values.

Using the code below and the attached hex file, I found the following issues, testing with nRF Connect:

1. On a V1.5 edition micro:bit, enabling notifications on Magnetometer Data works as expected but with Magnetometer Bearing no notifications are received.

2. On a pre-V1.5 micro:bit the code doesn't seem to even start. The "BDL - MAG" message does not appear and the device is not performing Bluetooth advertising.

microbit-Bitty-Data-Logger-Magnetometer.zip

Additional observation: Using the Bluetooth magnetometer service used to initiate the "Draw a Circle" calibration procedure. This no longer happens. Should it?

let sampling_frequency_ms = 0
let connected = 0
bluetooth.onBluetoothConnected(() => {
    connected = 1
    basic.showString("C")
})
bluetooth.onBluetoothDisconnected(() => {
    connected = 0
    basic.showString("D")
})
basic.showString("BDL - MAG")
bluetooth.startMagnetometerService()

[microbit-sam]

Hi Martin
I've tried your hex file on a 1.3b and a 1.5, both run for me and I can connect and interact with the services and receive heading notifications - but I needed to request a calibration first

The magnetometer service has changed and now requires a request to calibrate, this was changed so that the calibration routine doesn't run as soon as the micro:bit starts

To trigger the calibration you need to write 0x01 to the characteristic e95db358-251d-470a-a062-fa1922dfa9a8

[smartyw]

Correction. The device that doesn't start is a V1.03 micro:bit.

V1.3B devices start but the magnetometer bearing notifications still do not work.

V1.03 devices do not start at all with this code.

[smartyw]

p.s. thanks for the info on calibration. Didn't know that.

[microbit-sam]

Interesting, I've not got a v1.03 - I'll see if Joe has one somewhere

I don't think it's been documented yet, I'm currently working through microbit-docs to bring them up to date with the DAL
https://github.com/microbit-sam/microbit-docs

[smartyw]

OK, cool.

Don't forget that Magnetometer Bearing notifications no longer work on any device version.

[microbit-sam]

Bearing notifications are working on both my v1.3 and v1.5 using the hex file you sent, I had to calibrate first (by writing 0x01 to the calibration characteristic)

[smartyw]

OK, I see. So the calibration behaviour has been changed... no auto-calibration when you instantiate the magnetometer service like we used to have and no notifications until calibration has been performed.

Hmmmm.

[smartyw]

OK, that works for me as well at 1.5.

[martinwork]

I BLE flashed that hex onto an old (how do I tell which version?) micro:bit that was already paired and calibrated. The iOS micro:bit app's monitor was able to connect and show bearings and the XYZ readings OK. I was even able to trigger re-calibration while connected.

I then tried USB flashing it to test the automatic calibration. I think you can trigger the calibration by reading the compass heading in the hex's startup code as well as by sending the BLE request.

When I tried to pair again with iOS, I discovered the hex doesn't seem to have pairing mode to show the LED pattern. I know what pattern to use and I did the pairing anyway, which appeared to work. When I tried to connect with the monitor, it didn't trigger calibration and didn't seem to be returning any bearings but is returning the XYZ readings. After triggering the calibration via BLE, it's all working.

[smartyw]

There's a version number faintly etched into reverse of the board just to the right of the pin 0 hole.

[smartyw]

Are you able to test on a 1.03 device? And is this the version that went into schools in the original programme? There are a lot of them out there if that's the case.

[microbit-sam]

I think v1.03 is before the school rollout, and possibly had a different mag on it (someone else will have to confirm)

Is this a C++ build @smartyw, which version of the DAL were you using? Even if the mag was different it should still run..

[microbit-sam]

When I tried to pair again with iOS, I discovered the hex doesn't seem to have pairing mode to show the LED pattern. I know what pattern to use and I did the pairing anyway, which appeared to work.

Using this hex I could connect and interact with the micro:bit without bonding

[smartyw]

This was a MakeCode built hex file and I selected No Pairing in the project settings.

If 1.03 was the school roll out, I guess this needs solving somehow. Can you lay your hands on one, @microbit-sam ?

[microbit-sam]

I think v1.03 was a initial run before that never made it out of the foundation and associated people, with v1.3 being the school distribution - @jaustin?

[smartyw]

I have lots of them :-)

Worth understanding what's going on in there, I'd say.

[microbit-sam]

What happens if you try to use the mag without BLE?

When I spoke to Joe he seemed to think the mag has a different i2c address so the micro:bit won't be able to detect it, even if this is the case it should still run and throw an 051 error when you try to access the mag

This hex should attempt to read from the mag when button A is pressed, and acc when button B is pressed

050-051-test.hex.zip

[martinwork]

Off topic... In order to connect to a new micro:bit with the iOS app, I need to know the LED pattern so I can go through the pairing process, whether it needs secure pairing or not, in order for the app to know which micro:bit to talk to. So a hex without pairing mode is not helpful.

The one I tested with earlier is v1.3. I also have a v1.03 and a 1.3B.

When I USB flash Martin's hex onto the v1.03, the LEDs remain blank - looks like it's crashed.

With 050-051-test.hex, it doesn't crash. The acc readings are similar on both v1.3 and v1.03. The magnetometer value varies, when each is connected to the USB and placed in the same way: v1.03 = 216700; v1.3 = -64300; 1.3B = 45700.

By the way, 050-051-test.hex appears to have only device info and partial flashing services so cannot be paired with the iOS app.

Martin's hex is DAL version 2.1.1--g. Sam's is 2.1.1-HEAD-g51011d3.

[smartyw]

Ah, I see @martinwork ran the tests I just ran. Happily I can confirm I got the same result :-)

[martinwork]

The same results is a good thing! I could be confused (too many micro:bits!) but I pasted @smartyw's javascript into a fresh project, so it doesn't have the customised text settings, added BLE and switched to "no pairing". This version runs on my v1.03 micro:bit and has pairing mode.

[smartyw]

OK, so this is getting weirder and I'm beginning to wonder if we have a MakeCode problem?

@martinwork I just did what you did (although I didn't understand your comment about customised text settings). I pasted the JavaScript from earlier in this issue, added the Bluetooth extension, switched off pairing, built a hex file, installed it on a 1.03 micro:bit and.... it worked. Started up. Scrolled some text. Bluetooth advertising.

I then imported the hex file I attached to the issue, examined the JavaScript and... as far as I can see it's identical to the JavaScript I just used to create a working hex file, does include the Bluetooth extension and does have pairing switched off. And that hex file... does not work.

[martinwork]

In MakeCode cog/Project settings/Edit settings as text. The problem hex has customised text here. I think the killer difference is "pairing_mode" : 0, but I don't know why...

[martinwork]

Maybe not "customised"... I seem to remember pairing mode getting removed briefly at some point for "no pairing" mode (terminology is a nightmare) and then put back.

[smartyw]

@martinwork Impressive! I don't recall ever (as in ever) using the Edit settings as text feature in my life. But I just imported the problem hex file and looked at this and it's totally different to the settings text in the working project:

{
    "name": "Bitty Data Logger Magnetometer",
    "dependencies": {
        "core": "*",
        "bluetooth": "*"
    },
    "description": "",
    "files": [
        "main.blocks",
        "main.ts",
        "README.md"
    ],
    "yotta": {
        "config": {
            "microbit-dal": {
                "bluetooth": {
                    "open": 1,
                    "pairing_mode": 0,
                    "whitelist": 0
                }
            }
        }
    },
    "targetVersions": {
        "branch": "v1.2.13",
        "tag": "v1.2.13",
        "commits": "https://github.com/Microsoft/pxt-microbit/commits/5d5b348757b15c6d00f5b7f560fd69592ca29424",
        "target": "1.2.13",
        "pxt": "4.4.7"
    }
}

No way did I type all that in! So what happened? Was I unlucky and bumped into a MakeCode release that was never meant to be and got regressed?

[martinwork]

I wish I knew what's going on! Do you have a version of the hex compiled before the update to DAL 2.1.1?

Looking at the DAL and microbit repos' use of MICROBIT_BLE_PAIRING_MODE, the only potential problem I can see is that no pairing mode removes a small delay in the code that tests for the pairing mode triggers. Could this be making something clash?

In fact, I think pairing mode is now required in MakeCode in order to support partial flashing, but I expect a C++ program will have the same problem with disabling pairing mode.

[smartyw]

No, sorry.

Wish I knew how all those settings got there. Wondering if I opened an old project, deleted much of the code and then saved with a new name. I don't know anything about the Settings as Text content or how it's changed over time.

If those settings came from an old MakeCode project (complete conjecture) then I guess MakeCode has a problem and should perhaps be updating those settings when a project is opened, if any of them are now redundant. But as I said... complete conjecture.

[jaustin]

@smartyw have you tried this on more than one v1.03 device? I've tested it (the hex file included with your original post) on a v1.03 here and it works (I've connected, got the 'C' and can read values over BLE.

I'm wondering if you've got a damaged device if it's only a single v1.03?

On a different note, we need to work out a process so things like the behaviour change aren't a surprise - the change was made as part of the driver refactor for multiple magnetometers that we did in a hurry to support the quick revision. @finneyj and @microbit-sam may recall the reason for the behaviour change... I think in the ideal world we should aim to have PRs to discuss for this sort of change, and in this case it seems it got merged with something much bigger...

[smartyw]

That's interesting. @martinwork reported getting the same results as I do.

I'll try again on a different device when I get a moment.

Yes, some way of communicating UX changing behaviours would be good as well as updating relevant documentation.

Adios

[martinwork]

Tried it again on my v1.03 with the same results (blank LEDs, apparently hung or crashed) though a newly built matching sample without the customised settings text does work.

The original microbit-Bitty-Data-Logger-Magnetometer works after updating the DAPLink Firmware to 0250 (from 0234).

[ukBaz]

Tried the following hex file with a v1.3 micro:bit
https://lancaster-university.github.io/microbit-docs/resources/BLE_All_Services_DAL_2-1-1-No-DFU.hex.zip
I get a blank screen (no C) when I connect.

With the magnetometer behaviour change, is there a way that I can tell if I need to issue a calibration on e95db358-251d-470a-a062-fa1922dfa9a8?
Other than subscribe to magnetometer data and if it doesn't serve any then issue a calibration.

[microbit-sam]

I think I'll need to rebuild the hex files to include the C and D, not sure how I missed that!

Docs have been updated with calibration info:
https://lancaster-university.github.io/microbit-docs/resources/bluetooth/bluetooth_profile.html