›

Data stability

alextarragoalextarrago
in iOS

Good evening, we've changed to the new 3.0 SDK and the transmission of the sensor fusion data seems to be unstable. After a couple of seconds (or minutes, it's kind of random) the data stops transmitting to the mbl_mw_datasignal_subscribe method. Is there any other config we're missing? We've checked all the information provided by the documentation, both iOS and CPP. Thanks.

Comments

  • EricEric
    edited September 2018

    Does the same behavior occur when using the MetaBase app?

    Post the relevant portions of your code so we can see if anything is wrong with your SDK usage.

  • alextarragoalextarrago

    Thanks Eric for the fast reply.
    We will try today if the MetBase app has the same behaviour.
    In the meantime, here is the code we use for the actual data retrieving in iOS, please let me know if we are missing something.

            //Sensor Fusion SETUP
        mbl_mw_sensor_fusion_set_mode(self.currentDevice!.board, MBL_MW_SENSOR_FUSION_MODE_M4G)
        mbl_mw_sensor_fusion_set_acc_range(self.currentDevice!.board, MBL_MW_SENSOR_FUSION_ACC_RANGE_8G)
        mbl_mw_sensor_fusion_write_config(self.currentDevice!.board)

        // Actual Data retrieving request
        let linear_acc = mbl_mw_sensor_fusion_get_data_signal(self.currentDevice!.board, MBL_MW_SENSOR_FUSION_DATA_LINEAR_ACC)
        mbl_mw_datasignal_subscribe(linear_acc!, bridge(obj: self)) { (context, data) in
            let dataSignal = data!.pointee.valueAs() as MblMwCartesianFloat
            DispatchQueue.main.async{
                StateMachine.sharedInstance.newCandidate(value: (x: Double(dataSignal.x), y: Double(dataSignal.y), z: Double(dataSignal.z)))
            }
        }
        mbl_mw_sensor_fusion_enable_data(self.currentDevice!.board, MBL_MW_SENSOR_FUSION_DATA_LINEAR_ACC)
        mbl_mw_sensor_fusion_start(self.currentDevice!.board)
  • alextarragoalextarrago

    We've just checked with the Metawear app. We connected the app to a MetaMotionR and start streaming data.
    The first test stopped streaming data after 15 minutes of data transmission. The second test stopped after 20 minutes, and the last test was streaming data after 22 minutes.

  • EricEric

    Try changing the ble connection parameters after you have connected to the remote device:
    https://mbientlab.com/csdocs/0/advanced_features.html#high-frequency-streaming

    Do you experience the same issue when you were using the older releases? How about if you use another platform (Windows, Android)?

  • alextarragoalextarrago

    We've just added the method to change the BLE Connection params with the following command:

        mbl_mw_settings_set_connection_parameters(board, 7.5f, 7.5f, 0, 6000);

    However, after several minutes, the sensor stopped transmitting data...
    Yes, the same issue was present in the older Swift SDK. We are only using iOS for now, next week we'll start using Android devices as well, but we need to fix the data streaming stability first. We've used several MetaMotionR devices.

  • EricEric
    edited September 2018

    How are you using the device?

    Is the device simply disconnecting, or is it resetting / running out of power?

  • alextarragoalextarrago

    No, it just stop transmitting data, it is connected and everything seems to be fine. We've just found that this usually happens on a high BLE activity environment (such as an office with lots of wireless headphones, mouses, keyboards, ...), is this normal?

  • EricEric
    edited September 2018

    No, those other devices should not cause the reported behavior. It would make sense if the board lost connection but you say that is not the case.

    What are the firmware and hardware versions of the boards?

  • marieescmarieesc

    Hello Eric,

    My name is Marie Esclozas, I am the founder of the startup, B4Coach.

    To answer your questions, all the boards that we have been using for the different tests are with the 1.3.7 Firmware and the 0.3 Hardware. We do have two 0.2 Hardware, but we stopped using the when we realised that the boards had changed.

    To be more precise about our product, we have integrated the streaming of data from the tracker within our app to then analyse it with our own algorithm.

    At the beginning, the streaming was even more unstable, the board always stays connected, but it stops transmitting data, or at least the app stops receiving it. We have implemented different solutions recommended on the forum and the random "disconnections" were reduced, but not stopped.
    We used to start and stop the streaming between each exercise and now we keep it open and we changed the standard 100Hz to 80Hz, for example.

    We thought we were able to identify when this is happening in bluetooth troubled environment (or wireless connection in general), like our offices (a very crowded coworking space) or a gym at peak hour, but in both cases we have been proven otherwise with the problem happening in an empty room (with no pollution) or the problem not happening in a gym during peak hour (more than 30 people around with connected objects) for a long period of time (over 45min).
    I have all those test recorded with time and location.

    Has this problem ever happened to you or to some of your clients, where the tracker stays connected, but stops transmitting data? From what we have read from past discussions on the forum, we have not been able to find any of your clients with the same problem.

    Best regards,
    Marie

  • EricEric

    No, we have not encountered this specific issue. As I have previously asked:

    • Do you see these same issues if you are using an Android or another iOS device?

      • What iOS device(s) are you using in your tests?

    • Are you 100% sure that the device is still connected when it stops transmitting data?

    Additionally, what data are you streaming and how fast? Is it only linear acceleration?

  • marieescmarieesc

    Hello Eric,

    To answer your questions.
    Yes, we have been having this issue with both Android and iOS.

    For iOS, we have been testing it with Iphone5, Iphone5c, Iphone6, Iphone6s, and IphoneX. So far the only device that did not stop receiving data from the tracker is the IphoneX, but we did a very limited number of tests with it.

    For Android, we tested it with four models, Xiaomi Redmi Note 4, Xiaomi Redmi 5, Samsung Galaxy Core Duo (2014), and Motorola Moto G (1st gen). So far only the Moto G device has stopped receiving data from the tracker.

    The device is still connected to the phone when this situation happens. We have found that certain environment make the bluetooth connection less stable. This means that the sensor stops transmitting data more.

    The data that we are streaming is the sensor fusion with linear-acceleration with IMUPlus settings at a rate of 80Hz.

    If it would help, I can share a log of all the tests that we have done so far with each device and where. You might be able to see a pattern where we have not been able to identify one.

    Is there anything else that we change in the settings to stabilise the transmission of the data?

    Best regards,
    Marie

  • EricEric

    I have never had good BLE experiences with the Moto G, though in my case it was 2nd gen. The iPhone issues are interesting as we've always had good BLE performance with iOS devices (both phones and tablets). This does suggest however, that your mobile devices may have BT radio issues.

    Yes, share as much information as you can.

    You can try increasing the transmission power with mbl_mw_settings_set_tx_power.

  • marieescmarieesc

    Hello Eric,

    I would understand if one or devices had bluetooth connections problems, but not most of the iOS devices that we have tested on. We actually had the case of another Iphone6 (not included in those tests) that had a hardware damaged and could not stream music via bluetooth.

    We will implement and test a higher transmission power.

    I am attaching the full recording of the tests that we have done. The information that we are recording is the following:
    1. Date: to know when we have done the test
    2. Training completed: to know if the tracker transmitted data until the end of the test or if it stopped transmitting data before. Bug app and battery are other reasons why the tracker stopped, but not related to the data itself
    3. For how long?: For how long was the tracker transmitting data before stopping
    4. Where?: the location where the test was done. MOB refers to our offices, Dribba our developers (you will see that the connection stopped only once there, we don’t know why), our team’s different homes, and the rest are gyms all around Barcelona
    5. Phone: refers to the brand of the phones that we are using
    6. Tracker: the name of the different trackers to differentiate them (the problems seems to happen with every tracker without distinction)
    7. Test: to specify the type of test, if the test was done in parallel with other test (test 3) or just one tracker and one phone (Control) are most that we have done
    8. Column H: If the tracker stopped transmitting data at what point of training it stopped (this data seems to be random as well)
    9. Comments: any comment relevant to the test

    We will test the trackers with more devices tomorrow I will let you know what are the results.

    Let me know if you find any relevant patterns from the tests.

    Best regards,
    Marie

  • marieescmarieesc

    Hello Eric,

    We have started to test on a higher transmission power of 0.
    What was the default transmission power before? Also what does the 4 value mean in terms of transmitting data would that make it more stable?

    We have successfully caught "on camera" what is happening with the raw data from the tracker. It happened when I was moving around our coworking and I noticed that the data was “slowing down” when I went through a specific space (very crowded with people and a lot of devices) when walking back the data flow picked up at "regular" transmission speed again and if I tried to go across that area the data stopped completely.
    I am attaching the latest connectivity testing that we have done, but I can't seem to upload the video onto the platform. How can I share it to you?
    Would you be able to say what is causing this? The test was done on an Iphone7Plus directly from our app showing the raw data from the tracker.

    About the Moto G 1st and 2nd gen, do you know what makes it difficult of work with BLE? This could be the reason why other devices are not working and the sensor.

    Best regards,
    Marie

  • patricepatrice

    Hello Marie,

    Human body is mainly made of water, and water is very very hard to cross for 2.4GHz (wifi and bluetooth) ; this could explain why signal drops when you put your sensor in a very crowded space as signal is mainly absorbed, and cannot reflect enough on ground and walls.

    What is the distance between your iPhone and the sensor?

  • marieescmarieesc

    Hello Patrice,

    It is a good idea.

    The distance between the iPhone (or any device really) and the tracker is less than a meter long. We put the sensor on the left wrist and we either hold it in the same hand or with the right hand. I believe that bluetooth headphones and phones are further distanced than the way we use the sensor.

    We have tested the distance between the sensor and the different devices in crowded gyms and at up to 4-5m the data was stable and kept streaming, so I do not believe that the water would influence.

    It is definitely an environment problem, but we still have not identified how the environment impacts on the stability of the connection exactly.

    We also have examples of the sensor to stop streaming data in an empty room (both in our own offices and at the gyms).

    @Eric do you have an answer to my previous post?

    Best regards,
    Marie

  • EricEric

    @marieesc said:
    Hello Eric,

    We have started to test on a higher transmission power of 0.
    What was the default transmission power before? Also what does the 4 value mean in terms of transmitting data would that make it more stable?

    Higher values amplify signal strength

    We have successfully caught "on camera" what is happening with the raw data from the tracker. It happened when I was moving around our coworking and I noticed that the data was “slowing down” when I went through a specific space (very crowded with people and a lot of devices) when walking back the data flow picked up at "regular" transmission speed again and if I tried to go across that area the data stopped completely.

    Hrm, perhaps I can artificially replicate this slowing down effect. The main issue is that we don't have a reliable way to reproduce what you are seeing.

    I am attaching the latest connectivity testing that we have done, but I can't seem to upload the video onto the platform. How can I share it to you?

    Put it on a video sharing service, like YouTube.

    Would you be able to say what is causing this? The test was done on an Iphone7Plus directly from our app showing the raw data from the tracker.

    No, as previously stated, we have not encountered this specific Bluetooth LE issue.

    About the Moto G 1st and 2nd gen, do you know what makes it difficult of work with BLE? This could be the reason why other devices are not working and the sensor.

    No. My best guess is that it is some combination of BLE hardware and software.

This discussion has been closed.