Hello Charlie,
Yes, it seems that the gateway is configured for DHCP and has obtained an IP address. Can you confirm that the gateway is plugged into a local LAN that has connectivity to the Internet? The DNS resolution failure is an issue that needs to be resolved in order to install the Senet Packet Forwarder and for the gateway to connect to the Senet network.
Regards,
Mike
Mike,
Yes, the gateway is plugged into the LAN with internet connection.
As a matter of fact, this gateway and the other 915 MHz gateway both are plugged into the same Ethernet switch. As you can see on portal, it is shown online in portal and I can also ping from that gateway to google server.
Regards,
Charlie
Hello Charlie,
Can you issue the command: cat /etc/resolv.conf on both gateways and verify the information is the same? These are the DNS servers that the gateway has received through DHCP.
Also, try and ping 8.8.8.8 from both gateways and verify that each are successful.
Regards,
Mike
Hi Mike,
I got different information from both gateways.
Also, the 915 GW is able to ping 8.8.8.8 but the 868 GW is not able to .
Regards,
Charlie
Hi Charlie,
Given the fact that the non-working gateway cannot even PING by IP, it sounds like they may be on different subnets. If you look at the IP addresses for both gateways are they on the same subnet? What happens if you connect the AEP model into the same port as the working gateway? Do the DNS servers change and can you ping by both IP and DNS name?
Regards,
Mike
Hi Mike,
I got it working now after I disabled the DHCP servers on the gateway. It is shown online status on the portal.
Thanks for all your help!
Regards,
Charlie
Hi Charlie,
Great news! Glad it is now up and running. We have confirmed that the gateway is now fully connected to the Senet Network. I believe that you stated this was an EU868 gateway? Once you confirm we will update the channel plan on the gateway accordingly.
Regards,
Mike
Hi Mike,
Yes, it’s EU868 gateway.
Regards,
Charlie
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.