Open ezamp opened 4 years ago
ARM Internal Ref: IOTCELL-2457
@ezamp Have you checked the crystal accuracy? Please see https://github.com/ARMmbed/mbed-os-example-lorawan/issues/90 and https://github.com/ARMmbed/mbed-os-example-lorawan/issues/21#issuecomment-366937981
I enabled the output clock in MCO1 (A8) pin and I analyzed the pin with the oscilloscope.
This is the result:
The frequency fluctuates between [31.7, 32.3]MHz.
Spreading factor 7 downlink works (class A device). The debug serial port confirms receipt of the downlink message:
Received message from Network Server
RX Data on port 13 (7 bytes): 07 01 11 5e a7 ff 9f
From this can we conclude that the crystal is accurate? If it were not accurate I would expect that the device is not able to receive the message in downlink by opening the reception window after sending the payload.
Same issue for me on a MTB_MURATA_ABZ based board. Would using an external 8Mhz crystal be better (i.e. setting target.clock_source = USE_PLL_HSE_XTAL)? I have the option to put a https://www.digikey.com.au/product-detail/en/abracon-llc/ABM3-8.000MHZ-D2Y-T/535-10630-1-ND/2344632 in circuit.
Hi,
Same issue building for MTS_MDOT_F411RE.
Were any one of you able to experiment using a quick and dirty fix (such as switching back to an older version of the project or hard setting DR to 0 for the device) ?
I'm testing these so I will probably put an update here with the tests I did.
@Bernard-A - I've had success playing around with "lora.max-sys-rx-error". I have it set to 200 currently and that seems reliable. Also very useful to be testing with a known good gateway so you can rule out that as the issue.
Hi,
I’m testing the mbed-os’ LoRaWAN stack by running the sample code mbed-os-example-lorawan 1 on Murata type ABZ chip. The initialisation is performed correctly but during the “connect” phase many JOIN requests are generate (12 seconds interval between one request and the next). For every JOIN request the LoRaServer correctly generates the JOIN accept. Other LoRaWAN devices are working properly and do not have this behavior, I exclude problems on the server side.
After several requests, the device accepts the join and sends the first uplink.
I have enabled tracing to check the join sequence. The join accept is received only when the join request is sent with DR = 0.
Join sequence:![Capture](https://user-images.githubusercontent.com/388509/81162436-77b91380-8f8d-11ea-9b74-82b72e560544.PNG)