Does bluetooth need to know if the board is a V2.0 or V2.2?

[microbit-carlos]

Board ID for BLE added in PR #114

Actually at this point in time CODAL it's not recognising V2.2 on BLE init, only V2.0:

codal-microbit-v2/source/bluetooth/MicroBitBLEManager.cpp

Lines 440 to 450 in b587d9c

	int versionIdx = 0;
	switch ( board)
	{
	case 0x9903:
	case 0x9904: break;
	default: versionIdx = 1; break;
	}
	ManagedString modelVersion( MICROBIT_BLE_VERSION[versionIdx]);
	ManagedString disName( MICROBIT_BLE_MODEL);
	disName = disName + " V" + modelVersion;

I don't know exactly how this string is used, but it's all processed in the MicroBitBLEManager::init() method. Is it necessary for this BLE string to distinguish between V2.0 and V2.2? Should we just hardcode a V2 string?

Without knowing much about how the BLE stuff is set up, is this information provided as a specific "info" service with a characteristic that provides board info (in which case it might be useful to provide more detailed information)?
Or is it part of a string that is broadcasted in some other way? (in which case it's less important, we might care to connecto a "BBC micro:bit V2" device, doesn't need to say "BBC micro:bit V2.0")

Does this string need to be set up in MicroBitBLEManager::init()? Or is there a different function that could provide this values? (for example, if it's a characteristic that is read, the DAPLink I2C version check can be done on demand)

The reason this is worth considering is that it might be beneficial to avoid having this DAPLink I2C transaction on uBit object init:

codal-microbit-v2/model/MicroBit.cpp

Lines 219 to 221 in b587d9c

	#if CONFIG_ENABLED(DEVICE_BLE) && ( CONFIG_ENABLED(MICROBIT_BLE_PAIRING_MODE) || CONFIG_ENABLED(MICROBIT_BLE_ENABLED))
	MicroBitVersion version = power.getVersion();
	#endif

We are considering to panic when the DAPLink I2C comms fails in ticket #137, and for example, if the board is in MAINTENANCE mode and the programme running doesn't use BLE or datalogging, it's better to just run as normal instead of panicking.

[microbit-carlos]

Related to:

• Data logging programme hangs if DAPLink does not have micro:bit specific features #137

[martinwork]

@microbit-carlos The version is used only for a suffix on the model name in the device information service, for the benefit of clients of the BLE services. The question is whether BLE clients need to distinguish V2.0/V2.2, or V2/V3.

The model name currently differentiates V2.0 from newer versions. See the question about future versions in #77. The idea was also discussed in https://github.com/microbit-foundation/codal-microbit/issues/67 (private), and in lancaster-university/microbit-dal#373.

If power,GetVersion() returned something invalid, say zero, it would be V2.X. I don't know if this string is being used anywhere. The iOS micro:bit app guesses V1/V2 based on the different DFU services, which is what gave rise to the question about how a BLE app should distinguish V1 and V2. It hasn't been changed to use the model string.

[microbit-carlos]

Thanks Martin, that's really useful to know!

From the top of my head I can't think of a reason why a BLE client would need to differentiate between a V2.00 and a V2.2x. So that could be hardcoded to V2?
If there is a reason to tell the difference, I think there should also be a "Hardware Revision String" in the Device Information characteristics? CODAL could always retrieve the Board ID from DAPLink on demand when that characteristic is read?

[martinwork]

It could be hard coded by reverting #114. I can't remember why the model string was chosen. I don't know if you could do the I2C comms inside a BLE event handler.

[microbit-carlos]

We are happy for this to be hardcoded in CODAL to indicate V2 only.