JonCarleton

OK..second processing attempt. Darks added and some more time in GIMP. Still pretty noisey.

Good, clear nights have been at a premium the last month, but I have managed a few sessions and decided to try M51, as it is listed as "EASY" in most of the HOWTO's and videos about the night sky. For the last month or so, I have tried and failed more times than I care to mention. Granted, most of the nights there was a high level mist layer that made only bright stars visible with the naked eye, but I figured I could manage if I kept at it. I failed a LOT. For a while I doubted the ability of the GOTO scope to get close enough for me to identify the target. I even spent one night with an angle finder and compass trying to verify the Alt/Az numbers on the reflector tube (a method that has served me well for objects that actually ARE easy). Eventually, I did a 1 star alignment on Alioth (the nearest star presented as a default option for alignment in SynScanPro) and then did a GOTO to the object. This time, it worked, though like most deep sky objects I have managed, it was not very obvious. One hundred ten-second subs later, I had something to work with. Here is my initial result. I still have work to do with the image. I didn't even apply darks to this one yet, it has a lot of noise and I seem to have lost a bit of focus in the stacking (Siril) compared to some of the single images. Processing suggestions gratefully accepted.

I got this shot by getting up at dark-thirty, just before the sunrise. I'm not posting my Saturn, as I couldn't get a clear focus. We've had a "smutz" layer at high altitudes that "looks" like clear sky until you try to focus through it. 10" SkyWatcher Dob.

I just trimmed some hardware off my rig, including that nasty SynScan hand unit and its connection to the Pi. I'm all WiFi now excepting a USB cable from the Pi to the focus motor and they are both mounted to the scope, so it barely counts. The only knot in the rope is the SynScanPro app having to run on the Android Tablet...and of course, alignment. It goes like this now:

Not to be a fly in the pudding....and this may just be an INDI thing, but I found that when I did an alignment using the SynScanPro app, I could not get the INDI driver to connect. It sent back the error that I first needed to align the scope. When I used the handset for the alignment, INDI was perfectly happy to connect. I can live with that, but I prefer the SynScanPro app as well, the handset doesn't have a 3 star alignment. This could be because the INDI driver is running on a Raspberry Pi located on the scope and connected to the handset via USB cable. I suspect that the WiFi interface is located in the base motor and bypasses the handset during a WiFi connection. And no...that's not enough to make me go out and buy a Windoze machine so I can run ASCOM drivers

Careful..you give away your age when you confess knowledge of pip Keep that up and I'll have to tell you my "Colossal Cave" story.

Alas, I am a member of the UNIX religion (and Linux, these days). I am gleefully ignorant of all things Windows and do not even own any Windows hardware. Even running Windows software in an emulation for testing is something I avoid like taxes. I can't help at all with Windows issues (I'm still mad at Bill Gates for killing CP/m in 1980).

Agreed..but seconds is enough to mess me up. My camera has a really narrow FOV and I doubt I could get a position match from some of the little patches of dark to which I have been pointed. More testing today...we'll see.

Not sure. I was having issues getting my location's exact lat/lons in place to the n'th degree and ended up hacking the Stellarium database to get it where I wanted it. I'm going to test again this afternoon and see if that helped. If not, I may try "adjusting" my location lat/lons or location timezone to get things to match up.

Down and to the right is my issue as well. More down than to the right, however.

I did some testing and find that my KStars and Stellarium do not agree on Az/Alt numbers. Running simultaneously, I can pick a star in each package and get different numbers. In each case the Az is as much as 2 seconds low and the Alt is up to 6-8 seconds low. Where's my hammer............

In my use of the SynScanPro app, it expects the telescope SynScan unit to be an access point (on mine, 192.168.4.1). Typically the SynScanPro app picks up 192.168.4.2 from the telescope access point DHCP server. After that, I hit connect and all works well. I am still having trouble with Stellarium not agreeing about that Alt/Az of targets with the hand unit...but that's not your issue.

It seems possible that Stellarium is double-dipping the DST adjustment. I need to spend some more time testing to find out exactly what's going on. Fudging the actual time zone or location is certainly on the table for testing. I know that if I select a star in KStars and the same star in Stellarium, I get slightly different coordinates. The telescope locations for each software package are a few tiny fractions of a second off, due to some rounding that is done in storage and retrieval, but I don't think that's enough to yield the level of difference I am getting. This is why I think it is a DST issue.

Let me admit first of all I am having issues with Stellarium talking to SynScan with coordinate accuracy presently that I am trying to work through. Although, I suspect my particular issue may be a DST or location setup thing. And, I am using Linux and the INDI driver. However, a Windows user put forth the following suggestion: https://www.cloudynights.com/topic/679620-stellarium-direct-ascom-support-testers-wanted/ which includes support for ASCOM. You'd have to find out if it can use WiFi instead of the direct connect. Everything I have read so far indicates that the new Stellarium can use either ASCOM or INDI drivers, remote or local and that StellariumScope is well on the way out. I have had no connectivity trouble at all using the INDI driver running remotely on a Raspberry Pi with a USB cable to the SynScan hand unit. I connect to the Pi via Wifi, so there was no real need to connect directly from the PC to the hand unit WiFi. There is also the issue of the SynScan hand unit WiFi requiring a keep-alive pulse to prevent it turning off. The SynScanPro app provides a keep-alive pulse.

