Well, it could certainly indicate you need some shielding or additional shielding.
> On Oct 6, 2017, at 4:56 AM, Gordon Klaus <[email protected]> > 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 <[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? >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>> >> >>
