Firmware v1.1.0 Release

Comments

• propan

  December 2015 edited December 2015

  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

  December 2015

  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

  December 2015

  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

  January 2016

  @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

  January 2016

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

  January 2016

  @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.