Very good points. I appreciate your suggestions.
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.
Not too close as that will introduce new issues. Keep at least 3 meters and preferably a wall between the node and the gateway.
Thanks for that advice. I have the perfect spot. ~8 meters, and the wall you suggested.
Hello,
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.
Thanks for cleaning up the list.
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…
Which limit? Self-imposed or otherwise?
You can always add timestamps as the data comes in - not ideal, but better than nothing.
10 byte recommendation I should have said.
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.
What? Where?
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”.
If solution found please do share - we are all in suspense! 
Clue …that will be because Nick is Chairperson of the local Lepidopterology Society in N.W Greater Manchester/Burnley area (total membership 1).
In my case I think it is not caused by the temperature.
The node is self built and consists of a PIC microcontroller and an RN2483. The controller is checking on receiving mac_tx_ok after each transmit of data. It seems that for any reasons the RN2483 did not send mac_tx_ok and then my node stops running. Also I am using cnf, I will change to uncnf soon.
The indoor node is already running with uncnf without any problems.
I believe that with a 5 min interval you are likely therefore breaching the TTN FUP! Soon = now? 
The node ran last night without problems. Previously, I had it connected to one of these:
The Arduino and Dragino shield pair were plugged into the outlet labelled, “Always ON”. The IOT Relay controls a string of lights, and perhaps the voltage delivered to the AC adapter for the Arduino “sagged” under the load of the lights. The node off time was exactly that of the timer settings for the IOT Relay’s lights.
Once I removed the Arduino AC adapter from the IOT Relay and plugged it into the mains, the unit ran all night.
Seems unlikely. If you look at your mains power adapter, you’ll probably see it’s rated for fairly severe undervoltage, to the point where if things were dropping that far, I’d be more concerned about fire risk than LoRa packets.
You might have radio frequency interference from the lights though… or possibly a horrible amount of distortion of the mains waveform from an evil light supply, though I’d expect most switching adapters to survive that.
Are you really sure the times match? The recovery point seemed to be different on different days, and there was the one that didn’t fail.
My actual guess would be that this is just coincidence and the real cause is something else. Note that seeing the problem fixed would not confirm the theory; you’d have to be able to re-create the problem by this method.
Yes. The waveforms are dependent on that day’s temperature, and since those vary, they appear to be unmatched. Also, the middle of the waveform shows no loss of data, and the program I run to control the lights was off that day.
The lights were on last night, but the node was on the mains, not on the relay and I got payloads all night long. So the interference issue doesn’t jive.
Thank you for your comments. I feel a little sheepish about this. My Engineering skills are not what they used to be.