SX1261 & RP2040 SPI speed and timing limits #938
Replies: 11 comments 29 replies
-
I'm guessing that at some point you got a debug message like "GPIO pre-transfer timeout, is it connected?". That suggests you either have an issue in the BUSY pin connection (unlikely if it works at higher speeds), or your lower clock speed is interfering with time measurement in the RP2040 Arduino core. Otherwise you're basically suggesting that the SX126x is taking longer to de-assert its busy signal when host MCU has slower clock, which seems rather implausible.
Is that really the place where it's failing? That would be surprising, could you post the output with debug+verbose? I would expect calibration errors to appear very early in initialization. The device error is 0x20 - quick look in the SX126x datasheet/SX126x header shows that this is
All of those are platform-dependent questions; at the end of the day, RadioLib just calls |
Beta Was this translation helpful? Give feedback.
-
That's correct. I'm thinking also about time measurement issues but I didn't investigate further. All code works fine at 48 MHz system clock and 4 MHz SPI speed.
Yes. I added a debug output after RADIOLIB_ASSERT in SX126x::begin and the assert was triggered after setCodingRate.
Lowering the system clock but not touching the SPI clock results for example in garbage when querying RADIOLIB_SX126X_REG_VERSION_STRING, string not found at all or after several tries.
Nope. My testing was a quick try to see what is possible in terms of power reduction. Then run into the radio lib issues but was not investigating into deep. Not sure if I will track this down further. This is why I asked for experience to see if it makes sense or not. Thanks anyway for your feedback. |
Beta Was this translation helpful? Give feedback.
-
Don't get me wrong. I do not blame radio lib or expect something. My question was purely about experience, if someone already tried low speed setups maybe etc. Just information exchange. I will think about some more and get back into this. |
Beta Was this translation helpful? Give feedback.
-
following |
Beta Was this translation helpful? Give feedback.
-
Reducing the clock below a stable speed for SPI may well be a zero sum game as the Pico doesn't have any useful low power modes, so whilst you may save a few nJ by lowering the clock, the RP2040 doesn't appear to sleep at less than 1mA and most of your power on Meshtastic is burnt on Rx time anyway. It might be worth trying a board without radio to measure the standing current at the different clock levels. |
Beta Was this translation helpful? Give feedback.
-
Actual status: The problems with low sys clock are not caused by the SPI speed but the delay(ms) functions. I did some tests with delaying a GPIO toggle and monitoring with a o-scope. The delay(ms) in framework-arduino provides a stable and reproducible delay by given time. Also delayMicroseconds works fine. With such unstable an unreliable delay the RadioLib is not working stable, some functions not at all. Not blaming the RadioLib here, just facts. When solved the Meshtastic code may run with 10-15mA on the Pico at 18MHz. |
Beta Was this translation helpful? Give feedback.
-
The RadioLib may not fail directly but a returned status is maybe not as expected. The status byte has a command timeout flag that notes: One function that reproducible has problems with inaccurate delay is |
Beta Was this translation helpful? Give feedback.
-
So after endless fiddling with Meshtastic code and no success I stopped and took a different approach. Created a completely new platformio project for the Pico module, included just the radioLib. Took some code from the radioLib example "RadioLib/examples/SX126x/SX126x_Settings/SX126x_Settings.ino". I see the same problems with SX1262 initialization at low RP2040 sys clock. Chip detection and init fails <18 MHz. Chip found, but other init failures 18 MHz > sys_clock < 24 MHz. Successful init > 24 MHz. Still have no idea what the problem might be. This watchdog maybe? That's the code I am running on a Pico with Waveshare LoRa module attached:
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Woohoo!!! Awesome it works!!!
The solution is so simple! That's the code for above output:
|
Beta Was this translation helpful? Give feedback.
-
Meshtastic code is working!
|
Beta Was this translation helpful? Give feedback.
-
I'm working with code from the Meshtastics project on the RP2040 platform in combination with a Waveshare LoRa SX1261 module.
To improve/decrease power consumption I reduced the RP2040 system clock. While the RP2040 accepts frequencies down to 18 MHz everthing below 23 MHz fails to detect the SX1261 using this radio lib.
With some tweaking of SPI speed (500 kHz indstead of 4 MHz) and an increasing RADIOLIB_MODULE_SPI_TIMEOUT to avoid GPIO timeout errors I was able to archive at least a chip detection and some initialization.
However, the init then asserts in setCodingRate
resulting in
In general high SPI frequencies with lower system clock will result in SPI read errors and for example garbage in the above version string.
So my question:
Are there any experiences with how low the SPI can be clocked and/or timing can be lowered to make the SX1261 work?
Beta Was this translation helpful? Give feedback.
All reactions