Feedback - Potential Customer on the fence

Hello, I thought about making this post for a long time, I’ve finally decided that if I just lurk, instead of posting, then you won’t know my feedback, so here goes…

I downloaded the trial a week ago, my friend keeps talking about how wonderful the software is and how I need to switch over. Here is what my experience has been / is:

First some background, I’ve been doing Astrophotography for just under a year now, and have only in the last 4 months started getting really successful results. I’m currently using my Canon 70D DSLR, an Explore Scientific ED127, an Orion “magnificent mini” autoguider setup, and an Orion Atlas mount that I had to rebuild after I bought i used. I started using a combination of Stallarium, Backyard EOS, Astrotortilla, and PHD2 in order to get my best images. While this combo has proven reliable, it’s very labor dependent in that I as the human have to constantly remember to do the correct action at the right time in order for things to work properly (Backyard EOS will tell PHD2 to Dither, but you have to use Astrotoritilla “by hand” to plate solve). So while it works wonderfully, it’s also more labor intensive.

My good friend who I go out imaging with a lot, has a CCD setup and has been using SGP for quite a while. When I learned that it would support DSLR I thought I would give the trial a shot. I was out at one of our darksites last night for my first real go at using the software after having done the simulator tutorials.

After setting up and polar aligning with my PoleMaster, I fired up SGP, created my hardware profile (luckily I had most of the needed info on hand from my other software, and I also had cell service at this darksite thankfully so I could lookup the pixel size of my sensor). I then created a simplistic sequence to shoot some of the Andromeda galaxy (wanted to start with a fairly bright object to make troubleshooting easier), and that’s when I started getting odd images. They were very dark and only contained a few stars. They looked underexposed. However the software was dutifully counting down the 5 min exposures, so I continued like this for a few hours, thinking I must be crazy. I then swapped to Backyard EOS to compare and could see that indeed something was very wrong.

After much searching on the interwebs I finally stumbled upon a post (and I apologize I can’t find it again, otherwise I’d give full credit to the guy who posted this fix), but it turns out that Mirror Lockup causes the software to only take the exposure for the time of the mirror lockup setting, in my case 2 seconds, yet the software counts down the full 5 min. This feature works correctly in Backyard EOS and since I had been using that setting successfully for months I kept it in my setup of SGP initially.

Eventually by the end of the night I was able to get a few subs of the Flame and Orion Nebula’s with SGP, and I ended up using it to get my calibration frames (bias, dark, flats), and btw the Flat’s wizard while nice, failed after X number of attempts, but turned out had it continued for 2 more iterations it would have been there (I ended up restarting it and setting manually the max exp. time and it was able to home in on the proper settings a little faster that time).

All in all - I’m pretty on the fence for the price right now. If I already owned a CCD and filterwheel and autofocus setup, then I’d be using your software all the way, but for my current equipment, and given the bugs I described (yes I most Def. consider the Mirror lockup thing a Bug that should be documented), I may end up holding off until I can finally afford to get a moonlight focuser setup I’ve been eyeing.

I hope that my experience and feedback will help you out. I think your software has some extremely amazing features if you have the hardware to back it up, but for those of us who are in a transition phase, it may make sense to wait on the purchase of SGP.

Best Regards

perhaps if you post the SGP logfile that corresponds to the mirror lockup bug Jared or Ken can take a look at it. without the log sometimes there is not a lot that they can do.

rob

Well, I concider the problems you’ve had to be minor actually. You’re using a completely different and new software package and you’re displeased with it because it didn’t work straight away with the same settings. Every software package I know has its own set of problems, it’s inevitable as nothing is perfect. However, if you’re going fully automatic, there really isn’t anything better. There are things like APT and KStars/Ekos now (which I use as well), but SGP is by far the most stable and feature-rich package I know of. Get to learn it a bit in a few sessions and then decide. I recommend it to everyone as well.

