• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 54 subscribers
  • Views 1582 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2541 / Sensortag

1886332
Expert 1325 points
Other Parts Discussed in Thread: CC2541

Hi,

How can I alter attributes of the Accelerometer and the Gyro included in your BLE cc2541 Sensor Tag board by using the Iphone and the Android smartphones following download of the application software.

For the cc2541 SensorTag, Using the Smartphone, how do I set the Cutoff frequency of the Accelerometer to 5 Hz and 
its sensitivity to 2 G; also how do I set the sensitivity of the Gyro to 1000 degrees per sec. and its cutoff frequency to 10 Hz?

Is it possible?

Thanks.
  • 0
    TI__Expert 4565 points

    You will need to create new characteristics within the accelerometer and gyro services that represent the values you want to be able to manipulate via the BLE link. Take a look at an already existing characteristic "sensorPeriod" in accelerometerservice.c. You'll see the value is readable/writable and if it is written to there is a call back function sensor_WriteAttrCB() that is invoked whenever the value has been written to.

    If you go to the call back function you will notice that there are some simple checks and then the variable is updated. At the end of this function sensor_AppCBs->pfnSensorChange() is invoked. This again is a function pointer that is set to call accelChnageCB() (function pointer is set within Accel_RegisterAppCBs() called in SensorTag.c). In this case the sampling period of sensor is adjusted but for your application you will probabaly need to write SPI/I2C commands here to the actual sensors to adjust their sensitivity/cutoff freq/etc.

    The commands to be written to the sensors should be in their data sheet but this is a brief overview of the SW flow for how your app would response to a phone writing to its attributes. You can also check out the sensortag wiki here: http://processors.wiki.ti.com/index.php/SensorTag_User_Guide#Accelerometer_2, which has some good information as well as links/descriptions of all of the included sensors.

    -Matt

  • 0 in reply to _mk
    Prodigy 10 points

    Thanks Matt for your prompt reply. Will try your leads. HW

  • 0
    TI__Guru 56590 points

    BTW, there is more SW related to the sensortag here:

    http://www.ti.com/tool/sensortag-sw

  • 0 in reply to _mk
    Prodigy 70 points

    Dear Matthew -

    Thank you for a piece of callback process description.

    As I understand you for a sensor we have basic callbacks sensor_WriteAttrCB() and sensor_ReadAttrCB. They are invoked when some values written to or read from

    Who invokes these callbacks, who is the caller?

    Sorry, I am fresh in the field, and maybe asking a question too obvious for everybody here.

    We are trying to develop BLE sensor module with our own sensors.

    Dmitry

  • 0 in reply to Dmitry Kostorev
    TI__Expert 4565 points

    Hey Dmitry,

    We deliver a large portion of the stack as a precompiled library and not source code so that's why you can't trace back through where these call backs are being invoked. I'll try to give a brief run down on what is happening with these call backs.

    There is a good intro to BLE here, http://mbientlab.com/blog/bluetooth-low-energy-introduction/, in case I start talking in gibberish. So for every service in the sensorTag (magnetometer, accelerometer, etc.) a set of attributes that are defined to be included in that service. These attributes are the basic building blocks of your GATT server (in this case your sensorTag device). The client, which in this case is probably your phone with a sensorTag app, will send requests to this server to either read or write these attributes.

    Before these services can be used they actually need to be registered with the GATT server so that it can define handles for each attribute. Once it's registered it will be in the GATT database and will be searchable from any GATT clients. The GATT server will handle all incoming requests for interacting with any fields of database/server, however the GATT server doesn't really care about the implementation of any of its services. That's where the call backs come in. The GATT server will determine which attributes are being written/read and then invoke those call back functions to allow the service to handle the actual changes to the state of the attribute. For instance, the service knows the permissions of certain attributes and also lengths of attributes so it can determine whether the read/write is legal and update the value.

    Also your application will probably want to take action based on updated characteristic values. If you sensor sample period is updated then the application will need to actually change it's sampling rate of that sensor. That's where you'll see the invokation of your application call backs (at the end of the service call backs) to notify the application which characteristic was changed.

    -Matt

  • 0 in reply to _mk
    Prodigy 70 points

    Dear Matthew,

    Sorry, I am a bit late with my Thanks. Thank you, great explanation. One of the best I have seen. 

    By the way, what if we are not adding a new sensor, but just replacing it with a similar one, let us say replacing acc with another acc. 

    What have we to do in this case?

    As I understand we are to make correction into that sensor register map in hal_acc, slave address, WHOAMI. 

    As I also understand in such case we can use already existing GATT UUIDs of a sensor to be replaced. 

    What else? Do I forget anything?

    Thank you in advance. 

  • 0 in reply to Dmitry Kostorev
    TI__Expert 4565 points

    Hey Dmitry,

    You will need to create/update the hal file for whichever sensor you add/replace to include the sensor specific registers, addr, etc.If you provide the same Hal APIs for interacting with the sensor you should be fine to reuse all of the other existing code. It's really only rewriting HalAccInit(), HalAccRead(), and HalAccSetRange(). If you can't rewrite them exactly then you may need to make some modifications to application code.

    -Matt

  • 0 in reply to _mk
    Prodigy 70 points

    Matthew, Hi -

    It seems to be working now. Great! Thank you again. 

    By the way, I am trying to increase acc Resolution from 1-byte per axis to 2-byte per axis. 

    But as I understood it is only in 1-byte array that we can transfer data from server to client. If it is like that it means that it would be the most optimal solution to process all the data on the level of the client starting from converting 1-byte data type into 2-bytes data type, in no reasonable way on the level of the server. 

    As I understant that is the way developers usually do it. Correct?

    Sorry for getting a bit off the thread. 

    Dmitry

  • 0 in reply to Dmitry Kostorev
    TI__Expert 4565 points

    Hey Dimitry,

    You can transfer up to 20 bytes of data within one BLE packet currently on our devices so you can easily increase the size of the sensordata array in the accel service to 6 bytes instead of its current 3. Just a further bit of info, you can even have attribute values greater than 20 bytes but you will have to use read blob requests to break the data up over multiple packets.

    You will need to change your HalAccRead though to give you 2 byte values for accel data and define the sensorData array as a 6 byte value and that should be all you will need to change on the server side.

    -Matt