Live data stream is stopping

I am using a Milesight Gateway UG63-868M model gateway. I can receive data from the sensors and send it to my own application successfully. However, approximately 1 day later, the live data connection from the gateway stops, and I do not see any data on the live data screen until I restart the gateway. Once I restart it, the issue is resolved, and live data can be received correctly again. I’m seeking assistance on what the problem might be. Thank you.

How often do your node send data?

thank you your reply. 1 minutes interval. i have 2 end devices

Have you heard of FUP?

What is the RSSI and SNR of these two illegal devices?

sensecap t1000a
“rssi”: -23,
“channel_rssi”: -23,
“snr”: 14.2,

milesight am307-868m
“rssi”: -23,
“channel_rssi”: -23,
“snr”: 9.5,

milesight lorawan gateway ug63-868m
“rssi”: -28,
“channel_rssi”: -28,
“snr”: 14,
"frequency

There are also 2 beacons indoors.

  • The uplink airtime is limited to 30 seconds per day (24 hours) per node.
    is it true?

Yes, if in doubt use this as a guide…the fewer the better- if your application cannot work under such constraints likely its is the wrong technology solution for you (wrt Dwell time, Duty Cycle, and/or FUP as appropriate).

https://avbentem.github.io/airtime-calculator/ttn/eu868/15

Search Forum for FUP.

1 Like

Why would you question something that is clearly written in the documentation?

With those RSSI’s, you don’t need LoRa, way too high for such sensitive receivers.

What do you use the live data stream for that you need it to work all the time - do you not use an integration to capture the data?

1 Like

I am surprised your nodes are working with RSSI so high.

If you read the doc you ill know it is true.

1 Like

First of all, thank you for your responses. Actually, I am new to LoRaWAN and I am trying to learn how to read data from some sensors I have acquired and use this data in my projects. What I am trying to do is to be able to receive emergency notification messages through monitoring and tracking in an indoor environment. For this, I am setting up my own LoRa network to be able to read data from some tracking sensors (like the SenseCAP T1000). I am trying to understand whether LoRa networks are suitable for such projects. I think I am hitting the fair usage policy. The reason for the high incoming signals is that the sensors and the gateway are very close to each other. Thank you for helping me understand the LoRaWAN technology.

Not the best device, only uses confirmed links, very fast for a few of them to make a gateway out of legal limits.

What emergency are you trying to track?

You are not accelerating you learning by sending date faster than FUP.

Our reason for choosing the Sensecap T1000 is its very low energy consumption. It features multiple operating modes, allowing it to conserve energy for extended periods depending on the selected mode. Additionally, it is equipped with multiple sensors that can measure values such as inactivity, light, and temperature-humidity. With WiFi, GNSS, and Bluetooth capabilities, it can be used to develop indoor and outdoor location tracking applications. Due to its compact design and low energy consumption, we believe this device will be suitable for our projects. Moreover, it has an emergency button that can generate an emergency signal. For example, a skier can use the emergency button to notify teams of their location after a fall, or a miner working underground can send an emergency message in case of an emergency. You are right, we don’t need to send data more frequently to learn more about LoRaWAN, but I didn’t realize that sending data from two separate endpoint devices at one-minute intervals would exceed this limit. I think I need to better understand the fair usage limit clearly stated in the documents

You had me at emergency in your previous post but this is almost light trolling!

LoRaWAN is not suitable for anything critical because [search forum for numerous prior discussions].

But UHF signals working reliably under snow or underground as a personal beacon? Reliability levels are going to be very low, particularly if the user is lying on top of the beacon.

If the SenseCap is sending confirmed uplinks, you can only do 10 per day.

As you keep referring to the FUP but not seeming to understand it or make the right noises about working within its limits, nor have you explained why you need the live stream to not stop and the use case is marginal at best, this topic is heading towards closure unless something meaningful gets posted.

But overall I’d strongly recommend turning all this TTN killing kit off, go and learn about how radio works and for LoRaWAN and read the Learn section (link at the top of the page).