Does this "Park" option park after every plate solve or just after polar alignment? With 3.5.x software I have a recollection that after polar aligning and selecting "stop" the mount would return to the parked position. (I frequently noticed this while attempting to slew to the first target after polar alignment.) Currently (3.6.1) if my polar alignment is off too far I will stop the process to start over. Now I have to re-park the mount manually.
Read More...
\
In order to get the flat panel off and the lenscap on manually I attend the sequence and stop if after the last flat is taken. I then take off the flat panel and replace the lens cap before starting the sequence again to take the flat-darks. I take my flats and flat darks during the day after the previous night's imaging session. I use an profile containing only the camera and the auxillliary device flat-man.
Read More...
My experience with flats is the same, no pause to ensure telescope is covered before carrying on. My work-around was aborting the sequence after the last flat was saved, covering the telescope (in my case removing the flat panel first), and restarting from the first dark flat sequence entry. Not ideal, must be paying attention, but workable. Now with 3.6.0 I can't even get this far. (still working on what the issues are...)
Read More...
I too have had issue with 3.6.0 (on Linux laptop Ethernet to 3.5.9 on Pi /Astroberry) and my Flip Flat type DIY flat panel. It worked previously but not well since the update. Random crashes and not completing sequences have been my issues. Unfortunately I have not had the time to dig into this yet in detail.
Previously system would run through sequences of flats for RGBL+Ha then do the associated dark flats. Now it doesn't want to reliably complete a single filter's flats. When it does, it frequently doesn't start the next filter in the sequence.
Hopefully I will be able to find time to sort this soon as we've been "forecast" to have some more clear nights before the moon gets in the way. (and I've a backlog of exposures with a different lens so my existing flats won't work),
Staying tuned...
Read More...
When I initially started using the Kstars/Ekos/Indi environment a few years ago I worked with a Fuji X-T2 mirrorless camera and a ZWO 120 mini guide camera controlled by a Raspberry Pi 4 (Astroberry) at the telescope with Ethernet to my laptop. I had a lot of issues with cameras staying reliably connected. This issue was solved when I added a powered USB 3 hub (12V) and plugged the Fuji into the hub and the ZWO mini into a USB 2 port on the Pi.
When I added a QHY268M last fall I just unplugged the Fuji and added the QHY camera - all was well. A few weeks ago I attached the QHY camera to an old Hasselblad lens (50mm FLE from a previous life) and mounted it alongside the ZWO mini/guide scope setup on a 300mm D-type rail. I used this along with the existing bracket holding the USB hub, SSD, RPi from the telescope setup. It all worked until a few days ago when I made a new, smaller bracket to hold the electronics. Then things started getting flaky. (On top of this, I had a new laptop (Linux/MacOS) as my old (though newer) HP (Linux/Windows) laptop died (completely) - so a new install of Kstars. Being in the mioddle of a rare string of clear nights I was anxious to make the most of these (essentially) moonless nights (~49 degrees north, so short "nights"). After last night's fiasco I approached the issue more methodically than I had to this point, when it finally dawned on me that I had plugged the two cameras into the same hub (because in the telescope setup there were three items plugged into the hub. I'm not using the ZWO-ASI focuser... duh.
This afternoon I moved the guide camera back to the RPi and all is good again. So, tonight should be more productive.
Moral of the story, for me at least, is: where you plug the USB cables in matters. (i knew that once, but seem I had forgotten it)
Read More...
I was using my Linux laptop running Kstars 3.5.9 pointed at star HD 198268 as it provided the framing I wanted. The laptop up and died so I switched to my MacBook Pro running Kstars 3.5.9 Stable (Build: 2022-05-25T20:48:13Z) and when searching for the same star discovered it couldn't be found. In a rare run of clear nights I was hoping to get more data centred on the same star.
As near as I can tell I configured both installs the same. What have I missed? What file holds the Henry Draper stars?
Read More...
I don’t know what camera are currently supported. Before I got a cooled camera I used my X-T3 with a reasonable amount of success. Kstars was at version 3.5.3 or something back then (Jan.Arya through August of 2021). I’m sure there have been some advancements but do not know with certainty.
I documented my issues and concerns on this site back then.
Read More...
Peter, I finally found time to work on my flat panel some more. The main issue I had was getting the LED string to be dim enough to allow an almost full range of control. Binned 2x2 Red needed a low intensity setting while unbinned H alpha needed almost full brightness to get an exposure time in the range I was looking for ( 2-10 seconds). I ended up with a series of diffusion materials and a 2-stop neutral density filter (stage lighting gel) to subdue the light intensity. The device is held together with masking tape at this time while I sort out a way to easily hold the four main sub-components together.
As a cobbled together device with bits acquired from a range of sources and 3D printed components supplied by my son, I don't feel comfortable in offering to build you one - mine is sized for my GT-71 refractor so it's quite compact. If you decide you want to tackle building one I would be happy to share with you my circuit diagram, program code, and design considerations.
Read More...
Willem, I noticed this issue first with Flats and 3.5.7. I updated to 3.5.8 three days ago, just before a rare clear night two nights ago. I noticed the issue when PixInsight's WBPP script reported a number of Flat exposures fell into a "No Filter" category. This time a few light frames were effected too. Filenames properly show filter used but FITS header is missing the Filter keyword. Last time I think only Flats were involved.
I'm hoping for a resolution as individually adding the proper keyword and value to each file is time consuming. I haven't the skills/experience to write a script to automate the process.
Read More...