LORA and BLE definitely needs some work. There are some other things that need to be set correctly for this to work as well so it is not just the settle time. We have just started with the lora support and I suspect there will be a fair amount of changes to that code, especially getting both to work nicely together. I still have not fully figured out what changes I would want to make (to either stack) so that they coexisted nicely together.
When you say lora depends on having HFXO enabled, are you referring to the current implementation or making a more general statement? I do realize that the current implementation uses the HFXO but I am not aware of any particular reason that it would be required (assuming code changes were made). Will > On Sep 25, 2017, at 6:48 AM, Gordon Klaus <[email protected]> > wrote: > > It seems that NimBLE does not play well with some others. In particular, > when BLE_XTAL_SETTLE_TIME is non-zero, NimBLE turns off and on HFXO (the > nRF52 64 MHz crystal oscillator) as it sees fit. But LoRa depends on > having HFXO enabled. > > We see many failed LoRa join attempts as a result of the poor accuracy of > HFINT (the internal oscillator). Setting BLE_XTAL_SETTLE_TIME to zero > fixes the problem because it disables this HFCLK source toggling, but then > we lose the power savings of disabling HFXO. > > At the very least, this workaround should be documented. I can submit a PR. > > I guess there should be some management of this shared resource, so that it > is enabled while at least one client needs it. > > And maybe LoRa should also toggle HFXO, for power savings?
