Think I introduced a bug with Promiscuous (requireCarrierSense) when used with directMode

[Crsarmv7l]

Last night when conducting some in depth experiments I noticed if I had Promiscuous(true, true) with requireCarrierSense= true enabled, and directSyncWord(0, 0), rx signals would be returned up to a certain point (varies based on the buffer size) but all eventually stopped returning.

This is not a crash as I can exit my rx loop within the compiled program and still use the radio and rx/tx/continue on.

I initially thought it was the CC1101 carrierSense adjusting to my continued transmissions (that I was attempting to receive) but no amount of time results in signals being returned after ceasing transmissions.

When using Promiscuous(true, false) with requireCarrierSense =false, directSyncWord(0, 0), rx signals are returned as expected for as long as desired.

My current thinking is that it is related to the directBuffer, as with directSyncWord (0, 0) we always have sync and with directMode we are reading the pin based only on the cc1101 clock. With carrierSense additionally enabled, signals are only provided to the pin if above the threshold. So maybe it is overflowing the buffer or not resetting the Read/Write position? I am a bit at a loss with dealing with the buffer and carrierSense as I can't remember anything from the datasheet that could be added to the directBuffer to evaluate if gotSync and carrierSense above threshold then write to the buffer and there are no errors/crashes presented when this bug is triggered.

[jgromes]

Couple of things to try out - first, please post a minimum sketch needed to reproduce this problem, as well as the specification of your platform (ESP32, some Arduino etc.). This includes trying to localize the issue - does this really happen only when requireCarrierSense is enabled? Or is that just a coincidence?

Next, the debug mode - enable the protocol debug level and you will see writes to the direct buffer as those happen.

Finally, all of this information is called for by the issue template, for a good reason - it speeds up the debugging process immensely.

[Crsarmv7l]

Closing for now. Rebuilt on a different computer and all seems fine.