Giving this a little more thought, I can visualize a "predictive focus tool" that could set the correct initial position and step size based on local conditions and the parameters of the rig being measured, by using a feedback loop created by logging the values of the independent variables (that have a significant enough effect to bother with) of each focus attempt, including the available weather data, into a text file database. This would need to be performed against the same starfield for some base number of repetitions at different weather conditions. You'd need to input the measured step distance measured, and the tool would use the telescope parameters configured elsewhere to calculate things like step-width of the CFZ and use the curves generated by the data set at each variable point to build a mesh of actual resulting values, that could be used as a predictor for focus setting(s) that should be pretty accurate once it has enough training runs in it. So as a user, you'd do the measurement, configure the tool with it, and select a reliable and non-variable star (like polaris, for example), run "Train Focuser" (autofocus that saves values to training file). Then, every time you set up, point to Polaris, and run "Train Focuser" again. Do it enough times, and it should get pretty good at predicting focus position for a given set of conditions. The mesh generated, likely might have value elsewhere in the software as well, since it effectively models the performance of your rig at a given location over time.


Let me simplify then. For the telescope you used to generate this graph, calculate the width of the CFZ , and the focal length change of a single step (in microns). Now, in your graphic, how many CFZ widths error are contained in the extreme spread (roughly 1000 steps) of the values you generated?

Thus, estimating a step position based on that graphic, is statistically more likely to produce an out-of-focus image, than one in focus.


Bart wrote: With elevation is meant the altitude of the object (as if using an alt-az mount), this -does- change during a session.

Also, if you take refraction into account, will you then -not- take it into account when using narrow band filters? There the effect isn't measurable.

Now a question, would you consider to focus during imaging or quickly adjust the focus in between lights?
Personally, I don't use very long exposure lights, especially with Starlink up and screwing up our images.

Elevation usually refers to the geographic distance from the earths center, most often expressed as altitude above sea level. What you're referring to is most often called the zenith angle, or the angular displacement from zenith.

The Refractive Index applies to all electromagnetic radiation. It is usually calculated for yellow light for use in astronomy. However, the actual energy (frequeny and amplitude) of a received photon is an independent variable in the calculation for angular deflection produced by the refraction index.

I refocus on every 2 degree change in temperature, or guider crapout, or at the start of any sequence. Focus while taking lights isn't critical to the process, but shouldn't be changed between exposures.


dmsummers wrote: @bdavis:

The refraction graph is about as I expected. The change from 40 to 25 degrees is on the order of an arcmin POSITION. Colors refract differentially, so we'd expect HFR to increase perpendicular to the horizon. Whether refraction or airmass is the major driver, I consider elevation to be a good proxy for modeling/controlling the effect (and it's readily available).


