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.
If the lights are really causing a brownout on the extension cord, you have a serious fire risk, not a LoRaWAN problem.
I really believe your LoRaWAN problem is something else.
If the lights are involved at all, it had better not be that much droop of the mains voltage but rather some other mechanism. Because if that is really it, you are in a quite dangerous situation, LoRaWAN project or no.
The airtime is 61.7ms, 5min intervall = 12 transmits per hour = 123.4ms per hour = 2.9616s per day.
I will delete the check of mac_tx_ok, the loss of some data is not a big problem for me.
No. You need to change the sending mode to unconfirmed, as otherwise each affordable transmission will prompt an unaffordably expensive (in terms of capacity) downlink in response - even if you ignore the result.
Its not the time (up or down) that is the problem - its the limit of number of downlinks! (Remember each time GW Tx’s your downlink it is unable to listen to every other node that may be transmitting an uplink - hence the limit for social responsibility.) Must confess I sometime find I have mis-configured a node or power up an off the shelf device only to find it breaches limit, or may deliberately configure as conf mode for short test (<10 Tx/Rx pairs) and get distracted or forget to switch off/change settings - am sure it happens a lot and to many people, but once aware should take immediate steps to correct where practical.
Be aware the RN2483 (not the A) is known to stop sending data when the temperature drops below zero C.
@Jeff-UK: I changed to unconfirmed.
@kersing: I’m using RN2483A.
I’m thinking about changing the interval to 10min, but now I leave it at 5min and will see what will happen.
The node fails to communicate while the lights are on AND WHEN the AC adapter for the Arduino is connected to the Relay. It was my wild a** guess that the relay voltage was sagging. Perhaps that was a little reckless of me to suggest. Inteference/noise? Perhaps. I’d love to troubleshoot it and really understand. I am not concerned about a fire as the total wattage of the lights is perhaps 500W. I have a watt-meter. I will check that out.
Night 2, Arduino not connected to the IOT Relay, no data gaps. I still have to measure the power draw of the lights. There are 55 of them.
Do you have a way to safely measure the voltage at the power strip when the lights are on?
Something like a Kill-a-watt plug-meter would measure both the consumption and the voltage.
You could also plug in the node’s main’s power supply and measure the output of that while the lights are on…
Thanks - good idea. I have one of those and plan to use it. I wish I had more time during the week. I will do the measurements this weekend.