I used the system to image the eclipse and the response is the same, there is a delay between the time I executed a motion (which I needed to do to keep the Sun centered in the imaging window) and when the mount actually moved. But it did eventually move and I was able to operate that way. But I do not understand why this new version (and others) does not respond like the earlier Astroberry 3.5.0. It appears the configuration files are the same and the drivers are the same (I think).

Has no one else experienced this latency with their mount using the Motion Control Panel? Am I the only one using Kstars with a CGEM mount?

thanks for any response.

Read More...

I examined the Indi driver files for the AStroberry 3.5.0 and the Kstars 3.7.0 configurations and they have all the same values and "on" and "off" settings.

Read More...

I am running on an Rpi4 (8 gb) with OS Ubuntu 22.04 (from an SSD) and recently updated Kstars 3.5.3 to 3.7.0. I have a CGEM DX mount which is loaded as CGEM HC configuration which actually uses CGEM GPS config file (as I understand from the Indi Control Panel). Polar alignment works fine, Slewing to targets works fine, Phd2 guides as well as it can with this mount. There are times when I need to make small adjustments to the mounts position to 'frame' a target (for example: try to get 2 galaxies into one view). To do this, in the past, I use the mount motion control panel popup on a low speed scale (3 or 4 but I am testing using 7) and step the mount a little in the proper direction to 'frame' the image I want.

I have a working Astroberry 3.5.0 on an SD card and I ran that tonight with all the same equipment and this process works almost instantaneously. However, ever since I started using Kstars 3.5.3 (I recall) the motion control buttons on the Motion Control Panel sometimes work and sometimes don't work and when they do work there is a latency between when I 'click' on the direction button and when there is motion and when the button turns red to indicate that motion was activated. I tested this on several versions of Kstars (3.5.3, 3.6.8 and now 3.7.0) and I am finding the same letency associated with the Motion Control Panel.

Tonight I ran a test using both the SD card with the Astroberry 3.5.0 where the Motion Control Panel works quickly and the latest SSD with Kstars 3.7.0 where there is still the latency. I did notice that in the 3.5.0 version the mount does not come out of Tracking before making the required motion, while in the Kstars 3.7.0 version the mount does come out of tracking first before moving the mount and then restarts tracking. The delay for stoping tracking looks to be very small in the logs, the issue seems to be that sometimes the mount motion is halted before the mount moves. I am attaching two logs from the run using Kstars 3.7.0; one log is an Indi log and the second log is the normal Kstars log. The test tongith was simple; I setup the mount using the last alignment on the pole, slewed to a star where I would see both RA and DEC motion if the mount moves, and then proceeded to use the Motion Control Panel to move the mount several times in each of the four directions. The log shows that sometimes the motion is halted almost immediately and sometimes it does move. When the mount does move it takes about 1 second to switch from "Tracking" to "Moving" and about another second to complete the move and restart "Tracking." But there are a number of instances where the mount motion is started but immediately halted.

The third log attached is from the test using Astroberry 3.5.0. If you look at the Motion of the mount in the logs you will see that the Astroberry log shows that the time between the mount moving and movement halted is very short, but the RA and DEC values have changed. However in the Kstars 3.7.0 log there is a similar short period between the call for motion and the halting of motion, but the RA, DEC numbers have not changed.

All of the equipment, cables, USB hub and RPi are exactly the same for the two runs which were only miutes apart.

I really would like to figure out what has changed to make the CGEM mount behave differently between the two versions of the program.

There are the two logs for the Kstars 3.7.0 run:

One suggestion would be to list what version the manual refers to and what is the date of the latest update. I don't recall seeing that when I looked at it.

I will consider what I may have to contribute to the manual.

Read More...

I am still experiencing this latency in the response of the EKOS Mount Control 'widget', however the log shows that motion was initiated and motion completed within a range of 1 to 3 seconds (no other information is shown in the log). I tried changing the Indi files for the mount. I swapped the mount Indi files from a previous version of Kstars, but this did not change the programs response. There previously used to be a selection for the CGEM DX mount (in an earlier version of KSTARS ) the current versions list a different type of mount (CGEM HC), but the reference is to a file for the Celestron CGEM GPS mount. The mount identifies as a CGEM DX.

I did notice that before the mount can respond to a motion selection it must first stop "tracking" and then re-engage tracking after the motion. This may be the causer of some of the latency. I tried turning off tracking and then selecting a motion, but the latency was still there.

What is interesting is that PhD2 guides the mount fine, which means it is not experiencing the same latency.

I don't recall this level of latency in older version of Kstars, I will have to check thru all my old SD cards to see if I can recreate the way it used to work.

I would appreciate any input on this and particularly if updating to 3.6.9 resolves this problem. I will be doing that as soon as I back up my current working system.

Read More...

