v1.16.4

Saveparams issue fixed

v1.16.3

Addresses an intermittent bug that causes a failure to reconnect after the main fw update

v1.16.2

• BLE improvements by Rob in 08/23

V1.16.0

Adds a WebSerial connection option
Add send file functions to the example dashboard
Customise file send parameters for each interface
Update elem updates functionality to work with new addon firmware version management from https://github.com/robotical/FirmwareConfigurators/tree/feature/addon-firmware-versions/FirmwareVersions
Breaking change to updateManager update URL handling
setupUpdateManager now has an extra parameter to provide a base URL for the firmware updates - e.g. https://updates.robotical.io/live

v1.15.2

Sound Streaming Improvements

v1.15.1

Added error prevention in ServoParamUpdate

v1.15.0

In the ServoFaultDetector, we first check if the fault bit of the status byte is enabled before going on and checking the fault byte of the atomic read

v1.14.0

• RICServoFaultDetector that detects servo faults
• Proper error-handling in the ServoUpdater

v1.13.5

Added a new util method: withTimeout which is a wrapper function that rejects an operation if it takes longer than the specified timeout.
This solves the issue were the webapp is trying to reconnect after a connection is lost, but freezes because the gatt.connect() method never returns.

v1.13.3

Prevent multiple audio streams from starting over the top of each other when streamAudio commands are sent in rapid succession.
Reduce occurrences of spurious streaming warnings.
Send streamID with ufCancel message.
Add placeholder to only send ufCancel and audio/stop messages over BLE if a stream is stopped before completion.
Don't send ufCancel or audio/stop message when restarting a sound - rely on the ufStart command to restart the stream

The expected behaviour is that the previous sound will stop and the most recently clicked sound will play. Where a user puts the start sound block in a tight loop we should avoid spamming the BLE connection

Since the streamHandler is asynchronous and recursive with a queue, there are a few edge cases to beware of, and it has previously been possible to end up with two instances of sendStreamContents running simultaneously using the same streamID but different stream positions, creating interference. The code could potentially be refactored to simplify these aspects

We also need to ensure that if the ufCancel and audio/stop commands are sent, we wait for them to complete before attempting to start the next stream.

There is still potentially an edge case here where a new sound is started at the exact point between when sendStreamContents completes, but before sendStreamEndMsg does - in this case the isCancelled flag may be set but without a pending operation to clear it. This hasn't yet occurred in testing, but the issue should still be fixed