@Matt Thanks for the SDK commit hash in another link, I have updated firmware to 1.7.3 and tried to set 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 the 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.*
Srinivasa: @Matt I have updated firmware to 1.7.3 and incorporated CPP SDK you mentioned, the downloading time is still long (like firmware 1.5.1). As we communicated earlier, the downloading time with firmware 1.5.1 is 50% longer than 1.4.4.
I have set the force mode by using mbl_mw_settings_force_1M_phy while starting logging. I copied the corresponding code below.
How can I make the downloading time to be the same as with firmware 1.4.4?
Environment: Phone XS MAX and IOS 15.3.
//added this line before mbl_mw_logging_start call
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)
It looks like this may just be the new download speeds with the Bluetooth 5.0 upgrade. We will keep looking for options but we may just have to accept this as the new standard.
@Srinivasa Could you confirm that there is a disconnect-reconnect cycle after forcing the 1M PHY? The setting only affects the link negotiation process, which typically occurs shortly after a connection is established.
@Matt
I have tried to disconnect and reconnect the cycle after forcing the 1M PHY and resulting in the unable to download the accelerometer data due to acceleration logger not found and same case happing with connection parameters too if we set more than 7.5 as min connection interval . i have tried wth 10,12.5,15.20 all were resulting same issue and with 7.5 there is no improvement in download time from sensor to device .
below is implemented screenshots of code and attached log for the same .
Log file :
2022-05-15 12:05:23 +0000 startLogging
2022-05-15 12:05:23 +0000 startLogging Time 1652616323.901923 is Optional("F2:E4:F0:07:57:5C")
2022-05-15 12:05:23 +0000 selectedScaleValue 3 selectedFrequencyValue 200.0
2022-05-15 12:05:34 +0000 stopLoggingFor d0f1b82b-f4ce-4ab2-9c14-0322e9e8385b/1b03009f-87c4-4e7f-81f6-01591896575e/test_51520225:35:23PM.txt
2022-05-15 12:05:34 +0000 stopLogging called
2022-05-15 12:05:36 +0000 stopLogging Time 1652616336.591401 is Optional("F2:E4:F0:07:57:5C") 2022-05-15 12:05:36 +0000 acceleration logger not found
2022-05-15 12:05:36 +0000 hideHUD called
Hey @Srinivasa, for now we are just accepting that since we updated to the BLE5 stack, the default conn speeds are simply slower. Unfortunately that is not something our devices can control.
Matt previously demonstrated in Windows10 machine via 'some quick tests ' that v1.7.3 is 1.5x faster than v1.4.5. Srinivasa also replicated Matt's test and confirmed that v1.7.3 is 1.5x faster than v1.4.5 in Windows device.
But, when Srinivasa did the similar simple testing in iOS device (target device), v1.7.3 is 1.5x slower than v1.4.5. So, strangely, iOS device seems to show the opposite trend from Windows device in the communication speed.
Do you think if it is possible that the iOS device is showing opposite trend from WIndows device in the communication speed?
So, would it be possible for you to make the similar testing on iOS device too as the one that Matt did on Windows device earlier? This will confirm that iOS and Windows devices are showing opposite trend in the communication speed.
I thought that it may be useful to Mbient too to be aware the opposite communication speed trend in iOS and Windows, if confirmed.
Comments
@Matt Thanks for the SDK commit hash in another link, I have updated firmware to 1.7.3 and tried to set below code while starting logging
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 the 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 .
Matt wrote :
@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
Srinivasa:
@Matt I have updated firmware to 1.7.3 and incorporated CPP SDK you mentioned, the downloading time is still long (like firmware 1.5.1). As we communicated earlier, the downloading time with firmware 1.5.1 is 50% longer than 1.4.4.
I have set the force mode by using mbl_mw_settings_force_1M_phy while starting logging. I copied the corresponding code below.
How can I make the downloading time to be the same as with firmware 1.4.4?
Environment: Phone XS MAX and IOS 15.3.
It looks like this may just be the new download speeds with the Bluetooth 5.0 upgrade. We will keep looking for options but we may just have to accept this as the new standard.
@Srinivasa Could you confirm that there is a disconnect-reconnect cycle after forcing the 1M PHY? The setting only affects the link negotiation process, which typically occurs shortly after a connection is established.
@Matt
I have tried to disconnect and reconnect the cycle after forcing the 1M PHY and resulting in the unable to download the accelerometer data due to acceleration logger not found and same case happing with connection parameters too if we set more than 7.5 as min connection interval . i have tried wth 10,12.5,15.20 all were resulting same issue and with 7.5 there is no improvement in download time from sensor to device .
below is implemented screenshots of code and attached log for the same .
Log file :
2022-05-15 12:05:23 +0000 startLogging
2022-05-15 12:05:23 +0000 startLogging Time 1652616323.901923 is Optional("F2:E4:F0:07:57:5C")
2022-05-15 12:05:23 +0000 selectedScaleValue 3 selectedFrequencyValue 200.0
2022-05-15 12:05:34 +0000 stopLoggingFor d0f1b82b-f4ce-4ab2-9c14-0322e9e8385b/1b03009f-87c4-4e7f-81f6-01591896575e/test_51520225:35:23PM.txt
2022-05-15 12:05:34 +0000 stopLogging called
2022-05-15 12:05:36 +0000 stopLogging Time 1652616336.591401 is Optional("F2:E4:F0:07:57:5C")
2022-05-15 12:05:36 +0000 acceleration logger not found
2022-05-15 12:05:36 +0000 hideHUD called
Hey @Srinivasa, for now we are just accepting that since we updated to the BLE5 stack, the default conn speeds are simply slower. Unfortunately that is not something our devices can control.
Hi Laura/Matt,
Matt previously demonstrated in Windows10 machine via 'some quick tests ' that v1.7.3 is 1.5x faster than v1.4.5. Srinivasa also replicated Matt's test and confirmed that v1.7.3 is 1.5x faster than v1.4.5 in Windows device.
But, when Srinivasa did the similar simple testing in iOS device (target device), v1.7.3 is 1.5x slower than v1.4.5. So, strangely, iOS device seems to show the opposite trend from Windows device in the communication speed.
Do you think if it is possible that the iOS device is showing opposite trend from WIndows device in the communication speed?
So, would it be possible for you to make the similar testing on iOS device too as the one that Matt did on Windows device earlier? This will confirm that iOS and Windows devices are showing opposite trend in the communication speed.
I thought that it may be useful to Mbient too to be aware the opposite communication speed trend in iOS and Windows, if confirmed.
We appreciate your excellent support.