Other Parts Discussed in Thread: CC1312R
I'm working on a proprietary RF frequency-hopping design multiplexed with BLE using the DMM API. While I think I have a decent grasp of how the DMM policies work and how the RF API works with immediate triggers, I am a bit uncertain about some of the timing / scheduling, particularly with regards to setting the frequency.
I've seen some previous discussion on the CC1312R regarding the frequency synthesizer command caching in the single-frequency case:
Here's my current interpretation of the proprietary RF API:
- The last CMD_FS command run on the handle will be implicitly applied before any CMD_PROP_TX / CMD_PROP_RX commands.
- If I provide an absolute start time, the RF API will take into account any settling time needed when turning on the frequency synthesizer such that the RX/TX command starts at the scheduled time
- In a single stack / no-DMM situation, I can chain the CMD_FS and CMD_PROP_TX together and run them in one command sequence and everything should work correctly.
In the multi-stack DMM situation, I'm not sure how I should be scheduling the CMD_FS and CMD_PROP_TX if I want to schedule the transmission with an absolute start time trigger so that it plays nice with the BLE stack.
Should I continue using one chained command? If I do, what is the correct way to fill in the timing information for RF_ScheduleCmdParams? Should I act as if the CMD_FS isn't there for the purposes of defining the activity and start time / duration / end time - or do I need to calculate the settling time myself and include that? Should I actually split up the CMD_FS and CMD_PROP_TX into two separate scheduled commands?