I can see on the oscilliscope that ListenResolIdle and ListenCoefIdle actually do control how long Listen-Mode's idle period lasts, but I'm starting to get the impression that the values set for ListenResolRx and ListenCoefRx are irrelevant.
That's correct. It's the misunderstanding just about anybody using listen mode seems to run into. The RX parameters control how long the radio looks for a signal (RSSI > Threshold) before deciding whether to go into RX. They can be much smaller than the duration of a whole packet. When the radio has switched into RX the timeout parameters control the size of the window.
When you said "the RX parameters" just then, were you referring to the two parameters ListenResolRx and ListenCoefRx and only those two parameters? I ask because the impression I'm starting to form (though I haven't yet collected enough data to confirm it) is that when the radio is looking for a signal (RSSI >= Threshold), it already is in Rx (and what I mean by that is that it is already consuming 16mA). It's just that if (RSSI < Threshold) for a duration of TimeoutRxStart, then it can exit Rx early and commence Listen-Mode's idle period. i.e. it's starting to look to me as though
the values of ListenResolRx and ListenCoefRx actually never get used for anything at all, which if true seems rather bizarre. I may be jumping the gun in saying that, though. Can you think of any scenarios where the particular values those variables are set to changes anything in any way?
Maybe instead of Rx, I should be calling it something like "the 16mA phase," which is when Rx and Rx related things seems to happen. After the idle phase but prior to "the 16mA phase", the current ramps pretty rapidly as the Rx apparatus gets fired up and allowed to settle.
Except wait. [Figurative lightbulb illuminates]. Now that I think of it, I've so far only tested with TimeoutRxStart = 0 (the default), so maybe there can exist a lower current phase that preceeds the 16mA phase when the RFM69 is just checking for whether RSSI has ever reached the threshhold. That could be a match for what you're saying is happening. With the default setting of zero for TimeoutRxStart that phase, if it exists, would be getting skipped over entirely. So, thanks for the tip: I'll try adding a large TimeoutRxStart to one of the next scope captures and see if the RFM69 shows a different pattern of current draw. If ListenResolRx and ListenCoefRx only relate to that earlier RSSI phase, as you seem to be saying, then my having had TimeoutRxStart set to the default of zero would explain why ListenResolRx and ListenCoefRx have so far seemed like useless settings.