Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.


  • Content Count

  • Joined

  • Last visited

Everything posted by JonCarleton

  1. I have a Skywatcher 250P (f4.7 1200mmx254mm) and use a ZWO ASI 178MC. Therefore, I have the FOV of your basic soda straw. This makes everything other than a few solar system planets a tedious mosaic exercise. A reducer seems a better answer than getting another scope, but have been given to understand they come with their own problems. I don't want to spend hours with spacers and rings trying to achieve a focus that isn't going to happen. Any recommendations?
  2. Redo the calibration, then run the Guiding Assistant from the Tools menu. Let it run for a few minutes, it will give you suggestions to APPLY that are usually spot on.
  3. HA! Found it! Settings->Display->Contrast. Set Contrast ALL the way off. Contrast, by the way, operates differently on the amd64. Now I can have my stars and planets on, with only a mild "haze" around them and still read nearby objects. I'm guessing I'm the first to stumble over this issue: Carte du Ciel V4.2.1 Raspberry Pi4 Ubuntu 64-bit (arm64) v 20.10 HDMI 1920x1080 display (1080P).
  4. OK, I found ONE way to kill the blob. If you turn off the display of planets and stars, it goes away. The amd64 version 4.2.1 doesn't do this. That''s going to make slewing to stars and planets a bit tedious for the arm64 version. Oddly enough, I can't find a way to turn ON that "feature" (and hope I never do) for the amd64 version. Turning stars and planets on and off has no effect except on the Pi version.
  5. I am using version 4.2.1 on both the amd64 (which is blob-free) and arm64 (Raspberry Pi4). Here is a screen shot of the BLOB killing the software. This is a daytime shot, so the sun is part of the blob issue, but any planet (or moon) will cause the same problem.
  6. I would like to start using Carte du Ciel more, as I like the way it works with my equipment....excepting one thing: There are teal blue BLOBS in areas of the sky with significant light (eg: Moon, Sun, Jupiter, Venus, et al). The odd thing is that this only occurs with the version I have installed on my Pi4 (Ubuntu Mate 20.04 arm64). The version on my laptop (XUbuntu 20.04 amd64) does not share this annoying feature. If anyone knows HOW TO TURN THIS ITOFF, please share. I keep reading and re-reading the docs in the hope of stumbling across a hint, but so far, no joy.
  7. I struggled with the setup for Astrometry.net from the very first time I got a headache reading the online documentation. I use Linux (Ubuntu), so I did the "manly" thing and ran: sudo apt install astrometry.net && sudo apt install astrometry-data-tycho2 All installed without error and I retired to bed thinking, "What a good boy am I." Next evening, I tried a plate solve with the main scope (via CCDCiel...calling Astrometry via solve-field) and it ran a very long time and failed (timeout). So I took a picture through the guide scope (same location) and it solved, though it took a very long time and was in danger of timeout. Next, I sent both images to the online server (https://nova.astrometry.net) and they both solved. Quicker than the local server for the one that solved locally and successfully for the main scope image that failed locally. Now, I understand the problem is getting the right index files and matching the right Astrometry image files with your scope parameters for the part of the sky you are looking at and yada-yada-headache-yada. But I noticed something that led to a shortcut, so I thought I'd share: When you solve via the website, it =tells= you which index it used....kinda. In my case, it said "solved using index-205.fits" for both images. From previous headaches, I know this relates to the 4200 series index files. and so I need all the 4205 files. So, I did a quick drain flush of the tycho2 data via : sudo apt purge astrometry-data-tycho2 and went to http://data.astrometry.net/4200/ to download all the index-4205-nn.fits files and placed them where the tycho2 files used to live. In my Ubuntu system: /usr/share/astrometry. Results: Bam! Near instant plate solve locally on both images. Now, am I done? Probably not. For different parts of the sky for my setup I may need to grab a few more file sets. Probably the ones adjacent to 4205, such as 4204 or 4206. It may take me a few plate solve failures to collect all the indexes I need. But if I get a failure, I have a simple process for resolution: Solve it online, see which index it used and get that -one- series. The key to fast solving is not to have ALL the indexes and to have ONLY the ones you need for your scope, location and sky. I'm pretty sure, for example, I don't need Southern hemisphere stuff for the Southeastern US. Why didn't the tycho2 files work (for the main scope image, anyway). They would have, had I the right ones and ONLY the right ones or if I had set the timeout high enough. Too many index files will slow the process significantly. I just didn't have such a simple method of identifying the index I actually needed with the tycho2. Although, through the fog of previous headaches, I do recall seeing a rather complex method for determining the ones you need from other index series.
  8. I've been using Pi's for some years now as webservers, sql servers and now my telescope server. But then, "I don't do Windows." I haven't owned a windows machine since 1995. When I worked as a programmer, I was all UNIX/Linux. The Pi3 is very stable, but the USB2 ports are a drag with fast cameras and running them remotely with VNC or SSH is reliable, but slow. The usual problem is having the Pi3 too far from the WiFi router. The antenna is tiny and it is therefore range-challenged. If you can manage a cable, running things via a direct ethernet connection will change your world. The Pi4 -can- be stable, but 64 bit OS versions have only recently begun to stabilize. I am running Ubuntu Mate 64 bit, that is still beta. I did run the (still beta) Raspbian 64 bit, but I ended up having to compile a lot of the INDI drivers to get them to operate properly, rather than just download the pre-cooked versions. Also, the software available for download seems to be more stable for Ubuntu distribution versions. I am presently using: AstroDMX_Capture: general imaging CCDCiel: pointing some imaging, plate solving, auto-focus and general operations platform Astrometry.net: plate solving (integrated with CCDCiel) PHD2: guiding (run independantly and/or managed via CCDCiel) Carte du Ciel (SkyChart): planetarium and pointing (integrated with CCDCiel) Siril: Stacking StarTools: Image fiddle-faddle (making me look better than I have a right to) GIMP: Final image touch-up With the exception of StarTools, which requires a modest fee, the rest merely ask for donations from those who are able. I strongly recommend the support of all of these fine programs if you are using them. I have found a few of things about the PI4: You really need heat sinks AND a cooling fan, especially if you intend to overclock the Pi. As to overclocking...for operational astronomy use (running the scope, cameras imaging and plate solving), there is not a lot of gain by overclocking and it does really increase the temp load. That is one thing that can lead to instability. I run mine stock. Frankly, while you -could- do image touch-up with a Pi4, that task really wants a machine with more beef. I have had problems with the USB3 ports on my Pi4's. The problem isn't software or design as much as purely mechanical. They seem to have no patience for cheap USB cable connectors. Every single USB3 instability I have experienced was down to the cable connection. Wiggle it or hold your mouth just right and it works. Slew the scope and it becomes unstable. Better quality cables and ensuring a good tight fit is critical to stable USB3 operations. Like the Pi3, the Pi4 has a weak WiFi signal. It is better than the Pi3, but not much. This leaves 3 choices: 1> Use a separate USB Wifi device with a "big -ole antenna," such as those sold for laptops, 2> Place your WiFi router nearer to the Pi4, or 3> Run an ethernet wire to your network. Myself, I hate wires, but running the network connectivity over a wire changes the whole picture of what can be done. This is a rather unique case, but I'll mention it anyway I focus using a WaveshareHAT board. There are a few other add-on boards that I have not tested, but the same may be true and is worth consideration: The board plugs in on top of the Pi4 GPOI pins and offers the option of running power to the board and powering the Pi with that single power supply through the HAT board. Nice, simple, clean, less wires. This works OK on a Pi3, but Pi4...DON"T DO IT! You'll be plagued with low-voltage issues. Also, don't try to use the remote power ON switch setting AND adding the standard USB power cord. Disable the remote powering option and power the two boards separately from separate supplies. Additionally, keeping a Pi4 cool is paramount. Trying to cool it with an accessory board riding on top of the main board via the GPIO port is more complicated. I had to build a special case with an extra side fan to keep things manageable. If I hadn't already gone to all that effort, I would have added the board via external ribbon cable in a separate enclosure. This rant is particularly for the WaveshareHAT board, but I have seen Arduino and other boards that have the same feature of powering the Pi through the HAT board using one power source. I haven't tested these, but I wouldn't trust them either.
  9. I need to look into Alpaca. I really am not familiar enough with the project to speak with any authority on it. Then too, I'm perfectly happy with INDI, and "I don't do Windows." Data conversion for dissimilar enterprise systems was my area before I retired, so I know it could be done. The real question is then, should it? The notion of an additional point of potential failure is certainly valid. I do see the value of running a Windows desktop with a Pi running the scope, especially when there is any real distance between the two. In my case, I am basically doing the same thing under Linux....Linux desktop, Pi/Linux at the scope, so the conversion issue does not come into play.
  10. The real question should be, "Can an ASCOM server talk to an INDI server. They are both TCP/IP XML message platforms. Both ASCOM and INDI have provisions for distributed remote servers with one primary server. I don't know the answer, because I don't do Windows. But it seems to me that if they don't do that yet, they should. It should go both ways. A primary INDI server should be able to talk to secondary ASCOM or INDI servers and likewise a primary ASCOM server should be able to talk to secondary INDI or ASCOM servers. TCP/IP XML is common between both platforms. The only reasons it may not be are that 1) Nobody thought of it yet, or 2) The XML specifications for the drivers have become too differentiated, or 3) The port for the two server types is different. None of which are particularly difficult problems to solve with a bit of code Even if things are completely mismatched, a simple socket program with a conversion between driver specifications could make it happen. Since I don't see it happening, and since it makes sense to have a Pi on a telescope running an INDI server with perhaps a primary ASCOM server connecting to the human-interfacing programs, there has to be a catch I'm not seeing. There was a project called wINDI that was reported to be an ASCOM->INDI bridge, but I don't know the status of it now.
  11. I run my PI4 without VNC and just SSH into it and run what little I need through the forwarded X display (ssh -Y). On my network, I really don't notice a significant difference between SSH and VNC. Then too, I run PHD2 and CCDCiel locally with a remote INDI server on the Pi4. I did try running everything on the PI4 via VNC, but it did get a bit sluggish.
  12. Hmm..I think I see now. Running the software at night, there are no blue blobs. The blue blobs that show in daytime seem to all contain planets. Perhaps that is a hint that you might be able to do some level of daytime photography of planets within the blue blobs. Interesting if true. Not my cup of tea, but interesting. That sound right??
  13. OK...I have a really basic question that =must= be answered in the documentation for Carte du Ciel somewhere, though I cannot find it or perhaps cannot describe it properly enough to generate an answer. So, I'll try here: When I open up Carte du Ceil, there are these very large, circular, light blue "blobs" on the chart. 1) What the heck are these blobs? 2) Why are they there? 3) How do I make them go away? (which assumes they don't have a really good reason for showing up that I am too inexperienced to understand at this point) The wash out the background, making it difficult to see what is that section of the sky. At first, noting that one such blob was more or less centered around Jupiter, I suspected that it was trying to show the zone of excessive brightness due to Jupiter. Then, I found a similar blob around Mercury and decided that explanation was a bit of a stretch.
  14. Stash_old==> Thanks, I'll look into CCDCIEL...though not the windows stuff. "I don't do Windows and I don't type on fruit." Wornish==> I have thoroughly tested and worked with Ekos, but had some issues with lockups and things that may be due to the odd collection of gear I have to operate For now, at least, other packages work better for me. Thanks for the mention, though. For many, Ekos is an excellent choice.
  15. Thanks All! I really appreciate it. Sometimes it is easier to ask folks in the same venue than Google. Google often sends me on long goose chases. ...and for the record....I don't mind paying for software...but I'm an old UNIX guy and just don't care for "Windoze."
  16. I have tried Stellarium. It points OK, but I really need to look at how it will sync to known coordinates. That's a TODO...thanks. CarteDuCiel is something I haven't looked at yet. Another TODO.
  17. I am looking for suggestions for Linux-based pointing software that will accept coordinates for sync manually or from Astrometry.net other than Ekos. I like the way AstroPhotoPlus works, but can't get it to run on a Pi4. I am currently running PHD2 for guiding, Astrometry.net (local command line) for plate-solving, my own Java DIY package for focusing (all of these with indi drivers) and AstroDMx_Capture for imaging. I could close the loop if I just could find a pointing package that would accept coordinates for sync. Ekos is an obvious choice, but I don't care for the way it operates and I have had many issues with it in my recent attempts at integration. Hopefully, there is something else out there I just haven't found yet. Lots of stuff for Windows, but "I don't do Windows," nor does the Pi without pain and suffering. I was reasonably pleased with AstroPhotoPlus, but can't get it to run on a Pi4 and support requests seem to be a very long-term process by design.
  18. Sombrero galaxy has been a tough one for me. I wish I could get one half as clear as that. Last one I took, one could barely see the dark border. Perhaps I'll try again this season.
  19. One of the keys to astro-photography these days is stacking. That is, taking loads of images and combining them with stacking software (eg: Deep Sky Stacker (Windows) or Siril (Linux)) to improve the resolution and density of your images. Stacking software aligns your images and will even allow you to collect images from multiple night sessions on a single target and combine into a single dense image. Why take multiple images instead of one long time-lapse? Imagine a two hour time-lapse that had 2 airplanes, 5 satellites and an owl fly through the field of view. Or perhaps the wind or a glitch in the mount caused some camera shake or clouds invaded during part of the exposure. Or, or, or...Two hours wasted. If you take 2 hours of exposures in smaller bits (eg: 5 minutes, or less...or more depending upon the mount) you can eliminate any bad images prior to stacking and still get excellent results...and add more to the stack another night. Once you have a good final image from stacking what will will amount to many minutes or even hours of data, then post processing is next. There is a process called "stretching" the image that makes the view of a mundane, but dense, well-stacked image, absolutely spectacular. This can be done in Photoshop (Windows) or GIMP (Linux) or in other specialized software that will have specialty image tweaking functionality, such as camera noise-reduction and other useful options. Much of this software is available as freeware/donationware and all of it has a learning curve. But it is well worth the time and effort to learn. Collecting multiple images underscores the need for the reliability of your mount. Collecting data on multiple nights requires precision pointing. To that end, there is a process called plate solving. The simplest, (but possibly slowest) method is to take an image, upload it to nova.astrometry.net and wait for the results (up to 10 minutes). It will tell you the -exact- coordinates of the image, allowing you to make adjustments as required. You can also download the astrometry data and software and run it locally with speedy results, but that process is beyond the scope of my intent here.
  20. Presently, I use AstroDMx_Capture for my imaging (I got started with it when it was the ONLY Linux program that supported the SVBONY305 camera), Siril for my stacking, My own Java panel for my focusing using the indi_wmh_focuser driver and I am still looking at plate solving and guiding. I use indi drivers for many things, but not Ekos so very much. It is a workflow thing with me and I do admit that my own ideas for workflow may be warped and even wrong at some levels. Astroberry is a very excellent package. If you are pleased with it, I'd say stick with it. The support is excellent and it is ever-evolving. To answer your question more directly, I like the way AstroDMx_Capture works and generally prefer separate programs for separate functions over all-in-one solutions. With respect specifically to AstroDMx_Capture, I like the way the color balance works with the real time display, and the way the control panel works for exposure, gain and other items. It is also remarkably easy to switch from AVI capture to FITS or TIFF for different targets or in the middle of a target sequence.
  21. I got a note from AstroDMx_Capture this morning about a new release of their software (version 0.78.3). The primary changes include 32 bit and 64 bit support for the Raspberry Pi and especially for the SVBONY305 camera using the new SDK from SVBONY. This is my primary imaging software, as I run Linux on both my Pi scope driving computer and laptop, so I am quite pleased. .3) ()version (0.7
  22. True to form, I missed again and still got an image. I really am going to have to sit down and get good at plate solving. This time I was aiming for the Trifid Nebula and ended up with the Lagoon. I eventually did find the Trifid and have also included my reshoot of the Dumbbell Nebula that was my original mistake ( I was aiming for the Angelfish Cluster). All of these are from my Skywatcher 250P/Synscan with a SVBONY 305 camera using AstroDMx_Capture. 200 subs @ 8 seconds/25% gain, 30 darks, no flats or bias. Stacked with Siril, finished with StarTools and Gimp...mostly Gimp, as I am still stumbling along with StarTools. I should also mention that of the 200 subs in each image, I had to eliminate as few as 15 in a batch and as many as 32 resulting from inopportune scope tracking (SynScan).
  23. That galaxy is pretty large, but the Skywatcher 250P (254mm X 1200mm) with the SVBony305 has a very tight FOV. I struggle with that for really large objects, such as Andromeda Galaxy. I have tried a .5 reducer, but it causes focus issues and probably needs an extension tube. There was a bit of cropping for drift between frames, but not much. I'd say less than 5%. I did shave a bit off the left side for centering, but again, very minimal. I also bined X4 the entire image, but that would not increase the "fill" of the galaxy in the frame. Thank you for your kind comments.
  24. I finally got around to processing some of the stuff I have been shooting. Here's a whirlpool galaxy: Image captured as 100, 1.5 second @ 50% gain subs with the SVBONY305 and AstroDMx_Capture software. Processed with Siril (stacking), StarTools (image clean-up, color balance), then GIMP (sizing and cropping) all in Linux. Darks, Bias & Flats were not used. Scope was a SkyWatcher 250P with Synscan, however, tracking was done with INDI indi_skywatcherAltAzMount driver and no guide scope. Synscan GOTO was not used.
  25. Looking good! You have come a long way in a very short time. You will find that some of the options in Siril work better for some types of images and other options for other types. It is a very powerful tool, but it takes some messing about with to get your legs under you. Then too, most of the image software is like that. I'm trying to wrap my head around StarTools myself....been using GIMP, and it is OK, but there are things I do in multiple steps that other programs make a single-step. Good job getting rid of the noise!
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.