Good idea...but there is one major flaw in that slaw...I am a member of the UNIX religion and do =not= run, nor own Windows. Nor do I care to. I have only just managed to evolve ever-so-slightly away from Solaris to Linux in recent years, but that is, in my mind, only a minor transgression. That said, I have considered running Stellarium with a serial connection in a more direct mode, I see that people have done that with some success. But if I can find a solution to the misdirection I am getting from Stellarium vs. KStars, I can stay wireless. I see that as a very big plus. It may be that I'll have to do some packet sniffing and see what is actually being passed over the network. It would, of course, be MUCH easier if I luck across someone who has already solved this particular issue

The big difference between the two is the diameter of the reflector. While this impacts the F-value, bigger diameter means more light gathering ability. Look at the specs for the reflector diameter for each scope (aperture). Of course, "bigger is better" only applies to the point you can lift and transport the beast. I'd love to have a 16" mirror...but I couldn't lift it, store it, or transport it. Oh...and with either choice, invest in a right-angle adapter for your finger scope. Or better yet, get your vendor to swap out the straight finder for one with a right-angle eyepiece. You'll thank me later.

I have been having a problem slewing running SynScan with Stellarium and an INDI driver. However, switching to KStars with the same INDI driver, it was on target (+/-) every time. Since the inaccuracy with Stellarium was about 15 degrees, I suspected a time issue, probably related to DST. And therein lies the problem: SynScan's time prompt asks for the 24 hour timestamp, which we can ASSUME is local time, then the UTC offset, and finally the Y/N for DST. This, in itself may be subjective. For example, I typically enter my 24 hour localtime, my standard UTC offset (-5 hours for Atlanta, Georgia) and currently, for the Spring/Summer DST YES. This in the hopes that it is making a -4 hour correction for Spring/Summer. It =seems= to be the correct approach. KStars, seems to take localtime from the computer clock, which is good. Like SynScan it seems to want a DST-independant -5 hours UTC Correction for Atlanta, Georgia, and asks for a "DST rule" that it apparently uses to convert to UTC. I tend to prefer this method, as it seems clear (to me, anyway) what the programmer intended. Stellarium wants a time zone, based upon cities and countries along a longitude line, then asks to enable or disable DST. I run with Americas/NewYork and enable DST. The onscreen display shows UTC -4, which is correct for this time of year. Stellarium also has an option for a "custom time zone," that I have not tried yet. Like KStars, it takes localtime from the computer clock. Since SynScan and KStars use more or less the same setup values, it isn't really a surprise that they work well together. Even though the Stellarium setup -seems- to make sense, it is pretty clear that it somehow doesn't match what KStars is sending the INDI SynScan driver. I suppose I could just use KStars and dump Stellarium. But, I -like- Stellarium and some of its features. Always the way it is, no?

Thanks, Rick. I did consider the sky star thing. I frequently do alignments as soon as I can make out Sirius, and when it skews to the next far less brighter star, I can't see it at all in the sky, but I can use it to align as I see it clearly in the scope. The heads-up for the flats makes sense. I'm going to have to find a way to key my camera to the focuser. I can see that.

Thanks again, Olly. My GOTO mount is a Dobsonian ALT-AZ. But I believe I get the idea. Results may be a bit different, but I should still be able to use star trails for a camera alignment.

Thank's Olly. My setup is not permanent and my SVbony305 is like an eyepiece. Excepting the brand stamp on the back there is no real way to tell exact alignment, it may not go in exactly the same way each time. I suppose I could scribe alignment marks on the camera and focus tube. I typically swap it out for a variety of eyepieces as I am selecting my target and trying to find it. Once I find a target and center it, I put the camera in and take my lights. I would prefer to leave the camera in place and look about that way, but it has a very narrow FOV and I have neither the experience nor the GOTO accuracy to find objects without a bit more sky to view. I have ordered a .5x reducer to help with that issue, but I don't expect great improvements from that sort of adaptation.

OK, got it (I think). So, no using the 1960's tie-dyed T-shirt or the white one with the big coffee stain on the front. I actually do own a plain, white T-shirt. If I can't find it, I can always put on a HAZMAT suit and pick one up at Dollar General. Thanks all!

A sky shot is certainly an option. I wonder if I need to wash out the blue or shoot in monochrome mode or will a blue flat work?

A pure guess, but since it is clobbering the bottom bit of your image, it smacks of not enough time to write the whole image (most software writes images from top to bottom). Or asking the camera to do something else before it finishes writing. For a DSLR, this might be due to a very slow or defective SD card combined with large images and/or short time between images. For USB cameras, perhaps a USB3 camera into a USB2 port or something busy going on with the host computer. If you are using a Raspberry Pi, it could be the microSD chip used for the drive is too slow. If you reduce the image size significantly and the problem goes away, then one of the above is probably in play. Otherwise, look for something mechanical.

Ah, I was hoping to do the lights "sans telescope." I have a 10" Dob and that would take one big tablet to cover. I would have to use a 22" or larger laptop monitor to cover the aperture. I suppose that eliminating the scope from the mix would negate the value of removing defects that originated in the scope itself. Rats! Thank's though. I ask stupid questions to become less so.

I recognize the need to darks and perhaps bias shots each time you photograph, as they are noise-dependent and subject to ambient conditions. My understanding of flats (or lack thereof) leads me to believe they are not so much about temperatures or transient issues. This leaves me with a few questions. First, to the main procedural question: Must flats be taken at each and every photo shoot or are they something you do once, or perhaps periodically? Now the operational questions: I'm thinking about using a tablet I have (LCD) and going to "about:blank" in a browser to create a white screen, then set the camera (SVBony305) right on top of the LCD screen (pointing at, and in contact with the screen). Is this a reasonable procedure and do I need to space it off the screen some (and if so, how much)? Or is that a really bad idea for reasons that would become obvious after the fact?