begin() is slow #1752
Replies: 6 comments 4 replies
|
In general I don't see a practical way to switch the modems this fast. Experiments in the past showed that the only reliable way to switch between LoRa and FSK is to perform a full re-initialization, so there is not much that can be skipped. Additionally RadioLib was not optimized toward minimum number of SPI transactions, so for example, on SX126x the same configuration command is performed multiple times corresponding to the different configuration steps in the begin method. But reworking this would be a complete change to the itnernal logic as it would require doing something like saving changes locally and only "committing" them by SPI commands at dedicated points. That seems to be too much trouble for something that most of the users do not care about. On a side note, I don't know your application but it seems to me you are trying to fit a square peg into a round hole. If you really need to switch the mode this fast, why not use an SDR or multiple dedicated receivers? |
|
Thanks. I don't have a good feel for where most of that time is spent. How slow are the SPI transactions? In my code I tried a begin() followed with several config calls, e.g.: |
Depends on the SPI clock speed you are using. The default is 2 MHz, so some performance could be gained just by increasing that. See the Wiki page about SPI, something like 8 MHz should be supported by all the radio modules (though you should check the datasheets for that). |
|
As for the pegs and the holes, I'm working on an application that runs on small battery powered devices carried in unpowered aircraft. Thus an SDR plus an RPi or something is too big and power hungry. It is nice if the thing can communicate in 2 (or 3) different protocols, with suitable time slicing, since there is diversity in what other aircraft send and listen to. Most of these protocols use FSK, so maybe I can avoid the begin() and just change the other parameters (bitrate, bandwidth, etc). But the interesting case is the one protocol that uses LORA, time-sliced with an FSK protocol. If it has to take 40 ms, that would still work, but if I can cut the transition down to 10 ms that would be better. |
|
Still seems like using two receivers (one for FSK, one for LoRa) would be easier, but as always it's a tradeoff: in your case between battery size/mass and overall complexity, and the performance/number of missed packets. |
|
More measurements show that, for SX127x::begin(), the bulk of the run time (about 30 ms) is in this first part: // set module properties Why would those be so slow, and can they be skipped in later calls? The exact same 3 lines are at the start of SX127x::beginFSK(). The Module init() does: And ArduinoHal::init() does: On the face of it I don't see any reason to re-do any of that? |
That is pretty unexpected, because assuming you are using Arduino, the only thing that gets called there is However, there's a workaround. If you go to the wiki page I linked above and create the module class instance in the way that's described there, it will not attempt to automatically initialize the SPI and leave it up to you to do. So you can choose to only do it once, you can try if that helps reduce the startup time. |
|
I'm already using that alternative Module creator: mod = new Module(nss, irq, rst, busy, RadioSPI); I see in ArduinoHal::init() it calls spiBegin() only if(initInterface) which should be false in that case. But it's still slow, I don't see why. I'll try and skip the "set module properties" part of the begin() (except the first time) and see if it works better (or at all :-). |
|
I wonder how much of the time spent in init() is actually just to print this out (to USB-serial at 38400 baud): [22.870569] RLB_DBG: since I have basic debug output turned on, and the module init() calls RADIOLIB_DEBUG_BASIC_PRINTLN(RADIOLIB_INFO). (That time "19:09:26" does not change so it's presumably set at compile time.) But I would have thought the serial output goes into a buffer and does not block? |
|
Serial is not synchronous but very much (semi-)blocking. So give it a go without the debug printing and you'll likely see improvements. |
Uh oh!
There was an error while loading. Please reload this page.
In my application I need to switch between radio protocols often, can be 3 times in a second. Sometimes the switch requires switching between LORA and FSK modes. It seems the only way to do that is via begin() and beginFSK(). The setModem() function actually calls those implicitly. The time it takes to run begin() or beginFSK() is significant, anywhere from 8 to 40 ms. When called 3 times in the same second it may mean losing up to 120 ms that could have been used for listening to incoming packets. I.e., it degrades the reception performance, as some packets will be missed. A friend working with the LR1110 saw even longer times to run begin() on that module. Is there a way to make begin() complete faster? I am talking about the case when I've already detected the presence and type of the radio module, and set up it for initial operation. Still, some things need to be re-setup. But probing the module for the chip version, doing a full reset, or (perhaps) calibrating things, is not needed each time. I tried arranging for skipping the probe and reset on the sx1276, and it seemed to make no significant difference in the run time of begin() and beginFSK(). The right solution may differ between module types. My target modules are sx1276, sx1262, LR1110 and LR2021. Thanks.
All reactions