JonCarleton

I may try to look at the core dumps. In the past with other issues, I have not found raw core dumps much help. The version I am using is the compiled Sourceforge for Linux version. I haven't tried the raw python version from github...but I may this weekend.

I got a surprise last evening. The moon was making dim objects a bit tedious, so I started "collecting" Messier open clusters. I really don't like open clusters as a rule, but conditions make limits. In the midst of a quick peek at M-46 I found a smudge. It wasn't dust or a cloud, so I looked further. It was a nice little planetary nebula hiding in the cluster. Imagine that! NGC-2438 inside M-46 (100 - 20 second images stacked with Siril and processed with GIMP).

@BCN_Sean: Nope, got that right. I'm an old-school terminal kinda guy. cd is my friend. The only thing I drag is my feet. @JamesF: Yep, no avx support. I knew it smelled like a library issue. Odd that -none- of my hardware has it. Still, I don't generally buy hardware with an eye for graphics support.

The big green Download button on https://sourceforge.net/projects/starnet/ is what I used. It downloaded a StarNet_Linux.tar.gz that I unfolded into a directory that contained the executable and some shell scripts with demo files to test operation. Thanks!

I downloaded from SourceForge the StarNet++ Linux tar.gz file onto a few Linux Ubuntu laptops and desktops (all AMD64 processors) I have and crashed and burned with every attempt. I am running Ubuntu 20.04 on most of them, but I did try on a 19.x version for grins (also a fail). When I untar/zip the file and run the test shell script, I get a core dump. For that matter, I get a core dump if just try to run the executable. I am not running PixInsight and just want to run the program stand-alone. If I must, I'll load some other version of Linux on a machine to make it happen. Anyone have a working version running on some version of Linux that could advise the specs required. There doesn't seem to be much info on this issue in the mind of Google at present. If I had to guess, I'd say it is probably a library version issue somewhere. I have not had time to plow through the core dump to try and decipher that kind of issue and hope to fine a reasonable answer here.

@Bright Giant: Probably I just fat-fingered something and created a second post. Ended up with two and couldn't delete the second one...which was originally the first with the wrong image.

Apparently, one cannot delete a bad image upload.

M81 Bode's Galaxy - 180 subs @ 15 seconds, stacked with Siril, processed with StarTools.

