Hi,
I have another question about my end-device under test. This particular unit (Dev Address: 1200836A) stopped all uplink transmissions after downlink (seq no 3) earlier today. Can you take a look at the network server log to see if there’s any error?
Thanks!
Charlie
In LW 1.0.x the DevNonce is any non-repeating number (random is ok). In LW 1.1 it is a sequence number. The same is true for JoinNonce.
There are no errors on our side, other devices are still communicating through the gateway.
Charlie,
As a follow up to the device communication issue (1200836A), was the device moved away from the gateway. The last communication from the device at ~6:00 PM EDT yesterday was seqno 33 and then at 8:50 AM this AM the seqno is 226. We can see that the data rate for that uplink is DR0 indicating that the device has decayed down to DR0 and should be uplinking across all 64 channels.
Regards,
Mike
Mike,
You’re right. This device was moved away from gateway last night and then brought back to range this morning. The data rate was decayed down to DR0 which makes sense because it was trying to maximize range.
Since my gateway supports only 8 channels, does that mean it is communicating outside of these channels? If I let it run for a while, would it eventually move within first 8 channels?
Thanks,
Charlie
Hi Charlie,
Yes, the device is supposed to reset its channel plan (and TxPower) to defaults in an attempt to reconnect to the network when it decays. Assuming the device is currently active, there is a 1/8 chance the network will receive the transmission. In this case we can see that the device was previously uplinking at a 5 minute interval. Today we have only received a single uplink and that was over 6 hours ago. The network attempted to update the device configuration to the proper channel plan at that time but there has been no additional communication. Given the previous uplink interval one would assume that additional data would have been received from the device. It may be worth validating whether the device is currently powered on and its configuration.
Regards,
Mike
Hi Mike,
Yes, the device is still active and running and hasn’t been powered down since yesterday. I just check the configuration and everything looks good.
Is there anything in the downlink command which might have caused my end-device to stop communication for some reasons? It just seems a bit incidental that communication stopped after downlink.
Regards,
Charlie
Hi Charlie,
I see that you have re-joined your device and it is again communicating on the network. The downlink was a standard LinkADRReq and was identical to previous and subsequent LinkADRReq’s with the exception of any data rate changes. The only obvious difference is that the device did not respond with the LinkADRAns (or it was not received) and then was not heard from until the re-join.
Regards,
Mike
Hi Mike,
I reset my device yesterday evening and it re-joined the network and started transmitting. I have seen similar issue at least once before and the problem seems to be very repeatable. In both cases, the device failed to respond right after downlink. I can’t think of any reason as to why it’s doing this. Perhaps, there might be some settings in the gateway or device itself which would prevent it from transmitting. I also notice that in both instances, the device was transmitting at DR0. Not sure if this has any relevancy with the issue. If you have any suggestion, please let me know.
Thanks,
Charlie
Hi,
I’ve registered my gateway and it is connected to the network but it’s still showing “offline” on the portal. Is there anything missing? Please help.
Thanks!
Hello Charlie,
We see that there are two gateways registered under your name, the first has completed the registration process and the second has not. Can you please confirm that you have followed the steps available on the online help for installing the Senet Packet Forwarder: http://docs.senetco.io/dev/gw/MultitechConduit/. In addition, if this is an AEP model of the gateway there are a few additional steps to verify (also detailed in the above documentation.
Thanks,
Mike
Hi Mike,
I have AEP model of gateway. Do I need to run the command in the console or is this just for mLinux model?
Charlie
Hello Charlie,
Please ensure that you follow the documentation for the AEP model gateway and connect to the gateway UI and disable the default LoRaServer if it is enabled.
Once confirmed it is disabled, please connect to the console and execute the command to download and install our Senet Packet Forwarder.
Regards,
Mike
Hello Charlie,
We have not yet seen the gateway connect to our network. Please advise if you are still having issues, or if you have just not had an opportunity to revisit this since last week.
Regards,
Mike
Mike,
I haven’t had a chance to revisit this issue. I will try it this week and let you know how it goes.
Regards,
Charlie
Hi Mike,
I finally got a chance to run the command on the console but, unfortunately, received following error:
admin@localhost:~# dlF=lgwInstaller.sh;dlC=senetco;wget --no-check-certificate http://docs.${dlC}.io/downloads/$dlF -O $dlF && chmod +x $dlF && ./${dlF} -c ${dlC}
–2018-06-07 09:55:13-- http://docs.senetco.io/downloads/lgwInstaller.sh
Resolving docs.senetco.io… failed: Name or service not known.
wget: unable to resolve host address ‘docs.senetco.io’
Looks like it’s not finding the web address for some reasons. I know our network connection is good because I have the other gateway connected to the same hub and it’s working fine.
Do you have any suggestion?
Thanks!
Hi Charlie,
This looks like a DNS resolution issue on the gateway. Can you please verify that the gateway can resolve DNS names by pinging our server:
ping docs.senetco.io
ping www.google.com
Thanks,
Mike
Mike,
No, I cannot ping either server. It says unknown host.
Thanks.
Hello Charlie,
We suspect that the gateway may still be configured with it’s default IP address. Please issue the command ifconfig -a and if the eth0 interface IP is 192.168.2.1 then that is the case and the gateway will either need to be configured to receive an IP address from DHCP or provisioned with a static IP address that is applicable for your network.
Depending on whether this is an mLinux model or an AEP gateway will determine how those changes are made. For the AEP model you will configure the gateway for DHCP or for a static IP through the web interface and for the mLinux model you will need to manually configure the gateway.
If it is an mLinux model this will require knowledge of vi commands to perform the update
Regards,
Mike
Michael,
The gateway I have is AEP model. I configured for DHCP and the IP address shown when I issue the ‘ifconfig’ is 192.168.2.101. So I think it must be configured correctly.
Thanks!