I haven't seen an option in EKOS. And have the same issue with my other focuser, a Pegasus DMFC. Shows temperature, but there's nothing I can do with it 
Also, even though it is a snoop device for the camera, neither the temperature nor the focus position are added to the FITS header, which I think would be very nice to have (again, that's for both of them).
Read More...
alacant wrote:
So we're back to the point that someone has to tell PHD2 to actually flip the coordinates
If I read the other posts in the thread correctly and if the mount does not report side-of-pier then if that option is not checked, DEC guiding runs away after a flip.
No, not true. at least not for me (CEM60EC, ieqpro driver). I don't have it checked.
True, guiding runs away after an automatic meridian flip initiated by EKOS. But it runs away in both axes, also RA, because the calibration orientation wasn't flipped. I have to do it manually (Tools->Modify Calibration->Flip Calibration Now...). Then it perfectly guides in both axes.
While I haven't tried, I'm definite sure that if I check it, DEC would run away after flipping the calibration.
The setting only affects how the guiding calibration is flipped, but doesn't tell when to flip.
Read More...
alacant wrote:
It doesn't need to; there is a setting in PHD2, 'Reverse Dec output after meridian flip'.'EKOS didn't inform PHD2 to flip the calibration.'
Oh wait, guess I got fooled. That is something different. It is an additional thing that some mounts need, but is not triggering any meridian flip by itself. It would be applied in addition to the rotation of the guide matrix, and doesn't tell when to rotate. But ioptron mounts don't need that option checked.
So we're back to the point that someone has to tell PHD2 to actually flip the coordinates. If the mount/driver supports pier side, it's done automatic, without pier side I either have to do it manually, or EKOS / the scheduler have to do it.
I agree, this should probably not go into the driver itself, else it needs to be done for every mount/driver that doesn't support it natively. So a wrapper function that uses the mounts info if present, else does some guess work....
Read More...
alacant wrote:
It doesn't need to; there is a setting in PHD2, 'Reverse Dec output after meridian flip'.'EKOS didn't inform PHD2 to flip the calibration.'
Oh, I indeed overlooked that. I was (only) looking for EKOS options to tell PHD2....
The question then is, how does PHD2 detect a Meridian flip? Maybe they already have the code that we are looking for?
** For details of mounts which report side of pier, see here:
github.com/OpenPHDGuiding/phd2/wiki/Reve...-after-meridian-flip
It seems the latest ioptron ASCOM driver does report pier side, so it must be the driver's responsibility to report rather than the firmware...
Cheers.
Hmm, not too informative that table. Just to say ASCOM supports it so not needed to set is a bit Windows-centric
I still wonder how that driver is doing it. Unless you have access to the raw coordinates of the motors you can only guess and/or derive it from the command history, or am I missing something here?
Read More...
dazza1639 wrote: I'm going to order one while they are on offer, and give it a go. I'm sure I will be able to get it working, even if it means a bit of trial and error.
I expect little trial and no error
I (also) have one, and it works like a charm with INDI. Have fun with it!
Read More...
Well, from my experience with the previous mount (GP-DX, eqmod driver) I know flip works perfectly when the mount/driver reports pier side.
So I wonder if one solution could be to check (in EKOS) if the mount does support pier side info, and if not send a separate flip command to PHD2 before telling it to guide.
I'm afraid though that this wouldn't help at all for a second target which is in the other hemisphere. There a lot more logic would have to be involved to decide if a flip is needed or not.
For a final solution I think EKOS would have to keep track where it is, starting from the very first slew. And if one crosses(*) the meridian, set it accordingly. As long as EKOS is the only one commanding movements (no HC, and no auto-flip from the mount) that could replace the pier side info for those that don't have it. But that sounds like a quite invasive, with changes in many places...
(*) rather, the target coordinates are in the respective hemisphere. For meridian flip, the slew happens after you are already on the other side, so technically you don't cross. Still, if the internal pier side tracker says you had been on the other side it would toggle the variable...
Read More...
sterne-jaeger wrote: 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.
Maybe some chime-in with flip-experience on the CEM60 with PHD2: Just went through one, and it didn't work. EKOS didn't inform PHD2 to flip the calibration. So while everything else had worked beautifully (re-point, align the target, in PHD2 select star and guide) the guiding was driving the star off. I had to stop, manually flip the calibration, and restart....
Read More...
I'd assume it is for that driver, but the only mount supported by that driver (AFAIK) is the CEM120. Other mounts still use the v2.5 protocol (supported by the ieqpro driver) that does not have the needed :GEP# commandChrisRowland wrote: I've had a look at the iOptron driver code.
- The iOptronV3 code has pier side implemented and it is read from the mount. No obvious reason why it isn't available.
I had already mentioned to ioptron support that it would be highly appreciated if the CEM60 would support pier side reporting, but I won't hold my breath fro this to happen.
PHD2 allows for declination and pier side so once the compensation for changing pier side has been sorted there should, in theory be no need to recalibrate.
Indeed, for mounts that support pier side info PHD2 just works.
Manuacturers are becoming more aware of the need for good control firmware so if something like pier side isn't available it is worth asking them for it. Don't expect an independent driver developer to do it - his asking for a feature counts as one request, no matter how many people have asked him. If they all ask the manufacturer directly that's many requests.
Chris
Please do! This email address is being protected from spambots. You need JavaScript enabled to view it. I did already....
I agree that it is a quite crucial part for mounts like the CEM60 that is almost perfectly suited to be run in a fully automated observatory. The lack of pier side info is a real nuisance.
Read More...
El Corazon wrote: The mount may not send that signal, but wouldn't Ekos detect that it is sending commands to the mount to move across the meridian and that recalibration or calibration swap is required?
Yes, that it does know. But it has no way of checking if that switch had actually taken place. Only the mount knows which side it is on, not based on coordinates, but based on the steps/position of the motors.
At least during the imaging of the first scheduled target that works, but when the second target it initiated, calibration does not seem to get swapped back. Ekos definitely has that information, since it accurately calculates the time until the next meridian flip.
Usually you can give a good guess which side you're on (like, when the position is more than 10-15 degrees away from the meridian). But inbetween always both pointings would be possible, and where you are depends on the history.
Read More...
Three days ago I did an update to the then-latest KStars (3.3.8_899_gd6a60f19d, self compiled from git) and did a successful observing night with it.
Today, without further changes, it crashed dead just by starting it. Running in gdb reveals
Thread 1 "kstars" received signal SIGSEGV, Segmentation fault.
0x0000555555bb01cd in SkyObject::translatedLongName (this=0x555558e874c0)
at /usr/src/packages/BUILD/kstars/kstars/skyobjects/skyobject.h:171
171 QString translatedLongName() const { return i18n(longname().toUtf8()); }BT suggested something during drawing of the sky view, but it was delayed a bit. So I tried changing the pointing before it crashed (click in map and move the mouse), and that prevented it from crashing.
Since then it's running fine. But maybe some Dev has an idea what might have gone wrong there? Attaching the logs, just in case...
Read More...
Yes, meridian flip worked nicely with my (eqmod-driven) GP-DX. The CEM60 driver doesn't work in that respect, because there's no pir side info. Not because the driver doesn't relay that info, but because you cannot get it from the mount. It just doesn't report that info Therefore I asked if there's any communication implemented to actually signal PHD2 to flip the calibration. But I think the is none.
Read More...
I'd second the question what happens for people using PHD2. Does that setting have any influence? Does EKOS send any info to PHD2 regarding a flip of coordinates?
Also, what about people with a mount that doesn't report pier side? How do you detect a flip there?
Read More...
Somewhat getting ridiculous.....
At least tell me then how 'scaling' would look in your opinion (and why multiplication is not scaling.....)
Read More...