My point is ... you can only receive when you listen.
So .. nice battery savings, but that also means you'd only receive an average of 1 out of 1000 packets sent to it, when you listen 1 out of 1000 units of time, right?
Notionally, yes, you have approximately the right idea. Not that it matters (well, at least to me), but technically the "on average" number would be closer to 1 out of 500 packets, if the transmission start time was random. If you were wanting to transfer a lot of data but only using listen mode to receive it at one packet a second, I would guess you would be worse off, because each waking of the arduino takes about 2.1ms of wasted current during warm-up on an 8mhz atmega328p and at least some time and current are lost in the process of going into PowerDown sleep. On the other hand, if the time between packets is normally greater than 2.1ms, maybe you wouldn't be worse off.... I'm not sure. Is anyone currently putting the arduino to sleep while waiting for the next packet when a train of packets is expected to arrive and then waking up "just in time" to process it? I'm not sure it would be worth the effort, but maybe. The big savings seem to happen from being in a deep sleep for a long time at the lowest current possible, and that tends to overshadow smaller optimizations.
I think a smaller Rx window could probably be achieved, which would be a desirable improvement for less wasted Rx current over time or reduced latency but the same cost in Rx current by having shorter cycles. How much smaller it could be I don't know. Actually, it's easy to shorten the Rx window--it's getting a non-continuous Tx cycle that's short enough to hit it reliably that gets harder. Right now when a proper packet is received at 200Kbps, DIO0 goes high 100 microseconds before the Rx current starts its fall to the idle current level, so with that as my only datapoint, I'm doubtful that an Rx current window of a mere 100uSec or less would be possible in Listen Mode. How much longer than 100uSec it would need to be, though, I'd be curious to know. On the other hand, the Rx windows just for detecting the start of a Tx could be less than 100uSec, provided that it can be "stretched" to wider by the timeouts when the start of a Tx is detected within that smaller window. 64uSec would be the absolute shortest limit that Listen Mode can be programmed for. @Joe and/or @Tom: are you already at the 64uSec limit?
At present I'm simply using sendFrame in a tight loop. To get less of a gap between Tx's, to hit smaller Rx windows every time, I'd need to open that up and optimize at a finer granularity within it to get a tighter gaps between packets but still remain non-continuous. Cutting the Rx window duration in half might not be too hard. I may wait, though, until I'm sure I have a definite need for that.