There is also [today’s other post being the previous one about the kit build] progress on several software fronts, specifically the small-board-computer (SBC) control, camera capture and rebroadcast.
We’ve got a central script on each SBC (currently all raspberry pi’s) that reads that computer’s configuration file and acts appropriately. It initially starts the chosen camera and streams it for framing purposes. When it is triggered (currently by button but eventually by interrupt signal in software as well) that framing is finished, it starts the main loop, either starting it’s job immediately or waiting for another trigger, as configured.
That software currently has 2 jobs, save a series of timelapse photos, or start recording video, both to the machine’s configured local storage disk.
We concentrated on local save first because testing of network stream quality of these cameras was, shall we say, not what the internet had led us to believe. For a long time we trusted our testing methods and didn’t question them at all, this was just how it was going to be.
Then I got fiddling around with streams and remote save, so I could just stream something and save it to the fileserver, for instance. And low-and-behold, the saved file didn’t have _any_ of the issues of the same direct stream!! What??
So, further testing has improved our thinking somewhat on streaming of the SBC cameras. We are focusing on purpose on HD video whenever possible, so the Raspberry Pi ZeroW is going to stay Timelapse only, and we’re not sure about wireless streaming quality still, those tests are ongoing.
BUT, all this streaming testing got tedious on the server, which led me to write a general stream capture script that immediately got more useful than intended! So now it has a list of pre-programmed streams and their necessary settings, and you can either save, re-broadcast or both for any chosen stream. Currently rebroadcasting has only been tested via the internal RTMP server, but it’s worked well enough to continue.
Only Forward! 🙂