When I use my EOS, I have to enable the mirror lock up feature on the camera and in SGP. I too have taken an entire night photographing the back of the mirror when I forgot to change the custom settings on the EOS. On a long exposure however, it is debatable if mirror lock up is all that useful in an exposure of 10 seconds or more. Once you remember that, and use B setting, it works just fine.

What is more - it is documented in the instructions - so I had no excuse. Different applications use different parts of the camera’s API, so they may not all work quite the same.

This is not quite the case. SGP does not automatically toggle the mirror lockup feature like BackyardEOS does. Unfortunately canon made this different for every model and supporting it is annoyingly difficult. If your application specializes in controlling only Canon cameras it makes sense to support this.

So yes, this is different, especially if you’re coming from BYEOS, but you just need to make sure the mirror lock toggle is the same in the camera as it is in SGP.

Thanks,
Jared

Hey thanks for the responses. Just want to clarify that I’m not “upset”, my intention was to give you my raw and honest feedback as someone who downloaded and tried out the software.

I started by attempting to duplicate setup that worked for me in the past with other software. If I may make a suggestion, perhaps a quick warning dialogue box if you use a non-zero value reminding the user that they need to double check this setting in-camera and / or has been known to cause issues with certain models of camera? Feels like that would have saved me some time in searching out the answer.

All-in-all I’ve been pretty impressed with the mosaic wizard (haven’t had a chance to do a test mozaic yet, but have been playing around with creating the capture plans).

Are there any plans to support Stellarium? By that I mean I used to use Stellarium scope to initially slew to a target. With SGP I find it easiest to use Stellarium to CTRL + C the details and then paste in the cords for my target to SGP. With Stellarium scope you hit CTRL+1 to slew to target. I think it would be pretty neat if you could hit a key combo in Stellarium and have those cords transferred instantly to a new target in your sequence. Just a convienance thing I guess but could save a little time.

Again, great software thank you for supporting the community. I’ll probably wait till the new v3 hits and then buy :slight_smile:

1 Like

Yes that would be very nice. Or via Cartes Du Ciel which I use. :slight_smile:

1 Like

Hi all,

Thought I would update the thread, I went out in my driveway last night to practice more with SGP in preparation for this weekend (planning to head out to the darksite).

Unfortunately It’s now the next morning and I am at work, so I won’t be able to paste my logs till later.

I experienced regular crashes where I would get the windows “SGP has stopped working” dialog box, and have to kill the process from the task manager.

I also noticed that my EQMOD was behaving oddly, it would “lock up” of sorts. I noticed this when SGP commanded a slew to a new target, it then started the plate solve centering, but what happened was that the error in pixels kept climbing solve after solve, I realized that SGP was commanding EQMOD to move the scope but it wasn’t actually moving it.

I killed both SGP and EQMOD and restarted everything and it did not occur again that night.

The crashes seem to come after changing an operation. Example if the sequence was doing light frames and the next thing was flats. Or if it finished lights and was moving to a new target.

In all I have probably 8-12 seperate log files I need to put up on Dropbox. Since I’m at work and can’t do so yet, I was hoping maybe someone had some thoughts as to what could be going on?

I use an ASUS ROG gaming laptop (red backlit keyboard!), it has 8 cores with the hyperthreading and I think I have 8 or 16Gb of RAM in it currently (have to double check). Other equipment: I use a 10’ USB 3.0 cable to a USB 3.0 four port hub that is on the scope tripod. The hand controller is hooked to it via the USB to serial dongle. I use an Orion Starshoot guiding camera and the Canon 70D also plugged into the USB hub.

I made sure that I killed the Canon EOS software before the session along with any other misc background taskbar stuff. (Printer monitor).

I believe that I am on the latest or close to the latest version of SGP as I have around 15 days left on my trial.

I tried out DSO Browser also, I really like how easy it is to get a target list imported to SGP. If any other info would help let me know otherwise I will zip the logs and get a Dropbox link up asap after I get home today. Thanks in advance!

