Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ERROR: Failed getting image, status = 11 (ASI_ERROR_TIMEOUT) #417

Closed
bbillp opened this issue Aug 11, 2021 · 174 comments
Closed

ERROR: Failed getting image, status = 11 (ASI_ERROR_TIMEOUT) #417

bbillp opened this issue Aug 11, 2021 · 174 comments
Assignees
@EricClaeys
Labels
bug needs software change

Comments

@bbillp
Copy link

bbillp commented Aug 11, 2021

Latest ALLSKY 8/10/2021 about 7PM PDT Los Angeles.

Pi 3b+
ZWO ASI178MC

Previous ALLSKY versions worked fine but except a recent version makes the ASI178 run hot

Attached as TEXT Files for the upload here,: config.sh and settings_ZWO.json
config.sh.txt
settings_ZWO.json.txt

Problem
One successful DARK image then ASI_ERROR_TIMEOUT repeats for any image.

In subsequent attempts I tried increasing USB from 40 to 100; autoUSB, reduced photo quality, No luck What next ?

â—� allsky.service - All Sky Camera
Loaded: loaded (/lib/systemd/system/allsky.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2021-08-10 20:01:36 PDT; 11s ago
Main PID: 10191 (allsky.sh)
CGroup: /system.slice/allsky.service
├─10191 /bin/bash /home/pi/allsky/allsky.sh
└─10282 /home/pi/allsky/capture -alwaysshowadvanced 1 -angle -6 -autousb 0 -autowhitebalance 0 -coolerEnabled 0 -darkframe 1 -dayautoexposure 1 -daybin 1 -daybrightness 50 -daydelay 5000 -dayexposure .5 -debuglevel 1 -extratext -extratextage 600 -filename image.jpg -flip 0 -fontcolor 255 255 255 -fontline 1 -fontname 0 -fontsize 7 -fonttype 0 -gaintransitiontime 15 -gamma 50 -height 0 -histogrambox 500 500 50 50 -latitude 33.5N -locale en_US.UTF-8 -longitude 118.1W -nightautoexposure 1 -nightautogain 0 -nightbin 1 -nightbrightness 50 -nightdelay 10 -nightexposure 10000 -nightgain 195 -nightmaxexposure 20000 -nightmaxgain 200 -notificationimages 1 -outlinefont 0 -quality 95 -showBrightness 0 -showExposure 1 -showGain 1 -showHistogram 0 -showTemp 1 -showTime 1 -showhistogrambox 0 -smallfontcolor 0 0 255 -targetTemp 0 -temptype C -text -textlineheight 60 -textx 15 -texty 30 -timeformat %Y%m%d %H:%M:%S -type 99 -usb 90 -wbb 90 -wbr 53 -width 0 -daytime 0 -tty 0

Aug 10 20:01:40 Allsky3B allsky.sh[10191]: Debug Level: 1
Aug 10 20:01:40 Allsky3B allsky.sh[10191]: TTY: 0 (no)
Aug 10 20:01:40 Allsky3B allsky.sh[10191]:
Aug 10 20:01:40 Allsky3B allsky.sh[10191]: Will NOT adjust gain at transitions
Aug 10 20:01:40 Allsky3B allsky.sh[10191]: Stop the allsky service to end this process.
Aug 10 20:01:40 Allsky3B allsky.sh[10191]: WARNING: Value of -1 less than min value allowed (32) for control 'Exposure' (#1).
Aug 10 20:01:40 Allsky3B allsky.sh[10191]: Taking dark frames...
Aug 10 20:01:41 Allsky3B allsky.sh[10191]: > ERROR: Failed getting image, status = 11 (ASI_ERROR_TIMEOUT)
Aug 10 20:01:43 Allsky3B allsky.sh[10191]: > ERROR: Failed getting image, status = 11 (ASI_ERROR_TIMEOUT)
Aug 10 20:01:46 Allsky3B allsky.sh[10191]: > ERROR: Failed getting image, status = 11 (ASI_ERROR_TIMEOUT)
@WirthmU
Copy link

WirthmU commented Aug 11, 2021 •
edited
Loading

Same error here with the latest version and GUI using a ZWO AI385MC.

Setting "Auto USB bandwidth" back to No and "USB bandwidth" to 80 solved the problem

@bbillp
Copy link
Author

bbillp commented Aug 11, 2021 •
edited
Loading

I tried USBAUTO no and 90 for the bandwidth, no luck. Also USBAUTO on , no luck.
I also set jpg quality very low to reduce the image size , no luck.

What else can I try ?

@pierrebilb
Copy link

Neither got luck, wathever value i put on bandwidth..
No idea..

@palmito9
Copy link

palmito9 commented Aug 12, 2021 •
edited
Loading

Also a 178mc owner.

With previous version I had to lower quality (png) to 7 and had to plug into a USB2 port.
All this to lower amount of corrupted images and reduce "reset SuperSpeed Gen 1 USB device number X using xhci_hcd" errors.

With the new version of allsky, encountered the timeout error no matter what setting.
I had to use to USB3 plug, but 4/5 images fail (image already saving) after "reset SuperSpeed Gen 1 USB device number X using xhci_hcd" error.

@pimmoon
Copy link

pimmoon commented Aug 13, 2021

Got the same problem on my Pi Zero which was installed two days ago. I tired with both 120mc and 178mc.. didn't work..

@EricClaeys
Copy link
Collaborator

This isn't good. During testing we eliminated the problem by setting USB Bandwidth high. One person has it at 100 with the camera the only thing on the USB 3 bus. Another has it at 75. I have 80 and auto-usb. One of us had to move the camera to the USB port.
Only one of you resolved the problem by using "auto" no, and "USB Bandwidth" of 80. Can other people try a different USB port? And continue trying different combinations of "Auto USB" and "USB Bandwidth "?
I have a feeling there may be a Pi USB driver issue, since we see the reset errors as well.

bbillp, would you please set your Debug Level to 3 then restart allsky and upload the log? The WARNING you got implies the exposure time was set to -1. Thanks.

@bbillp
Copy link
Author

bbillp commented Aug 13, 2021 via email

@Dentonknifeworks
Copy link

"would you please set your Debug Level to 3"
Where is this done?
Thanks
Brad

@EricClaeys
Copy link
Collaborator

bbillp,
If you have auto-exposure turned on, then the corresponding "exposure" setting is used as a staring point.
For example, if nighttime "Auto-Exposure" is turned on, then the nighttime "Manual Exposure" setting is used as a starting point if the program is started at night. However, when the program has been running during the day and nighttime comes, it will use the last daytime exposure as a starting point for night, adjusting the gain if "Gain Transition Time" is greater than 0. This is done to avoid abrupt changes in brightness between day and night.

In version 0.7, the nighttime exposure setting was called "Exposure".

I have my nighttime "Manual Exposure" set to 45 since when it's fully dark, the camera takes 60 second auto-exposures.
Does this help?

@bbillp
Copy link
Author

bbillp commented Aug 14, 2021 via email

@bbillp
Copy link
Author

bbillp commented Aug 14, 2021 via email

@EricClaeys
Copy link
Collaborator

Brad,
If you are running the newest GUI, go to the "Camera Settings" page and at the bottom, click on the "Show Advanced Options" button, then change the "Debug Level" option. We figured most people wouldn't use that option, so we hide it by default as an advanced option.
If you are NOT using the GUI (and I highly suggest you do), then edit the settings_ZWO.json file (I think that's what it's called), looking for the "debuglevel" setting.

@Dentonknifeworks
Copy link

Dentonknifeworks commented Aug 14, 2021 •
edited
Loading

I am using the GUI, but nothing shows up for the RPIiHQ Advanced Options looks to be only for the ZWO. Advanced Options is there, but nothing is added to the GUI when turned on. I added it to the settigs_RPiHQ.json file but not sure it's an option.

@EricClaeys
Copy link
Collaborator

Brad,
Debug level is in capture_RPiHQ.cpp, but I failed to put it in the settings file. Ooops.
You can get it by adding the following lines to the camera_options_RPiHQ.json file (probably in /etc/raspap):

{
"name":"debuglevel",
"default":"0",
"description":"Debug level, 0 is lowest level.",
"label":"Debug Level",
"type":"select",
"options": [
	{"value": "0", "label": "0"},
	{"value": "1", "label": "1"},
	{"value": "2", "label": "2"},
	{"value": "3", "label": "3"}
],
"advanced":1
},

@EricClaeys
Copy link
Collaborator

I just submitted an update for this to Thomas. Thanks for pointing it out.

@thomasjacquin
Copy link
Collaborator

@EricClaeys Did you send me a pull request for this?

@EricClaeys
Copy link
Collaborator

@thomasjacquin Yes. I submitted 15 pull requests last night. Each was in its own branch.
5 pulls for allsky-portal and 10 for allsky.

@thomasjacquin
Copy link
Collaborator

@EricClaeys Weird, I'm not seeing them on the GitHub page and I didn't get any notification.

@EricClaeys
Copy link
Collaborator

Here's a screenshot showing some of them. Could be my lack of GitHub knowledge and I did it incorrectly, but I created separate branches for each one, per your suggestion.

EricPulls

@EricClaeys
Copy link
Collaborator

When I click on one of the pulls I get a page similar to this. I did NOT do anything with the "Merge pull request" - should I ?

EricPullsMerge

@thomasjacquin
Copy link
Collaborator

@EricClaeys I think it's because you submitted a PR onto your own fork of my repository. Let me see if I can bring them over.

@EricClaeys
Copy link
Collaborator

When I try to submit on yours, it tells me I don't have write permission, so I don't try.

@thomasjacquin
Copy link
Collaborator

Can you select the base repository to push to? See item 4 on this page.
https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork

@EricClaeys
Copy link
Collaborator

EricClaeys commented Aug 15, 2021 via email

@bbillp
Copy link
Author

bbillp commented Aug 15, 2021

snip “bbillp, would you please set your Debug Level to 3 then restart allsky and upload the log? The WARNING you got implies the exposure time was set to -1. Thanks.”

V0.8 with debug = 3 , create dark images, one dark file created and the image folder 20210814 was created then saved sudo service allsky status to status.txt Attached are the files for config.sh, settings_ZWO.json, status.txt, log.txt . I was expecting to see a lot of info from debug level 3 in log.txt but there isn't .
.
config.sh.txt
log.txt
settings_ZWO.json.txt
status.txt

@bbillp
Copy link
Author

bbillp commented Aug 15, 2021

Are Erics updates ready to download and update 0.8 on the Pi ?

@EricClaeys
Copy link
Collaborator

Bill, my updates aren't there yet. I'm having some problems with GitHub which is making it difficult to merge my changes into Thomas' master.

@EricClaeys
Copy link
Collaborator

Bill, sorry, I wasn't clear. Post the /var/log/allsky.log file. Maybe first stop the service, remove or truncate the file, then start the service and let it go a while, then upload allsky.log. That way it will only contain the most recent data, which makes it easier to look at.
The log.txt file basically contains the arguments to allsky.sh and one entry for each picture taken. It isn't very useful.
Eric

@EricClaeys
Copy link
Collaborator

Bill, try the attached capture.cpp file - it should fix the -1 exposure for dark frames.

capture.zip

@manfredwilhelm
Copy link

Same problem for me. I use a ZWO ASI120MC Cam. Worked with older version of allsky.
Raspberry PI 3 B+
Tried different USB-Settings or CAM-Modes (RAW...) No luck.

allsky.log

@linuxkidd
Copy link
Collaborator

re point 8, it looks like you didn't add -DOPENCV_C_HEADERS like the x86_64 section does.

Dang, eagle eyes! I fixed it now... and, happy to report it still works fine. :)

I did omit the actual display function of the code.. I spent a bit of time looking into how to implement it in OpenCV4, but came up empty on execution. I don't use it, so it wasn't high priority for my hacking around.

@EricClaeys
Copy link
Collaborator

@linuxkidd Michael, anything we should change in the master software based on your test?

@linuxkidd
Copy link
Collaborator

@EricClaeys Bullseye support is a bit bleeding edge, but everything else is working fine on all new buster installs even with updates. The only thing I have different from default is I've disabled auto-exposure in Daytime capture. In my first attempts with that early on, it was still causing wild swings of brightness.

I'll set it back to auto at this point and see how it goes.

@ckuethe
Copy link
Collaborator

ckuethe commented Sep 23, 2021

@bobhillier99

Could you please paste the code that you changed to count the number of errors? It's a good idea so I'll add it to the next capture.cpp.

Even better, you should do up a PR. It's easier to review, and easier to cherry pick changes if others want to experiment with it, and easier for you to be credited for your contributions to Allsky.

@EricClaeys
Copy link
Collaborator

@linuxkidd Michael, if you send /var/log/allsky.log while you're having wild swings, I'll take a look. I've also noticed some swings in the log file but haven't had time to look into it.
Thanks - Eric

@bobhillier99
Copy link

@EricClaeys
Do I use the supplied capture0.7with0.8arguments in a 0.7 build or an 0.8 build? It doesn't work in an 0.8 build?

@EricClaeys
Copy link
Collaborator

@bobhillier99 use it in a 0.8 build. It won't have any of the 0.8 features except printing an error message if a capture fails. 0.7 did almost no error checking.

@linuxkidd
Copy link
Collaborator

@linuxkidd Michael, anything we should change in the master software based on your test?

FYI -- I found that the OpenCV4 compatible methods work with Debian Buster as well as Debian Bullseye. I've submitted a new issue #508 and a new PR #505 for this.

@maphilli14
Copy link

@linuxkidd Michael, anything we should change in the master software based on your test?

FYI -- I found that the OpenCV4 compatible methods work with Debian Buster as well as Debian Bullseye. I've submitted a new issue #508 and a new PR #505 for this.

I appreciate this extra work and findings, but I don't know how to read those two open issues. Any action we can take to debug this further and make progress on this issue?

@linuxkidd
Copy link
Collaborator

Hi @maphilli14, apologies for the confusion of mentioning these other Issue/PRs.

I initially had the same timeouts, but a fresh install of buster + allsky resolved it entirely on my setup. If you opt to test this, be sure to back up your settings_ZWO.json, config.sh and the allsky/scripts directory (if you've modified anything in there).

@maphilli14
Copy link

I just did a fresh install and git clone and it still errors out.... see attached

allsky.zip

:(

@maphilli14
Copy link

Hey dumb question. With lots of 'scientific' cameras there is a separate register to change the exposure range is that possibly in play here? IE, exp values from 1ms to 100ms are valid for mode A but to get to 100ms to 1000ms you need mode B and for beyond 1sec you need modeC? Possibly?

Let me know what other logs you might need? I can try a higher logging level as suggested or a different capture.cpp if needed.

TIA

@EricClaeys
Copy link
Collaborator

@maphilli14 Allsky restarted only once because of ASI_ERROR_TIMEOUTs but was successful many other times. Did you restart it the other times or did it restart itself? There are quite a few restarts.
Do you have the version 0.8 exposure mode on or off? Either way, try the opposite. Also try setting USB Bandwidth to 40.

There is no separate register to change exposure range. If you want to see the exposure range for your camera, set the Debug Level to 4 and restart. It will show you all the camera's capabilities including their default, min, and max values.

@maphilli14
Copy link

I tried your suggestions and may have gotten lost along the way but I attached several setting example logs. This was fairly consistent


Oct  4 22:18:19 allsky allsky.sh[25565]: NOTICE: Camera does not support ControlCap # 3; not setting to 53.
Oct  4 22:18:19 allsky allsky.sh[25565]: NOTICE: Camera does not support ControlCap # 4; not setting to 90.
Oct  4 22:18:19 allsky allsky.sh[25565]: NOTICE: Camera does not support ControlCap # 2; not setting to 50.

As was the total inability to go beyond 1sec exposures of any kind.
allsky.zip

Thanks for all the help and support!

@EricClaeys
Copy link
Collaborator

@maphilli14, those message are just saying your camera doesn't support gamma (most don't) and setting color balance since you have a mono camera. A future version of capture.cpp won't attempt to set color balance on mono cameras. Those message are nothing to worry about.

Try downloading the newest capture.cpp which is in the "src" directory at https://github.com/thomasjacquin/allsky. First rename your current capture.cpp to capture-ORIGINAL.cpp, then copy the new one in and run "make capture".

The new file increases the max number of consecutive errors from 2 to 5. I don't think it'll help but it's worth a try. Also increase the USB Bandwidth from 40 to 80 and if that doesn't help, increase to 100.

After you run "make capture", stop the service and run "sudo rm -f /var/log/allsky.log", then restart the service and let it go a few minutes and send me the log file.
Thanks.

@maphilli14
Copy link

Yes, much the same...
allsky-20211005.zip
.

@EricClaeys
Copy link
Collaborator

EricClaeys commented Oct 6, 2021 •
edited
Loading

@maphilli14 Sigh...
What's up with the multiple ***** Starting AllSky ***** and Making sure allsky.sh is not already running... at the top?
Did you stop it after the 3 buffer clear exposures failed at 00:23:11? The normal exposure after that succeeded.
The last run in the log file failed on the 3 buffer clear exposures but then had 5 successful exposures.
All the runs had USB Bandwidth at 100 and Auto USB as No. Did you try with Auto USB Yes and different Bandwidth settings?

Also, please try with 0.8 exposure mode off.

If none of the above work I don't know what else to do other than use the attached file. which is the version 0.7 capture.cpp.

capture0.7with0.8arguments.zip

@maphilli14
Copy link

Thanks @EricClaeys I seemed to have lost all camera ability. Switching to daytime mode at the end of that night of troubleshooting left it timing out no matter what settings. I tried refreshing the entire allsky from repo 2x times. It's as though something stuck in the camera registers. Even powering off for many minutes did not recover. I will refresh again tonight and try the suggested cpp! TIA

@EricClaeys
Copy link
Collaborator

@maphilli14 Sorry you are still having problems. Can you attach the camera to a Windows machine and connect via ASI Studio?
Have you tried a different cable or different Pi? Know anyone else with a camera or Pi you could borrow. Just trying to narrow it down to hardware or software issue.
ZWO documentation doesn't mention any settings that persist across power resets, and there is no documented reset function.

@EricClaeys EricClaeys self-assigned this Oct 9, 2021
@EricClaeys EricClaeys added the bug needs software change label Oct 9, 2021
@maphilli14
Copy link

no sweat, I can but it's on the roof and raining, might be some time.... I have recovered basic, < 1s exp again. I found in the logs I needed to manually specify zwo in the config.sh file. All seems to work mostly, the cpp file complied but doesn't execute well...

Oct  9 21:39:20 allsky allsky.sh[25030]: STARTING EXPOSURE at: 2021-10-09 21:39:20
Oct  9 21:39:22 allsky allsky.sh[25030]:   > Saving image 'image.jpg' that started at 2021-10-09 21:39:20  (0 us)
Oct  9 21:39:22 allsky allsky.sh[25030]:   > Sleeping: 956 ms
Oct  9 21:39:23 allsky allsky.sh[25030]: STARTING EXPOSURE at: 2021-10-09 21:39:23
Oct  9 21:39:30 allsky allsky.sh[25030]:   > ERROR: Failed getting image, status = 11 (ASI_ERROR_TIMEOUT #1 (with 0.8
 exposure = NO))
Oct  9 21:39:32 allsky allsky.sh[25030]: STARTING EXPOSURE at: 2021-10-09 21:39:32
Oct  9 21:39:39 allsky allsky.sh[25030]:   > ERROR: Failed getting image, status = 11 (ASI_ERROR_TIMEOUT #2 (with 0.8
 exposure = NO))
