CC2530: Is it possible to bypass Tx/Rx calibration?

It is possible to override the calibration itself using the FSCAL2 register. However this does not remove the 192 µs delay during TX and RX startup. There is no mechanism to speed up automatic TX/RX switching or RX/TX switching. This is hard coded to 192 µs.

For unidirectional communication (no ACK, data only in one direction), there is one trick I could think of (this is really a hack, and I have not tried it myself):

In RX the state machine will jump rigth back to RX without any delay if you set FSMCTRL.RX2RX_TIME_OFF = 0, giving back to back RX operation. On the TX side set FRMCTRL0.TX_MODE = 10. This will make the state machine read the txfifo over and over. If one then after tx of the first packet has started to write the next packet in the txfifo (must inclyde preamble and sync word in the fifo for the following packets) the transmitter will start transmitting the next packet right after the first packet has finished. The TXFIRST_PTR can be read to control where the read pointer is so one does not overwrite any txdata not yet sent. One must access the TX FIFO memory space directly via the XREG memory space, not though the RFD register. CRC will not be generated properly so it must be calculated by SW and put in the TXFIFO as well.

The RX device will probably miss the first premble byte, but this should not cause any problems, if it does, one can add more preamble bytes in the TXFIFO. The CRC should be calculated correctly on the RX side.

You loose the automatic acknowledgements by doing this, so this must be done by the application. I suspect that all the extra involvement from SW to make the above described hack to work could quite easily cancel out the 4% power save though.......

Thank you for the suggestion with TX_MODE, I guess any similar mechanism with stuffing packets (along with preamble/sfd/crc) as a part of a bigger packet, sent at once, would also do the trick. The "4%" figure is for 128-byte packets, for 16-byte packets the power saving would be almost 20%. I will dig more in this direction.

As for Rx, since you mentioned it, would it be possible to enter Rx mode and then (!!) change the frequency, if I want to switch a channel? Let's say I'm interested in doing a quick scan across 16 channels and stay on each channel for ~1msec to try detecting SFD. Normally it involves going between idle<->Rx states, with SW and calibration overhead. What if, instead, I were to enter Rx mode and then start changing channels by directly writing FREQ+VCO_CAPARR[] values to switch the channel? This is ~15% projected power savings, with similar SW overhead for changing a channel. Do you see any issues with it, like out-of-band emissions (while changing FREQ+VCO_CAPARR[]), or radio state machine going crazy (will flushing RX FIFO take care of this)? Are there any other registers which need to be updated for changing the channel?

It is possible to change the frequency while in receive as you state, but it will affect the stability of the synthesizer and possibly loss of lock in the pll. The state machine does not know anything about the programmed frequency, so it will not be affected by this.