Let' try to narrow it down step by step.
OK, so the time of KStars is correct. When you take your hand controller, what does the mount say? If you take a look a the INDI EQMod tab, do the time, date and location values match with KStars?That said, the times reported in the log upon system initialization are correct, so KStars and Ekos are at least using the correct times. If there were a mismatch with the mount, how would I determine it and how would I correct it?
It's not optimal, but you are right, that should not be a significant problem. By the way, you could add your own location with precise GPS coordinates.With respect to location, I've set up KStars with the city of Ottawa, Canada as its location using its default coordinates in the KStars setup wizard. From my phone, it tells me I'm about 6' west and 1' south of those coordinates. Now if I understand the implications of that correctly, with no other data available, the mount would tend to aim slightly west of the true location of an object and thus it would tend to flip slightly *earlier* in time than it would were the precise coordinates known.
Plate solving has no effect upon this, it only helps to position the scope in the right direction.So how would updating that with information from a plate solve affect it? I've already determined that an HA>0.2h has the same results, and that's more than the time difference introduced by my physical offset from the default Ottawa coordinates.
Sure, either the the mount was already on the eastern side of the pier before crossing the meridian or - vice versa - remained on the western side when the meridian flip function initiated a re-slew to the current target.Given this ~13° initial targetting discrepancy, and given than I've tended to aim for objects fairly close to the meridian to plate solve (it's sort of a site constraint), I suppose there is a possibility that there is an erroneous determination post-plate solving that the mount has already been flipped, even though Ekos reports a countdown to a pending flip?
Don't think that this helps. More alignment points improve the model but it does not have an influence which pier side the mount selects. This is only dependent on date, time, location and target position.I guess I could try to initially solve on objects well east of the meridian to remove any possibility of uncertainty as to what side of the pier the mount is on.
You do not need plate solving for testing it, it is sufficient if you have your mount running.But that would have to wait for another clear night, not until Thursday.
As a next step it would be interesting on which pier side the mount is when a meridian flip fails (or finishes within seconds).
- Wolfgang
Read More...
Hi Aurneth,
my theory is still that there is a mismatch in time or geo location between your mount and EKOS. EKOS itself has no influence upon the decision of the mount which pier side is chosen when slewing to a specific target. The assumption of EKOS is that the mount changes the pier side after the target has crossed the meridian when the same target is re-slewed to. That's the entire magic behind the EKOS meridian flip.
When we see that it takes only seconds to slew again to the same target, the mount simply has taken the decision to stay on the same pier side. This is something where EKOS has no influence, it's a decision of the mount firmware. The explanation is that at least for the geo location and time of the mount, this decision is correct - but it does not match with EKOS. So either EKOS has a different time or date set or the geo location do not match - or maybe both.
@Chris, Jasem: do I miss something here? I haven't seen anything unusual here besides the situation that the mount does not always change the pier side as expected. Everything else seems to run fine.
- Wolfgang
Read More...
Did you check whether geo location, date and time are matching between EKOS and your mount? It might simply be the case that your mount has a setup where the meridian crossing is later for your mount than for EKOS.
Read More...
I think updating the documentation is top priority, but it should not be too complicated. Maybe you have the chance to update the Arduino part. I think the Trinket Pro isn't the best choice, since it needs an additional FTDI chip for USB connection. Understanding this took me a while, since it was my first Arduino project. Using an Arduino Nano or a Arduino Pro Mini is a lot easier, since they bring a full fledged USB Serial interface.
Just one hint: with your change the HTML code needs an update as well to show the SQM values.
Regarding the code change: I have an idea how it could work. We could build an INDI driver on top of the current firmware making part of it superfluous. When I find some time, I'll make a suggestion.
I sent you a PM here in the forum so that we can exchange our ideas without discussing everything here in all details.
Wolfgang
Read More...
Hi Gilles,
many thanks again for your update of the Arduino firmware for new new sensors. I tested it, everything works fine. Only for the meteoWeb page I needed to make some minor changes so that it could show the SQM values instead of IR-Radiance.
But with the variety of sensors comes in a new complexity for users. Depending on the specific set of sensors, users need to change both the firmware, the INDI skeleton file and in some cases even the HTML page and the python scripts.
What do you think if we reduce the Arduino firmware in such a way that it gives access to sensors, but all calculations are shifted up to the INDI driver. As a mid term goal it would be great if everything can be configured through the INDI driver without touching the firmware.
Does that make sense?
-- Wolfgang
Read More...
That's a good way to simulate the pier side. Nevertheless I'm not a fan to drag this inside of EKOS but leave this inside of the INDI driver. Maybe we could add this function in a foundation class like inditelescope.cpp so that we do not rely on all single manufacturers to implement it.
Nevertheless, it's a workaround and does not cover all edge cases and pier side strategies of all mounts. The ultimate point of truth is the mount and it's firmware, since it ultimately decides wich way to turn the axis.
Read More...
Jo, the point is that during the scheduler run, calibration returned "DEC swap enabled" and when you started it manually for the same target, calibration returned "DEC swap disabled". I fully agree that calibration steps and all other parameters were exactly the same. Nevertheless the calibration significantly differs concerning the fact whether DEC swap should be enabled.El Corazon wrote: The argument against Chris reasoning that the declination of the second target (NGC2023) plays a role is that I had no problem collecting about 150 well-guided frames AFTER I just turned off the scheduler and restarted it, this time with DEC swap disabled. The target was still the same, nothing in the mount setup had changed, the only difference was that I stopped and restarted the scheduler. Calibration steps and all other parameters remained the same. Therefore, the mount and the default guiding parameters were perfectly adequate to guide well at the low declination levels.
I still am quite sure that this is due to weather conditions or mount physics (backlash etc) and it is not the result of a software bug.
Jo, I would warmly recommend trying PHD2 at least for your iOptron mount. And I am not convinced that you will be happy with only RA guiding enabled. As you rightfully stated, there are several sequences where the guiding runs very smoothly.
Cheers
Wolfgang
Read More...
Hi Jo,
the log names the module that writes the log:
[2019-11-23T23:25:15.407 CST INFO ][ org.kde.kstars.ekos.guide] - "DEC swap enabled."
That means it is a log entry from the guider.
I agree with you that setting "DEC swap enabled" is wrong - the log shows clearly that as soon as the guider tries to correct in DEC direction, the scope drifts away. My only explanation is that this is simply due to a failed (but not detected) calibration. Why:
- In the guiding module the calculation for DEC swap yes/no is based on deltas measured during calibration
- This calculation is the only place that sets the DEC swap checkbox, which controls the DEC corrections while guiding
- There is no code in the scheduler module that addresses DEC swapping.
-- Wolfgang
Read More...
Jo,
I took a closer look what happened. The scheduler itself is agnostic about DEC signals and its directions. It seems to be a problem of the internal guider and its calculations.
When I understand the calibration algorithm right it obtains DEC swapping out of the direct calibration behaviour, so it might be the case that simply your calibration went wrong.
Please check how many calibration steps are set. Maybe increasing this values gives more accuracy.
HTH
Wolfgang
Read More...
Hi Terry,
the startup script of induino meteo starts a stand-alone INDI server, which is wrong in your case. If you want to run both, you need to modify the startup script such that it only issues the echo command starting the induino meteo driver.
Read More...
@ Wouter: no, it does not affect dithering. I checked it both with the internal guider and PHD. After each slew the calibration is cleared. But when the guider dithers, it is not recognised as slewing. Hence for dithering the calibration is kept.
@alakant: this change applies to all guiders. If the option "Always Reset Guide Calibration" is selected, both internal and external guiders receive a "clear calibration" command for each slew detected. If the option is NOT set, all decisions about calibration are left to the selected guider.
Regarding mounts that do not report the pier side, I cannot answer it, since my mounts and the simulator support it. Needs to be tested, but worst case simply set the option.
HTH
-- Wolfgang
Read More...