Not sure this helps, but here is what I have seen after pulling latest and doing some quick testing:
It does appear that the first join attempt fails fairly often. I tried half a dozen times and it appears that the first transmission succeeded only once. It always succeeded on the second attempt however. I am doing US band testing btw; I have not done any non-US band testing. One item I need to verify is actual transmission attempts and what is reported in the statistics. In the US there are two join requests transmitted: one in the “normal” channels and one in the channels that are in 64 plus range. So I have to verify if both are being sent and both are actually failing. I have noticed that the gateway I am using has only reported a received join request on the normal channels (channel number < 64). A quick note: I am using a multitech gateway and when the joins fail the multitech gateway is not reporting any received packets. So the gateway is simply not seeing the transmissions. I looked at the gateway stats and I do not see any error statistics so it looks like it simply does not see the packet or there is a MIC failure (seems like the multitech gateway does not report MIC failures). My test setup is far from ideal though; the gateway is seeing me very poorly; not sure if it is the antenna or maybe antenna connection to module but I would have expected better than the -97 to -100 RSSI being reported. I will dig into that in a bit. Oh, I should probably mention that the BLE app I am using is a peripheral that should be constantly advertising. I have tested with the peripheral having a connection but have not done exhaustive testing where the peripheral was constantly keep busy in a connection. Anyway, if I have something more to report I will post it here... > 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? >>>> >>>> >> >>