Oct  9 21:39:41 allsky allsky.sh[25030]: STARTING EXPOSURE at: 2021-10-09 21:39:41
Oct  9 21:39:48 allsky allsky.sh[25030]:   > ERROR: Failed getting image, status = 11 (ASI_ERROR_TIMEOUT #3 (with 0.8
 exposure = NO))
Oct  9 21:39:50 allsky allsky.sh[25030]: STARTING EXPOSURE at: 2021-10-09 21:39:50
Oct  9 21:39:56 allsky allsky.sh[25030]:      ***** Stopping AllSky *****
Oct  9 21:41:58 allsky allsky.sh[25457]:      ***** Starting AllSky *****
Oct  9 21:41:58 allsky allsky.sh[25457]: CAMERA: ZWO
Oct  9 21:41:58 allsky allsky.sh[25457]: CAMERA_SETTINGS: /etc/raspap/settings_ZWO.json
Oct  9 21:41:58 allsky allsky.sh[25457]: Starting allsky camera...
Oct  9 21:42:00 allsky allsky.sh[25457]: /home/pi/allsky/allsky.sh: line 166: /home/pi/allsky/capture: No such file o
r directory
Oct  9 21:42:00 allsky allsky.sh[25457]: 'capture' exited with RETCODE=127
Oct  9 21:42:01 allsky allsky.sh[25457]: *** After fixing, restart the allsky service. ***

