My Arduino / Dragino LORA shield combination works well as a weather station, except it has started to intermittently stop sending data. The screenshot below shows ‘gaps’ in the sent data that occur at the end of the day. The only thing I can guess is that during dropping temperatures the circuitry fails to send data to my TTN Indoor Gateway. The Gateway is 100 feet from the node, and there is window glass and roofing between it and the node. I am using SF7, and will try SF8. When I reset the Arduino / Dragino shield pair manually, data is transmitted once and then the gaps continue when the 5 minute interval in my sketch is reached. Eventually, the weather station starts to transmit on its own again.
From this little information, I do not expect anyone can diagnose my problem unless this is similar to a known issue where LORA data is not transmitted during a cool down (perhaps when SF7 is marginal).
What other things could be going on in the local environment that are end of day / drop in temperature related? Perhaps some HVAC is starting up and causing some local interference. Or additional blinds on the windows? Or power fluctuations?
Those are good questions and considerations. No blinds. No HVAC. The only thing I have not mentioned was a concern about condensation, but I don’t know why that would prevent timed data from being sent, and not data from a reset.
Think about what you alter / disturb by doing a reset that cause it to get through first time - an open door, a light turned on, any small detail that could just cause the beat of a butterfly to alter the circumstances favourably at a time when everything is marginal.
Do you have any other nodes you could run, left indoors, and see if their data feed continues?
These outages look like they’re at the same time of day though varying duration, it’s worth wondering if your gateway somehow loses connectivity to the back end. If you have the TTIG that’s a bit notorious for dropping off wifi, for example.
Personally I believe in giving gateways an independent status report tracked outside the network server; but that’s a bit harder with a gateway where you can’t add to the software.
I never see the Gateway green light blinking during the ‘outage’. I do have another Arduino/Dragino pair. I will try them inside and very close to the gateway.
I have a similar problem. I do have 2 identical nodes with temperature/humidity sensor running using in indoor gateway. One node is indoor, one node is outdoor. The nodes are not running for a long period, only a couple of days, but the outdoor node stops transmitting today in early morning when the outdoor temperature reached almost the minimum. First I thought about a low battery, but it wasn’t the battery. The indoor gateway is only handling the two nodes, there seems to be no conflict, the nodes are transmitting at different times. I will restart the outdoor node and see what happens until next day.
How cold? There was at least one reference node design that had a software bug with an unsigned variable where it would fail when the centigrade temperature it was measuring went negative.
It was the first thing I thought of with the problem of this thread, but then I saw that int he problem that kicked off this thread, the issue wasn’t at the minimum temperature, which was seeming to get through (though it would be nice to see individual points without whatever smoothing…)
I will restart the outdoor node and see what happens until next day.
Be careful with restarting nodes, it can lead to complete failure if an ABP frame count goes back to zero, necessitating a restart on the network side too
Please delete that, it’s meaningless clutter as there’s no time information, and it makes the thread unreadbale
What would be meaningful would be the points on a graph with the time axis.
If you were going to to something as text, it should be the points immediately preceding and following each outage with their timestamps and especially frame counts.
I do not save the time data. Arguably not the way to go, but who knows what rev 2.0 will bring. I think I decided not to collect time stamps because I was scared off with the 10 byte payload limit.
Timestamps would not be part of your payload, but part of the metadata you get from TTN. Also with the frame counters (those are part of the packet, but a reserved part added by the lorawan stack on the node, and they have to be there no matter if you care about them or not)
If we see a big time jump, and we see that the frame count also jumped, then we know a lot of packet were missed, for example because the gateway was offline. But if we seem a time jump and the frame count didn’t jump, then we know for some reason the node didn’t transmit. And if we see a frame count reset, we know the node rebooted or something, maybe browned out…
Perhaps I will add timestamps next. I send the data from my integration to a server I manage and process the data there, and could easily timestamp it then.
We definitely encourage efficiency as the air waves are a shared resource. But if your app needs 12 bytes, it needs 12. Or whatever number you need. Adding a faux timestamp (not actual date & time) so you can see the devices “timestamp” can give some very useful information.
That works if TTN isn’t already giving them to you. But grab the frame count which TTN is giving already. Also probably grab the SF or its inverse the datarate, at least if you ever think about doing ADR…
@Jimg you have described your node/gw config & devices but can you shed any light on your back-haul connectivity between the GW and The TTN servers? What AP/router/hubs/switches etc. & how configured/daisy chained, DSL/3G/4G/fibre, which service provider? (Inc any recent changes) Where in the world? (From your image I assume somewhere Napa/Sonoma Valley area?
reason for asking is I have seen and have seen reported many times before in other forum threads and elsewhere that e.g. a DHCP lease may get renewed at a regular time either on an internal network or often as part of an external service provision - in case of Service provider (often problem with a DSL Modem or a Mobile Data connection/SIM Service) often in early hours of morning, and this can lead to a short disconnect and possible a GW then struggling to reconnect for a short time after (again the TTIG often finds itself in the frame!). Often a pain to nail but if drop out is similar time each day or in more problematic situations often every 2 days (48hr lease) or longer with pattern not immediately obvious. Gets worse to confirm where there are pieces of networking kit daisy chained each on different lease intervals
I think I found the problem. I will test it tonight. Drum roll. Suspense. I believe it is/was a stupid mistake by me. The clue is the post from Nick McCloud about “any small detail that could just cause the beat of a butterfly to alter the circumstances”.
