This is a follow-up to my original 12/20/19 post above, concerning frequent failure of one or more of three cameras to post approximately hourly JPEGS to an FTP site that hosts our club website. I have investigated nearly all suggestions. I have reduced JPEG file size to under 120 kB and staggered posting periods: currently 60 minutes (3600 seconds), 73 minutes (4380 seconds), and 87 minutes (5220 seconds) for the three cameras. We have recently upgraded our host web service to a dedicated server with significantly more memory and file storage capacity than before. Still, quite often, at least one of the periodic postings fails. I do not believe, as I did previously, that signal quality associated with the LTE modem at the remote site is at fault. I can always log into the site from home via Chrome Remote Desktop and observe nearly flawless real-time 15-FPS video from all three cameras - certainly more of a strain on available information bandwidth than three periodic 120-kB JPEGS. In other posts, I’ve read that BI uses a single hour-based clock reference to time FTP posting. For example, upon setup with the posting periods shown above, the first camera always posts at the top of the hour (say 12:00 noon), the second camera would initially post at 1:13 pm, the third camera would post at 1:27 pm. The next postings would occur at 1:00 pm, 2:26 pm, and 2:54 pm respectively for the three cameras, and so on. Since the posting periods are different for the three cameras, there will eventually be overlaps / interference in individual camera posting attempts. In a simple simulation of the first 40 hours of activity with the timing scenario shown here, there would be three instances of exact overlap (zero difference in clock time) in posting attempts between two cameras. Due to latency involved in completion of the actual posting function (e.g., time required to establish connection with the FTP site, etc.), overlap/interference events are more frequent. In this 40-hour simulation scenario, there are eight occurrences of two cameras posting within three minutes difference in clock time, and 11 occurrences within five minutes difference in clock time. Bottom line, I believe the major cause of failed periodic FTP posts I’ve been observing is due to the single hour-based clock reference within BI. An alternative approach, which could conceivably be embodied in a future BI option, would enable the user to define a single posting period (e.g., 60 minutes) staggered throughout the hour, e.g., top of the hour for the first camera, 20 minutes after the hour for the second camera, 40 minutes after the hour for the third camera.
