Firmware 1.7.2 -- MMS / MMR / MMRL

MMS

  • Added charge status indicated by LED (native implementation)
  • Added Force 1MHz PHY mode endpoint

MMR / MMRL

  • Updated charge status indication to native implementation (frees user resources and reduces interference with user LED commands)
  • Added Force 1MHz PHY mode endpoint
  • Added automatic sleep mode initiation at low battery level (60s below 3050mV to trigger)
  • Reduced pin change interrupt overhead and latency
  • Fixed dead lock corner case in scheduler (inherited from MMS branch, no known sighting/trigger in previous MMR releases)

Comments

  • Just updated the firmware to 1.7.2,
    1. But there's still a problem of sensor not staying connected when the distance is 10/15 feet, and if we connect it first and then take it away the data stops coming.
    2. And if we try to initialize the sensor at a distance of 10/15 feet, it does not connect to the system and throws an exception.

  • Yes is there any associated SDK update @Matt currently we are using the below sample App to communicate with the sensor

    https://github.com/mbientlab/MetaWear-SDK-iOS-macOS-tvOS/branches
    Sample App code

    Appreciate your response

  • URGENT HELP WITH FIRMWARE 1.7.2 NEEDED

    Today we had to cancel research study participants at our University and will keep having to cancel our appointments until we can get the accelerometers working.

    We have 6 devices – all are Model MetaMotion R, Model Number 5, Firmware 1.7.2, Hardware 0.4.

    We believe that the new firmware update (1.7.2) has made it so that our accelerometers won't work with any devices. They were working yesterday before the update. The devices we typically use with the accelerometers are android cell phones, running with Android Version 9, to access the MetaWear app. We have tried other personal devices, but these are not working either. Once we connect the devices to the phone, we are able to start the recording on the accelerometer as usual (set to data logging, accelerometer on, set to 25Hz, 2g). However, when we try to download the data, the screen shows “Download failed” in red, followed by an error message that reads, “Error - Failed to retrieve logged data from some devices. – Please make sure they are charged and near your Android device, then try again.” The only option available is to select OK, and try again. No matter how many times we run through this process of attempting to download the data, we encounter this same error. Our devices are all charged above 90%, and sitting on top of or near the screen of the phone they are connected to. Once we get this error, the devices seem to be stuck in recording mode. Occasionally, we are able to get out of this recording mode by pressing the “update firmware” button, however, this does not always work and must be repeated several times before the accelerometer exits the recording phase. This method also results in us having to sacrifice the data we collected just to get the device out of recording mode. We have also tried pressing the “Run Diagnostic” button, but nothing happens. We have restarted our devices, re-installed the app, tried new devices – all to no avail.

    Is there any way we can revert to the old firmware that was previously installed on the devices? That way we won’t have to cancel more scheduled research study participants this week.

    Thanks for your quick help, we really need it!

  • @Srinivasa Support for forcing 1MHz PHY was added to the Cpp SDK along with bindings in this commit https://github.com/mbientlab/MetaWear-SDK-Cpp/commit/5ee04ff14c5fe9545cc87b30fddcd6665d8b323c

    @jepse032 We have released a firmware 1.7.3 which resolves an issue with the log memory driver for the model and revision of your devices. We will follow up with instructions for downgrading firmware in your other thread, should you find it necessary to do so.

  • edited April 21

    @Matt Thanks for the SDK commit hash,I have updated firmware to 1.7.3 and tried to set the below code while starting logging

      mbl_mw_settings_force_1M_phy(device.board, 1)
                mbl_mw_acc_set_odr(device.board, selectedFrequencyValue)
                mbl_mw_acc_bosch_write_acceleration_config(device.board)
            self.textLog.write("selectedScaleValue \(selectedScale)  selectedFrequencyValue \(selectedFrequencyValue)")
            //start device
            let signal = mbl_mw_acc_bosch_get_acceleration_data_signal(device.board)!
            mbl_mw_datasignal_log(signal, bridge(obj: self)) { (context, logger) in
                let _self: DeviceObject = bridge(ptr: context!)
                let cString = mbl_mw_logger_generate_identifier(logger)!
                let identifier = String(cString: cString)
                _self.loggers[identifier] = logger!
            }
            mbl_mw_logging_start(device.board, 0)
            mbl_mw_acc_enable_acceleration_sampling(device.board)
            mbl_mw_acc_start(device.board)
    

    I still didn't observe the reducing time to download the data from the sensor to mobile. it was like 1.5.1?

    Am I missing where I should call this mbl_mw_settings_force_1M_phy? I have tried with after start or after stop live logging before download none of the options no change in download time?

    Do I need to set any changes in other CPP bindings ????

    Please appreciated your input to overcome the long-pending challenge. I have tested with iPhone XS MAX and IOS 15.*

    Thank you.

    SrinivasaRao Ladi

  • Hey @Srinivasa,

    I still didn't observe the reducing time to download the data from the sensor to mobile. it was like 1.5.1? Unfortunately this was only a test and was not guaranteed to succeed.

    Am I missing where I should call this mbl_mw_settings_force_1M_phy? I have tried with after start or after stop live logging before download none of the options no change in download time? No, you have implemented this correctly.

    Do I need to set any changes in other CPP bindings ???? No.

    We will look for other alternatives but this may simply be the default due to Bluetooth 5.0.

Sign In or Register to comment.