Issue with Nightscape 8300

Greetings! First, as a new astrophotographer kudo’s for the interface of SGP … it’s really nice, very easy to set things up and the tie-ins to other software like AstroPlanner, PinPoint, PhD and others really makes it easy for someone to get something done … again, kudo’s! My money was very well spent on this!

My problem is with my primary CCD, the now-discontinued, now somewhat reviled Celestron Nightscape 8300. I’m running under ASCOM 6.2 SP1 with the ASCOM driver for the C8300, and it works well with both AstroFX and MaximDL 6.13; both give me images.

Using SGP 2.5.1.17, however, with the C8300 set as camera it connects and I can manipulate the fan speed, but taking an image with either a light sequence event or a ‘frame-and-focus’ button press yields the same … a uniformly white “image”. Changing exposure time, changing binning, changing lot’s of things still results in the uniformly white image (and that’s with scope cap on, so it should be giving me a dark), everything else looks normal (it exposes for the right amount of time, spends about the right amount of time downloading, just gives me a white goose egg)

Changing the camera to the Orion G3 (ASCOM), the StarShoot AutoGuider (ASCOM) or a Nikon D90 results in expected images; darks look like darks, lights have blobs, etc. It’s just the C8300 that doesn’t work properly, and only with SGP … (sigh)

There was one other fellow with a C8300 problem, but I don’t have what he described and I’m comfortable with using SGP with my D90 and fighting with Maxim for the C8300 … but I’m hoping there’s a way to get the C8300 working since it’s so much easier to do a target sequence with SGP than with Maxim!

Thoughts? Thx again!

Logs and examples would be great.

Glad you like it

Might just be an auto-stretch error on SGPro’s part. You might try yo manually stretch the image or open it in another application to double check.

As Chris mentioned, we would need logs showing the issue to provide any other insight.

I really appreciate y’all helping with this … it’s maddening, such a powerful and useful program, foiled at the last second … sorry for the length of this post also …

I ran four experiments; one with a simple “one shot focus” of the Orion SSAG, then of the C8300, then using MaximDL of the C8300 using their direct driver, finally one of the C8300 using the ASCOM driver that SGP uses. Each picture was with the lens cap on, in quick succession with as much cruft removed as possible …

First, the SSAG experiment, there’s the logs …

Dropbox - File Deleted

… this was from this initial condition …

… and resulted in this image, a nice dark …

I then repeated the experiment using the C8300 as the camera, here’s the log …

… which had this as the initial condition …

… and resulted in this as a captured image … not a nice dark, a uniform white (sigh) …

To verify that my camera wasn’t wonky, I then loaded up MaximDL 6.13 with first the native C8300 driver and did the same exposure … here’s what I got, a nice dark …

… and realizing that SGP uses the ASCOM driver for the camera and not the “native” driver that MaximDL uses, I then reloaded the Maxim camera with the C8300 as driven by the ASCOM driver … and another nice dark …

It’s pretty baffling, I didn’t see anything strange in the logs between the SSAG and the 8300 and it seems to be performing OK under the native driver as well as under ASCOM for MaximDL. The SSAG experiment worked properly, which means that SGP is doing what it needs to do for the focus/ capture/ display path, just not for the C8300. The crosshairs are being displayed on both images as well …

(sigh) Like I mentioned, I’m OK for using SGP with my D90 and G3 (which works well) and when I need to use the C8300 with the miracles of COM automation and AutoIT and a lot of elbow grease I can craft together something where the SGP events instead of taking lights just call scripts which control MaximDL captures, I’d just really prefer not to …

Thx again!

Redo of the SSAG dark (sigh)

Would you mind terribly just posting a link to the logs so that this thread is readable in the future? Thanks!

Also, can you upload and provide a link to the “bad dark”?

Sorry, my bad! Didn’t read the posting hints until after I composed the message … DropBox is installed and such, here’s some links …

To the “bad dark” Dropbox - File Deleted
… to the “good dark” Dropbox - File Deleted

… to the SSAG logfile Dropbox - File Deleted - Simplify your life
… to the C8300 logfile Dropbox - File Deleted

Thx again!

Sorry, I should have specified. I will need to take a look at the linear FITS image.

Done! Thanks again for your help!

Here’s a light capture of the SSAG camera … [ Dropbox - File Deleted ] and it’s logfile [ Dropbox - File Deleted ]

Here’s a light capture of the C8300 camera … [ Dropbox - File Deleted ] and it’s logfile [ Dropbox - File Deleted ]

Here’s a light capture using MaximDL of the C8300 using it’s direct driver [ Dropbox - File Deleted ]

