For better or worse, there's not really a good way to do it. Kstars/Ekos/INDI doesn't really trigger a meridian flip specifically
, it just does a goto. The good news is we can replicate that.
(From memory, so apologies if any of this is off.)
What is done internally for OnStep is things are compared in location to preferred pier side. Which can be best, west, or east.
What the 'command' for meridian flip does is set the perferred to be east (or west, I've turned myself around I think) then a goto. Best from my recollection prefers to keep it on pointing east if already there (think re-centering target), but if not and it's in the overlap, but close it'll move to pointing west.) So if you set it to pointing west (which should be east) it does the same thing if you issued the meridian flip command. Assuming it's within the limits. (Otherwise neither does anything.)
The limits that you set on things are the auto meridian flip limits in OnStep, and it should be set to ON for the auto meridian flip, with home pause set to off. The Ekos setting is the HA to set it before is Mount/Meridian Flip, and that needs to be set lower than your auto flip limit, if you want kstars to know about/initiate the flip.
Hope that helps. Apologies for it being from memory as I seem to have misplaced the cable for my test board (a mega without anything on it) (Tiny hopefully amusing rant: I can find micro, usb-c, and mini cables, along with nikon camera cables, but not old usb1/2 full size cables. Anyone remember when this was promised as a single universal standard so we wouldn't need serial port converters? Ha! /rant)
Apologies if this is essentially a duplicate, I thought I'd responded already, but don't see it.
There shouldn't be anything causing that, but I have in the past had issues that sound similar with a build from non-clean. I'd make a new build folder and see if it keeps happening. I haven't touched any of the park code. It mostly comes from @azwing and/or the lx200 base. However, I don't see any changes there. Can you turn on verbose debugging and post a log? (It should show :hR# and/or :hP# being the unpark/park commands)
The problem is that INDI::Weather (Well, WeatherInterface more specifically) handles things as if it's a read-only value (which is usually not an unreasonable assumption). So I'll probably implement a 'setT/P/H' control above and on the same tab as a workaround, and see about sniffing weather values from other drivers as an option. To allow for dew heater operation without having the sensor on OnStep. Also probably grab OnStep's dew temp calculation, and for the heck of it, the MCU Temperature (if available on the processor).
Added to the latest master. It's read only though, and I need to look into the dew heaters, and for the BMP280 I have, add support for changing the values (and useful for a heater for anyone who doesn't have a weather sensor, or maybe I can pull that from others.)
Please let me know if anything is broken. (I don't think so, but well it can happen.)
rbarberac: That should be fixed with OnStep unless I misread conversations?
It looks like that's not the right firmware, or at least I can't find any reference via google of dmfk72uc02_162.euvc (Their naming scheme has for the 2nd an m (mono) or an f (color) never both)
It looks like you uploaded the wrong firmware, try it with the DMK 42AUE03 namely the dmk42ue03_4001_uvc.euvc as that appears to be the only AR0132 sensor based ones they released (along with a DFK version), though I can't find any support references to that model number outside of repository. Though I did find an old product catalog.
The controls thing should use the uvcdynctrl command either the same? or something similar, as above. Hope that helps.
Since I haven't updated in a bit. I fixed a bug yesterday not allowing to set the slew rate, should be in the next release.
Port 9998 has worked for quite a while.
As far as the focuser, I haven't implmented it yet. I did get into the habit of using 1 micron = 1 step in Config.h. I'd like to not break it for anyone potentially using it, but I need to refresh myself on the focuser. I'll probably let it toggle.
Couple of things on my todo list (numbered for convenience, not priority):
1. Changing the MaxRate replacement (degrees per sec)
Question on this: Would people prefer a settable 50-200%, as Degrees per sec, or the 50,75, 100, 150, 200%?
2. Intervolometer support
(Might be a priority, simply because I have some D5100s, and if I could trigger them as well as the main one in Ekos, that'd be handy until the Ekos/Kstars Imaging train gets done.)
3. Focuser Changes
4. Dew heater
5. Weather support. (Read BME280/etc)
6. Tangent arm support (Plate solve then adjust?)
7. Check backlash values (Changed to allowed to 3600)
8. DC Focuser support (Not sure if that works already or not?) Might need someone who has one to help with this.
9. TMC_SPI reporting support. (I got one for testing, and finally went to put it in on this cloudy night. I unfortunately missed the: You have to have both axis be SPI if one is, so this will be working at some point, but when is a big question. Oops.)
10. Equivalent of MoveAxis support to allow for following satellites. (Kstars issue more likely than OnStep directly, as the custom rates are added in, but Kstars doesn't have a way to send the rates/information, AFAIK)
Anything anyone else wants?
Off topic: That's a cool idea for design. I can't do it on mine, but I'm assuming that's a rotator as well?
On Topic: I also use a 3D printed focuser, and I have similar issues with backlash, though usually it's pretty good about it. I'll put it on my list of things to look at doing. But I've been quite involved with a local makerspace lately, and that doesn't show signs of letting up.
I have thought about it before, and I really think it's a good idea to look at.
Especially If it's obtained over a time period, if there was a way to pass a value for how fast/slow it's moving (assuming RA only) then that could allow for some drivers to adjust their tracking rate to correct. (I know OnStep could, and I suspect others.)
Just pushed a pull request up, and updated to version 1.8. No new features, but it does fix a delay issue for fork mounts.
It also changed the mount type to be an enum, because that seemed a bit more readable, and has a few incomplete things for looking at the PEC recorded values.
As I look at the PEC values, it strikes me, that everything using a ms value derived from an ancient interface is silly, as opposed to sending it in arc-seconds, or fractions thereof.