UART TX output - "scheduled (0/8)"

I'm trying to read Puck UART TX characteristic in Go, I got nowhere on Mac, but am getting something back now I'm running Linux.

But I can't make sense of the output.

It should return "hello" and frustratingly I've seen this once, but every other time I get variants on the below:

d (0/8)

>

A couple of times I've had a few more characters before the d (so my inference "scheduled").

Anyone know what this is? The > looks like the prompt?

Writing to RX works fine.

Looking at espruino codebase this would appear to be the error I'm getting back partially:

(from Espruino/libs/bluetooth/jswrap_bluetooth­.c line 87)

BLE task completed that wasn't scheduled (%d/%d)

The numbers I get are 8/0 rather than 0/8 - I transposed them in first post

What does this error mean?

Wow, that's a strange one - are you using up to date firmware?

With the UART, you're supposed to subscribe to get notifications - and then you're sent a notification when the output data on the UART changes.

It's possible that by actually reading the UART characteristic when it's not expected that you'll read it it's triggering the error you're getting?

Both the pucks I'm using are on v1.96.

The function in the library that gives me this error is a request to read the characteristic yes.
There's another function in the API to subscribe to the characteristic, and a handler should pick up TX output. I've also tried that, but that gives me nothing at back at all.

Could I do anything to make UART TX characteristic ready for a single read?

If you try and read with the Nordic nRF Connect app it won't actually let you read the characteristic at all. The fact that the Go library lets you do it seems like a bug in the library (although obviously Puck.js shouldn't error on it - I'll try and look into that).

If you subscribe then it should work, as long as something is printed to BLE once you're subscribed (existing output won't get displayed).

If subscribe is broken then your best bet would be to make a new characteristic that actually can be read with NRF.setServices and to then implement whatever you need via that?

Ok thanks @Gordon, I considered using a new characteristic yes, but I'll try with the subscription to TX again first. I had no idea that a straight read from TX was bad form - as you say, likely a problem with the library

Yeah, each characteristic reports back which operations it supports. I honestly didn't think it was even possible to read from something that didn't have the READ property set so it's not something that got tested.

I'll make sure that gets fixed, but it's probably best to avoid doing the TX read as future versions of the BLE library you're using or even different hardware might decide to stop you from doing it.