Chris,

the Ascom sources from iptronn, to my knowlegde, are not published ... (fortunatelly there is a logging function in the ioptron commander showing what is sent/received)

Suppose you refer to the "iOptron ® Mount RS-232 Command Language 2014" manual op the iOptron site? That contains a lot if info, but does not seem to document all available commands.

Normally (if not delayed again by UPS because of operational problems) a CEM60 (non-ec) should arrive tomorrow. I can try to set up a new dev. environment (gave up earlier af uploading a focus driver and getting too many git issues) and will see what I can do. No promisses.


Rgrds,

Paul

Chris Rowland,

Are you talking about this document? RS 232 Command Language

There is no explicit information about pier side. The only reference to pier is on page 8. A partial quote is "This command assumes that the mount has been manually positioned on the proper
pier side for the calibration object. " and is talking about the :CM# command.

If the CEM120 driver reports pier side, there must be an additional command not documented at the link above. We would need to see if the mount responds to the associated query. Trying to infer pier side from other information could lead to mount collisions and would, potentially, make guiding a real mess (switching directions when the pier side hasn't actually switched).

If you read a few posts further back in this thread you will see what I am talking about.

Isn't that always the case with mounts that have no absolute encoders? If you don't put the mount where it should be at cold start, or move manually when connected to computer you are probably in deep trouble ...

Paul

The place where this happens is if you do a solve and sync after the mount has tracked past the meridian. The sync assumes the mount is past the meridian when in reality it isn't. The StarSense HC used to do this and the most obvious problem was that pier flips went through the south pole rather than the North - well as long as nothing got in the way.

Maybe sync should be prevented close to the meridian.

As for pier side I could make an experimental change to the driver to try the speculative CEA command and see if my hypothesis can be conirmed. Will rely on some people volunteering to test and provide good log data and Jasem agreeing to push the change so it appears in the nightly. it would be better if somebody with a suitable mount was to do this...

I can definitely test things, in doubt you can send me just patches, I have to compile myself anyhow. I'm a bit limited timewise though, as I'm on duty here in the observatory....

Chris,

i did some tests sending different values from my Arduino to the ASCOM driver but could not really see how pier side is deduced. (Sometimes even Pier side says "neither" suppose when pointing at az 0. Suggest you wait until i do shome research (comparing to RA/DEC, Height, AZ values from GAC and GEC commands) when the CEM60 arrives.

Paul

Hi,

did a session last night with NINA connected to the Cem60 connected via the ASCOM driver. (After a struggle with W10, deciding that I had now 2 active COM4 ports. So clash with my UPBv2)

Did some resume in the attached file. Haven't analyzed it but it shows the GAC, GEC and GEA commands with the mount in different positions.
(What was strange, I did plate solving with Sync and Reslew, but could only find slews, no sync and the pointing model stayed 0 for all parameters. Wonder if this is ASCOM or Nina)

File attached; If you need the full log let me know. I willing to test if you make changes to the driver but currently only an old rpi2 that I can use. I connected it to the mount yesterday so that worsks)

Paul

Correction: not sure anymore about scope position after the first slew (in RA for SharpCap PA) I always forget to write things down ... and trust my memory. So pier side may have been west. Need to retest that one.

P

I've had a look and much of it makes sense.

The GEA command returns a good value for the pole angle of Castor -58.155, adding 90 gives 31.84 which is correct.
This is the same for M99 except that the dec axis value is positive, indicating that the slew from Castor to M99 did a meridian flip. Given their relative positions this makes sense, although you didn't mention a flip at this point.
But you say there is a meridian flip on M99 but I don't see any change in the GEA parameters.
Ah! that's because the second log fragment for M99 is a copy of the first! Not even the time changes.

The description of what you did is great but it would be better if you were to make notes of what happened and when as they happe and provided this with a full log rather than log fragments The fragmentation process just adds a layer of confusion.

I think there's no reason not to try using the GEA command to get pier side, I'll tidy up what I've already done and push it.

Chris

Hi Chris,

probably pasted the old buffer in the file. S**t happens.

Its complicated, ASCOM not only correct either. Doing some daytime tests.

Slew to M82 which is in the eastern part of the sky. Telescope seems to slew to the correct direction but is east of the pier. I would expect it to be on west side (but weight would be down in both cases).
The pier side reported in Ascom is WEST. (not what I see when looking at the scope)

Further when dec = 0 Neiter is reported . (Telsecope can slew in RA in any direction it stays Neither) As soon as I do slight move in DEC it changes to West or East, and there i one point where it flips. (Probably then sign changes in GEA command)

Paul

I've pushed my changes to my repository at github.com/Chris-Rowland/indi.git

I have edited the indi_ieq_telescope driver to try to use the GEA command to set the pier side. There's log data written so a verbose driver log is essential.

I'd appreciate it if someone could try this and report back. The only files changed are ieqpro.cpp, ieqdriverbase.cpp and ieqdriverbase.h. Otherwise I will need to do a PR and persuade Jasem to accept untested code.

I described tests that would be nice on the other pier side thread, basically pier side values at hour angles of -9, -3, +3 and +9 and allowing the mount to track across the meridian and seeing how the pier side behaves when the mount has tracked past the meridian by a reasonable amount.

Chris