It has been just over a year since my last article. I had several ideas I was working on but all got pushed aside as other events happened. My wife is now retired and taking up more of my time. Our property is still demanding as ever and never seems to reach a stable point. I spend less time in my shop and more out on a tractor mowing or moving things around. It never seems to stop.
I was using Windows 10 for Skype as the Linux version didn't work. I hate 10, it's updates happened in the middle of skipping and forced a reboot. I have turned some of the really bad options off, like the "send all your keystroke to M/S", only to have it say it will turn them back on during the next update. Which means you can not secure Windows 10 in any meaningful way. Thankfully, there is now a Skype for Linux and since then I have not used Windows at all. So, sometimes good things do happen.
I was able to upgrade all my routers and switches to Gigabit without changing out any of the wiring. I had installed Cat 5 over the years and it seems to be working just fine for gigabit speeds. I feel part of that is the somewhat short runs involved and limited number of systems. I do see some speed improvements for transferring files between systems, which I do often, but when it comes to the internet, everything slows down due to our 3Mbit WiFi connection. At night we can slow down to below 1Mbit, but they have been working to improve things. We no longer just hang for minutes as we have to wait for traffic to clear a slot for our data. But living in the country does have draw backs.
What I have spent lots of time on is what we call "Turtle Cam". We have a pond on our property and it has been invaded by turtles - about 5 at current count. I built a small island for them to sun themselves on and we felt that a camera, focused on the island would be a fun project. To the rescue is Raspberry PI's with cameras. Simple ideas, but nothing but problems.
It goes something like this - build box for PI oneW, add solar panel, add battery, put box on top of sprinkler stand (remove sprinkler first) and put out by turtle island. Worked for first afternoon and then required a hard reboot when brought back to shop. I checked battery voltage and it seemed too low, and thus it must have just died after a few hours of no sun. I tried a few more test and then more test and then started narrowing it down to the WiFi not keeping a connection if too much time passes without data transfers.
I moved the camera and oneW into a building that has a view of the pond and used regular Cat5 connection and no lost of connection during the night. I checked the internet to see if others were experiencing this problem, and sure enough there were plenty of suggestions to fix it. Typically they all provided some code to force a re-boot of the system and start again. I did my own version of the concept and was able to keep a WiFi connection intact for many days. I feel the issue maybe related to systemD and will talk about my feeling towards systemD later.
For those interested here is my crontab for taking pictures and resetting the system. Be advised that this issue is both regular PI's and the oneW. I though at first it was only the oneW, but a PI3 would crash after about an hour of no data movement. Could this just be some power saving mode in systemD that needs to be turned off? Not sure yet. I found after some testing that ssh-ing in failed even after resetting each hour, however a ping from the command line did bring it back on-line. So your experience may vary from mine, and a simple ping every so often might be all you need.
> crontab -l
# Edit this file to introduce tasks to be run by cron.
#
# m h dom mon dow command
# 1 8-16 * * * sudo /sbin/reboot
5 8-16 * * * sudo /bin/ping -c 2 192.168.1.100
5,25,40,55 8-16 * * * /usr/bin/python /home/kibler/bin/cam_capt.py
6,26,41,56 8-16 * * * /usr/bin/scp /home/kibler/Desktop/capt.jpg 192.168.1.100:/home/kibler/html
7,27,42,57 8-16 * * * /usr/bin/scp /home/kibler/Desktop/pond*.jpg 192.168.1.100:/home/kibler/html
> cat /home/kibler/bin/cam_capt.py
from picamera import PiCamera
from time import sleep
import datetime
import time
date = datetime.datetime.now().strftime("_%H_%M")
camera = PiCamera()
# camera.rotation = 180
# camera.brightness = 60
# camera.sharpness = 20
# camera.contrast = 20
# camera.resolution = (1280, 720)
camera.resolution = (1640, 922)
camera.annotate_text = "Pond"+ date
camera.start_preview()
sleep(3)
camera.capture("/home/kibler/Desktop/pond"+ date + ".jpg")
camera.capture("/home/kibler/Desktop/capt.jpg")
camera.stop_preview()
The above crontab will reboot or ping ( try each option to see what works for you ) the system between the hours of 8AM and 4PM - the typical good daylight hours for the regular camera. Speaking of cameras, sure a lot to talk about.
I must start out by saying I have trashed at least 3 cameras so far. I feel two failed due to bad cable connections. The flat cables can come loose if the units are not secured solidly. One unit had issues and looked like the contact had come loose and trying to fix it just made things worse. You need to know that the camera units is not the whole PC board, but the unit that is stuck to the board. There is a connector and a very short cable from the actual camera to the socket. Then, there is the cable connector that goes to the PI itself. So, if you have more than one camera, and one has a problem with the PI connector, you can take off the camera and put it on another PC board.
There is a lenses on the camera that can come off and must for use with telescopes and some devices. I tried many times to hook the camera to a telescope with no luck. Several internet sites explained that you need to un-screw the lens and then adjust the camera at the correct focal point to get an image. I did that by mounting the oneW on a block of wood with screws in the bottom that were in a slotted piece of wood. Thus I could slide the camera back and forth till I got a good image when placed looking into where the eyepiece would normally be. The results varied, but it did work very well with a non PI camera that was for normal closed circuit lenses - type C. The overall results was less than ideal and I found numerous minor problems that caused me to drop the idea. Having said that, there are several people who have gotten great pictures using the method. Your experience will vary and I think you need to spend a lot of time working out minor tweaks.
Let me start out by saying this is mostly based on guesses and things that have happened to me as of late. I think systemD is needed and a good first attempt of handling all the many, and I do many, system utilities for a current Linux system. I don't agree that we need all the utilities or that they need to be started for every boot. However, people are putting them in and using them. So like it or not, we needed a way to have better control and great reporting of problems. SystemD does that and I have used it several time to fix and solve problems.
Where I have issues and what I think is the problem, is with the list of things being started and how people who may not have such a great understanding of how Linux works or did work, are installing systemD items. You need to separate the systemD tool itself from the list of items and their scripts they run. I feel the tool works as designed. The tasks and how they interact are not so great. I started having problems with setting a fixed IP for several updated systems. I ended up finding that a hard reset was needed to get any of the settings to take effect. Using systemD to restart the network tools always failed and only a hard reset would work.
Clearly some features have been dropped and other tools are used now, like DHCPD.conf for setting fixed IP's and making all other tools and config files ignored. However, I have changed the config and still had to do a hard reset to get the changes, as nothing else seemed to work. I am not the only one with this problem, as there are plenty of web sites and blogs talking about this very topic. The difference is that none put the problem at the systemD configuration or selection as I do. Changes are being made that do not reflect the UNIX/Linux idea of keeping it simple. Hard reboots may be normal in Windows, but it is not acceptable or normal in UNIX or Linux systems - ever.
Most user have the start up process "silent" or not displaying messages. I have mine on and do watch what goes by. I saw one day that the network was setup and started using DHCP after a few lines went by. That means that very very early in the start up process, DHCP is called and ignores the configure file, and does do a DHCP call, even if your hardware might not be ready. I have no idea why someone would think that all systems need to do DHCP calls, especially when they have a fixed IP address already. People who are putting things into systemD are making assumptions that clearly are not true, have never been true, and just don't make sense. I think this is going to be a big problem for a long time, as those who really know about what goes on are all retiring and ignoring problems like this.
I hope that people start to better understand what they are doing and problems like this go away. However I have my doubts that will actually happen anytime soon.
I have reworked the turtle cam and it seems to be working better, but still has issues with focusing the camera lens. I have found this is a major issue and some of the non-PI made camera have better lenses and can be focused easily. Consider using a portable HDMI monitor, I use a 13inch 12V powered one, and the wireless keyboard to be at the unit and make adjustments. You must use the HDMI output to be able to adjust the camera while watching the monitor. the python tools write directly to the video memory and thus the only way to adjust thing is with the HDMI monitor.
However, you can still do things remotely by using "ssh -X IP-address", as "ssh -X" command will treat all graphic output as if run from the local screen. I wrote a little script that fires off the capture and then starts the image viewer so I can see it on my remote screen. You can do this to adjust the focus, but dreadfully tiring as you take picture, wait, view picture, adjust, repeat. Very time consuming and almost impossible to get good results, but does work. The small script is:
python cam_capt.py gpicview /home/kibler/Desktop/image.jpgThe cam_capt.py code was provided above. Remember to adjust the image name or location to match any changes you might have made to where the image gets put. You need to have loaded the package "gpicview" as it is not a normal program. This will work for PI's or regular Linux hosts. I connect to PI systems from x86 system using this method all the time. This is one feature that most user don't know about Linux and Unix system - rarely do you use an actual system from the attached keyboard - you do it all remotely (along with maybe a hundred other users at the same time).
Here are some pictures of the "turtle cam" equipment and my testing PI's and cameras ( love those C-Clamps).
Turtle Cam version 1
Inside initial turtle cam
Initial on site
Test setup in shop
New setup using HF Solar
On site now
