Pete6

I'll need to get back to you in a day or so as I'm in the middle of a few other mods right now. I have a spare RPi that I can load a virgin copy of astroberry so that should give me a clean test environment. One I have that I shall play Lego bricks with t e configuration until I break it. More on this in a few days. Cheers Pete

You may be right about how the PoleMaster is being mounted. I have been play with the configuration a little. I have a set of relays at the bottom of my pier that allow me remotely to turn various devices on my telescope. Because of the problem I was having with the PoleMaster I put in onto its own relay. If I power up my rig with the PoleMaster power at boot time I can access it and it works. I can also cut the power to the PoleMaster with no problem but I cannot turn it back on again. If I do the astroberry Pi 4 crashes and needs a power cycle to recover. This too is repeatable. Turning off/on the OnStep controller works as does power cycling the myFocuser, camera heaters (no USB connection, obviously) all work fine. Maybe these observations will help point you to a solution.

Here is the output of lsusb with and without the QHYCCD PoleMaster. Edit: I turned off the power to a 4 port hub to kill the PoleMaster. This explains why two devices went down when I cut the PoleMaster's power. If you need this done differently, please say. With: Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge Bus 002 Device 002: ID 03c3:224a Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 009: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Bus 001 Device 008: ID 0ac8:3520 Z-Star Microelectronics Corp. Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Bus 001 Device 012: ID 1618:0941 Bus 001 Device 004: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Without: Bus 002 Device 003: ID 174c:55aa ASMedia Technology Inc. Name: ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge Bus 002 Device 002: ID 03c3:224a Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 009: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Bus 001 Device 008: ID 0ac8:3520 Z-Star Microelectronics Corp. Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub I hope this helps. Thanks again Pete

I have tried both powering down and unplugging the PoleMaster camera. The result is the same. Once the PoleMaster sees power (or plugged in) oaCapture gives this error and won't run in the GUI. My fix is to use one of my power system control relays to cut the USB 5V supply to the USB hub in question. Of course this means give a 4 port USB hub over to the PoleMaster but, it renders the system functional. I will do any tests you define to see if it helps. It might be possible for you to VNC into my astroberry Pi if necessary. Let's see how it pans out.

I am not sure if this is the right thread. If it is not then please move it. I have a Pi 4 with 4GB memory. It boots from a 1TB SSD and has no microSD car in the device. I run the latest downloadable of astroberry and have done all the updates/upgrades. I also have a QHYCCD PoleMaster on the mount. If this is connected to a USB port neither oaLive or oaCapture will run. Clicking them does nothing. Running them in terminal gives the errors shown in the image. Cutting the USB power to the port with the PoleMaster allows oaCapture to run. I am running oaCapture 1.8.0 and oaLive 1.9.0 as delivered with the astroberry image. This problem is quite repeatable as my USB 3.0 hub (connected to a Pi USB 2.0 port) has a switch for each port. Thus power on = oaCapture not running, poer off = oaCapture runs. Has anyone got a fix for this please. Thanks Pete

webcam uses Civil Dawn and Dusk times to switch modes. The camera seemed happier with this. You can select whichever Dawn / Dusk set you wish in lines 218 - 230 in the webcam file. Currently this is set to Civil but it can be changed to Nautical or Astronomical. I display these last two Dawn . Duck times only for information. They do not do anything inside the code. It's an astronomer's tool so I display all the Dawn / Dusk daily timings. Only the Civil times are currently used to switch camera modes and videos.. Hence the Midnight sun text is just informational. I changed one thing in your file. At line 136 twiSetVid=-00:15 # Offset advance or delay for the Video Day / Night switch. I did this to give a 6 minute interval between the camera switching to night mode and the night video start. This is how my system runs currently. There is a text file in /home/allsky named daily_times.txt This is a copy of the table that webcam puts out. It is there purely for reference so that times are accessibly without re-running webcam. Please try this as this is how my Pi Zero W is currently working. Please let me know what happens. Pete Jason-webcam

