BLE - Unable to write after read

Bugs and Other Issues
,
1

Thank you everyone for your time and support.

I have created a simple app to read and write from/to a Nordic ble MCU (nRF52833)

Using the latest MIT App Inventor BLE (version 20200828) extension I can connect and communicate as expected, with the exception that once I read, I can no longer write.

I can only guess that there is a bug in the BLE extension that causes something to step on its toes.

Behavior is:

Scan for devices
Select device from list
Connect to device
Register for Shorts using Nordic:
serviceUuid - 6E400001-B5A3-F393-E0A9-E50E24DCCA9E
characteristicUuid_RX - 6E400003-B5A3-F393-E0A9-E50E24DCCA9E
WriteBytes using Nordic:
serviceUuid - 6E400001-B5A3-F393-E0A9-E50E24DCCA9E
characteristicUuid_TX - 6E400002-B5A3-F393-E0A9-E50E24DCCA9E
Data is sent (confirmed by looking at the terminal in Termite)
ReadShorts using Nordic:
serviceUuid - 6E400001-B5A3-F393-E0A9-E50E24DCCA9E
characteristicUuid_RX - 6E400003-B5A3-F393-E0A9-E50E24DCCA9E
Display shortValues in text box
WriteBytes using Nordic:
serviceUuid - 6E400001-B5A3-F393-E0A9-E50E24DCCA9E
characteristicUuid_TX - 6E400002-B5A3-F393-E0A9-E50E24DCCA9E
No data is sent (confirmed by looking at the terminal in Termite)

Scan for devices
Select device from list
Connect to device
Register for Shorts using Nordic:
serviceUuid - 6E400001-B5A3-F393-E0A9-E50E24DCCA9E
characteristicUuid_RX - 6E400003-B5A3-F393-E0A9-E50E24DCCA9E
ReadShorts using Nordic:
serviceUuid - 6E400001-B5A3-F393-E0A9-E50E24DCCA9E
characteristicUuid_RX - 6E400003-B5A3-F393-E0A9-E50E24DCCA9E
Display shortValues in text box
WriteBytes using Nordic:
serviceUuid - 6E400001-B5A3-F393-E0A9-E50E24DCCA9E
characteristicUuid_TX - 6E400002-B5A3-F393-E0A9-E50E24DCCA9E

No data is sent (confirmed by looking at the terminal in Termite)

Essentially I can write data until I read data. Then I can no longer write. I can read data repeatedly with no problems. I am pushing data only once per event from the Nordic device.

I can provide additional data as needed.

Thank you again.

2

I thought I'd share the fix to my issue, since I figured it out on my own.

If you are reading and writing with the UART service on BLE devices you must not use the "read" block as this forces an always open read channel on the UART service and blocks all write events until reset.

Instead register to receive the data type you want using the service and characteristic needed (should be 2 different yet usually similar IDs)

Then use the "when data is received" event to define what you want to do with the data.

There is no need to "read" the data type you registered for. This allows you to write whenever you want. Also there is no need to register for a data type that you are writing, as you set those UUIDs when writing.

Good luck everyone and have fun!!

3 Likes
3

That's a very very useful tip Adam!

Note that to send-receive simultaneously the MTU (maximum transmission unit) size can be increased.

4

We tried increasing the MTU to max but still could not write once a read was started. I'm not sure at this point when I would use a "read" except that maybe you can read without registering for a data type as a one time thing... although even then we could not write once a read was started. We also spent a bit of time unregistering, but found that disabled everything and could not be enabled without reset.

Thank you for the support.

5

ah - I did not mean read in the sense of the read method, I meant read as in receiving :thinking: There are occasions when a Project needs both without stopping either - for example when 'driving' a robot.

6

Ah, yes. We are transmitting and receiving simultaneously now... gotta watch that "read"... Even with a moderately sized MTU our communications are clean. Its so nice when things just work... :wink:

1 Like
7

Also, a lot of people think the MTU max is 512 bytes (517 bytes on Android) done-and-dusted but that isn't a given as the original max was 244 bytes.