M82 - Cigar Galaxy, 200 subs @ 15 seconds stacked with Siril and processed with StarTools (although I did a quick-and-dirty test process with GIMP that resulted in an image that wasn't significantly different from this one). I am very disappointed that I got no hint of the nebular flare that is supposed to extend above and below the galactic center. Apparently, I need many more subs to get that feature. A shame, as I would be reasonably pleased with this image if I didn't know about the nebula I failed to capture.

M1 - Crab Nebula 130 10-second subs stacked with Siril and processed with StarTools. Alas, yes. I know I still have squishy stars. Auto-focus works, but guiding doesn't. PHD2 seems to hate my mount...not really designed for Alt/Az, I suppose.

We had a good night of seeing conditions, so I got some distant targets, Cleopatra's Eye Nebula and Superman Galaxy. Stacked 100 subs @ 20 seconds for each image.

I have never used the SV105 for guiding, but the SV305 is my guide camera now. It has worked without fail with the indi_sv305_ccd driver for indiserver. I have used it to image in the past and occasionally now through the guide camera with exposure up to 30 seconds. I typically guide with an exposure of 2-3 seconds. There may have been some issues with the driver when it first came out that artificially limited the camera for ASCOM or INDI, but I know that, for INDI, at least, that was corrected at least 8 months ago. There have been some minor issues with the SV305Pro (not related to exposure), but that is an active project and if it isn't fixed today, it may be tomorrow. The SV105 is a V4L2 (basically, a webcam) device. I see no reason to believe that it wouldn't work with the indi_v4l2_ccd driver and PHD2, but I only ever used it for my initial imaging trials with VLC. It was not limited for exposure. Many of the issues people have with this camera (and really, any astro camera) are power related. You really need to run astro cameras using a powered usb hub. They are "heavy eaters" in the power department. It is not uncommon, for instance, to hear Raspberry Pi users complaining about computer instability after installing an astro camera directly to a USB port (without a powered hub). This can also occur with some laptops. This is especially important if you are running more than one camera to a computer (eg: guide camera and primary image camera). That is a lot to ask for USB power from a Pi or laptop. NOTE: I recommend setting the binning at 4x4 for the SV305 as a guide scope for PHD2. I have noticed that even if I set all the specs in PHD2 to 4x4 binning, it doesn't really set them in the driver. It also does not load the default configuration when connecting to the driver. My recommendation is to connect the camera in PHD2, then go to the Indi Control Panel->Options->Load to load the configuration on startup of PHD2. This assumes you went to the Indi Control Panel and set the bin to 4x4 and then Indi Control Panel->Options->Save when you setup the camera initially (I believe the bin setting isn in Indi Control Panel->Image Settings, but I have slept since I did the original setup, so that may not be right). It may be me, but I also think the contrast slider in PHD2 works backwards. There is probably a good reason for this, but if you don't see stars, perhaps the contrast is at the wrong end of the spectrum.

I would look at plate solving before guiding, but that probably won't work with Stellarium. You can use PHD2 for guiding with Stellarium, but you'll need to be running either an ASCOM or INDI driver for PHD2 to connect to the scope.

Just a guess...I don't do Windoze, so I don't do ASCOM, but INDI has a different setup in the Connection Tab for USB vs. WiFi. I don't know what the default is for ASCOM.

@Newforrestgump: If you are looking for goto control for your scope (and/or guiding) and want a wired connection. The simplest way is a USB A-B cable (same as a USB2.0 printer cable) connected to the hand controller, with the hand controller connected to the motor as marked in the scope manual. You then set the hand control to "PC Direct" and you should be good to go for basic pointing. You will need a driver whatever program you choose for pointing.

Stellarium doesn't really guide. It relies on the mount to talk to the camera (ST4) port or the use of an external, such as PHD2 to talk to the camera and mount through drivers. The above setup is reasonable for most mounts as a setup with Stellarium. Stellarium, in that case, does the initial point and then an external guiding program keeps the tracking honest. That works well if your star alignments during setup are tight. Although, if you move across the sky a lot to various targets, you probably have to do some centering and other minor tweaks. The more current way to do guiding (sans ST4 cable) is to talk to the mount through INDI or ASCOM drivers (Linux or Windoze). If, for example you choose to use Ekos (KStars) internal guider, you would have an indi mount driver and an indi camera driver. Both the mount and camera would be connected to the computer running the indiserver service. The guide camera will be connected to a computer via USB (either a laptop or an on-scope IOT type computer). The mount would be connected via either USB or WiFi to the indiserver computer. Ekos, then, looks at the images it receives from the indiserver process via the camera driver and makes a determination of what to send via pulses to the mount driver through indiserver. Ekos also does plate-solving. PHD2 works the same, more or less. INDI or ASCOM drivers handling the connectivity. Some cameras are supported natively by PHD2, but the process remains similar. I have no cables (other than power) running to my scope. It runs a Pi4 on the scope that runs indiserver and handles the USB to the cameras and WiFi to the mount controller. I connect my inside desktop to the WiFi and am done. One of the big advantages of ASCOM or INDI drivers is plate solving. Alas, it is like a drug. Once you use it, you can't live with just slew to target with a planetarium program.

I've been running Pi3's since they came out (as webservers and SQL servers) and Pi4's on my scopes since they came out. I believe the "issues" people have been having are: 1. Lack of 64bit OS with the Pi4 was released. Time has solved this one. Even Raspberry Pi OS has a 64bit version now. 2. Lack of proper cooling. Especially when/if you overclock. You can't use a box case and either need a heat-removing case or a fan...maybe 2 fans. 3. USB issues due to power. The USB ports on a Pi do not have a robust power supply. Cameras are HEAVY eaters. You MAY NOT run most Astro cameras solely on the power of a Pi USB port. If you try, either the Pi or Camera will be unstable and fail. The simple solution is to add a powered USB hub to drive the USB devices. Problem gone. There was also a delay with some Astro software in getting 64 bit versions that would run on the Pi4 out there. This was partly due to #1 and is mostly resolved for most Linux software now...though there are some exceptions as of this writing. It made sense really, if the 64bit OS came out yesterday, you can't expect all the re-compiles with adjustments to be done today. That said, I have no issues with my dual Pi4 setup whatsoever.

Frankly, I don't think I would bother with the SV305/Pro...unless your (very old) mount has a specific need for the ST4 port. One could argue that for guiding, you might get a more pinpoint image from a monochrome camera and therefore the ZWO mono is a better option. Unguided imaging will only get you so far. It is not good at all for dim images. Sure, it works for planets and bright things...but guiding is the ultimate solution.

There are many, many ways to run headless at the scope in Windows or Linux. VNC is one. SSH in Linux is another. KStars/Ekos will talk to an indiserver via a WiFi socket (So will CCDCiel) in Linux, anyway...probably Windoze too, so you could run it inside on a Desktop or Laptop and connect to the scope computer over WiFi. I have 2 Pi4 computers on my scope. One runs indiserver and manages the scope, the other is basically my Laptop/Desktop-ish. I port the HDMI monitor output with a iogear device and use a USB wireless Logitech keyboard. The reason I use two Pi4's is because the USB ports and WiFi take a beating with just one. With two, I can run indiserver on one, use it's WiFi to talk to the scope on the scope HotSpot network, connect to the other Pi4 via an ethernet cable for a rocket-fast network between them, so no delay on images..and still connect to the Internet with the WiFi from the other for network time, amont other things. I run the second Pi4 as though it was my laptop and just keep the keyboard and screen in the house. A bit complicated, perhaps, but it makes sense when you think about it. The only thing that changes when I remote is I have to use my phone for an Internet HotSpot for network time sync.

I don't use Windows, but I'd be surprised if KStars didn't at least connect to ascom drivers. I'd have to look at the docs...and the KStars docs are a bit behind the current version. But connecting from a client to an indiserver on a remode box should be non-OS-specific. and +1 for plate-solving!!!!!!! It changed my world.

Well then...KStars has a Windows version. And yes. You can get good results with either. Unless you have special needs in hardware or some specialty operation, you can win the war from either side. Myself, I hate Windows, but I recognize in this instance, that the field is level-ish. There are, of course, fans who will argue the point from either side.

Good job! But wait until you try plate-solving! It is magic. No other way to say it.

There is good software in both platforms. I think the main deciding factor should be the drivers. If you can find INDI drivers that work well for your hardware, then either Kstars or CCDCiel will make good options. If the ASCOM drivers work well, then APT is a good choice. A lot of the software doesn't care. PHD2, PixInsight, StarTools and several others work the same on either platform. Astrometry, for plate-solving as an example, doesn't care which platform. Deep Sky Stacker is a good Windows-only program. But no better than Siril in Linux.

I actually bought a ZWO monochrome camera for guiding in November of 2020. It is still in the box. I may try it sometime in the future, but for not, everything is working well...especially guiding, so I go with the, "If it ain't broke, don't fix it!" rule. I also bought a ZWO ASI178MC at the same time as a primary imager (hense the relegation of my SV305 to guiding). It has taken me a few months to get used to the settings for the ZWO ASI179MC and begin to get reasonable images again. It is concern for another period of re-education that has kept the ZWO monochrome camera in the box. It may never be my guide camera. I may just start using it as an imager for filtered monochrome images when I finally unpack it.

The SV305 has no ST4 port. The SV305Pro does. HOWEVER, most folks don't use the ST4 port any more on modern mounts. It is better in many cases to let the mount driver handle the pulses rather than mixing the sources of mount control. There is a Dylan O'Donnell video on YouTube demonstrating guiding setup in which he demonstrates removing the ST4 cable from its packaging and setting it on fire. While this may not work for every mount with a ST4 port, it is current wisdom for late model equipment.