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 <[email protected]>
> 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?
>>
>>
