JonCarleton

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).

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.

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.

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.

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.

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.

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.

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.

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.

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??

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.

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.

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."

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.

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.