Replies: 1 comment 1 reply
-
The SPI speed determines mainly how fast you can fill or read the FIFO; the crystal on the radio module is primarily the source for its frequency synthetiser (which is what creates the hundreds of MHz of the RF carrier), and the MCU clock impacts how fast your MCU can process instructions.
There should be no such effect. The SPI is a synchronous interface, that's why it has a clock signal in the first place. Unlike asynchronous serial interfaces (such as UART) where the baud rate has to be known to both sides of the connection, exact frequency of the SPI clock doesn't actually matter, as long as you stay within the manufacturer-defined bounds (typically tens of MHz). You could set the SPI clock to 1234 Hz and it would still function perfectly OK, data is sampled according to the clock rising/falling edge. There's no need to align it with anything. What could be happening though is that the SPI is not fast enough to refill the FIFO. |
Beta Was this translation helpful? Give feedback.
-
Timing is a big deal with RF signals, so I am trying to understand how all the speeds above work together, which ones matter and the effects of adjusting them (outside of pure trial and error)
I got to thinking about this because my FIFO refills still sometimes invert the signal (AAAAA55555) part of the way through the signal. Pure guess but it maybe because I am not aligned with the clock ticks?
I went digging into the CC1111 which has a 12mhz 8501 mcu and a crystal that provides 24mhz clock.
Meanwhile arduino has my esp32 set at 240mhz, CC1101 has a 26mhz crystal, and the SPI transactions are currently the default 2mhz.
I suspect the ESP32 speed probably doesn't have much effect on the radio, and that it is mostly SPI speed and Crystal clock but obviously I don't know. Appreciate any insights.
(Plus underclocking the esp32 would be really nice for power savings)
Beta Was this translation helpful? Give feedback.
All reactions