• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 974 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: Sensortag: Sampling Frequency Problems at 100Hz

Alejandra Gomez
Intellectual 670 points
Part Number: CC2650

Hi, 

I'm using the CC2650 Sensortag to acquire movement data 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 


Conversely I developed an Android App to acquire the data, based on the SensorTag App. 


I started doing some tests, and I found a strange behavior of the sampling frequency, it normally acquires at 100Hz but sometimes the frequency goes down to 30Hz. 

After this I modified my App in order to start/stop an acquisition every minute for one hour, in order to asses the frequency behavior of each acquisition. 
Attached is a figure with the mean acquisition frequency, over the several acquisitions. In which it can be seen how the frequency falls to 30Hz and at some point rises again to 100Hz. 

After seeing this, I used the Packet Sniffer to see if there where any differences in the transmission itself in terms of extra packets or something similar. But there are none, the only difference can be seen in the following figure, and is the time difference between successive data-carrying packets.

In the figure, you can see the Acquisition Time Difference (from CC2650 Timestamps) and the Transmission Time Difference (from Sniffer Timestamps) when the mean sampling frequency is 100Hz, and when the mean sampling frequency is 55Hz (in this case, it is possible to see how around the sample 25 the frequency drops to 30Hz - yellow-). 


I have considered elements as the battery charge, the timestamps (they were originally added from the app and now the come from the SensorTag itself), and the app itself. But I don't seem to find an explanation to this behavior nor a solution. I find it very strange, but now I'm guessing is a problem of the device itself or the data transmission. 

Any ideas on why this is happening? Or any suggestions on how to fix this?


Thanks in advanced, 
Alejandra 

  • 0
    TI__Guru** 106705 points
    Hi Alejandra,

    It is not really clear what you are showing in the last plots. You should anyway debug the application code on the CC2650 to try to figure this out.

    Regards,
    Fredrik
  • 0 in reply to Fredrik K
    Intellectual 670 points

    Thanks for your reply Fredrik, 

    How do you suggest me to debug the application code, considering that the frequency behavior is completely random and I cannot predict when will it happen?

    Also, what is not clear for you from the plots?

    Maybe I can clarify them for you so we can try to be on the same page here.

    Thanks,
    Alejandra

  • 0 in reply to Alejandra Gomez
    TI__Guru** 106705 points
    Hi Alejandra,

    I would start looking at the I2C communication between the motion sensor and the CC2650. And then perhaps look into whether the CC2650 actually receives and handles the data from the sensor. You need to figure out if this is a sensor problem or a CC2650 SW problem.

    Also keep in mind that the SensorTag is a demonstration platform, not a fully supported end product.

    Regards,
    Fredrik
  • 0 in reply to Fredrik K
    Intellectual 670 points
    Hi Fredrik,

    I'm trying to debug the application code, as you suggested.

    To do this I modified the optimization level of the sensortag_app project to 1 (I was not able to build the project with OFF or 0).

    Now I'm trying to look at the I2C Communication, and I was wondering if you could guide me through.


    I started to analyze the files SensorI2c. and SensorMpu9250.c, and some of the functions within, hoping I'm in the right path. But I'm not quite used to working with this, and I don't know what to look for on the debug variables, or where to set my breakpoints.


    Thanks in advance,

    Alejandra
  • 0 in reply to Alejandra Gomez
    Intellectual 670 points
    Hi Fredrik,

    I'm still trying to debug the application code, I have been reading about I2C, the possible reasons for missing Acknowledgment, and slow transmissions, and I think I found the movement sensor address (1001000) but I'm still quite lost, and I'm not sure what should I look for in the code itself.

    Any chance you could guide me through this?

    Best,
    Alejandra
  • 0 in reply to Alejandra Gomez
    TI__Guru** 106705 points
    Hi Alejandra,

    I would use a logic analyzer and start off by looking at the I2C communication. Is it as expected?

    Regards,
    Fredrik
  • 0 in reply to Fredrik K
    Intellectual 670 points
    Hi Fredrik,

    I don't have a logic analyzer, and right now is not super easy for me to get one. I only have the device (CC2650), the DevKit, and the USB Dongle to use with the Packet Sniffer.

    Is there any way to work around this without it?

    Or are there any other ways for me to try to figure this out with what I have?


    I'm sorry for the super general questions, but I'm very interested in understanding this behaviour.


    Thanks,
    Alejandra
  • 0 in reply to Alejandra Gomez
    TI__Guru** 106705 points
    Hi Alejandra,

    You are probably stressing something in the system beyond what it is capable of. It could be the sensor sampling, it could be that your I2C task is being de-prioritized over BLE tasks. It is difficult to say without proper debugging.

    You could try to make a bare-bone example without BLE which dumps the sensor data to a terminal through UART and see how that goes.

    Regards,
    Fredrik