Jason, None of this should be happening. Could you please either post here or PM me the /home/pi/webcam file. I have no idea what has happened but I will find out. Actually if you need to post it on Dropbox or Google Drive let me have the link. Thanks

Hi Sam, This sounds pretty exciting to me. I have no experience using the HQ camera although I have read all about it. It seems a mighty camera. It should work with AllSky Camera but given the foregoing, I ain't tested it so you are a (the?) pioneer here. I will give you all the help I can which may turn out to be worth exactly what you pay for it... One thing has emerged from testing and that is the Pi (even a 4) seems to take a fair while to completely clear itself after processing an image. This is why we have had so much discussion about how often a Pi Zero can take an image at night. This was also why I limited my image size to 800 x 600 pixels. I hate wasting pixels but It just took too long. There is a utility on the Pi called htop and that will show multiple instances of raspistill if it starts to run into trouble. If this happens just increase the variables shotD (Day) or shotN (Night) which determine how often - in minutes - the Pi takes an image. In general, more frequent images = less time to process them, bigger images = more processing time needed. Pretty obvious. The HQ camera has a larger sensor and higher resolution with more pixels. However it seems to be able to do at least some processing within the device so maybe it will all even out. The Raspberry Pi forum is your friend here and member jamesh is the Raspberry Pi employee who seems to be the oracle of the cameras. Please stay in touch here as this looks to be very interesting. Kind regards Pete

