Observed the change in download recorded data from sensor to phone

Hello,

We are using MRL with logging mechanism,

With Firmware of 1.4.4 for 30 secs recording with 800 Hz sampling rate is taking approx 64 secs to download the data from the sensor to phone but where as with same code with Firmware 1.5.1 observed the change of download time almost by 50 %

made some test runs and it is clear that the downloading time increase is coming from the firmware. For example, for the same sensor, the downloading time increased about 50% after updating the firmware (#d & #e vs #f & #g in the recording time comparison below).

29 sec recording with 800Hz: 92 sec (MetaMotion RL #1 with Firmware 1.5.1 & Hardware 0.5)
1 min recording with 800Hz: 188 sec (MetaMotion RL #1 with Firmware 1.5.1 & Hardware 0.5)
30 sec recording with 800Hz: 92 sec (MetaMotion RL #1 with Firmware 1.5.1 & Hardware 0.5)
**30 sec recording with 800Hz: 62 sec (MetaMotion R #2 with Firmware 1.4.4 & Hardware 0.3)
**1 min recording with 800Hz: 123 sec (MetaMotion R #2 with Firmware 1.4.4 & Hardware 0.3)
**30 sec recording with 800Hz: 91 sec (MetaMotion R #2 with Firmware 1.5.1 & Hardware 0.3)
**1 min recording with 800Hz: 186 sec (MetaMotion R #2 with Firmware 1.5.1 & Hardware 0.3)

      var handlers = MblMwLogDownloadHandler()
                handlers.context = bridgeRetained(obj: self)
                handlers.received_progress_update = { (context, remainingEntries, totalEntries) in
                    let _self: DeviceObject = bridge(ptr: context!)
                    let progress = Double(totalEntries - remainingEntries) / Double(totalEntries)
                    DispatchQueue.main.async {
                        let macAddress = _self.device?.mac!
                      //  print("progress for \(String(describing: macAddress)) is \(progress)")
                        _self.delegate?.updateProgress(progress: Float(progress))

from the sample app reference from Mibient tutorial . i would like to understand why there is extra time for new firmware is there any issue in new firmware ?

could you please let us know if there is a way to improve (from our side) the downloading time from Firmware 1.5.1?

Thanks
SrinivasaRao Ladi.

«1

Comments

  • The new firmware supports the new BLE5.2 which has two modes:
    1. Long range but slower data throughput
    2. Short range but faster data throughput
    Unfortunately in BLE5.2 #1 is the default. We are looking at the capabilities of Android, Linux, and iOS BLE stacks to look for settings to enable #2.
    You can read more about this in the BLE spec online.

  • edited August 2021

    Thank you laura for your continued support.!!!

    • Did you mean that your team is looking for ways to enable option #2 in the firmware? Or do you mean to enable in the SDK for developers?
    • Is it possible for us (developers) to select/enable option #2 from our SDK for iOS?
    • You don’t have to promise but do you have an approximate time frame that your team plans to make option #2 available in either the firmware or SDK for the developers?
    • What is the “Range” in the options? Is “Range” the distance between sensor and phone that is accessible via Bluetooth?*
  • edited August 2021

    .

  • Did you mean that your team is looking for ways to enable option #2 in the firmware? Or do you mean to enable in the SDK for developers?
    This has nothing to do with our firmware, it is settings on the smartphone and computers that need to be changed.

    Is it possible for us (developers) to select/enable option #2 from our SDK for iOS?
    You have to look into CoreBluetooth and see if they support this.

    You don’t have to promise but do you have an approximate time frame that your team plans to make option #2 available in either the firmware or SDK for the developers?
    1-2 months.

    What is the “Range” in the options? Is “Range” the distance between sensor and phone that is accessible via Bluetooth?*
    https://blog.nordicsemi.com/getconnected/tested-by-nordic-bluetooth-long-range

  • edited August 2021

    Did you mean that we, developers, can enable/select option #2 from our code for iPhone/computer even before your team makes option #2 available in either the firmware or SDK for the developers? Or did you mean that it is not possible for developers to make option #2 available so we have to wait until the firmware or SDK change by your team?

  • edited August 2021

    Thank you Laura for your continuing support.

    1. Is there any possible way for us developers to enable option 2 (faster data throughput) in BLE 5.2 without your team’s Firmware/ SDK update?

    2. If it has to be with your team’s update, does it have to be firmware update or SDK update only?

    1. I looked into the BLE API from Apple the other day and I could not find a way to do so. There is nothing to do on our side, the Nordic BLE stack works as intended.
    2. It is not on our side, it is on the master side that you would change the BLE settings but Apple and Android doesn't seem to allow developers to change the config at this time.
  • Thanks, Laura.

    Just for my understanding, could you please clarify my question below?

    You mentioned earlier in this thread above as below.
    "Unfortunately in BLE5.2 #1 is the default. We are looking at the capabilities of Android, Linux, and iOS BLE stacks to look for settings to enable #2."

    Now, after you looked at the BLE API from Apple,

    1. Did you mean that you (from either firmware or SDK) are not able to enable #2 (Short range but faster data throughput)?
    2. So it appears that there is no way (either firmware or SDK or via our own iOS-based scripting) to enable #2. Is my understanding correct?

    Your clarification will help me choose our next development step.

  • There is no configuration for BLE server side changes in the stacks/libs we use as of this date.

  • edited December 2021

    is there any way to use BLE 5.2 Option 2( Short range but faster data throughput)?

  • This is unfortunately not done on the sensors side but rather on the OS/smartphone/computer side. You have to look at the calls/settings for your master device, not our sensor (our sensor just does what the master tells it to).

  • edited December 2021

    Hello Laura,
    Thank you for your response.
    I have done some studies on Bluetooth communication layers and understod that 2M PHY(Short ), Coded PHY (Long ) range modes
    1. it seems the Bluetooth mode defaults to the IOS version, Do you think we can change settings from IOS SDK ?https://developer.apple.com/forums/thread/665542
    2, To update PHY Procedure it has to be done on both ends means Master and slave.
    PHY Update Procedure
    Bluetooth provides the flexibility to switch to using different PHYs during a connection. Different PHYs can be used in each direction as well between the two connected devices. For example, this procedure can be used to switch to using the Coded PHY after two devices have connected using the standard 1M PHY allowing the two devices to increase the range at which they maintain the connection.
    The PHY Update Procedure can be initiated by either the master or the slave after the connection is established.
    Reference link:
    https://www.novelbits.io/long-range-bluetooth-coded-phy/
    https://jimmywongiot.com/2021/05/23/how-to-work-with-ble-codec-1mbps-2mbps-and-codec-phy-on-nrf52-series/

    also, found a snippet that can toggle the BLE coded / uncoded PHY on nRF52 SDK. since it was firmware code can you please give an interface to update this value from iPhone C++?

    https://github.com/jimmywong2003/nrf52-ble-phy-coded-update-example?

    Appreciated your response
    Thank you

  • edited December 2021

    Hey @Srinivasa, we wrote the firmware so that whatever the master requests, the slave (i.e the metawear) will do.
    The issue is that the bluetooth libraries we use on the software side (smartphone, computer... such as core bluetooth in the swift sdk) don't have a function to change the PHY.
    Does that make sense?
    The issue isn't on our side, it's the lack of changeability on the software side (you need to ask Apple to support this on Core Bluetooth). It is entirely out of our hands.

  • @Srinivasa, we may be able to do one thing in firmware which is disable 2M PHY via the SDK. Would that work for you?

  • @Laura said:
    @Srinivasa, we may be able to do one thing in firmware which is disable 2M PHY via the SDK. Would that work for you?

    Yes I have asked to Apple and below is the response I got. we would like to achieve the good data throughput to download the accelerometer data from sensor to mobile in short range communication . we are able to get good one with 1.4.4 firmware do you mean by disable 2M PHY via the SDK shall we able to achieve the same speed as earlier .1.4.4 for latest Firware version ?

    Apple Link : https://developer.apple.com/forums/thread/697481

  • @Laura said:
    @Srinivasa, we may be able to do one thing in firmware which is disable 2M PHY via the SDK. Would that work for you?

    Yes, It will work if we disable 'LE 1M PHY', 'LE Coded PHY' so only 'LE 2M PHY' is available.

    'LE 2M PHY' is the mode we want to communicate.

  • edited January 21

    @Srinivasa

    I want to clarify a couple of things.

    MMRL uses a slightly older chipset than MMS, which does not support LE Coded PHY at all, so the slowdown cannot be related to it.

    Firmware 1.4.4 did not support 2M PHY at all, 1.5.1 primarily enabled it by switching to the LE 5.1 standard.

    We are proposing a setting to disable the 2M PHY, so that the device behaves more similarly to firmware 1.4.4.

    In general, it is presumed that a host like iOS will use the 2M PHY when available and if the signal strength is suitable. The higher bandwidth may be associated with more interference or similar reducing the download rates, which the new setting would help to diagnose.

    For interoperability, we can not add a 'disable 1M PHY' mode, as it may render devices unconnectable. It may not even be allowed per the bluetooth spec, but I am not certain. All MetaWear devices establish their connections over 1M, and then the host may transition the connection to 2M.

    There are a couple other small features planned to intercept with this firmware update, so there is no ETA at the moment.

    Matt

  • Matt,

    Thanks for your reply.

    • 'LE 2M PHY' is the one that we want to use. We don't want to use and so we want to disable 'LE 1M PHY' as we want higher data rate.
    • Firmware 1.4.4 seems to use 2M PHY (higher data rate) which we want. But Firmware 1.5.1 seems to use 1M PHY which we don't want to use due to the lower data rate. That's why we want to use the older version (Firmware 1.4.4) feature.

    Is your note still applicable with the above two aspects?

    Regarding your note "We are proposing a setting to disable", do you mean the 'setting' by iOS? As Srinivasa noted in the postings above from the communication with Apple etc., it doesn't seem to be feasible to handle any setting to select an option (1M or 2M) in iOS.

    Any suggestion on how we can use 'LE 2M PHY', as was automatically available in Firmware 1.4.4?

    Thanks for your help.

  • Hi Matt, Any update on the above new firmware?

  • @qpal1012

    There is a misunderstanding here regarding Firmware 1.4.4 and 2MHz PHY.

    • Firmware 1.4.4 was running a BTLE 4.1 compliant software stack. 4.1 had absolutely no support for 2MHz PHY. Any results obtained with 1.4.4 were absolutely obtained over a 1MHz connection.
    • Firmware > 1.5.0 is 5.0 compliant, and the client may select a 1MHz or 2Mhz PHY.

    As a result, if your performance issue is related to PHY type, then it is due to using 2MHz.

    We are proposing a setting to disable the 2MHz PHY. If the client requests a PHY change with the new setting active, the MetaWear device will report that only 1MHz is supported, so there will be no transition to 2MHz.

    There is no possibility to force the 2MHz PHY -- many client devices only scan for advertisements at 1MHz, so the setting could easily make a device un-connectable.

    @Srinivasa

    The firmware has been implemented, but C++ and downstream API hooks are still under dev/test/release.

  • @Matt
    Thank you. Please let us know as soon as the SDK update is available to use.

  • @Srinivasa,
    The SDK was updated.

  • @Laura
    Thanks for letting me know.
    when am trying to update to the latest firmware using the official Metabase App it's not showing any new firmware version. and trying to see the source code SDK at the below repo

    https://github.com/mbientlab/MetaWear-SDK-iOS-macOS-tvOS

    Can you please share the details of which repo/Firmware version should be used for testing of updated change as mentioned above and also snippet how to disable the 2MHz PHY?


    .
    Thank you for your continued support.

  • Firmware 1.7.0 is for MMS only.

  • Hello,
    Is the above firmware update (1.7.0 for PHY change for faster download) planned to be implemented to MMRL too? We really hope so. We earlier purchased MMRL of 100ea and we have been waiting for the (PHY change for faster download) update in the firmware/SDK revision for MMRL, as can be seen from this thread.

    Thanks.

  • @Laura can you please check the MMRL request as we are waiting. to use this sensor on pilot
    Thank you

  • @Srinivasa The MMRL update for this feature is in testing now. It is getting some internal changes integrated from the MMS development line, so it will be an extended test cycle. Estimate would be a release end of next week barring unforeseen issues.

  • Thank you @Matt. It's glad to know that also checking all unforeseen issues. please notify me once firmware and SDK are available for me to use.

  • @Srinivasa
    I will make an announcement once we release the firmware and SDKs in the forum ;)

  • edited April 11

    @Laura Can you please let me know when SDK is available?

    as I am able to download the latest Firmware 1.7.2 for MMRL

    With the current Codebase, we are not able to get the progress Update can you please share the updated SDK link here

    Currently, we are using the below the repo - https://github.com/mbientlab/MetaWear-SDK-iOS-macOS-tvOS

Sign In or Register to comment.