It's not a position graph, it's a graph of the Index of refraction versus the elevation angle at standard temperature and pressure (STP). It is a number representing the angular displacement of incident light rays through the atmosphere showing the effect of thickness of the transited airmass between the observer and the celestial target. The calculated index is directly influenced by temperature and pressure (among other things, but these are the two largest factors), Elevation angle is a scalar value, and it's change due to earth rotation, is based on the location data, which doesn't change (or shouldn't)., so it has no mathematical relationship to temperature, and isn't a proxy value for anything. Unless your mount is on a moving object, it will not have have a direct impact of tracking error, unless .

Temperature has several effects. It causes the materials in the mount or gear to expand or contract, which can change the elevation angle slightly, and the error it produces will be relatively constant, and always in the same direction relative to the direction of the temperature change. So you wouldn't expect to see a lot of tracking error scattered about the regression line, instead you'd see the directrix of the parabolic regression line move up or down the Y axis, but the parabola itself doesn't change its shape.

The principle effect of temperature changes is that they change the index of refraction (RI), and thus change the apparent size of celestial objects. If the atmosphere were still and well regulated, then this wouldn't be a problem, but it isn't. It roils, changes density, and the stratification of the air changes, and this produces inherent error in the RI, and that translates directly to focusing, tracking and guiding errors, and those will be randomly scattered about the calculated RI.

In your post, you refer to Temperature Compensation as though it is a single term, but it's not. It's an ephemeral value calculated specifically for each value modified. There is no one "Temperature Compensation" value. Theres one for refraction, one for expansion/contraction, and probably others. A programmer would have to discuss how they used temperature in the various processes, to discuss it in more specific terms, but the main takeaway, is that temperature compensation is only a meaningful term when it includes the process or value being compensated. It will be different for every process.

dmsummers wrote: I consider elevation to be a good proxy for modeling/controlling the effect (and it's readily available).

It's not. The elevation angle is fixed (or should be) and does not change during a session. It is used for the initial calculation of the RI (and alignment, etc), but thereafter is constant, and so has no further effect on focusing or focus error.


@dmsummers, I'm theorizing only, but given the data you presented, I'm going to bet on refraction being your main residual driver below 40 degrees elevation angle. My logic is as follows: 1. The focuser is mainly using HFR, which is a measure of the size of the circle encompassing the star in the image. 2. Refraction directly effects the measured size of the circle, mainly beginning at 40 degrees above the visual horizon, as illustrated below:


3. Changes in the HFR outside the expected due to step movement show up as residuals (error) in the measured HFR, forcing the measured points to fall outside the polynomial used to determine best focus.
4. Temperature, pressure, humidity. dust, in the air volume the light passes through, all change the refraction of received light

What I don't know, is the size of the HFR errors produced by refraction at 40 degrees and below, or their stability, or the extent to which the programmer factored it into to the focuser tools, but given the parameters you've listed, I'd be surprised if it wasn't the main driver.


Very interesting data. It would be interesting to map the two curves against the calculated refraction coefficient , since I think that's probably the largest part of the differentials you are seeing. Assuming a weather source is configured, Ekos should have that data somewhere, perhaps a script could be genned up to log the calculated R, temp, pressure, humidity, current step, elevation angle, and current HFR. This could be used by the focus module to maintain a quadratic that could be used to auto-configure the focuser at runtime, and perhaps condition other activities as well.


It works very well indeed, and my first tests with it have me slobbering at the improvements in guiding error. The old CGEM motor board and plastic spur gear could manage a 2.5 arcsec guide error RMS on a really good day. My initial tests with Onstep reduced that to around .75-1.0 arcsecs, and I haven't really tuned it yet, or connected the timing signal from the GPS to the oscillator on the Onstep board. I'm currently learning Fusion 360 and designing a case for it. Already printed the motor mounts for it, but had to back up and re-print them with a more temperature resistant plastic, which led to experimentation with annealing the plastic, etc.

Not sure about the CEM70 for Onstep, but the CGEM can be readily Onstepped with a remarkable improvement in accuracy and function. You can use mainboards that also support dew heater control, focuser control, and more. The whole rig can be customized in both software and hardware in a lot of ways, depending on your skill level.


I went a different way, and am upgrading the drive train and control electronics. The largest part of tracking error on a CGEM is the weak plastic spur gear, and cheap motors/motor control. The mount is stout otherwise. So replacing the old spur gear drive with modern stepper motors, and a 3d printer motor control board running OnStep software.


Onstep website is located HERE


Brian Davis replied to the topic 'INDI Driver for SVBONY cameras' in the forum. 2 months ago

Generally, the RPi4 has all 4 USB ports tied into a single PCIe lane limited to 4Gb/s (the SD card uses USB also). The whole Pi, has a max current limit of 1.2a, including board power, and whatever goes out the USB ports. This is why so many people have trouble running gear off the Pi's USB ports.

So, a good first step for problems with all USB gear attached directly to the Pi, is to move it off to a powered hub. Consider that any form of disk write, including images, temporary files, etc, are going to use a lot of USB bandwidth, and since USB 3.0 has a limit of 5Gb/s, and the Pi can do only 4, directly attached devices that use both current and bandwidth (like Cameras of any sort) are an iffy proposition at best, and often produce weird problems, problems caused by starving other devices, or just not working at all.


Once you've connected the Pi to your WLAN, then connect your PC to the same WLAN, and communicate with VNC. Just connect to "stellarmate.local" with VNC, and you should be good to go.


AstroNerd wrote: I really don’t see what all the hype is about in this thread, a GPS is a great add on for my kit, and it gives all the needed info to the system, it is not, as has been said a bad thing at all and works very well. It only sets the time and position once during the initial set up of ekos during a session, the default setting is to not if you were to start refreshing all the item then yes, that would not be good, but this just isn’t the my GPS UBLOX dongle will stay put..... :)

There's no hype. I had a discussion with Jasem about this, and he asked that I make a post about it, and submit an article via the "Research" link above (which doesn't work). Technical posts which provide advice contrary to the "conventional wisdom" always receive pushback and questions, as they should. Such discussion tests the knowledge presented, and aids in understanding. Unfortunately, it's the Internet, and so such posts always attract lots of bombastic ignorance as well.

Where the post went south of right and wrong, was when someone here with Moderator rights, abused the authority they were entrusted with, and proceeded to repeatedly modify what I've written, without notice to me or any other reader, or in support of any rule. They did it purely to appease their own ego.

If this is permitted here, I won't be posting here again.


AradoSKYindi wrote: Hello,

Under KSTARS and INDI, GPSD is PPS based under Ubuntu. With Raspbian, CHRONY provides time. I would suggest using GPSD and properly configure it. I never thought to use GPS for time. PPS was it.

PPS is a logic-level electrical 1hz signal. Unless you see a separate wire from your dongle attached to one of the GPIO pins on the Raspberry Pi, then no, you don't have PPS active, and no, GPSD isn't using what it doesn't have.

To enable PPS in GPSD, you must first create a /dev/ppsXX device. That is normally done by using a dtoverlay, which requires the explicit naming of the GPIO pin the PPS signal is received on. Don't know whether GPSD can be started with a missing device named in its config file or not.

AradoSKYindi wrote: U-Blox 7 device provides PPS. PPS is part of their setup requirements. Besides, my KSTARS GPS sampling rate is 15 minutes. Within KSTARS, I can update as needed manually. As long as I know where I am, a GPS dongle, (properly configured), is a welcomed addition.

Well, here's the manual and spec sheet for the U-Blox receiver, as published by the manufacturer: UBLOX-7 Manual

You'll note, that the receiver can provide a PPS pin, but only if it's packaged that way. USB is not one of the ways. Nor is PPS any part of it's "setup".

Clearly, your understanding of GPS in general, is insufficient to accurately advise others on the subject.