I have seen the join fail at times but not very many consecutively. I have seen that fail at times with the lora stack (and no ble) as well so was not overly concerned at the time. I may also not have been up to date with all the latest nimble changes.
Is there any specific testing you are doing with the nimble stack and lora? For example, continuously moving data in a connection while attempting to do a lora join? Are you using a peripheral or central role? In any event, I will grab all the latest and let you know what I see from my end. > On Sep 25, 2017, at 9:59 AM, Gordon Klaus <[email protected]> > wrote: > > Thanks! Unfortunately, we have already configured the task priorities, so > that doesn't explain our current troubles. > > Even with LORA_MAC_PRIO: 1 and BLE_XTAL_SETTLE_TIME: 0, our joins sometime > take several attempts (< 8 or so). Have you had a similar experience, by > chance? > > On Mon, Sep 25, 2017 at 6:28 PM, will sanfilippo <[email protected]> wrote: > >> Other than the normal lora config variables settings really the only other >> one is the lora mac priority. This one is a bit interesting as you might >> want the nimble stack to work at a priority lower than lora ; just depends >> on the use case/app. Anyway, here are the config settings for the combined >> image: >> >> LORA_MAC_PRIO: 1 >> LORA_MAC_TIMER_NUM: 4 >> SHELL_CMD_ARGC_MAX: 32 >> TIMER_4: 1 >> BLE_XTAL_SETTLE_TIME: 0 >> >> Note that I listed all of the config settings just in case >> >> >>> On Sep 25, 2017, at 9:19 AM, Gordon Klaus <gordon.klaus@telenordigital. >> com> wrote: >>> >>> It looks like HFXO needs to be enabled generally for LoRa to work. HFINT >>> has frequency tolerance typically <±1.5% (max <±6%) which are >> unacceptable >>> for timing receive windows, as we've seen in our experiments. Whereas >> HFXO >>> is required to have tolerance <±60ppm. >>> >>> I'd love to know what else needs to be set correctly for LoRa and BLE to >>> work together! We've spent a lot of time already figuring out this >> timing >>> issue. >>> >>> On Mon, Sep 25, 2017 at 5:38 PM, will sanfilippo <[email protected]> >> wrote: >>> >>>> 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 <gordon.klaus@telenordigital. >>>> com> 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? >>>> >>>> >> >>
