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.

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 19

    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 19

    .

  • 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 23

    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 25

    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.

Sign In or Register to comment.