… and another from MaximDL using the ASCOM driver [ Dropbox - File Deleted ]

The light capture shows the same “whiteness” of the focus capture (which narrows things a bit), hopefully the FIT info will give more clues … :slight_smile:

Looking at the various FITS files using MaximDL, it looks like the C8300 light does look like its a good dark, even though it’s displayed in the SGP window as all white …

It’s also much larger than the Maxim FITS file, four times larger at 16M versus the Maxim 4M. The SSAG FITS file is only 2M, reasonable as it’s half the pixel density of the C8300. SGP may not be able to handle a CCD image of that size for the display, to say nothing of why it’s generating a 4x larger file …

… hmm … :slight_smile: … the game is afoot!

All KAF-8300 1x1 images are 16MB. I think you have Maxim binning.

KAF-8300 are actually pretty small… If we can’t handle that we are in trouble.[quote=“CodeWorrier, post:11, topic:4269”]
Looking at the various FITS files using MaximDL, it looks like the C8300 light does look like its a good dark, even though it’s displayed in the SGP window as all white …
[/quote]

Looking at the file you provided for download, that image is just BAD. How are you arriving at that conclusion?

Ah, didn’t know that 1x1 8300 images are 16MB … good to know! As to the dark being “good”, that was just an observation that when I opened it in Maxim it wasn’t a uniform white field, it had the specklies that darks have … so, it’s bad, got it!

Let me know if there are more experiments I can run, thanks again for your help!

For more samples, I loaded up the beta SGP and ran the same experiments … one light with the SSAG, two lights with the C8300 … same results as before, hope this give more insight! Thanks again!

The SSAG light logfile Dropbox - File Deleted and the result Dropbox - File Deleted

The first C8300 light logfile Dropbox - File Deleted and that result Dropbox - File Deleted

And the second C8300 light logfile Dropbox - File Deleted and that result Dropbox - File Deleted

@CodeWorrier

These FITS samples are all linear? If so, I don’t really have any great suggestions. Maybe the camera’s ASCOM logs might provide some further hints.

If I were forced to guess I would say that the ASCOM driver is possibly not thread safe and when SGPro hits it from multiple threads it gets into a weird state. Have you tried to take images from SGPro with the cooler off?

Hmm … I don’t know enough about FITS files to understand the “all linear” statement … I tried looking for any camera ASCOM logs, nothing found so if you know what keyword to enable in the ASCOM profile explorer I can see what’s up with that …

I don’t see where to disable the CCD cooler from inside SGP, I can only adjust the fan speed from there (although killing the cooler would seem to negate the value of the 8300 versus my D90) but it’s still worth a shot, where would I do that?

I can forward over the FITS files from the ASCOM 8300 grabs that MaximDL makes, those are using the same ASCOM driver, maybe that will help …

Thx!

Hey Ken! OK, trying to determine what was wrong with the FITS file to better see what could be off … I tried loading the two above files in about every FITS editor I could find, they all loaded and showed what looked like a “dark”, even with the long lit streak of a pixel column error … but everyone loaded the FITS file fine, no complaints …

I then surfed on over to the NASA FITS file verifier page [FITS Tester Page] and tested the two FITS files … here’s what I got …

and then …

neither of which show any kind of damage or strangeness …

Is there a way to have SGP have a “… display that busted, all-linear, you’re on your own file” for the focus/ light window display? That way it’s all on me if it’s a good FITS file or not, rather than a solid white display?

Thx!

I guess I’m not really sure of what you’re after. The data SGPro has access to is just bad. There is no setting I’m aware of that can make it not bad. The images you provided show a minimum ADU value of 63493 (that is super bad).

Linear simply means “unmolested” pixel data straight off the CCD (not stretched).

Ah, got it … OK, I found the TEC control, fiddled around with it a bit, no difference. You’re saying that the minimum ADU was just a few thousand electrons off of full saturation, which for an exposure with the cap on makes the sensor useless for actual work (even if I set a pedestal to something crazy like 63400) …

(sigh) So, I’ll stick a fork in this and call it done … SGP works very nicely with my D90 and G3, just not with the 8300 … Maxim works nicely with the 8300 and the G3, but for some reason (even with the DSUSB) can’t do an exposure longer than 30 sec like SGP and BYN can do …

I’ll use the proper tool for the proper instrument, I guess … thanks much for your help, I’ve learned quite a bit!

Hi,

If you have MaximDL, take its Nightscape driver and open it with SGP PRO (right click the driver, open with program…) . Then the camera works properly in SGP. This is the only way I got it working.

1 Like