@maphilli14
Copy link

also fwiw i used to use the same setup with 4sec 250gain exposures for over a year as an allsky camera. during that time i used the zwo sdk and oacapture to test things with prior, should I try that again?

@EricClaeys
Copy link
Collaborator

@maphilli14 After running make capture you need to run sudo make install to get it to copy the "capture" command to the correct directory.
What was CAMERA in config.sh before you set it to ZWO? Blank? We now set it to blank to force people to update the file since several names changed.

Definitely try with oacapture. If it works and AllSky doesn't then it's something in AllSky. If oacapture doesn't work either it points to a hardware problem.
Where can I get oacapture?

@maphilli14
Copy link

Seems to fail going beyond 1000ms in oacapture too

image
:(

I'd have to remove and put into windows to see if it's a driver thing or camera thing.

@EricClaeys
Copy link
Collaborator

@maphilli14 That probably points to a hardware or SDK issue; let's see what happens under Windows.

Where can I get oacapture?

@maphilli14
Copy link

maphilli14 commented Oct 12, 2021 via email •
edited
Loading

@EricClaeys
Copy link
Collaborator

@maphilli14 I'm closing this issue since it's been resolved, and opened https://github.com/thomasjacquin/allsky/issues/650 for the problem you're having.
Eric

@EricClaeys EricClaeys mentioned this issue Oct 21, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@EricClaeys EricClaeys

Labels
bug needs software change
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests