Nordic UART service bug: should use notifications not indications #259

thanks @bluetooth-mdw - awesome analysis as ever!

Aligning with Nordic's service would be a good idea I think, and notifications make more sense in my mind anyway i think. Unless anyone out there can think of any compelling reasons to the contrary, I'd suggest we change it.

@martinwork - Any significant implications in changing this for your app?

Yep.

I remember talking to them about which point of view TX and RX is, and there was definitely some confusion there. Happy to let the dust settle.

OK - well we are using their UUIDs, so we should meet their spec. Let's flip the TX/RX 'lines' as of the next release. No sense prolonging incompatibilities...

thanks!

Thanks for the heads up. Our app will be unaffected. I am working with an offline copy of the DAL and only updating semi-manually.

In our app's firmware, I have already made the UART code use notifications, not for this reason, but thinking it would enable improved throughput and buffering.

At first, when I read the above, I thought the TX/RX UUIDs were right already, so had a look round to check. I found that MicroBitUARTService's UUIDs are reversed compared to Nordic and mbed usage, but maybe not according to the documentation! Somehow, without realising this was different from the DAL, I have matched them to mbed's definition (see below) in our firmware and app.

This is what I found:

Nordic's description under the heading "UART/Serial Port Emulation over BLE" isn't clear to me. It seems to be reversed compared to actual usage.

At the end of the mbed UARTService header, there is a good explanation, saying that tx/rx are from the point of view of the external client - ie desktop/tablet/phone. It writes to rxCharacteristic=6e400003 and reads txCharacteristic=6e400002.

The app NordicSemiconductor/Android-nRF-UART writes to RX_CHAR_UUID=6e400002 and reads from TX_CHAR_UUID=6e400003. These UUIDs correspond to mbed's but the TX/RX names are reversed.

The MicroBitUARTService uses mbed's UUID #defines but writes to txCharacteristic=6e400002 and reads rxCharacteristic=6e400003, so the usage is reversed.

While I am all for a BLE UART 'standard', the problem is there isn't one.

My app pfodApp (www.pfod.com.au) handles 7 different BLE Uart implemenations from various manufactures and this proposed change will not affect it as it already has that config for another 'nordic' style board, Adafruit SPI BLE boards. (The Arduino 101 'nordic' board is similar, but uses INDICATE)

However, the sheer volume of micro:bits in the wild seems, to me, to have defined already another standard.
If you change the micro:bit standard now, what happens to the existing micro:bits and those in the supply chain?
How do they get updated to the 'new' micro:bit UART standard?

I fear the result will be two micro:bit UART standards and a give rise to cases of that micro:bit app will not actually connect to that version of micro:bit.

Given the number of micro:bits already out there it would seem simpler to have Nordic change their (one) UART app to also accept the micro:bit UART standard.

Yes I already do that in pfodApp in addition to checking against 'known' Uart services.
However in pfodApp, I check every service UUID returned for a suitable set of characteristics that could be used for a UART and also then check the characteristics for Notify/Indicate settings.

Finally some manufacturers , just to be different, use just one characteristic UUID for both TX and Rx, so I have to allow for that 'standard' also.

What did Nordic say about registering their set of UART UUIDs as a BLE Standard?

Just to add that everyone really has agreed on the spec for Nordic UART, and it's the opposite of what micro:bit still does.

If you use the Adafruit Bluefruit devices/apps, Espruino, Nordic's app or cloud website, or Nordic's own libraries for Nordic UART central or peripheral they all use the flipped UUIDs and notifications.

I really think this should change - or at the very least you should change the UUIDs around to be something micro:bit specific so there is no confusion.

@gfwilliams @bluetooth-mdw

Thanks both for raising the profile of this issue again and providing the background.

If a de facto standard has emerged, it makes sense to align to it IMHO.

The challenge is of course supporting any micro:bit apps that are already out there through such a change to keep things as smooth as possible.

@martinwork @bluetooth-mdw Thoughts on what we can do to make an easy transition for you? As an ideal, I guess we'd like to ensure a "nothing breaks" model... and we will have old versions of apps and kids micro:bit programs out there to deal with.

Just a thought - but could you make both UUIDs writable, with notifications/indications on each? I think it may then work with both old and new apps.

@gfwilliams You mean like a virtual wireless auto-MDIX?!?

I think I want one!

I guess there are situations where the connecting apps don't transmit first though. We could define polarity based on an notification registration, but what to do if the app doesn't register for a notification and doesn't transmit? Default to the de facto standard I guess?

I could be wrong, but I don't think you have to figure out which way around to do it - you could just use both at the same time...

• When sending from the micro:bit, Indicate on 0x0002 and Notify on 0x0003
• When either characteristic is written to, treat that as data coming in to the micro:bit

Do you think that's likely to work @bluetooth-mdw?

I'm for keeping it simple too. I think dropping indications would mean it doesn't need to keep a live copy of the currently-called-txCharacteristic, releasing a little RAM.

All good points. It is important to note that we are just talking about a subset of the BLE functionality here,with the other services remain unchanged.

Still, if we're going cold turkey, we should at least align a updated release of the affected micro:bit apps we know about with this change.

@martinwork @bluetooth-mdw Do your apps make use of this BLE uart service?

Also tagging @jaustin in here, in case he's aware of other apps that we may want to reach out to. Is the Scratch team using this maybe? others?

One of my apps uses it (@bluetooth-mdw here in disguise!)

@finneyj No. Our apps are using a custom implementation.

Hi, is this issue still active?
I'd like to use Nordic UART in MakeCode.

So far, I forked microbit & microbit-dal and modify codes as PaulAustin demonstrated. It works fine with mbed. I compiled my sample code with "yotta install tadakado/microbit". I can connect microbit UART from Nordic UART compatible app, such as Bluefruit iPhone app. (Still I can't see UART in the service list, but it does have the service)

I prefer to use Nordic UART in MakeCode. Because it's easy to communicate with other Nordic BLE device and integrate with various MakeCode extensions. Especially it's quite useful for kids. My current project is to send iPhone's ANCS (call/email/sns...) message to a microbit-car through an ANCS-UART repeater. I made the ANCS-UART repeater and my kids will make the microbit-car part. When phone calls, microbit will dance!

Another ping on this issue. I appreciate that changing to TX - Notify and RX - Write is tricky as an ecosystem has developed around the current implementation. However, as discussed further up the thread, it seems like micro:bit needs to do a breaking change one way or another. Either changing UUIDs or changing to what Nordic have as their current implementation. I would prefer to go with fitting in with the NUS "standard" because there are other resources out there for BLE-Central implementations of it that could be leveraged.

I had to revisit the tx/rx for microbit V2 codal libraries. Swapping the advertised IDs is. Looking at putting in a pull request but what to still check out a few bits. For those that venture in this thread.

PaulAustin/codal-microbit-v2@bf466de#diff-a1a10cdd833c4df0c66831f22593a204e869d64d80c53016f01d2fb212931580