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? > >> > >> > >
