jiberjaber

So there's a bit of a problem at the moment, the movies are not quite right which I think is because of the output of Sunwait and the loss of astro dark here. I suspect there needs to be an exception in the code to handle detecting the "--:--" and in that case using another time, perhaps Nautical?

Tensioned using a flat blade screw driver to gently move the motor mount to get (what I thought was) the right tension and then nipped up the holding bolts. I was pretty sure I had the tension equal at both axis - I've slackened both off since replacing the RA one

Hopefully this will work, some are masters, others not as I haven't built them yet masterFlat-BINNING_1-FILTER_Luminance.fit masterFlat-BINNING_1-FILTER_Red.fit masterFlat-BINNING_1-FILTER_Blue.fit masterFlat-BINNING_1-FILTER_Green.fit masterFlat-BINNING_1-FILTER_H_Alpha.fit Flat_NoFilter_0.242_secs_2020-05-28T16-52-54_001.fits Flat_OIII_0.879_secs_2020-05-28T17-05-10_001.fits Flat_SII_0.750_secs_2020-05-28T17-04-50_001.fits

Help! What have I done wrong to get vignetting this bad? I've double checked that the filters are as close to the camera as can be, camera is asi16000, filters are ZWO unmounted 31mm... (since the photo of the EFW, I've flipped a few of the filters to the right direction so the a/r coating is in the right place) - vignetting wasn't this bad when it was just the DSLR and the flattener. Any pointers welcome please!

Welcome Kris, I found this quite useful when I first started its quite an old thread but gives a good idea of what can be seen with a scope of particular size etc Clear Skys!

Ah that's sort of good news, at least you know what it is now!

Only time I have heard that kind of noise is either when the mount payload has crashed in to the pier / tripod or the worm gears are meshed too tightly and stalled the stepper motor. If there was no equipment crash then it might be something in the worm gears that has jammed them - hard to know without inspecting them inside I guess. If you are not mechanically minded and with suitable tools it might be best to leave it to the shop to look at.

Yep - thats what I have done, it calls a script every 2 mins which calls mosquitto_sub -C1 for each of the three topics I need to grab data from the server running them concurrently as one updates every 5 seconds and another updates ever 2 mins! These are piped to a tmp file which is then copied to the final file when teh mqtt stuff has finished so if the webcam updates there is always data there for it to put in the banner (other wise the pipe file just blanks till the data is pipped!) I added an additional file which has a timestamp in so I can see that teh mqtt script was successful quickly, but I will probably turn this off now I am happy it is working.

Yep - I've got those modifications running also from when you first mentioned it. I just need to have a think about the best place to put the commands to pick up the weather data then I can simplify the code I have reading the files. I think if I run them every 2 mins it should grab at a sufficiently realtime rate for the camera annotation.

I've managed to plumb my weather station in to the allsky camera now, so outdoor and wind speed added to banner text, it picks up the mqtt messages from the weather station, stores them to a file and uses that feed the banner text. The mqtt messages arrive separately and at different times, so getting them direct from the php isn't an option, however at the moment they are just a long file with a new value appended on the bottom, I'll have to do some cron scripting to get a figure as a single line in a file I think.. I might have to fork your github in order to keep track of personal modifications I have made! The new lens is performing better than the other one I tested it with. Really happy with this now, must resist the temptation to customise it too much! Thanks Pete!

So the live video stream worked well and the new lens is fitted. I've also tested the modification to the code for getting the text banner on to the video, it was quite simple, just alter copy copypic.sh to copy the buffer.jpg rather than the webcam.jpg I had a look through the other scripts but I think the only copy of the picture occurs in the copypic.sh script. I might experiment with bringing the temperature in from my weather station now I have this banner text There's a new issue I have come across though, sunwait is reporting --:-- Midnight sun and it seems to have broken the suntimes page

OK - so my wide angle lens has arrived but remembering how much of a pain it was trying to focus it whilst on a ladder and using a laptop to run a capture and then view a still on a remote drive I decided to relook at streaming, I couldn't get it to work last time but success! I used the details from the following page to set up a UV4L which gives me an additional web page with a 'real time' stream of the camera which looks like it happily co-exists with the all-sky camera stuff. https://medium.com/home-wireless/headless-streaming-video-with-the-raspberry-pi-zero-w-and-raspberry-pi-camera-38bef1968e1 The author also recommends increasing the GPU memory allocation to 256 (which you can do via raspi-config under the "7 Advanced Options" menu, "A3 Memory Split" So - I think I'll fit the wide angle lens whilst the BBQ is getting ready - plenty of could to focus on tonight (unfortunately!)

I think the location.conf route is not working, I get no change to the location data the system thinks it is at when I edit it (weather and satellite still think they are in Poland). I have had some success with using Kstars to be the single version of truth when it comes to location. In Kstars, go to Settings, Geographic and create a home location then after saving that, go to Settings, Configure and in the INDI tab select Kstars updates all devices. This works for me with no GPS device on the system.

