Start logging a filter never returns a message


I've been using the develop branch of the iOS SDK for the last few months and lately I'm having a problem issuing the .startLoggingAsync() command. The code I'm using to initiate a log is:

config.quaternionFilter.startLoggingAsync().success({ (obj) in


            }).failure({ (error) in



where quaternionFilter is a filter defined in the sensor persistent connection as:

  quaternionFilter = device.sensorFusion!.quaternion.periodicSample(ofEvent: 30)

I check if the configuration is valid before accessing so I don't think that is the issue. The problem is that I never receive a response in either the success block or failure block. If I check if the filter is logging after the call, it always reports true. However, when attempting to download the log files I don't get data back, as if it was not logging. 

Do you have any idea why I may not be getting a response from the startLoggingAsync() call? Any help would be appreciated, thanks. 


  • I should add as well that about 75% of the time I do connect to the sensors and receive a message for the startLoggingAsync command. Only about 1/4 times using the app I do not get any messages from the call.
  • edited October 2017
    What firmware version, hardware revision, and board model are you using?

    Is your board in a clean state when you run the code?
  • My boards are hardware revision 0.1, firmware 1.3.4 and model number 5 (MetaMotion R). I'm running an iOS app with 10.3 (not yet upgraded to iOS 11). Before running my code, I launch the MetaWear sample app and reset to default, and then soft reset. Once my app launches, I set config to nil, and then set the configuration with my configuration class which has been working fine previously. In my "run from startup" configuration call I initialize the sensor fusion filter that I want to log. I have tried with and without having a stopLoggingAsync call in the startup function with no luck. Once the sensors have had their configuration set, I reconnect to the boards and call startLoggingAsync. This call is at least a minute after the other startup and connect calls. I have tried checking the connection state before calling startLoggingAsync and the boards always return connected. I have also tried to query the filter to see if it is logging and it returns false before the call and returns true after the call, always; even when I query the sensor that does send a response from the startLoggingAsync call. If I try to stop logging and download from the sensors that did not send a respond message, even though the filter returned true to logging, I reach an assertion saying there are unmatched activate/deactivate calls in a BFTask block.
  • I've let the iOS dev know to take a look at this thread.
  • Thanks Eric, one more additional point to add as well, it seems as if the sensors sit for a while without contact from the app, it does not work correctly after. Is it possible that the sensor fusion mode changes to sleep automatically or something similar?
  • I'll be taking a look at this today, and hopefully publishing a more in depth guide to persistent configurations, but I have a few offhand pointers that may help:
    • There is no need to use the MetaWear sample app to reset, when you call setConfigurationAsync that will perform the same function as "Reset to Defaults".  So keep things simple and only use one app
    • There is no need to set the config to nil before assigning the config you want to use.  Just assign what you want and it will automatically clean up anything from the previous config
    • In the "runOnDeviceBoot" you need to create the filter events, assign them to stored properties (member variables) of your config class, and you should call startLoggingAsync.  After the setConfigurationAsync call finishes, you are free to disconnect and close the app.
    • When you come back, remember to connect and grab the configuration object so you may access that perviously stored property (your filter event), and proceed to download
  • For a real life example see the updated StarterProject 
  • Thanks Stephen and Eric!
This discussion has been closed.