I know I was interested in your software when I first saw it, over a year ago, but I still am running the original "Instructables" software from Thomas. I should get back to updating to your program.

Did you ever look into incorporating an evaluation of "seeing" from the images? It would be useful for establishing exposure times for people who are imaging thru telescopes. Forgive me if I asked this before or if someone else has already asked, I did not read thru all the responses, this time.

Read More...

Yes I did try to build it with .Net, but it gave me errors and I just assumed that it would not work on a 64 bit machine and system. I have not had a chance to try it again on an Rpi that had more ram.

I would be grateful for any specific suggestions that I should try with my system.
thanks,
Ron

Read More...

I am having some difficulty getting this to run, but it may just be me. My target machine is an RPI 4 running 64 bit Ubuntu LTS 20.04, but I am first trying to get the program to work on a separate rpi 4, running Raspian Linux 10, the processors are ARMv7.

I am able to get dotnet to load successfully ( I ran the script command for the latest version and it installed Version 6 ) and I downloaded all the files for the CollimationCircles program.

When I first tried to do the build the error I recieved told me that your *.csproj " file was asking for version 7 of dotnet, I had to change that line in the file to read version 6. After making that change I entered the "dotnet run" command. Right now it is hung on that build. I will wait and see if it finally builds, this RPI only has 1 G RAM.

Can you fill me in on what the specifics of the process will be for the machine I am running Kstars on, which I said above is an RPI 4, 8 G RAM running 64 bit Ubuntu.

thanks,

Read More...

Great to have it on Linux, I will have to try it on my Rpi running Ubuntu. I have been using AI's collimation tool, running on my laptop. I control the RPi, running Kstars at the scope, over ethernet cable to a laptop inside my garage (where it is warm) over VPN. As long as I am doing collimation using an artificial star the scope is still in the garage (on wheels, so I can roll it out on the driveway for seeing the night sky), then having the tool on the laptop is ok. But if I try to collimate using a star I need to be at the scope, where I have a tablet, also running VPN, so I can see the screen for polar alignment and focusing. When I get this running on Ubuntu, next time I uncover the scope, I can use it for star collimation.

One suggestion, in AI's collimation tool there is a break in the crosshairs at the center, so you can really see the out of focus star central spot and how well centered it is in the cross hairs (the crosshairs are also not as thick as yours) and which way to make the final small adjustment. You might think of making that change. It is only a suggestion and I have not tried your tool as it is, so it may work just fine. I would be interested in hearing other users comments.
thanks,

Read More...

I have not been able to repeat the problem. I have checked my udev rules, ran udevadm to check on device settings, unconnected and reconnected the tablet via usb tethering, set both automatic and manual ip definition of the usb wired connection (Note: I am running 64 bit Ubunto LTS 20.14 - and not making any updates as everything was working - same for the version of Kstars). What ever I do now seems to work. Nothing has changed the CGEM XML file in .indi directory. Yet, I know yesterday when I checked that file (as a last resort as to why the mount would not connect even though the error was telling me it had something to do with USB0 and USB1) it had the connection set at ttyUSB1, while the default CGEM file (I always keep a backup of how it was before when it worked) had ttyUSB0. So somewhere that .xml file was changed, but I have not been able to figure out how or where.

Anyway, right now everything is working, Kstars runs, all the equipment connects, I can run VPN on my laptop (in the garage, where it is warm) to control everything and when I need a screen at the scope I can use the tablet, running android VPN viewer on a fixed address on the RPI and the tablet usb tethered. I went to usb tethering because the wifi connection right at the scope could be iffy depending on which side of the scope I was standing with the tablet. The tethered connection is very fast and reliable (does real time updates during polar alignment and focusing).

It seems there is always something that causes a delay in getting the system running at night, so I have gone to getting everything up and running during the day and then just rolling the scope out at night, so fortunately I did not lose any "scope time" because of this. All the same, I wish these 'computer' issues did not happen. They are far more numerous than any other equipment problems.

thanks for looking anyway.

Read More...