Wonderful, thanks both - I'll give that a watch through. I did assume flat-darks were just a case of replacing my EL panel for the scope cap and shooting at the same gain, bias, temperature and exposure as the flats?

New rowan belt and a temp sensor in the post today, belt fitted, hoping to be back in the game tonight!

New belt arrived today, fitted it and adjusted tension and got the belt moving up and down again though not as bad. re-adjusted to be 'quite slack', perhaps a little more slack than the DEC belt and all seems fine. I've ran it back and forth for a good few mins and it seems to be behaving itself - hopefully get chance to run some test guidance tonight and see if things are heading in the right direction

Ta, Dr G seems to be on quite a few videos on youtube when I google "Dr Robin Glover speaking about imaging times" is there a specific one ?

No you have helped - thanks Plan A just refers to taking as much as can on each filter in turn i.e. say 60 mins on L and then 120mins on each of RGB possibly split over a couple of nights. There seems to be a table on CN which implies a lot shorter exposure for Bortle 5 skies - I think trying it will be the best approach and then see how that pans out

Dave, My initial plan from what I've read is to start with unity gain, a set bias and -10 degC then see how it all goes. Those exposures seem a lot longer than I was expecting for RGB, is that because of the bias offset you I guess? Thanks Skipper - sounds like plan A is the way to go then, adapted to the amount of time available to image

Thanks Mark. Useful info.

I'm eagerly awaiting my delivery tomorrow of my new toy from FLO, an ASI1600 and filter wheel. I've a load of questions I have been working through and I am sure there will be more, but one I haven't been able to google as such is if there is a convention on which filters go in which wheel slots ? I've got the 8 position wheel coming and the ZWO filter set for LRGB and Ha, SII, OIII Also interested to hear thoughts on sequencing imaging, seems most might do double on L and the run RGB (i.e. 2min L, then 1M each of R,G & B ) there also seems to be various views on should it be all on each filter or run them in sequence eg A: 60 min of Lx2min subs followed by 30 mins of Rx1m, 30 mins of Gx1m, 30 mins of Bx1m OR B: 2xLx2m then 1xRx1m then 1xGx1m then 1xBx1m, then loop around back to L to start teh sequence run again x 30 runs. I can see some pros and cons of both above, but B seems like it might be less efficient (focus on each lens change?) And finally, it's a bit of a step change from DSLR to mono I get the new calibration requirements but still a couple of queries... at the moment the main one is, so I need to take flats for each filter used? (I am assuming dark-flats can be for a single filter, say L?) Looks forward to some hints, tips and answers Cheers

Like every good temporary installation, it's sort of become permanent! It was just a proof of concept originally, but it's been too useful in its current form!

Hi Pete - Yes I used the stop cron service etc but as my Pi is sealed into a small cola bottle (only just big enough for a USB cable to be plugged in, I was unable to take advantage of the focusing using a HDMI connected monitor. I did hope I could stream the video feed to VLC on a laptop but when I tried it, it complained about the video codec and I didnt have the time to investigate further. When the wider angle lens turns up I'll look again because spending over an hour climbing a step ladder and then coming back down and executing a command over SSH then using a viewer to see what changed isn't the most efficient way of trying to fine tune the focus! The only files I've changed have been the ones we've covered in the thread so far. So from memory Changed webcam.sh to add lat/long and then to alter timings (same ones you were experimenting on) removed the second wait for raspistill added backup script to be executed to the new movie scripts (both night and day) commented out the find and remove of files <110kb in all scripts within the /home/allsky/pics directory. I might have missed something out but it's been spread over a few days and I didn't write any notes ! One thing is for sure, there is potentially a difference in ownership of files, this shouldn't be a problem for the autonomous cron jobs as they are all run by 'god like powers' of root user. Here's last nights webcam captures which you can see the change in file size bathtub curve. (I commented out the removal of <110kb files around midnight, so no files between 22:30 and 00:00) I'm pretty sure there must be something to do with how the Pi is handling darker images from my V2 camera

Well I just checked and the night video stopped at the same time as last time. I went through all the scripts in pics directory and commented out the find and remove any file <110k and the movienight created a newer version of 0000 (just so happened that's just after I placed the comments in the scripts). My night pictures are circa 53k and certainly have data in them as can be seen on the 'live cam view'. Will monitor and see what the night movie looks like tomorrow morning

hmmmm, I'm not sure mine is 100% happy at the moment. After playing with the focus yesterday evening (which improved the stars) and a reboot (because I had stopped the cron service etc and with a restart it still isn't working). I eventually had to SSH in and delete the contents of /run/shm/ to get it to show anything other than the read error picture. After that it's been running fine but my night movie is still short (only 18 secs long and looks like there is a gap in the middle I think) If we can figure out a way to use the banner version of the picture with the timestamp in it, then that would confirm or deny the gap perhaps? I'll have a look today, might just be a case of copying the banner version over the original?