CC1352R: BLE Scanning during quiet times of sub 1GHz prop radio activity

Perhaps this kind of case is what was envisioned for DMMPolicy_StackRole_reserved1 and DMMPolicy_StackRole_reserved2, one each for my kinda-dual-role and sub-1GHz stacks?

My central needs are for scanning only -- I can give the BLE priority for that when I want to scan. When being a GATT server (peripheral) though, I definitely need to give priority to my sub-1G.

I'll readily admit that my BLE knowledge is limited. That said, I thought BLE ran transactions at intervals: if the participants miss their appointment, the transaction is retried again next interval. Isn't that what slave latency and supervisory timeout are about? My system can definitely tolerate delayed service of BLE notifications or attribute reads (such as when sub-1G is running) as long as they get through eventually. My sub-1G protocol has idle times (from a few to a few hundred ms in duration, variously, with guaranteed windows at least one per 205ms) which I was hoping I could use for BLE activity on the CC1352R. My theory was that if I set the BLE connection interval to a few ms and let the latency (number of missed connections) be high, it would all work out. No?

Remember, I don't need full central capabilities - just scanning for beacons intermittently. Otherwise, my 1352's BLE role is that of peripheral.

Hi Daniel,
You are correct about the data being retransmitted, if it doesn't get through. However, missed connection events causes breaks in the synchronisation if you do not allow the Link Layer to run and calculate the next connection event.

Joakim,

     I see. Thank you. Does this mean the BT stack is not capable of being suspended for multiple connection interval periods and then correctly scheduling its NEXT one when it is restored? I was hoping I could run in the following model: Let's say I have the BT connection params set to a Connection Interval of 2ms and the timeout set to 500ms. My proprietary sub-1G stack has, for the sake of example, intermittent work to do over a 300ms window. I thought the remote BT endpoint would try - and fail - to rendezvous with my embedded target every 2ms during the 300ms my target was busy using its proprietary stack. Then, when my target was free to do BT, it would release the BT stack which, I had hoped, would look at the system time, realize it had missed 150 connection intervals (at 2ms each), compute the next connection time, and actually meet the remote endpoint for a successful rendezvous at the appropriate point in phase with the established 2ms cycle. Is this not possible?

     Thinking about it further, if the BT stack needs to run to keep time but I need my sub-1G to dominate for 300ms, I should be able to tell the DMM that my sub-1G has priority such that the BT stack's RF activity would just get dropped by the DMM during the sub-1G busy window -- the key difference being the BT stack got to run and thus keep up with its scheduling. As long as the DMM actually prohibited the BT stack's RF activity from getting through during the sub-1G busy window (even when my proprietary stack had no RF commands submitted to the RF module), that would be enough to achieve my desired results. What's critical here is that my proprietary sub-1G may be technically idle for some of that 300ms window, though it needs to retain control of the RF module for performance reasons. Or at least I think it does. Maybe I'm not thinking about this the right way. As long as my stack had priority at the DMM, it would simply disrupt the BT RF activity if/as needed and the BT stack would do what it had to do to recover, with processing time available always and RF access sometimes. Do I understand correctly? That could work for my application. Thanks for your patience as I come up to speed on this.

    In that case, my question shifts to best practices. Does the DMM consider the radio to be locked to a task (stack) for the entire interval between RF_open() and RF_close(), or is it finer-grained than that? I'm trying to understand what consistency protections I need to employ to ensure my proprietary protocol can coexist with the BT stack doing RF transactions during my proprietary stack's idle times.