Hi Charlie,
Thanks for the prompt reply. The gateway channel plan has been updated to EU868. Please let us know if you require any additional assistance.
Regards,
Mike
Mike,
I am able to join my device and see some uplink data. Thanks again!
Regards,
Charlie
Hi Mike,
I am currently testing a 868 MHz device and come across following scenario. Not sure exactly what’s going on and wonder if you can explain.
The device was transmitting uplink messages for several hours, and then it was taken to a further distance. As you can see in the screenshot, a downlink ADR was sent (below highlight) and the device responded. After that, all the message stopped until the device was brought back closer to the gateway (@04:22:56).
My interpretation of the downlink is, turn on 16 channels and apply DR4, PWR0 to all channels. Is that correct?
Please advise.
Thanks,
Charlie
Hello Charlie,
The screen shot did not come through the post, but I believe I have found the events/timeframe in question that you have referenced for the devEUI ending in 4BD1. Assuming I have the correct sequence, we can see that the device was consistently uplinking with an Average RSSI of -62 and an SNR value of 9 (seqno #’s 0-48). At that time the device was moved away from the gateway we see that uplinks 49 – 56 and 58-69, and 72-89 are not received by the gateway. Of the three uplinks that were received during this time, average RSSI drops to -88 which is still very good, but average SNR drops significantly to -7 so the alternate location is clearly interfering with the device communication. The fact that the device is operating at Data Rate (DR) 5 is also a factor as the device is moved further away from the gateway. The communication failure started prior to the downlink sent on the received seqno 70 and the downlink is not related to the change in device performance.
Regarding your inquiry to the LinkAdrReq command sent to the device we are commanding the device to turn on all channels, set the Data Rate to 4 and to transmit at the max power of the device. Of note is the fact that the device does not change the data rate to DR4 when commanded.
Regards,
Mike
Hi Mike,
Thanks for your detailed explanation.
It seems to me that the device accepted the data rate change (DR4) but rejected both power (0) and channel plan requests. Based on my understanding, the default MaxEIRP is 16 dBm according to LoRaWAN regional specification. By setting TX power to 0, this effectively commands the device to transmit at 16 dBm.
From the RN2483 datasheet, the max output power is 14.1 dBm at 868 MHz band. If this is the case, I’d expect the device to reject power request and continue its current TX output. Is it possible for network to change to power 1 instead?
Thanks,
Charlie
Hello Charlie,
Regarding the channel plan rejection, the planned upgrade of our network server next week will address this.
The TxPower value is to be respected as an upper limit by the device. The device is expected to determine the actual TxPower based on its own capabilities.
Regards,
Mike
Hi Mike,
In regard to the TxPower comment above, MicroChip RN2483 (868 MHz) is using this number as the actual output power, not an upper limit as expected. Please see attachment for an excerpt from MicroChip command reference users’s guide.
I think this would explain why the power request is rejected. Is it possible to change power request?
Regards,
Charlie
Hi,
We are still seeing issue with PWR=0 being sent to our 868 MHz device. I thought this should be resolved with your planned network upgrade but apparently it not resolved. This is causing ADR being rejected and limits our transmission range.
Would you please help? Is it possible to have a call?
Thanks,
Charlie
Charlie, setting TXPower to zero is valid for all regions and all devices. It indicates the device is to use maximum available (limited by HW or regulation) power. What device are you referring too?
-Dave Kjendal
Dave,
The device I’m referring to is Microchip RN2483A. According to their reference guide, the valid range for 868 MHz is from 1 to 5. I believe setting power to 0 would be rejected by that device.
Charlie
I understand your concern (if it does behave that way, it is a bug in theie implementation). But I would like to know the EUI of the device you see behaving poorly.
Thanks
Dave
The DevEUI of the device in question is 0004A30B002261AF.
Which version of Firmware are you running on the RN2483?
The firmware version running in that device is v1.0.4
Hi Dave,
Is there any chance for the downlink not to send TXPwr = 0 for this particular device (RN2483)? According to Microchip, this is an expected response from this 868 MHz device to reject TXPwr zero.
One other thing I notice is that there is no specific selection for RN2483 when I tried to register this device into portal. Unlike the 915 MHz device (ie: RN2903) where there is a specific selection, I had to choose “Other” under Device Type for RN2483 device. Does that mean this device is not fully supported?
Is there any plan to add a selection for “Microchip RN2483 (868 MHz)” in the future? Please advise.
Thanks,
Charlie
Hello Charlie,
We have assigned a profile to the device to force the Tx Power to 14dBm (1). We have confirmed that this was accepted by the device and has resolved the ADR rejected issue
The device designation has no bearing on whether a device is supported in the portal or not. We periodically update the list of devices, however there is no functional difference between a listed device and one selected as “Other” aside from the fact that we associate a picture of the device. At present, adding the RN2483 is not in the roadmap.
Regards,
Mike
Mike,
I can see now the TX Power is accepted. Thanks for your help and support in resolving this issue.
Charlie
Mike,
I have a quick question. One of my colleagues is still seeing TX_Pwr = 0 on his account. I thought this change is applied to all accounts but it doesn’t look like that’s the case.
Do you think you can help? Is it possible for this change to be in effect for anyone who’s running with RN2483A 868 MHz device?
Thanks,
Charlie
Hello Charlie,
That is correct the change in TxPower was only applied to the devices in your portal account. If there is another device that requires this change please have the account owner reach out to us and we will apply a profile to that device as well.
Regards,
Mike
Hi Mike,
Okay, that would explain why the change is not seen on his devices. I will ask him to reach out to you in regard to this.
Thanks for your help again.
Regards,
Charlie