Good day all,
I have an end node based on a CubeCell connected to a weather station. The problem I have is that I don’t receive any information from the station during a for a wile. The next day the station start sending again for some hours. It is better understood in the next photo (each point is a data).
I thought it was a coverage problem but then i checked the RSSI and the signal is quite good (valued between -60 and -90 dB).
What can cause the problem?? It happens the same thing always: I start receiving around 8 in the morning without problems. Then I stop receiving around 2pm. All days happens the same, except the first week that I received data the whole week without problems.
Sometimes it also happens that it sends for a short period after I stop receiving:
I think isn’t blame of the node. I have other same nodes that works fine.
So, that actually sounds like a problem of this individual node then?
I would check settings of the node firmware.
Also check if the device has the same or different settings in the TTN console as other nodes that do work well.
Do the nodes uses OTAA or ABP?
And do they reset themselves on a regular basis?
LoRaWAN has an FNCT counter that has to increase for every new transmission, packets with lower FCNT are dropped by the network. With devices that uses ABP, a device reset might also cause their internal FCNT counter to reset to 0 too. That means that all subsequent packets will be dropped until you sent a packet with FNCT that is higher than the last received FCNT on the network side.
To avoid this, you need to make sure that the firmware doesn’t just restart FCNT on reset.
Can you find out the behaviour of the node in this regard?
Another way is to use OTAA. Upon joining the network-side FCNT is reset, so you don’t run into the problem described above. Now with OTAA, you also should make every effort to keep the session data, like encryption keys, because every join consumes downlink airtime from the gateway and eventually you’ll run into a similar problem with the device nonces running out.
Looking at the graph it seems you are sending very often. What is the uplink interval and at what SF are uplinks transmitted? Do you adhere to the FUP (max 30 seconds of airtime a day)?
Regarding your issue, is there a line of sight between the node and the gateway? Could it be something is blocking that line of sight in those periods? (A car/van or something else)
Hi bertrik,
Thanks for your help! The node uses OTTA and is registred as the other nodes, the only diferences between the devices are the LoRa credentials (are generated automatically). The device sends every 1 minute. In the office where I do the tests it works fine. Maybe the problem is the place where it is the end node.
Hi kersing,
Thanks for your help! The node sends every 1 minute several bytes. The SF are between 7 and 8. The truth is that I don’t know the total airtime during one day. It is possible that because of a lot of traffic it stops beig able to make uplinks?
I don’t know if there is something blocking the line between the node and the gateway (I have not mounted the device myself). But it seems it’s not.
That is too often. Please invest some time in researching the fair use policy and how to calculate the airtime each uplink uses. The is plenty of information on this forum regarding the subject including links to calculators and hints on where to find the information in the TTN meta data sent with each uplink.
The same metadata has information in RSSI and SNR which might help in pinpointing your issue.
You appear to have missed the point - it’s not about how it affects your technical solution - not that the weather changes that much that a minute uplink time seems to be necessary, it’s about you misusing the facilities that are provided to you for free, misuse that may impact other users in the area.
I will inform myself better and see how I can calculate the airtime. I want to fulfill the FUP policy. Didn’t know abaut the 30 seconds of airtime/day since today.