Thank you for this information, I was unaware of that capability. I will spend some time going thru the Kstars Handbook on this and other features. I have been using Kstars for several years now, but I admit that I have only updated the version I am using as new features were presented that I felt warranted the upgrade. I have not kept up with ALL of the changes and additions.

Read More...

Thank you, is that in 3.6.8 or 3.6.9. I am currently running 3.6.8 and I don't recall seeing it, but I may have missed it.

Read More...

Advancements in processing software include the ability to remove the stars from an image and recombine the stars from the same or a different exposure. In order to preserve the color of the star field it is important not to saturate too many stars and too many pixels in any one star. I understand we have an exposure calculator, but that is mainly concerned with swamping the read noise and gathering enough exposures to reach a desired level of S/N.

It would be beneficial if the Fits Viewer could present the number of saturated pixels in an image, so we could determine what minimum exposure to use in gathering just the star data to preserve the most color in the stars.

I don't think the current 'statistics' include this number (I would be happy to be told different).

thanks,

Read More...

I am running Kstars 3.6.8 on an Rpi4 with an Ubuntu 22.04 OS. I have a CGEM DX mount and I am experiencing the same latency, fortunately I am not, currently, chasing comets. What is the solution in my case? Is the mod in an Indi Control setting, a driver or in Kstars/Ekos itself?

Read More...

John,
Thanks again. Yes that was going to be my next step, uncheck everything. I will check it out (bad pun) the next time I am under the stars.

I have lots to learn about using your Auto Focus tool, but what I have used so far has been working great for establishing a good focus.

Ron

Read More...

John,
Thank you. I am glad that my activity has possibly identified potential bugs in the process. I am afraid that my understanding of the settings for filter offsets is still incomplete. I have watched your video several times, but never while I was actually setting up the filter offsets at the computer. So I have always been assuming I understood the settings.

I will try setting the filter settings again, but right now we are in the middle of 'pollen' outbreak from the pine trees and my scope will turn yellow in a few minutes outside.

My confusion is based on this: I have locked my filters (GRB) to LUM, but I don't want to run a LUM Autofocus when I switch filters. If I call for a Red filter, why would I want to run an AF run on Lum and then apply a pre-determined offset rather than just running an AF on the Red filter? The only reason I can assume is that you might not be able actually do an AF using the Red filter, because the object is to dim. That seems unlikely when setting the system up.

I have pre-established the offsets for my filters (RGB). I run an AF on LUM at the beginning of the evening. Then during the night when I call for a filter, I expect it to move to the most recent LUM AF position plus the offset for that filter. I recall that I did not check any of the AF boxes for any of the filters. I have offsets input, I put LUM in the Lock column for each filter (RGB) so that its offset would be applied to the current LUM setting. (which does seem to be updated when I performed the recent LUM AF). I do not want the offsets to represent the setting from one filter from another (so RED is -90 from LUM and G is +20 from LUM, not from RED).

My question is how do I set up the filter settings so it behaves that way? If I leave all boxes unfilled (no AF boxes checked, no LOCK filter boxes filled in) then does it behave the way I expect? Or do I need to alter my approach?

thanks,
Ron

Read More...

Thank you for following up on this. This looks very promising. I do recall a discussion on CloudyNights (CN) where they considered using the DEC guiding value as an indication of 'seeing.' Their reasoning was that if you had a decent polar alignment then there should be no DEC corrections other than whatever was due to star motion from seeing. So if you subtracted any drift in DEC then the resultant DEC rms motion should be also correlated with seeing. I have not more information than this, but I will try to fine the reference from CN.

thanks,
Ron

Read More...

John,
OK, Glad that you understand the issue I was having. I have never used the scheduler, I roll my scope out of the garage down the driveway to use it. So I only use the capture module to take images, one night at a time. I would expect the capture module to adjust focus when I change a filter to take an image. It seemed like that worked during my previous night, I will attach that log. I don't really need to see or use the filter settings popup from the capture module. Once it is set up in the focus module I would expect it to use those values whenever I use any filter.

I have my filter offsets registered from LUM, but I don't want it to do a LUM Autofocus when ever I change a filter. I want to be able to set up the offsets, then in am evening I will perform a lum autofocus to establish its best focus for that night (at that time and temperature - I may update that later in the evening) Then I would expect the imaging module to adjust the focus (using the pre set offsets) whenever I go to use a filter for imaging.

At least that is what I was expecting the program to do. I will work with whatever you decide. I think this is the correct log.

John,
A little more about my equipment. I have two imaging trains, one uses the EAF and a filter wheel the other does not (a second camera on another scope for plate solving). Last night I was only imaging with the optical train that uses the EAF and the Filterwheel. I did plate solve with the second system, but I never ran a focus routine with it. I did run a focus routine on that system in my last outing, but it does not use the EAF, so I only loop with it while I adjust focus manually using a Bahtinov mask. I don't know if somehow the system could get confused about what was bing used to image, however the imaging last night worked with the filters, I was just not getting automatic focus adjustments.

Read More...