Hi,
When running a sequence I'm finding kstars is skipping the slew and alignment stages and trying to go straight to guiding despite being in the wrong part of the sky. I'm seeing this in the log:
```
2023-06-14T00:39:17 Starting guiding procedure for M 27 ...
2023-06-14T00:39:17 Job 'M 27' is proceeding directly to capture stage because only calibration frames are pending.
2023-06-14T00:39:12 Scheduler started.
2023-06-14T00:39:12 Scheduler is awake.
```
I have the track, align and guide checkboxes ticked but for some reason it's ignoring them. Any suggestions please? It wasn't behaving this way before the recent kstars update. I can work around it for a classically scheduled night by manually slewing and aligning and then letting the sequence run, but I'd be worried about using the greedy scheduler as I doubt it would slew to the second target. (This is hot off the press, we'll see in the morning if it has bothered with the observatory shutdown routine...)
Read More...
I've never really had a problem with planetary capture on Linux. For capture I use firecapture which runs fast enough, I can capture as fast as the data will come from the camera over USB3. (And sometimes AstroDMX Capture, which although it isn't free software I sometimes prefer, especially for lunar imaging.) Either way, I record straight to an M.2 drive which can take data far faster than USB3 can provide it. A raspberry pi 4 just about has the I/O bandwidth to keep up with 2Gbit/s output from a camera if it's writing to a USB3 drive (even with the pi's suboptimal USB3 implementation) although it might end up being throttled by the capture software if that's trying to do anything CPU-intensive in terms of a preview, and I definitely wouldn't expect it to be able to write that data rate to the microSD card.
As for processing, the usual Windows software (autostakkert!, registax, astrosurface) runs fast and well for me using recent Wine versions. I notice there are a lot of grumbling Wine logs, but the programs run well enough to achieve the required processing.
In terms of developing ekos for planetary capture, I think the first thing is to avoid doing anything to disimprove its deep space capture abilities. AstroDMX has support for INDI cameras since v2.0.2 although the author reports that there are issues with speed and for fastest capture the native drivers should be used, so perhaps the first thing might be to look at removing any bottlenecks to the data rate that might be caused by INDI. After that I guess ekos becomes just another capture application, so would need to look at implementing the same kinds of things as the other capture applications: high speed debayering and high speed preview rates, guiding based on the COG of the planet disc in view, auto ROI adjustment to help in coping with drift, setting of capture frame / time limits, tools like indication of RGB channel misalignment, etc. etc. One specific suggestion would be that the separation of all the camera settings into the INDI control panel is all very well for deep sky imaging where you don't change them often, but for planetary imaging it's much more convenient to have camera settings directly to hand so look at taking the best usability features from the existing front-runner planetary capture apps.
On the processing side, I write code for Siril; there is an ambition to improve our planetary processing capabilities in either the 1.3 development cycle or the one after that (it depends how we get on as there are also some other substantial feature additions as well as (if we're brave enough!) moving from gtk3 to gtk4... So hopefully there will be more native processing options in the not entirely distant future.
Read More...
Yes, that was the issue. Before I realised that was the problem I tried removing the focuser from my optical chain to prevent it and I got a message (sorry, I didn't capture the logs) that I think said something about autofocus not working, so perhaps it was just a slightly unclear message. Anyway it's resolved now 
Read More...
I'm having a possibly related issue. Since installing 3.6.5 on ubuntu lunar, whenever I try to take a flat ekos tries to do an autofocus. Of course that ruins everything because I had it nice and focused and then put my flat panel on the tube, so it could never focus anyway. I've checked the filter list and none of them have the autofocus box checked. Essentially I never want ekos to do any autofocusing, under any circumstances (especially for flats). I have an electronic focuser but I want to use it manually. Is there some new setting I've missed that I need to turn off, or is there a bug? (Really it seems like any attempt to autofocus when taking flats is a bug...)
Read More...
Ah, thanks Jasem, I've pulled the change in from git so I'll test it next chance I get. I'll close the kstars issue as it's been dealt with here.
Read More...
Hi,
I'm just reposting this here as it doesn't seem to be getting any attention on the kde bugzilla - I'm not sure if that's still being monitored.
This is a kstars issue, as on my laptop I reverted to kstars 3.5.7 while keeping indi-toupbase 2.0+t202304160731 and it happily takes multiple exposures without stopping and restarting the fan & cooler. It's pretty bad, especially when taking flats or bias, as it's impossible to maintain a stable temperature. Also I worry the extra thermal and electrical cycling could have an impact on the camera's life.
SUMMARY
Touptek camera driver (possibly others, but the Touptek is the only one I can check) gets reset after every exposure. This is making it impossible to capture a sequence of bias frames as after every frame during the reset the fan and cooler switch off and the temperature rises before they switch back on again. I don't want to incur any risk from unnecessary thermal cycling from taking hundreds of bias frames, and in any case it would drag out the process excessively if I were to wait for the temperature to stabilise again after each one.
If I use the INDI control panel and trigger an exposure manually, the camera does not reset, so I suspect the issue is within ekos.
STEPS TO REPRODUCE
1. Set a job of multiple exposures using the Toupcam driver.
2. Start the job.
OBSERVED RESULT
The camera fan and cooler stop and restart before each exposure.
EXPECTED RESULT
The camera should remain in a state of constant cooling throughout, with no resets occurring.
SOFTWARE/OS VERSIONS
Windows: N/A
macOS: N/A
Linux/KDE Plasma:
(available in About System)
KDE Plasma Version: 5.24.7
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3
Read More...
I have kstars on my laptop and also on my astroberry. The astroberry is headless, except for vnc, and being a raspberry pi it is slow anyway, so it's a real pain to make it display a terrain file so I can draw an artificial horizon around it. On the other hand my laptop is nice and fast and I was able to draw the artificial horizon quick and easy. The problem is, I need it on my astroberry so that the scheduler running on the astroberry can be aware of the horizon so it doesn't start jobs when blocked by trees or buildings. And I'd really like the artificial horizon to be exactly the same on both machines so they are consistent (I tend to plan my observing on the laptop as it's quicker and more pleasant to scroll round the sky with HIPS overlays showing. I know the artificial horizon data points are saved in the kstars sqlite file: if I just copy this file (or even the whole of ~/.local/share/kstars) across from the laptop to the astroberry, will I end up with a working artificial horizon on the astroberry or will I just break things? If not, what is the best way to do this? (As a feature request, if there were a way to import and export artificial horizons to / from a file to make transferring them between machines easier, that would be fantastic!)
Read More...
Has there been a change to the polar align module behaviour recently? I upgraded kstars from 3.4.x to 3.5.6 stable (using the ppa repository) and the behaviour seems different. Previously at the end of the align the mount would park itself: now, it remains at the position the final alignment image was taken in.
Also I encountered a problem where the mount would take the first alignment image, rotate and take the second, and then partway through rotating to take the 3rd image it would stop dead. I resolved it by turning off the auto meridian flip option on the mount, after doing that the PA assistant worked fine.
Read More...