• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 463 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.

CCS/CC1352R: DMM policies documentation

Angel C
Intellectual 360 points

Part Number: CC1352R

Tool/software: Code Composer Studio

Dear Support,

I have been working lately in a DMM application with BLE and SubGHz interfaces. I used the dmm_wsnnode_ble_sp_app as starting point (SDK 4.30) and also checked available documentation regarding DMM and its integration to the project. However, it is still confusing how some things are done.

I understand the DMM uses the GPT and optionally the application policy table defined in syscfg. I suppose I can tweak the default tables and add different application states to basically control the DMM scheduling adding weights dynamically. I have tested this and it seems to work, so I keep it as an option. However, I find it more adequate to modify the GPT and leave the application policy table for exceptions (like OAD in the example).

For this, I still have not found in the documentation how the .appliedActivity is linked to any of those activities defined in the policy file (e.g. dmm_priority_ble_wsn.c). The DMMPOLICY_APPLIED_ACTIVITY_XXXX constants seem to be a simple bitmask, but it is not clear if those correspond to the activities listed in GPT or how are they linked (This will help developers to link custom activities for instance). SDK Examples often use the DMMPOLICY_APPLIED_ACTIVITY_BLE_CONNECTION with no alter to the constant value, which makes me think it is kind of a bitmask. Could you please shed a light on this?

Furthermore, modifying the GPT and increasing the normal priorities of SUGBHZ activities besides de BLE advertisements (as explained in Dynamic Multi-protocol Manager Integration) it seems advertisements are not being scheduled. Modifying the application policy table to apply an extra weight and find out the causing activity, it turns that advertisements have more priority only when the policy sets .appliedActivity to ALL or DMMPOLICY_APPLIED_ACTIVITY_BLE_LINK_EST.

I am simply using a commercial iOS app to see the advertising intervals, not really connecting. Is responding to scan requests already considered as an “establishing connection” state? Or is there a mismatch between those DMMPOLICY_APPLIED_ACTIVITY constant values  and the actual activities? Is there any information available regarding this application states transitions for a ble peripheral? The source code only exposes the application-level activities e.g. CONNECTED or ADV.

I hope I was clear enough, maybe I am missing something simple here. Any ideas would be helpful. Thanks in advance.

Best Regards,

Angel

  • 0
    TI__Guru* 87971 points

    Hi

    I will have someone looking into this for you.

    BR

    Siri

  • 0 in reply to Siri
    TI__Guru 58425 points

    Hi Angel,

    You seem to have the correct understanding on how to best leverage the GPT and Policy Table, lets see if I could potentially spread some light on the remaining grey spots :)

    For this, I still have not found in the documentation how the .appliedActivity is linked to any of those activities defined in the policy file (e.g. dmm_priority_ble_wsn.c). The DMMPOLICY_APPLIED_ACTIVITY_XXXX constants seem to be a simple bitmask, but it is not clear if those correspond to the activities listed in GPT or how are they linked (This will help developers to link custom activities for instance). SDK Examples often use the DMMPOLICY_APPLIED_ACTIVITY_BLE_CONNECTION with no alter to the constant value, which makes me think it is kind of a bitmask. Could you please shed a light on this?

    It could be that this is a bit unclear, I will try to look over and make it more clear in the future. The mapping here is down to the GPT order. Take BLE as an example, the GPT is ordered connection -> link establishment -> broadcasting -> observing. The bitmap map to this as the bitmask offset. So basically. If you use "DMMPOLICY_APPLIED_ACTIVITY_BLE_LINK_EST" it applies to the second activity in the GPT which if ordered correctly is the "link establishment" activity. Note that each activity is in groups of three.

    As for the usage of DMMPOLICY_APPLIED_ACTIVITY_BLE_CONNECTION without modifying the value, could you shar where you see this? The examples I look at often use 25 as an offset in the policy in combination with this activity.

    Furthermore, modifying the GPT and increasing the normal priorities of SUGBHZ activities besides de BLE advertisements (as explained in Dynamic Multi-protocol Manager Integration) it seems advertisements are not being scheduled. Modifying the application policy table to apply an extra weight and find out the causing activity, it turns that advertisements have more priority only when the policy sets .appliedActivity to ALL or DMMPOLICY_APPLIED_ACTIVITY_BLE_LINK_EST.


    This is likely due to the type of advertisements you are using. It is in the pipe-line to add in a explanation of what the different stack states means in more detail but for advertisements for example, they are either a "LINK_EST" or "BROADCASTING" activity depending on if it is connectable or not. If the advertisement is not connectable it falls under the the "BROACASTING" activity otherwise it is the "LINK_EST" activity. 

    Simply put, it is somewhere along the lines of:

    Connection -> connection data exchanges, for instances connection events

    Link Establishment -> Any event related to the establishment of the BLE connection

    Broadcast -> Non connection related events, for example scannable only advertisements

    Observing -> Observing only events, for example scan events

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Intellectual 360 points

    Dear M-W,

    You nailed it, that clarifies many things and confirms my suspicions. It makes sense now that the connectable advertisements are part of the LINK_EST activity. Maybe having this clarification somewhere in code or the documentation will help to make it clearer as you mentioned. Same for BLE stack activities and their transitions.

    With DMMPOLICY_APPLIED_ACTIVITY_BLE_CONNECTION I meant that it was not clear to me how this was linked to the connected activity, now with the bitmask explanation it does.

    Thanks for your time and help.

    Best Regards,

    Angel