You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Gordon Klaus <go...@telenordigital.com> on 2017/09/25 13:48:06 UTC
BLE + LoRa
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?
Re: BLE + LoRa
Posted by will sanfilippo <wi...@runtime.io>.
Well, it could certainly indicate you need some shielding or additional shielding.
> On Oct 6, 2017, at 4:56 AM, Gordon Klaus <go...@telenordigital.com> wrote:
>
> Sorry, I was wrong about the delay. I was looking at the "tmst" field,
> which it turns out is the "RX finished" time (and also it is in
> microseconds, not milliseconds). When I check the "time" field (time of
> pkt RX), the shadow packets are exactly simultaneous with the real packets.
>
> The frequency difference IS always the same. I didn't notice this before,
> but they are always 1 MHz apart (e.g. 868.5 and 867.5). There is a very
> rare exception where there actually two shadow packets (in addition to the
> actual one) that break this rule.
>
> Does this suggest a flaw in the board design, if RF signal is leaking to
> one of the debug cables? Can you explain why it happens much more
> frequently when there is a console connection open? (It happens much less
> frequently when the debug cable is connected but the console is not.)
>
> On Thu, Oct 5, 2017 at 7:31 PM, marko kiiskila <ma...@runtime.io> wrote:
>
>> RF signal leaking to one of the debug cables, and then that acts as
>> an antenna? Is the frequency difference between actual signal and
>> ‘shadow’ always the same, or about the same? Do you see the ‘shadow’
>> ever come before the frame with good RSSI?
>>
>> I don’t know where the time stamping happens, but if that
>> happens after frame delivery has been serialized… In that case you
>> could have timestamps which are slightly different, but actually for
>> frames which arrive at the same time.
>>
>> I’m just guessing here ;)
>>
>>> On Oct 5, 2017, at 8:10 AM, will sanfilippo <wi...@runtime.io> wrote:
>>>
>>> I cannot say that I have seen this. I do have a question though. You
>> said that the device is not physically sending these packets because they
>> overlap in time. You also mentioned that the shadow packets are within
>> 10-30 msecs of the real packet. Is what you are saying that the real packet
>> is > 10-30 msecs in length and the start of the shadow packet overlaps with
>> the end (or some portion) of the real packet?
>>>
>>> In my past RF experiences I have seen something like this with a device
>> that transmitted at a high power level and the signal bled into other
>> channels (i.e. device A transmitting on channel X; device B receives that
>> packet, at a much reduced RSSI, on channel Y). That explanation does not
>> explain the delay of 10-30 msecs however.
>>>
>>> Of course, attaching a cable could create another path/antenna. Still
>> does not explain the delay. I would have suspected the firmware doing
>> another transmission but you have ruled that out…
>>>
>>> Others I am with are scratching their heads (as am I).
>>>
>>>
>>>> On Oct 5, 2017, at 6:31 AM, Gordon Klaus <gordon.klaus@telenordigital.
>> com> wrote:
>>>>
>>>> Thanks for sharing your experiences, Will. Sorry for the delayed reply.
>>>>
>>>> Our device is a BLE peripheral. We've haven't been moving data at all
>> in
>>>> BLE. It seems clear that BLE is not at fault.
>>>>
>>>> Our latest findings show that having a connection to the console is
>> causing
>>>> strange LoRa behavior. In particular, we observe that our gateway is
>>>> receiving "shadow packets": messages with low signal strength (RSSI <
>> -100)
>>>> simultaneously (usually within 10-30 ms) with the actual packets (RSSI
>>>> -40). These shadow packets are received on different channels (867.x
>> MHz)
>>>> than the actual packets (868.x) and are usually corrupt. Our network
>>>> server was not handling these duplicate, corrupt messages correctly and
>> so
>>>> they interfered with the join procedure and transmitting other data.
>>>>
>>>> We see these shadow packets very often (90% of the time) when the debug
>>>> cable is connected and with a console connection open in telnet or
>>>> JLinkRTTClient. Without a console connection, never at all. We see the
>>>> shadow packets in tcdump and in the network server logs.
>>>>
>>>> We have verified that the device is not actually sending more than once
>> (it
>>>> would be impossible anyway, as the packets overlap in time).
>>>>
>>>> We've tried it with several different device<->programmer setups
>> (always on
>>>> the EE-02), and with a couple different gateways.
>>>>
>>>> It would be interesting to hear if you have the same experience, or any
>>>> inkling of an explanation.
>>>>
>>>> On Mon, Sep 25, 2017 at 9:44 PM, will sanfilippo <wi...@runtime.io>
>> wrote:
>>>>
>>>>> 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
>> <gordon.klaus@telenordigital.
>>>>> com> 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 <wi...@runtime.io>
>>>>> 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 <wi...@runtime.io>
>>>>>>> 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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>
>>
Re: BLE + LoRa
Posted by Gordon Klaus <go...@telenordigital.com>.
Sorry, I was wrong about the delay. I was looking at the "tmst" field,
which it turns out is the "RX finished" time (and also it is in
microseconds, not milliseconds). When I check the "time" field (time of
pkt RX), the shadow packets are exactly simultaneous with the real packets.
The frequency difference IS always the same. I didn't notice this before,
but they are always 1 MHz apart (e.g. 868.5 and 867.5). There is a very
rare exception where there actually two shadow packets (in addition to the
actual one) that break this rule.
Does this suggest a flaw in the board design, if RF signal is leaking to
one of the debug cables? Can you explain why it happens much more
frequently when there is a console connection open? (It happens much less
frequently when the debug cable is connected but the console is not.)
On Thu, Oct 5, 2017 at 7:31 PM, marko kiiskila <ma...@runtime.io> wrote:
> RF signal leaking to one of the debug cables, and then that acts as
> an antenna? Is the frequency difference between actual signal and
> ‘shadow’ always the same, or about the same? Do you see the ‘shadow’
> ever come before the frame with good RSSI?
>
> I don’t know where the time stamping happens, but if that
> happens after frame delivery has been serialized… In that case you
> could have timestamps which are slightly different, but actually for
> frames which arrive at the same time.
>
> I’m just guessing here ;)
>
> > On Oct 5, 2017, at 8:10 AM, will sanfilippo <wi...@runtime.io> wrote:
> >
> > I cannot say that I have seen this. I do have a question though. You
> said that the device is not physically sending these packets because they
> overlap in time. You also mentioned that the shadow packets are within
> 10-30 msecs of the real packet. Is what you are saying that the real packet
> is > 10-30 msecs in length and the start of the shadow packet overlaps with
> the end (or some portion) of the real packet?
> >
> > In my past RF experiences I have seen something like this with a device
> that transmitted at a high power level and the signal bled into other
> channels (i.e. device A transmitting on channel X; device B receives that
> packet, at a much reduced RSSI, on channel Y). That explanation does not
> explain the delay of 10-30 msecs however.
> >
> > Of course, attaching a cable could create another path/antenna. Still
> does not explain the delay. I would have suspected the firmware doing
> another transmission but you have ruled that out…
> >
> > Others I am with are scratching their heads (as am I).
> >
> >
> >> On Oct 5, 2017, at 6:31 AM, Gordon Klaus <gordon.klaus@telenordigital.
> com> wrote:
> >>
> >> Thanks for sharing your experiences, Will. Sorry for the delayed reply.
> >>
> >> Our device is a BLE peripheral. We've haven't been moving data at all
> in
> >> BLE. It seems clear that BLE is not at fault.
> >>
> >> Our latest findings show that having a connection to the console is
> causing
> >> strange LoRa behavior. In particular, we observe that our gateway is
> >> receiving "shadow packets": messages with low signal strength (RSSI <
> -100)
> >> simultaneously (usually within 10-30 ms) with the actual packets (RSSI
> >> -40). These shadow packets are received on different channels (867.x
> MHz)
> >> than the actual packets (868.x) and are usually corrupt. Our network
> >> server was not handling these duplicate, corrupt messages correctly and
> so
> >> they interfered with the join procedure and transmitting other data.
> >>
> >> We see these shadow packets very often (90% of the time) when the debug
> >> cable is connected and with a console connection open in telnet or
> >> JLinkRTTClient. Without a console connection, never at all. We see the
> >> shadow packets in tcdump and in the network server logs.
> >>
> >> We have verified that the device is not actually sending more than once
> (it
> >> would be impossible anyway, as the packets overlap in time).
> >>
> >> We've tried it with several different device<->programmer setups
> (always on
> >> the EE-02), and with a couple different gateways.
> >>
> >> It would be interesting to hear if you have the same experience, or any
> >> inkling of an explanation.
> >>
> >> On Mon, Sep 25, 2017 at 9:44 PM, will sanfilippo <wi...@runtime.io>
> wrote:
> >>
> >>> 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
> <gordon.klaus@telenordigital.
> >>> com> 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 <wi...@runtime.io>
> >>> 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 <wi...@runtime.io>
> >>>>> 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?
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
>
>
Re: BLE + LoRa
Posted by marko kiiskila <ma...@runtime.io>.
RF signal leaking to one of the debug cables, and then that acts as
an antenna? Is the frequency difference between actual signal and
‘shadow’ always the same, or about the same? Do you see the ‘shadow’
ever come before the frame with good RSSI?
I don’t know where the time stamping happens, but if that
happens after frame delivery has been serialized… In that case you
could have timestamps which are slightly different, but actually for
frames which arrive at the same time.
I’m just guessing here ;)
> On Oct 5, 2017, at 8:10 AM, will sanfilippo <wi...@runtime.io> wrote:
>
> I cannot say that I have seen this. I do have a question though. You said that the device is not physically sending these packets because they overlap in time. You also mentioned that the shadow packets are within 10-30 msecs of the real packet. Is what you are saying that the real packet is > 10-30 msecs in length and the start of the shadow packet overlaps with the end (or some portion) of the real packet?
>
> In my past RF experiences I have seen something like this with a device that transmitted at a high power level and the signal bled into other channels (i.e. device A transmitting on channel X; device B receives that packet, at a much reduced RSSI, on channel Y). That explanation does not explain the delay of 10-30 msecs however.
>
> Of course, attaching a cable could create another path/antenna. Still does not explain the delay. I would have suspected the firmware doing another transmission but you have ruled that out…
>
> Others I am with are scratching their heads (as am I).
>
>
>> On Oct 5, 2017, at 6:31 AM, Gordon Klaus <go...@telenordigital.com> wrote:
>>
>> Thanks for sharing your experiences, Will. Sorry for the delayed reply.
>>
>> Our device is a BLE peripheral. We've haven't been moving data at all in
>> BLE. It seems clear that BLE is not at fault.
>>
>> Our latest findings show that having a connection to the console is causing
>> strange LoRa behavior. In particular, we observe that our gateway is
>> receiving "shadow packets": messages with low signal strength (RSSI < -100)
>> simultaneously (usually within 10-30 ms) with the actual packets (RSSI
>> -40). These shadow packets are received on different channels (867.x MHz)
>> than the actual packets (868.x) and are usually corrupt. Our network
>> server was not handling these duplicate, corrupt messages correctly and so
>> they interfered with the join procedure and transmitting other data.
>>
>> We see these shadow packets very often (90% of the time) when the debug
>> cable is connected and with a console connection open in telnet or
>> JLinkRTTClient. Without a console connection, never at all. We see the
>> shadow packets in tcdump and in the network server logs.
>>
>> We have verified that the device is not actually sending more than once (it
>> would be impossible anyway, as the packets overlap in time).
>>
>> We've tried it with several different device<->programmer setups (always on
>> the EE-02), and with a couple different gateways.
>>
>> It would be interesting to hear if you have the same experience, or any
>> inkling of an explanation.
>>
>> On Mon, Sep 25, 2017 at 9:44 PM, will sanfilippo <wi...@runtime.io> wrote:
>>
>>> 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 <gordon.klaus@telenordigital.
>>> com> 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 <wi...@runtime.io>
>>> 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 <wi...@runtime.io>
>>>>> 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?
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
Re: BLE + LoRa
Posted by will sanfilippo <wi...@runtime.io>.
I cannot say that I have seen this. I do have a question though. You said that the device is not physically sending these packets because they overlap in time. You also mentioned that the shadow packets are within 10-30 msecs of the real packet. Is what you are saying that the real packet is > 10-30 msecs in length and the start of the shadow packet overlaps with the end (or some portion) of the real packet?
In my past RF experiences I have seen something like this with a device that transmitted at a high power level and the signal bled into other channels (i.e. device A transmitting on channel X; device B receives that packet, at a much reduced RSSI, on channel Y). That explanation does not explain the delay of 10-30 msecs however.
Of course, attaching a cable could create another path/antenna. Still does not explain the delay. I would have suspected the firmware doing another transmission but you have ruled that out…
Others I am with are scratching their heads (as am I).
> On Oct 5, 2017, at 6:31 AM, Gordon Klaus <go...@telenordigital.com> wrote:
>
> Thanks for sharing your experiences, Will. Sorry for the delayed reply.
>
> Our device is a BLE peripheral. We've haven't been moving data at all in
> BLE. It seems clear that BLE is not at fault.
>
> Our latest findings show that having a connection to the console is causing
> strange LoRa behavior. In particular, we observe that our gateway is
> receiving "shadow packets": messages with low signal strength (RSSI < -100)
> simultaneously (usually within 10-30 ms) with the actual packets (RSSI
> -40). These shadow packets are received on different channels (867.x MHz)
> than the actual packets (868.x) and are usually corrupt. Our network
> server was not handling these duplicate, corrupt messages correctly and so
> they interfered with the join procedure and transmitting other data.
>
> We see these shadow packets very often (90% of the time) when the debug
> cable is connected and with a console connection open in telnet or
> JLinkRTTClient. Without a console connection, never at all. We see the
> shadow packets in tcdump and in the network server logs.
>
> We have verified that the device is not actually sending more than once (it
> would be impossible anyway, as the packets overlap in time).
>
> We've tried it with several different device<->programmer setups (always on
> the EE-02), and with a couple different gateways.
>
> It would be interesting to hear if you have the same experience, or any
> inkling of an explanation.
>
> On Mon, Sep 25, 2017 at 9:44 PM, will sanfilippo <wi...@runtime.io> wrote:
>
>> 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 <gordon.klaus@telenordigital.
>> com> 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 <wi...@runtime.io>
>> 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 <wi...@runtime.io>
>>>> 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?
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: BLE + LoRa
Posted by Gordon Klaus <go...@telenordigital.com>.
Thanks for sharing your experiences, Will. Sorry for the delayed reply.
Our device is a BLE peripheral. We've haven't been moving data at all in
BLE. It seems clear that BLE is not at fault.
Our latest findings show that having a connection to the console is causing
strange LoRa behavior. In particular, we observe that our gateway is
receiving "shadow packets": messages with low signal strength (RSSI < -100)
simultaneously (usually within 10-30 ms) with the actual packets (RSSI
-40). These shadow packets are received on different channels (867.x MHz)
than the actual packets (868.x) and are usually corrupt. Our network
server was not handling these duplicate, corrupt messages correctly and so
they interfered with the join procedure and transmitting other data.
We see these shadow packets very often (90% of the time) when the debug
cable is connected and with a console connection open in telnet or
JLinkRTTClient. Without a console connection, never at all. We see the
shadow packets in tcdump and in the network server logs.
We have verified that the device is not actually sending more than once (it
would be impossible anyway, as the packets overlap in time).
We've tried it with several different device<->programmer setups (always on
the EE-02), and with a couple different gateways.
It would be interesting to hear if you have the same experience, or any
inkling of an explanation.
On Mon, Sep 25, 2017 at 9:44 PM, will sanfilippo <wi...@runtime.io> wrote:
> 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 <gordon.klaus@telenordigital.
> com> 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 <wi...@runtime.io>
> 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 <wi...@runtime.io>
> >> 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?
> >>>>
> >>>>
> >>
> >>
>
>
Re: BLE + LoRa
Posted by will sanfilippo <wi...@runtime.io>.
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 <go...@telenordigital.com> 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 <wi...@runtime.io> 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 <wi...@runtime.io>
>> 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?
>>>>
>>>>
>>
>>
Re: BLE + LoRa
Posted by will sanfilippo <wi...@runtime.io>.
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 <go...@telenordigital.com> 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 <wi...@runtime.io> 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 <wi...@runtime.io>
>> 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?
>>>>
>>>>
>>
>>
Re: BLE + LoRa
Posted by Gordon Klaus <go...@telenordigital.com>.
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 <wi...@runtime.io> 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 <wi...@runtime.io>
> 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?
> >>
> >>
>
>
Re: BLE + LoRa
Posted by will sanfilippo <wi...@runtime.io>.
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 <go...@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 <wi...@runtime.io> 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?
>>
>>
Re: BLE + LoRa
Posted by Gordon Klaus <go...@telenordigital.com>.
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 <wi...@runtime.io> 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?
>
>
Re: BLE + LoRa
Posted by will sanfilippo <wi...@runtime.io>.
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 <go...@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?