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