Closed across-suffolk closed 3 years ago
Do you have auto-gain enabled as well?
No, auto-gain is turned off. Would this make a difference? I had thought about using a python and php script to issue a reset command at astronomical twilight but this seems something of a sledge-hammer to crack this nut.
I am having the same issue since updating to Buster. I am suspecting a conflict between the settings.json in the allsky directory and the settings.json in the/etc/raspap directory I am using the GUI.
@CleverJay Have you noticed a difference between the 2 files?
Once you install the GUI, /home/pi/allskysettings.json
is used anymore so the 2 shouldn't conflict.
Are you also using an ASI120? Just trying to find a pattern here.
I am also using the GUI and had noticed that altering any of the settings on the web page, even a tiny amount, causes the auto-exposure to re-adjust and work correctly - until the next night.
I am also using an ASI120MC. I renamed the settings.json in the all sky directory to eliminate a possible conflict. I exhibiting exactly the same behavior as across-suffolk. Every evening I have to remember to alter a setting and then save the cam config, and then it works.
For me this is an intermittent issue (the camera is fine tonight without intervention) and I do not have the knowledge to comb through this but I am going to try reinstalling tomorrow but without the GUI. Jay: have you always had the GUI Installed?
I reinstalled all sky and the guy when I updated to Buster. I was also getting corrupted images at twilight, I am trying turning off "post end of night data" to see if that affects the issue. You can see an example at: https://skylapser.com/allsky/videos/allsky-20200315.mp4 The twilight image is corrupted and then it is under-exposed until I saved the camera settings and then I got corrupted images again for a while. Strange.
I am getting corruption in the same spot on my images, usually occurring early morning, just before twilight. A similar portion of the image, with streaks where the column of pixels is repeated off to the right, almost as if the camera suddenly switches to a square aspect ratio and simply fills in the rest with the last column of data. I had thought this was a separate issue from the short exposures and I have seen others complain of the corruption but without the short exposures.
I will reinstall without the GUI and report back.
Just reinstalled allsky but of course the GUI is still installed. Not sure how to remove, although I believe the settings and config are being picked up from the allsky folder now and changing settings in the GUI make no difference. So far the exposure is ok but with such a major change I would expect this. Will report back how tomorrow night works and if the corruption remains.
First night was a success, auto exposure worked fine and there was no corruption of the right side in the image. Will report further in days to come.
Second night seems successful so far.
Overcast conditions are making it difficult to judge. My timelapses are viewable at: https://skylapser.com/allsky/videos/ Hoping for better conditions here in the next couple days. Fortunately social distancing is allowing me plenty of time to debug.
It seems that by turning off "post end of night data" that I don't have to reset the camera.
The only end of night processes I have set are to make the movie and the start rails, I have no exporting or uploading. This is the third night that the auto-exposure has worked correctly, since I reinstalled allsky. I still have the GUI on the Pi but not installed correctly; this is still a hang-over from the initial install. I can change the settings in the allsky directory but need to restart the service to effect the changes. So far the auto-exposure has worked and there has been no corruption of the images. If this keeps up it could implicate the GUI as a possible culprit.
There have been no issues with short overnight exposures for the last ten nights, since re-installing. The only difference that I can see in my system is that the settings.json file are located in the ~/allsky directory and not being picked up in /etc/raspap/. This is consistent with the initial comment from @CleverJay in this thread and suggests that there is an issue when the GUI is fully installed.
I am still having the issue. If we take a look at: https://skylapser.com/allsky/videos/allsky-20200330.mp4 from last night. you can see that I get corrupted image at the beginning and the end of the night recording. You can also see that the images are underexposed up until 20:55 when I i clicked "save" on the camera settings. I don't have to adjust any settings., I just have to hit "save" so that it starts reading from the settings json file. I renamed the settings.json in the Allsky directory, so when I click Save, it is reading the settings.json file from /etc/raspap/. perhaps I should do this the other way round.
Hi, I have the same issue, exposure getting stuck at a low value the entire night. I don't have the GUI installed and I have the ASI120MM-S camera. If I reset the service in the middle of the night it will work fine until morning. Does this happen with other cameras? Clear skies, Lucian
Yes, I have a ASI120MC-S. I turned the autoexposure off. Have exposure set to 20 secs. I still get occasional random horizontal lines and occasional times when no images are created for an hour. I have not thought about restarting the allsky service. I will add a cron job to do that and see what happens.
Thx Phil
On Tue, May 5, 2020 at 2:45 PM Lucian Vancea notifications@github.com wrote:
Hi, I have the same issue, exposure getting stuck at a low value the entire night. I don't have the GUI installed and I have the ASI120MM-S camera. If I reset the service in the middle of the night it will work fine until morning. Does this happen with other cameras? Clear skies, Lucian
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/thomasjacquin/allsky/issues/166#issuecomment-624296316, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANNYA3CZGSLQHOTAGVUUACLRQB3G3ANCNFSM4LNDQ6BQ .
Hello, I've a ASI120MC-s (Rb Pi4) and I have the same problem. I have to restart the Allsky to enable the Autoexposure. Any solution ? Thx Frank
I thought the problem had been solved by reinstalling the software but not the GUI. This worked for a few weeks but then occasional nights would occur where the exposure stayed around 1-2 seconds, resulting in black images. The frequency of these occurrences has now increased to 3 or 4 times a week. As to a solution, I am not proficient enough with coding to jump through and locate a fix; this would be something that Mr Jacquin and other contributors may be able to answer. Given the bugs elusive nature I suspect it is not an easy critter to trace.
Some people appear to have success in forcing a restart of the service each night. With this in mind I am considering running a python script to send a restart command to bash at twilight each night. A previous project that I built used PHP to calculate twilight times (civil, nautical and astronomical) for a garden light timer; it should be fairly simple to use this process to send a bash command using the python os module.
Hmmm, ok. It's strange because I've tested with a ASI224MC and no problem. I'll probably delet the autoexposure and use a fixe value for the night. I'll keep on eye on this subject.
How long have you run the 224 without an auto-exposure issue? It is very possible that this bug only manifests in the 120 (colour or mono) cameras. There is another issue of images becoming corrupt, with the right 1/4 of the image being streaked and this appears to also be confined to the 120. This would certainly be a fix, albeit an expensive one.
One week for the ASI224 and no problem.
Maybe it's possible to restart the Allsky application just after the switch in night mode ? I don't know how to do that...
I have done some digging in the code and perhaps @thomasjacquin could correct me if I have misunderstood (I do not know C++). The night time capture appears to be initiated in a function called bMain, with a simple boolean value being passed to the ASI camera using ASISetControlValue, in line 821. This suggests that the exposure time is calculated by either the camera driver or, more likely, the camera itself. This being the case there is very little or no override possible before video capture starts a few lines later at 828 and the glitch in exposure time is set in for the night at this point.
Some users have taken to restarting the entire service, which would re-initialise the camera in due course and seems to solve the problem but is drastic. What is not know is the cause of the glitch in the first place, either in the ASI driver or the camera.
What I cannot work out is whether the day/night checks and initialising of the camera auto-exposure setting is instigated each time an image is captured or only once per night; I suspect the latter and would value @thomasjacquin comment here. It may be that a second day/night check or initialising of the camera could solve the issue, particularly if exposure times remain uncharacteristically low.
OK, I can't do something... I tried to restart automatly during the day but the problem stays the same. I've to restart during the night mode. For this moment, I've disabled the AutoExposure and I use a constant value. I'll test it the next night. Wait and see... If you find a solution, it'll be great :-) @thomasjacquin Si vous passez sur ce forum, help :-)
Hello, This night, I've changed the ASI120MC-s by an ASI224MC. And all was perfect. So, the problem is really only with the ASI120MC-S...
Hi, Thanks for reporting the issue and thank you to users who own different versions of the camera. It seems that the issue is confined to the ASI120. I don't own that camera so I am unable to reproduce the issue. Just out of curiosity, @Frankastro85, @across-suffolk What settings do you use for gain and autogain? I had noticed a similar issue when trying to use both auto-exposure and auto-gain at the same time in the past.
Hi Thomas, thanks for your message. I have auto-exposure turned on, with max exposure set at 40000. Auto-gain is turned off but the setting shows 200.
I am hoping to get some time in the next few weeks to write a simple python/php script that runs independently and times a service reset to occur a few minutes after the night has started. I suspect this could help but may not catch all auto-exposure glitches, as the issue does seem to be in the camera - it may even cause more trouble.
For me a second option is to try another camera but do not own another ZWO and do not fancy my chances of adapting the driver for an Altair Astro camera.
I have a ZWO120MC-S and it exhibits the same problem. Auto-Gain is off, and minimum gain is set at 200, but the actual gain used during the night is 100 according to the text on the images. Auto-exposure is enabled, but the actual exposure doesn't change throughout the night, and its at 0.098s.
Allsky has previously worked with the same 120MC camera.
Here's the contents of my settings.json from /etc/raspap
{"width":"0","height":"0","exposure":"10000","maxexposure":"20000","autoexposure":"1","gain":"200","maxgain":"200","autogain":"0","coolerEnabled":"0","targetTemp":"0","gamma":"50","brightness":"50","wbr":"53","wbb":"90","bin":"1","delay":"10","daytimeDelay":"5000","type":"1","quality":"95","usb":"40","filename":"image.jpg","flip":"0","text":"","textx":"15","texty":"35","fontname":"0","fontcolor":"255 255 255","smallfontcolor":"0 0 255","fonttype":"0","fontsize":"1","fontline":"1","outlinefont":"0","latitude":"49.12N","longitude":"112.77W","angle":"-6","time":"1","darkframe":"0","showDetails":"1"}
Hi all, Thomas, my settings : {"width":"0","height":"0","exposure":"20000","maxexposure":"30000","autoexposure":"1","gain":"50","maxgain":"100","autogain":"0","coolerEnabled":"0","targetTemp":"0","gamma":"50","brightness":"50","wbr":"53","wbb":"90","bin":"1","delay":"10","daytimeDelay":"5000","type":"1","quality":"95","usb":"40"... In fact, If I use my ASI224MC, no problem. If I change the ASI224 by he ASI120MC-S with the same installation, the Autoexposure isn't correct. I've disabled the AutoExposure and I used a constant value the last week but the problem stays the same. I'll try the line code "sudo reboot now" friday night. Thank you.
My website : http://blogastro.free.fr/allsky/index.html
Hello, Finally, I keep my ASI224MC. The picture is more better than the ASI120MC-s and the programm run perfectly for the ASI224. Thank you, Frank
I also have this issue of broken autoexposure, with the 120MM camera and Debian-Buster. Based on the info I'm seeing in previous posts I gather that the only known workaround at this time is to restart the service nightly. I'd like to add my data point by confirming that this does seem to help (although it is pretty extreme). In case it is useful to anyone, below is a crontab entry that wakes at 5pm every day, waits until civil twilight +10 minutes, then restarts the allsky service:
0 17 * * * sunwait wait exit set angle -6 LATITUDE LONGITUDE & sleep 600 & systemctl restart allsky
Note this needs to run as root, so use sudo crontab -e
then add the above to the bottom of the crontab. You will also need to replace LATITUDE and LONGITUDE with numbers according to your location.
This issue is from an older release of the AllSky software. If you think it might still be relevant, please test it with the newest version and submit a new issue if needed. Thanks
Running on a RPi 3 A, with ASI120MM. Going into evening, sometimes the exposure does not adjust and stays at daytime rates of around 0.05s, resulting in an night full of very dark Images. I have tried a fresh install but still getting the same issue on some nights (sod’s law means it often happens on a clear and dark night!). I found that if and of the settings are tweaked slightly it causes the system to re-evaluate the auto exposure and works fine. Is there any way I can ensure that the auto exposure works every time?