Anybody seen this. I am running Kstars on a Raspberry Pi 4, I access the Rpi using VPN on a laptop, in my garage connected over ethernet. But I also have an Android Tablet, that I use at the scope, just to view the screen output (for example; while I am focusing). The tablet is USB port connected to a spare USB port on the RPI. Yesterday I had to switch to a new tablet, the old one became unreliable (they both are inexpensive 7" models). I did nothing different, just connected the tablet using USB tethering and added the correct address into the VNC viewer on the tablet.

Today, my CGEM mount would not connect. After searching around I found that the CGEM....xml file in the .indi folder had been changed; the port went from ttyUSB0 to ttyUSB1.
I did not make this change, what can make this change in the xml file??

I reset the .xml file and now everything is working again. But I don't know if this will happen again.

thanks for any responses.

Read More...

I also update my darks a couple of times a year. I take them using a fridge to reach the desired temperature, I usually take them every few degrees. I image at a fixed gain (50) and exposure (I use 12 seconds as I find that is long enough to pick up faint stars and yet not produce noticeable star trails), so I only need to match the dark to the camera temperature (I store the temperature in the Dark Frame Name, so it is easy to search on and find the one closest to the image temperature). I have ImageMagick loaded on the Rpi and run command line routines like "level" and "brightness-contrast" to sort of stretch the image. All of the image storing and processing routines are run in shell scripts that are called from subroutines in the main capture.cpp (C++) program.

I have thought about changing the camera (ZWO ASI 120MC) parameters when the moon is out, but I have not found camera settings that deal with a bright moon and can still image stars. I will look into how you are dealing with this. I also like the idea of determining sky brightness and logging this with the AP images I take with my telescope, on the same night. It may help set my expectations when I process the images.

I have had a lot of fun with the AllSky camera project over the past 3 years, it is probably time I did some updating of the program and equipment. I am on my second Rpi as the USB ports on the first one stopped working after about 2 years outside (the Rpi and camera are in a water tight junction box container with the usual plastic dome.)

So thanks for providing an alternative approach.

Read More...

I am interested in your project, I have been running my own modified version of Thomas's software on a Rpi 3B with a ZWO camera, for several years. In my version of the software I make use of darks, to remove hot pixels, and stretching algorithms to bring out the most in the images. I have found that I need to take darks over a range of temperatures, because the hot pixels for my ZWO camera depends on the camera temperature. And in order to cancel them out I have to match both the exposure time (which I fix) and the camera temperature when the image is taken.
Can you briefly outline how you handle darks and any additional image processing.

thanks,

Read More...

I did find 3 asteroids (already known but not by me) by imaging an object over an extended period of time with multiple exposures.  The image sequence clearly showed 3 objects moving relative to the stable background stars.  So the process is certainly viable.  

Concerning the crashes of Ekos using a Raspberry Pi 4, that is what I use a Raspberry Pi 4 with 8 Gbits of memory, running EKOS 3.5.0.  However, I too had crash issues, especially during plate solving before I changed the operating system to 64 bit Ubuntu.  I found that the 32 bit operating system was not consistent in performing the plate solving operations and would sometimes crash.  I consulted with someone involved in writing the PHD2 code and we concluded that changing to a 64 bit operating system resolve the issues and it did.  I would suggest you explore that path as an option.

 

Read More...

I think I read someplace that the Kstars team is only (mostly) supporting the LTS (Long Term Support) versions of Ubuntu, which would be 20.04 LTS, you may have a longer wait for the newer but less supported versions.

Read More...

I am running Ubuntu 20.04 64 bit on a Rpi 4 with 8 Gb RAM and my latest installation is Kstars 3.5.3 stable; as I recall it had all the components and my ZWO and SX camera were working.
lsb_release -a
Ubuntu 20.04.2 LTS
Codename: focal

I installed only the Ubuntu Server and then then the lubuntu desktop, I am running it with Lightdm as the desktop manager.
Kstars 3.5.3 stable Build 2021 -04-26T13:22:43Z
It has the EKOS tab and as I indicated my cameras all seem to work.

However, this is not what I am currently using (I set this up an a new SD card), my current system at the telescope boots from an SSD and is still running Kstars 3.5.0 in which everything is working and I am reluctant to update it until I am positive I will end up with a working system.

Ron

Read More...

Ronald Scotti replied to the topic 'Problem with Polar Alignment' in the forum. 2 years ago

I have always had this issue with my CGEM mount as well. It also comes up with crazy numbers for how much the mount should be moved during PA. I set the PA option to manual move, then I open up the "motion control' panel in the mount tab and note the 'hour angle' I then use the 'motion control' panel to move the mount 1 hour for each 15 degrees of motion I intend to use for PA. I don't have to go outside to see the mount, the panel tells me what direction the mount is moving, I can control the speed of motion with the 'motion control' panel. It works fine and quick and performs PA exactly as it should. The only time I have to go to the mount is to make the final PA adjustment, for that I start the PA looping (after it has presented the correction arrow or line) and at the scope I monitor the progress of my 'adjustments' using a tablet that is linked wirelessly to the Rpi running Ekos using VNC.

I never have resolved why the PA angle motion numbers are so large or that it does not move as intended, I have just continued to manually move it and it works just fine.

Read More...

It seems I may need to build indi-core first, but I get errors when I try to build that also.

yet on a command line if I run indiserver indi_sx_ccd it says startup: indiserver indi_sx_ccd so something is working. It is just that EKos is not recognizing it somehow at it still shows it is not connected.

tried enough for tonight.

Read More...

I have a CMAKE error 285 of "could not find INDI include directory"
looking at the log now, it does not help much.

Read More...