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