![]() ...
·
![]()
·
1
like
|
---|
I am recently having a problem where my camera will randomly stop writing to the hard drive, and I was hoping to get some input to help me trace this problem. So the issue is: Every few hours at relatively random times the camera will "apparently" stop writing to the hard drive. Naturally, this is a problem as the telescope stops shooting images in the middle of the night. I have examined the NINA log and everything in the system is trying to work but the camera fails to write to the hard drive with no indication of preceding errors. I get an error that says: 2024-04-23T02:21:40.6801|ERROR|CameraVM.cs|Capture|754 NINA.Equipment.Exceptions.CameraDownloadFailedException: Camera Timeout - Camera did not set image as ready after exposuretime + 60 seconds - Exposure details: Exposure time: 60, Type: LIGHT, Gain: 130, Filter: Hardware: Beelink U59 computer, Player One Ares-M camera, Player One Phoenix 36 mm filter wheel, Sky Watcher EQ6Ri mount. Interface is NINA, and I am using EQMOD to run the mount. I am using the Player One drivers for the Xena-M guide camera and the Ares-M imaging camera. The Beelink U59 mini PC has two hard drives, an internal one that runs NINA, EQMOD, Stellarium and all the drivers, and a Sandisk Extreme 1 TB SSD connected by its OEM USB C to USB C cable.I am having trouble tracing it because on the same day NINA came out with their 3.0 update, the SSD arrived in the mail. Both were added to the system at the same time. Until then, everything was working fine. Now, I am pretty sure this issue either relates to a bug relating to NINA writing to an external hard drive, a Player One camera driver error related to changes made to NINA, or to the SSD. My questions are: 1. Has anyone else had trouble with NINA directing image files from the camera since the 3.0 update? 2. Has anyone using Player One cameras experienced problems with their cameras since the NINA 3.0 update. 3. Or has anyone experienced problems with the Sandisk Extreme SSD? Additional Note: I think the problem is related to the SSD. I had it connected through a USB 3.1 rated hub but sometimes hard drives don't like hubs, even good hubs. Thoughts? |
![]() ...
·
![]() |
---|
Try saving on the internal SSD and see if this solves the issue. If it does then you know who is the culprit if not you can move on to the next step: either the cables or the drivers. BTW, I get download failure errors at times but NINA keeps on executing the pre-ordered sequence.
|
![]() ...
·
![]()
·
1
like
|
---|
I had the same error once, but I don't use an external hard drive. I can't remember if it was when I was plugged in to a USB hub, or if I simply switched a cable. I would try what Andrea suggests. I don't know what your set up is exactly, but I use the Remote Copy plugin to get all my images from my imaging rig to my normal PC. That could eliminate the need for the external drive on your imaging rig. |
![]() ...
·
![]() |
---|
andrea tasselli: That's what happens for me. NINA keeps on executing but the files won't save. |
![]() ...
·
![]() |
---|
I have had this happen a few times. I don't think it is NINA because it seems to be an issue with Camera Hardware or Driver not responding with an image. It happened in SharpCap as well so NINA is probably not the issue. Reconnecting the camera usually fixes the issue. Aside from that I always write to the local SSD then copy to an external drive. There is a NINA plugin that does this for you in the background. There is also a NINA plugin that will re-connect/cycle your camera on download failure but it kills the cooling so it is not the best option. |
![]() ...
·
![]() |
---|
I have read external hard drives, whether platter or SSD, really should not be plugged into a hub, so I found a USB C to USB C 3.1 cord, removed the USB hub and connected the SanDisk 1 TB Extreme SSD directly to the USB port. I also came across some information that was uncertain but indicated you should have NINA write to a directory in a hard drive, so I setup a directory. I have had the system dummy imaging all day and night. It's shot 1200 dummy images so far but experienced two camera file writing hangups, and I think I found the problem! And it was not at all what I expected. The glitch seems to relate to NINA and PHD2, specifically the Center After Drift instruction in the Advanced Sequencer. Since the NINA 3.0 update, Center After Drift is bugged. I can say this conclusively because even with it deactivated in the sequence, it will still try to center the mount. The camera will continue to film while Center After Drift tries to work but will not record. Sometimes, once Center After Drift is done, camera file writing does not resume. I am not a programmer. I don't know how or why this is but it is the error. Even with Center After Drift turned off in the sequence, the system tried to center once per hour all day and gave errors when it couldn't. Twice (so only 2 out of 12 times) the camera would stop writing to disk at that point, though it continued to loop. Oh, the wonders of modern tech and its endless gremlins. |
![]() ...
·
![]()
·
3
likes
|
---|
Addendum: I just heard back from Player One . They have had other reports of this bug since 3.0. They are presently updating the PO driver and already have an updated ASCOM driver out. I am currently running a six hour test on it but it appears to have resolved the issue.
|
![]() ...
·
![]()
·
1
like
|
---|
Hello @Sky Story ! I write here because I have the same failure as you... Since June 2024 I use a Player One Poseidon M Pro in remote, with Nina (last version) and mini pc. After a few hours, randomly, an error notification appears. "transfer to camera failed" (written in French so I translated by muselé, maybe not 100% same wording as yours :-) ) But the session goes on, at each final light, it tried to save but fail. It tries again and again, sometimes it reaches to save again after a while, sometimes not. I am quiet sure my problem is the same as yours. I wanted to know if you solved the issue and what corrective actions did you find for ? I will try a night whitout automatic centering after drift instruction. Does someone knows how to disactivate PHD2 to scan the equipment to avoid that the main camera is choosen for guiding? Thanks a lot for your support :-) Nicolas |
![]() ...
·
![]()
·
1
like
|
---|
Nicolas MARTINO: Salut Nicolas, I think I have resolved the problem. A couple weeks ago the issue happened as soon as I activated PHD2. The imaging camera lost connection. This clued me in to the likelihood of a driver conflict. I checked the ASCOM drivers and found there were two drivers for the cameras, and both drivers referenced both my Player One cameras (the guide camera and the imaging camera). I deleted ASCOM camera driver 2 and removed the imaging camera from ASCOM driver 1. Then I configured NINA to operate the imaging camera from the Player One driver, and operate the guiding camera from the ASCOM driver. Since then, I have had no further failures. Hope that helps! |
![]() ...
·
![]() |
---|
Hi @Sky Story Thanks for the explanation! Do you use a Player One camera for guiding too ? Or only for imaging? I use a Poseidon as main camera and an Ogma for the guiding. But I saw in the Ascom profile explorer that the Player One Ascom drivers was bounded 2 times to the Player One (and I got a list of 2 camera choices in Nina) I will delete one bind and only keep one Ascom driver bounded to the camera. And hope this will erase the problem... Clear skies, Nicolas |
![]() ...
·
![]()
·
1
like
|
---|
I use a Player One Xena-M for guiding and a Player One Ares-M for imaging with the SCT. I had the exact same issue: there were two ASCOM drivers for the cameras and each showed both cameras. I deleted ASCOM 2 and removed the Ares-M from ASCOM 1. ASCOM 1 now only runs the Xena-M and the Ares-M is run only with the PO proprietary driver. It all appears to be working properly now.
|
![]() ...
·
![]() |
---|
For your case it make sense as the 2 cameras are a Player One. It's not my case so I'm not sure PHD would scan all Player One ascom drivers when my camera is an Ogma… or I am wrong and PHD would anyway try to change camera as there is an available driver ? |
![]() ...
·
![]() |
---|
Are both your cameras in the same ASCOM driver? That is probably the problem. The issue only occurred for me when I had PHD2 on, so it's definitely related to PHD2. It would happen when PHD2 would lose and then restart guiding. I use NINA, and I also found it helped to start PHD2 and connect the guide camera and mount before starting the imaging camera. |
![]() ...
·
![]() |
---|
![]() ...
·
![]()
·
1
like
|
---|
I don't know anything about programming, but from my experience I would suggest getting rid of all those extra ASCOM drivers. Use the PO proprietary driver to operate the Poseidon and the ASCOM for your guide camera. For whatever reason, PHD2 seems to get the ASCOM drivers confused.
|