• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 53 subscribers
  • Views 1213 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2650: acquisition frequency is not stable when frequency is set to 100 Hz

simone tonti
Prodigy 40 points
Part Number: CC2650
Other Parts Discussed in Thread: CC2540

Hi,

We are developing an acquisition system based on TI CC2650 connected to a smartphone through Bluetooth. As we need to track fast movement, we have recently modified the firmware of the sensor tag in order to boost the acquisition frequency up to 100 Hz. 

However, we have observed that the acquisition frequency is not stable within the different acquisitions and sometimes the sensor tag acquire the accelerometer and gyroscope signal to a very low frequency rate. To isolate the issue we have modified the firmware in order to receive directly the timestamp used by the TI CC2650 and we have developed a mobile application to perform a stress test. This Android app allows us to perform a series of 60 consecutive acquisitions which are 1 minute in length (1 hour test session). We have tried with several TI CC2650 tags and different smartphones but every time we observe a worsening of the acquisition frequency which is followed by the rearrangement of the frequency to the 100 Hz nominal frequency. In the image below you can see the registered behavior and the observed valley in the acquisition frequency value.

Have you ever see something like this before? What could cause it? As this analysis has been performed using the TI CC2650 original timestamp, it seems not an issue related to the mobile application or smartphone.

Thank you in advance for your help!

  • 0
    TI__Mastermind 39610 points
    Hi Simone,

    I don't think I can give you any good feedback because I don't really understand what exactly your question is or what you mean by acquisition frequency. What do you mean by acquisition?

    Are you asking something related to the BLE Stack or are you asking about your own application code?
  • 0 in reply to Evan W
    Prodigy 40 points

    The acquisition frequency is the frequency calculated on the basis of the timestamp of the sample acquired through the sensor. For the example above, the interval in ms between each accelerometer sample is used to calculate the average acquisition frequency within a one minute acquisition (our stress test protocol simulates several acquisition of 1 minutes however the same frequency issue can be observed with longer and nonconsecutive acquisitions in real life as well). The same behavior is observed if we use the gyroscope or barometer samples whose "acquisition frequency" is the same so it seems not a problem related to a specific sensor but to the whole platform.

    As the sensor parameters (i.e. SENSOR_DEFAULT_PERIOD) are set to 10 ms we are expecting that the average acquisition period is 10 ms. However this period sometime is bigger and thus the acquisition frequency (1/period) is smaller than 100 Hz. We are able to reproduce this behavior with different CC2650 sensor tags and different smartphones.

    It is not a problem of our application as we are using the timestamp generated by the sensor tag itself which is sent to our mobile application thanks to a FW modification of the sensortag. It seems a problem in the buffer management (if any) of the platform or in the communication protocol (because we don't know at which level the timestamp is generated by the sensortag!). By the way, the "acquisition frequency" is not always the same between different acquisitions (i.e. in 1 minutes at 100 Hz we are expecting to have 6000 samples from each sensor and instead sometimes the sensortag sends a smaller number of samples)

    I hope now it is more clear and that you can help me!

    Thank you.

  • 0 in reply to simone tonti
    Prodigy 40 points
    Is there anyone that can help me?
  • 0 in reply to simone tonti
    TI__Mastermind 39610 points
    Simone,

    I'm sorry, i still am having a very tough time based on your description of understanding what exactly the problem is that you are seeing and how it relates to BLE. Can you please explain more about what your application is doing, what you suspect may be happening and how this relates to BLE?

    Are you saying that throughput dips? If so, what is your PDU size, connection interval, etc?
  • 0 in reply to Evan W
    TI__Mastermind 39610 points
    I'm going to close this post due to inactivity. To reopen this thread, just post a follow up question. Otherwise, after 30-days of inactivity from this post, this thread will lock.
  • 0 in reply to Evan W
    TI__Mastermind 39610 points
    simone,

    If you wish to mark this as rejected, please provide more information to your problem.
  • 0 in reply to Evan W
    TI__Mastermind 39610 points
    Simone, any updates? Otherwise, I will have to close this thread, based on your description, we are having a hard time understanding how you relate your question to BLE. If you could provide more information about the settings in your application, how you're using the device, we may be able to help.
  • 0 in reply to Evan W
    TI__Mastermind 39610 points
    I'm going to close this post due to inactivity. To reopen this thread, just post a follow up question. Otherwise, after 30-days of inactivity from this post, this thread will lock.
  • 0 in reply to Evan W
    Prodigy 40 points
    It seems to be an issue of the CC2650 (and other Texas platforms) in the I2C serial protocol that negatively affects the performance at high frequency. We are trying to debug it since Texas is not able to provide a work-around or fix for it.

    Cheers
  • 0 in reply to simone tonti
    TI__Mastermind 39610 points

    Hi simone,

    Can you elaborate on what you mean by "and other texas instrument platforms"? 

    To give you some in put, we have two teams that support the Bluetooth Low Energy forums. One team covers the BLE Software Stack and anything around that. The other covers the functionality of the chip such as HW IP like I2C etc. I took this thread because I thought you had a BLE related question based on parts of your description. Now that it is clear that you are having issues with the I2C, i can give this thread to an appropriate representative that should be able to help more. We do need your help though in providing more details on what you mean by other TI platforms though please. 

  • 0 in reply to simone tonti
    TI__Mastermind 22976 points

    Hello Simone,

    I am representative of the HW team for this specific TI platform.

    As Evan said before it would be very useful for us to know more information about this problem in order to help you resolve your issue.

    Since I am coming to this thread for the first time, I would like to know a couple of things before I can provide you with additional help:

    1. SDK Version?
    2. Are you testing on CC2650 or CC264X?
    3. What board are you using, custom or one of our development boards?
    4. What sensor are you using, are there any other sensor on the same I2C bus?
    5. Are you using one of our examples, if so which one, and if not can you provide me the FW?
    6. Why and how have you isolated the problem to I2C, may we see some screenshots of the I2C trace?

    We would also like to know why you said you have problems with "and other texas instrument platforms". We would really like to help you and come to a resolution.

    Regards,

    AB

  • 0 in reply to AB
    Intellectual 670 points

    Hello AB, 

    I'm working on this with Simone. 

    Since we both are comming to this thread for the first time, I would describe to you what I've done so far: 

    I'm currently working with the CC2650 SensorTag (and its DevKit) in Code Composer Studio 8.2.0 and the BLE SDK 2_02_02_25. 

    I'm using the sensortag_cc2650 project with some modifications. 

    What I'm trying to do is acquire data from the Movement Sensor (MPU9250) at 100Hz. 

    To achieve this I modified the following sections of the firmware, setting them to 10ms:

    In st_util.h, SENSOR_MIN_UPDATE_PERIOD 

    In sensortag_mov.c, SENSOR_DEFAULT_PERIOD 

    Moreover, I'm using the timestamp module within the sensortag_mov.c to get a timestamp in milliseconds from the board. 

    I increased the MOVEMENT_DATA_LEN by two bytes (originally this was supposed to be four, but with four it becomes very problemmatic) and I'm assigning the timestamp into the last four bytes of the data characteristic. 

    As Simone mentioned we have developed an app that allows us to perform a series of 60 consecutive acquisitions, of 1 minute each. 

    We consider an acquisition to be the data we receive from the texas between START/STOP commands.

    Since each acquisition has a duration of 1 minute we expect to have ~6000 samples in each of them.

    The number of samples is our first approximation into determining the acquisition frequency, but since we also have the individual timestamps we use the mean time difference between successive timestamps as an indicator of the acquisition period and acquisition frequency.

    I have isolated the problem to I2C as a suggestion from a TI-Employee in another thread. 

    Moreover I've used the CC2540 USB Dongle and the PacketSniffer and by manually correlating each packet to the data acquired I was able to see that I'm not loosing  any data during the transmission. 


    I don't have the equipment to capture the I2C trace, so I haven't been able to go further. 


    Please let me now if the FW or the stress test .APK would be useful for you. 

    I'm not sure what Simone meant by "other texas platforms" we are mainly focusing on the CC2650. 

    Thanks in advance, 


    Alejandra

    :)

  • 0 in reply to AB
    Intellectual 670 points
    Hello AB!

    Any news?