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