Logs link: Dropbox - File Deleted

I have an Avalon mount that uses the Synscan controller. It is a portable system. In the past I had, like everyone else, an EQ6, which I used with EQMOD.
When I switched to SGP, I debated whether to use EQMOD or the ASCOM driver for imaging. I decided, with SGP centering and meridian flip options to use Chris Rowland’s ASCOM driver. I don’t miss the bells and whistles that EQMOD provides, or indeed the occasional gremlin.

Interesting, I’ll do some searching and see if I can find it to try that. Thanks

I use EQMod with an AZ-EQ6 and never experienced those crashes. To me it sounds more like a problem in communication between your computer and mount. Many times when things start to behave weirdly, it’s a comms issue, sometimes caused by bad cables and such. I would definitely check on that and make sure the connection is of good quality signal-wise.

+1 - it may not be a comms cable either, check the power cable too.

Buzz I think your on to something. I noticed one night the red power led on the mount flickering/flashing. I thought/assumed it was because the boat battery box I run things off of was running low. Turns out it did it again the other night. I bet my cable is going bad… ordering a new one pronto

@rottielover - with respect to possible comms issues (high on the suspect list based on your description) what brand usb hub are you using? Is it powered?

Powered hub is essential (or direct connection to PC). Astro imaging experience of many has demonstrated that not all hubs are made the same.

DaveNL

It’s this: atolla Ultra Thin Design SuperSpeed 4 Port USB 3.0 Hub (Black) https://www.amazon.com/dp/B00WE65I5K/ref=cm_sw_r_cp_apip_SWlJAlAYMZiwT

It can be externally powered, but I have not had need of that yet. My Canon 70D plugs into it (self powered from its internal batteries, I have the two battery handgrip extender). The Orion starshoot camera which should be drawing 0.25a or less, and the USB to Serial adapter for the mount, again if that thing is drawing 0.25a there’s something wrong with it.

I didn’t have this many issues till recently. The change made was switching to SGP from a combo of Backyard EOS, astrotortilla, etc. I had previously noticed that the power led on the mount would sometimes flicker so I am out trying to source a new power cable right now for it.

I do have a spare 10’ USB extension cable, I could try plugging the guider camera in to its own USB port (I would do opposite side to isolate it internally to the laptop hubs).

The only other USB item is my polemaster but I use that at the start of the night to get polar aligned then it goes back in it’s case.

The theory of unpowered hubs and the reality sometimes differ and show up in astronomy. Some devices are notorious for being susceptible to small changes in power voltage levels and a long lead or the wrong hub can cause annoying issues. At one time there were reports of USB3 hubs having difficulties with USB2 equipment - but that may be sorted now. FWIW I know of several astrophotographers who have had issues with otherwise reliable hubs but when subject to external environment, are less than reliable. I think many of us have established a reliable hub and just stuck with it - often using the NEC chipset and with a robust power supply too. The one that consistently works for me and my friends is the StarTech Industrial USB2 hub, which uses a 12V feed. Mine is fully loaded with 10 devices and lives outdoors. I use high quality cables, as short as possible and use ferrite clamps on the sensitive camera cables, just in case they pick up or broadcast RF.

As usual XKCD has a relevant comment xkcd: USB Cables

USB? That’s Unreliable Serial Bus isn’t it?

I think it’s a shame that serial was killed off, large voltage swings and low speeds. It Just Worked. For high speed data transfers over long distance Ethernet.

2 Likes

Indeed - it’s ironic that more than half of my devices have USB to serial converters, proving that USB speeds are rarely required.

I managed to prove this was true the other night, first clear night for ages too.

I set up with my shiny new StarTech hub the other night and gave up after two hours of repeated equipment disconnects. I set everything up yesterday to troubleshoot it and noticed the power wasn’t plugged in for the hub. I connected it and it tested perfectly for over an hour.

Doh!