Jump to content

Canada's top-tier Telescopes & Accessories
Be as specific as possible when reporting issues and *ALWAYS* include the full version number of the application you are using and your exact *CAMERA MODEL*
NEVER POST YOUR KEY IN ANY PUBLIC FORUM, INCLUDING THE O'TELESCOPE SUPPORT FORUM ::: IF YOU DO YOUR KEY WILL BE DEACTIVATED WITHOUT NOTICE!
  • 0

Back again with imaging aborted


cruxaustralis
 Share

Question

Hi there,

after using BYN for years without any problem I'm stuck with the recurrent problem of aborted imaging sessions. I changed the cable as suggested earlier ( a Nikon one), fastening it with tape so it wouldn't move. But the problem remains. It's a bit of a nuisance having to go outside repeatedly and check whether the session is still running or not. Last night I noticed that even restarting a session ( which has worked so far) doesn't work anymore. I waited for a couple of seconds to see the program starting, then left only to see after an hour that no picture at all had been taken. I copied part of the logfile that includes the timespan in question. The whole logfile is too big to be sent.

Text1.txt

Link to comment
Share on other sites

  • Answers 19
  • Created
  • Last Reply

Top Posters For This Question

19 answers to this question

Recommended Posts

  • 0

Hi there,

these are the 2 logfiles from Oct 17th.

The logfile 211017 includes the time from the start to the unintentional abort at  22:44:29,336

Restart after noticing the abort  at 23:04:15,755

Intentional abort at 23:48:05,223 after an unsuccessful attempt to acquire flats.  Download of 1 second - flats  unsuccessful, took more than 60 seconds, program seemed to freeze

2nd logfile includes the unsuccessful attempts to restart the program, same problem with the download of flats. Session therefore finished at 23:51:07,231.

 

 

Logfile 211017.zip 2nd logfile 211017.zip

Link to comment
Share on other sites

  • 0

Thanks, I have never had a false positive before with Defender.

To the OP, I would suggest checking the USB cabling. The first indication of an error is the image download failure at the reported time. Subsequently it appears that the same error occurred at 23:47.

Download failures are often caused by interference of anti-virus software, but it did work initially so I would not expect that to be your issue. Cabling is the next most likely cause.

Link to comment
Share on other sites

  • 0

The actual error is a download timeout; meaning the camera has failed to provide an image after the image was taken and BYN failed gracefully. I am not sure why it happens, but this is not cause by BYN.... BYN simple waits for the camera to notify an image is ready for download, but the notification never comes.

2021-10-17 23:48:17,569 [CameraTakePictureOnMessageRecieved] ERROR - Image download timeout, process terminated after 60 seconds
 

On the upside, I think I just fixed this nasty/repetitive int32 parsing error... it's actually a warning/info message when trying to read the noise reduction property; it should have never been logged as an error in code.

Link to comment
Share on other sites

  • 0

Oh.... and in your second logfile, the camera disconnected and BYN failed gracefully.

2021-10-17 23:50:58,683 [Main] INFO  - Camera action fired: 'MaestroDisconnect'

Could this be cable drag?  Dead battery?  Poor USB cable/connection?

Link to comment
Share on other sites

  • 0

A comma? I changed that to a period earlier that after being notified of that being a possible reason why the exposure time was not given to every frame. But the exposure time is now quoted correctly.

No, I didn't use the Ascom control of BYN. The scope control is not connected to BYN, it's via the Celestron hand controller.

Link to comment
Share on other sites

  • 0

I am not sure what is going on then because the timestamp of every line in the log file has a comma as the decimal separator like the following:

2021-10-17 21:03:56,402 [Main] INFO  - BackyardNIKON 2.1.3.29671 started!

It shows the seconds part of the time stamp to be 56,402. Notice the comma before the fractional seconds.

Confusion reigns.

Link to comment
Share on other sites

  • 0

I did see that it wasn't consistent.

AFAIK, the DateTime.ToString() method needs to use a custom format string to display the fractional seconds. Are you sure that you are not always using the comma as the decimal separator?

CurrentCulture.CultureInfo.NumberFormat.NumberDecimalSeparator should give you the current decimal separator for the user's selected number format settings.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...

Important Information

This site uses cookies to offer your a better browsing experience. You can adjust your cookie settings. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies, our Privacy Policy, and our Terms of Use