No this is not doing narrow band. In fact I only just got the Raspberry Pi Cam V2 with its Sony IMX 219 sensor to gather enough light down the M12 mount to its 1/4 (I think()" sensor. There us also not IR filter so in fact this is about as wide a band as I can make it. My goal was to make a very cheap but usable AllSky Camera. Using a Pi Zero W you can make a working setup for well under £40 not including the case. Jiberjaber has used a drinks bottle for that. So not too expensive. If you skip using the temperature prob you can assemble the whole device with zero soldering and standard Raspberry Pi parts.. Shortly (within the next couple of weeks) I shall be installing one at my dark sky astronomy club site in (nearly) darkest South Carolina http://charlotteastronomers.org/ Hopefully I shall have a link that I can access from home that I can post here. The club already has an AllSky Cam so if you look at the site you'll find it but that is not narrow band either. This is not really a narrow band game. The idea is to see the whole sky regardless of the weather. Pete

If you want to run a job every 2 minutes, open up webcam and find the part where I write out the crontab file and stick a line or two in there. There are plenty of examples in that code . echo "*/2 * * * * $HOME/myjob> /dev/null 2>&1">>$HOME/webcamcron should do the trick. That way it will get written to the crontab file each day when webcam runs itself and writes a new crontab file.

Good. I am glad it is working now. I thought you would have done the mods but I really wanted to publish my findings so that in the future people do not have to go down the same hole. It is clear that the Pi Zero W has a lot less computing power than the Pi 4 but it also generates a lot less heat and is far, far cheaper so you can build my little box for less than £40. Of course it has to work and perhaps I was a little premature in publishing. I thought it worked. Mine did, well pretty much... It was just a few tweaks to the Pi Zero W version that were needed. I shall update the README.MD to reflect the new settings on Github and it should be good to go. You have given me a lot of help so thank you Jason. I could have had a far worse early implementer than you. Please let me know how it works in the longer term. Pete

@Jason, I am going to try Install UV4L and WebRTC when I get some free time. That was a nice find. Thanks. I like the weather station integration. Editing the webcam.php is just fiddly, not hard and it looks perfect. It looks as if you are making real progress here. I too have been testing. As I said a few days ago, I have increased the gap between switching the camera from night to day and the start of the night video to 6 minutes. Combined with a 5 minute shot interval this has performed flawlessly the last 3 nights. I reccomend that you try these timing as well. # Shifts camera mode time at Day / Evening Twilight 121 # For the dusk camera mode 122 # HH:MM Not used anymore 123 SSet=-00:00 # Advance or delay when the camera switches from night to day. 124 SSetP=00:00 # Camera switch time. Needs to be at least 1 minute EARLIER than the Video switch time. 125 SSetVid=-00:00 # Offset advance or delay for the Video Day / Night switch. 126 127 # Shifts camera mode time at Evening Twilight / NIght 128 # For the night camera mode 129 # HH:MM 130 twiSet=-00:00 # Advance or delay when the camera switches from day to night. 131 twiSetP=-00:09 # Camera switch time. Needs to be at least 1 minute EARLIER than the Video switch time. 132 twiSetVid=-00:15 # Offset advance or delay for the Video Day / Night switch. 133 134 # Number of minutes between movie frame concatenation. Default here is 10 [minutes] 135 concat=10 136 137 # Minutes between movie image copies. Default is 3. 138 # raspistill can take up to 1 minute 45 seconds to process a night time image. 139 cap=3 140 141 # Interval for raspistill to take shots. Night time needs to be longer since raspistill needs longer at night to complete. 142 shotD=2 # Daytime shot interval. Default is 2 [minutes] 143 shotN=5 # Night time shot interval. It can take raspistill up to 1 minute 45 seconds to process a night time image. Default is 4 I also edited /home/allsky/pics/newnightmovei.sh and removed the comment s at lines 39 and 40 that perform the 2nd check for the presence of a webcam-*jpg file with which to start a new night video. Last nigh this worked well too. I really want to let this run for a few days to make sure but felt that I needed to continue to contribute to my own project. 35 # Check the essential presence of raspistill webcam-*.jpg file(s). If none, wait for one to be created. 36 while [ ! -f /home/allsky/pics/webcam-*.jpg ]; do sleep 1; done 37 /bin/sleep 5 38 # Do it again just in case concatxxx ran meanwhile. 39 while [ ! -f /home/allsky/pics/webcam-*.jpg ]; do sleep 1; done 40 /bin/sleep 5 Pete

root@0W-AllSky:/home/allsky/pics# ls -l total 10808 drwxr-xr-x 2 root root 4096 Apr 29 18:16 b -rwxr-xr-x 1 root root 1329 Apr 19 20:47 concatday.sh -rwxr-xr-x 1 root root 1341 Apr 19 20:47 concatnight.sh -rwxr-xr-x 1 root root 299 Apr 30 08:24 copypic.sh drwxr-xr-x 2 root root 20480 May 18 20:50 day -rw-r--r-- 1 root root 9476568 May 18 21:05 movieday.mp4 -rw-r--r-- 1 root root 624245 May 18 21:35 movienight.mp4 -rwxr-xr-x 1 root root 150 Apr 4 19:52 movie.sh -rwxr-xr-x 1 root root 2528 May 14 22:54 newdaymovie.sh -rwxr-xr-x 1 root root 2515 May 15 21:04 newnightmovie.sh drwxr-xr-x 2 root root 12288 May 18 21:35 night -rw-r--r-- 1 root root 447810 May 18 21:35 webcam-1589852161.jpg -rw-r--r-- 1 root root 447810 May 18 21:35 webcam-1589852342.jpg I can post the code for any/all my files as you wish. If you PM me I can set up a temporary remote SSH for you. That way you can copy them directly. I'll just change the passwords for your session. I really want your system to work. This AllSky Camera is really frustrating to fiddle with because you only get one sunset per day. Did you see the little trick I posted for focusing. You MUST have the console connected for this to work 'cuz that's were the images will be displayed. service cron stop raspistill -k service cron start

Well maybe your camera is delivering images of a different size to mine. As downloaded and with a Pi Cam V2 it should work. The 110Kb file limit was set up for and is stopping all white image files on my Pi Zero W system. Could it be that your system is producing files that are smaller? If so the 110Kb limit certainly needs to be changed. Here is a ls - l dump from my Pi Zero W system