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.
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?
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
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?
Thank you Laura for your continuing support.
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?
If it has to be with your team’s update, does it have to be firmware update or SDK update only?
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,
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.
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).
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
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?
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
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.
@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.
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.
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
@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