Firmware v1.1.0 Release

Eric

MetaWear firmware v1.1.0 is available for all MetaWear boards.  You can update your boards with the iOS or Android app.  This update:

• Enhances math data processor to work with accelerometer and gyro data.
• Adds constant operation to the math processor.
• Supports event handling for lost BTLE connection.
• Adds buffer data filter.
• Enables the configuring of BTLE connection interval parameters.

propan

Thanks for an update. Have been working with TCS34725 via I2C. After update from 1.0.0 started to get the error on readData. The board is suppose to return single 0x44 identifier.

 java.lang.RuntimeException: Received I2C data less than 4 bytes: [0x0d, 0x01, 0x44]

at com.mbientlab.metawear.impl.DefaultMetaWearBoard$25.process(DefaultMetaWearBoard.java:2653)

at com.mbientlab.metawear.impl.DefaultMetaWearBoard.receivedResponse(DefaultMetaWearBoard.java:3026)

at com.mbientlab.metawear.MetaWearBleService$2$6.run(MetaWearBleService.java:909)

....

Same issue with both 2.1.0 and 2.3.0 Android API. However readData seams to work while routing the data.

matthewpjw

Latest iOS CocoaPods (2.0.0) release fails to build for me, after update I have the following new pods:

Installing Bolts (1.5.1)

Installing Metawear-iOSAPI 2.0.0 (was 1.11.0)

On build I get several errors in the API headers, eg:

MBLEvent.h

Pods/Metawear-iOSAPI/MetaWear.framework/Headers/MBLEvent.h:239:4: Type arguments cannot be applied to non-parameterized class 'BFTask'

Pods/Metawear-iOSAPI/MetaWear.framework/Headers/MBLEvent.h:242:4: Type arguments cannot be applied to non-parameterized class 'BFTask'

MBLData.h

Pods/Metawear-iOSAPI/MetaWear.framework/Headers/MBLData.h:51:4: Type arguments cannot be applied to non-parameterized class 'BFTask'

BFTask+MBLExtensions.h

Pods/Metawear-iOSAPI/MetaWear.framework/Headers/BFTask+MBLExtensions.h:57:19: Category of non-parameterized class 'BFTask' cannot have type parameters

Any suggestions?

Matt

Matt

This is a major point release with many new internal and external features.  Full release notes:

- Improved log readout algorithm for robustness and reliability

- New task scheduler and queueing system

  - Adds multi priority main task queue

  - Adds centrally managed hardware resource queues

  - Adds multi priority TX buffer to handle data bursts and prioritize events

  - Central resource pool enables deeper queues for all subsystems

- Added "Local Read" endpoint for all read registers to reduce unnecessary radio traffic and energy use

- Fixed idle current leak due to LED driver errata on MetaWearR

- Added GPIO pin feature enumeration

- Added workaround for BLE stack TX buffer leak

- Added "boot crash" check to recover devices crashing at boot due to startup macros

- Added end points to control BLE connection performance

- Fixed issue with count/accumulator filter

- Added hooks for MetaWearC

- Added multi channel support to simple math data processor

- Added notification endpoint for GAP (radio) disconnection

- Added ADC retry for reads likely to have been disturbed by radio induced supply voltage droop

- Added GAP (MAC) address read register

- Added constant output mode to simple math filter

- Added "buffer" filter to allow reading rather than streaming of filter events

- Fixed issue with delayed i2c reads

- Fixed integer overflow issue affecting timers and time delta filter

- Improved efficiency of packet matching by command, logger and data processor

- Eliminated dynamic memory use from several data filters

- Eliminated dynamic memory use by short entries in command module

Eric

@propan

Sorry about that.  The readData variant that returns an AsyncOperation should have been marked as deprecated.  Use the version that uses the data route system.

@matthewpjw

Another user is reporting a similar (same?) error as you here: 

http://community.mbientlab.com/discussion/1427/strange-errors-at-runtime-tutorial-ios-3a#latest

I've forwarded the errors to our iOS dev.

matthewpjw

Tracked my issue down to having an older version of the Bolts framework in the app.  All working now.

propan

@Eric

Thanks for clarification. I'm configuring the board in interactive mode in the beginning, like checking if parameters have been properly set up before hooking it up on the data route for the measurements.

I guess I will have to redesign this part now to have some branching in the route data handler.