Chris Rowland replied to the topic 'Help with running a script to control a telescope' in the forum. 1 hour 20 minutes ago

So where is the function to determine GST?

Read More...

Chris Rowland replied to the topic 'Help with running a script to control a telescope' in the forum. 6 hours 20 minutes ago

Thanks but that only works of you are running EQMod, many mounts don't implement the LST command.

Read More...

Chris Rowland created a new topic ' Help with running a script to control a telescope' in the forum. 7 hours 53 minutes ago

It occured to me that writing a script to control a telescope could be a way to help people collect the data I was asking for.
I'e found the indi_getprop, indi_setprop and indi_eval script methods but have run int a few problems.

The indi_* commands need the telescope name. Is there a way to get this from the server in some way? The standard properties have ACTIVE_DEVICES - ACTIVE_TELESCOPE but I haven't found a way to read this from a script.

I need the local sidereal time so I can set positions as hour angle. The standard properties specify TIME_LST.LST. Is there a way to read the LST?

Thanks,
Chris

Read More...

Chris Rowland replied to the topic 'ZWO Drivers and Rasperry PI 4 for ALL SKY Getting started questions' in the forum. 11 hours 46 minutes ago

With a RPi4 running Raspbian I suggest using the AstroPi3 scripts to install indi and Kstars.
Download the script (git clone from the repository) and run the setupAstroRaspbianPi.sh script.
It will set your system to a good state with useful enhancements and install KStars and Indi with their dependencies.
My experience is that it just works.

Other solutions seem to me to require far more fiddling and configuring.

Chris

Read More...

Chris Rowland replied to the topic 'Losmandy Gemini Slew Fails' in the forum. yesterday

What's happening is that the mount seems to be rejecting the slew command with code 6. The reason could be that there is something about the position that the mount doesn't like, perhaps it is to a position that is out of range. The mount manual may have more information about what causes the mount to fail to slew and maybe even what the code 6 reply means.

Read More...

Chris Rowland replied to the topic 'Ongoing Problems with Scheduler and Meridian Flip' in the forum. yesterday

El Corazon wrote:

ChrisRowland wrote: I've pushed what should fix this. I was able to reproduce the problem by setting the simulator to flip early and when that happened the problem described happened, the time to flip was reported as -11 hrs or so, the pier side as East and the hour angle as a small negative value.

The Kstars buid doesn't matter for the iOptron tests because this is a driver test, not a KStars test. The latest Indi build should be fine.

I've allowed for the early flips, the pier side is still East, the Hour angle negative but the time to flip is now over 12 hrs indicating that the next flip will be in 12 hours which is what is expected. As a result there is no flip attempt.

The code is in the master but will need an overnight build before it will be in the bleeding edge build.

Interestingly this problem and the other problem have different root causes, this one an early pier side change and the other one a failed park and an incorrect pier side report from the mount. The symptoms look similar but that doesn't mean that the same fix is needed.

I still need the slew tests with logs I described in the other thread.

BTW, with a round world when is overnight in the context of builds?



Which Kstars build do you need for the slew logs? You want the logs for the iOptron driver, correct? I am using the CEM60 driver, I assume that is the same as the ieqpro you are requesting. I need to check that when fire up that mount.

Please explain one thing for me, please: How do you set the mount to flip an hour early? Can this be done inadvertently and could I have introduced that problem unknowingly? Where is that setting?

The simulator has a flip position setting in the simulator tab of the simulator driver. It's normally the last entry on the simulator tab.
For a real driver there could be many ways. Some mounts can be set the flip early - or late. A mount that started with an hour angle error which was corrected with a sync could cause this, so coud a time zone or DST setting error. Having a different time in the mount and Ekos could have an effect.

It makes no sense running elaborate tests if the problem is that a simple setting in Ekos is wrong. I want to check that that is not the case.

Thanks, Jo

The 'elaborate' tests have nothing to do with this second problem - and bear in mind that the 30 minutes or so it will take you to run these test is far less than the time it will take me to analyse the results and work out how to implement a solution.

As I said the two problems have diferent causes and need different solutions.

Read More...

Chris Rowland replied to the topic 'Ongoing Problems with Scheduler and Meridian Flip' in the forum. 2 days ago

I've pushed what should fix this. I was able to reproduce the problem by setting the simulator to flip early and when that happened the problem described happened, the time to flip was reported as -11 hrs or so, the pier side as East and the hour angle as a small negative value.

I've allowed for the early flips, the pier side is still East, the Hour angle negative but the time to flip is now over 12 hrs indicating that the next flip will be in 12 hours which is what is expected. As a result there is no flip attempt.

The code is in the master but will need an overnight build before it will be in the bleeding edge build.

Interestingly this problem and the other problem have different root causes, this one an early pier side change and the other one a failed park and an incorrect pier side report from the mount. The symptoms look similar but that doesn't mean that the same fix is needed.

I still need the slew tests with logs I described in the other thread.

BTW, with a round world when is overnight in the context of builds?

Read More...

Chris Rowland replied to the topic 'Ekos enters endless loop after parking - request for data.' in the forum. 3 days ago

Yes an indoors test is exactly what I want, especially as you are in the Southern Hemisphere. If you can do a Southern test and Jose a Northern one there's a chance that I can get the pointing state more accurate close to the pole.

Read More...

Chris Rowland replied to the topic 'Ongoing Problems with Scheduler and Meridian Flip' in the forum. 3 days ago

That looks like the problem, I set the simulator to flip an hour early and it immediately tries to flip, but the flip fails because it's already flipped. It should do nothing.

Read More...

Chris Rowland replied to the topic 'Ongoing Problems with Scheduler and Meridian Flip' in the forum. 3 days ago

Looking at your local time of 21:43 I would expect a meridian flip to be possible for M51 at about that time.

However the mount reports that the pier side is already East, looking West. So I don't see why one was needed and indeed the mount reports that the flip failed because the pier side has not changed. It started East and finished East.

Looking at the HA it is -0.443 so it looks as if the mount did the flip early. Is this expected?

I can't see the mount, where was the OTA? On the East or West side of the pier?

Have you set the mount so it does the flip early?

Read More...

Chris Rowland replied to the topic 'Ekos enters endless loop after parking - request for data.' in the forum. 3 days ago

I've had a bit more of a look at this and part of the problem is that the mount reports the pier side incorrectly when the declination is close to 90 degrees.

The reason is that that declination repored by the GEC commad and the declination axis position reported by the GEA command do not match. What I'm seeing is that at a declination of 90 deg the declination axis moved about 1.5 degrees past the meridian. This changed the pier side but not the hour angle. From what EKOS was seeing the mount appeared to be parked with the counterweight shaft pointed up instead of down. The difference in position could have been because of a sync.

There may be a solution to this in a closer examination of the axis positions, for example when the declination is close to 90 use the hour angle to determine the pier side. The snag is that for hour angles close to 0 or 12h this will be inaccurate because the mount may have tracked past the meridian. Some one observing Polaris track through the meridian could be out of luck.
I may be able to reduce this area of uncertainity by comparing the dec and declination axis positions but I don't have one of these mounts so need log data from someone who does.

I have a series of experiments that i need doing, yes, this is Science! It doesn't need any imaging or guiding and can be done in daylight.

This is what I need:

  • You must be running the ieqpro driver.
  • I need full data from the driver but nothing from anything else. If running from EKOS the mount ekos logging should have debug on but nothing else. The mount logging must be on and set in the driver to debug or verbose if you have it.
  • I'm looking for a log that contains full data from the driver but nothing from any other device. A little from the EKOS Mount module might help.
Then:
  • Get the mount aligned, a quick align, starting at the park position should be OK.
  • Slew away from the pole.
  • Sync the mount about a degree different in declination from the reported position. This is to give us a small difference to cope with.
  • Make sure Meridian flip is off, we don't want unexpected flip attempts.
Then the tests:
  • Slew to a position where the mount is looking more or less East, I'm looking for an hour angle of -6h, declination 30 to 60 degrees.
  • Wait a few seconds then slew to declinations of +80 deg, +89 deg and 90 degrees. Each time wait for the slew to stop and allow a few seconds for the log to record the position. You should see the pier side be reported as West (looking East) but it might change close to or at the pole.
  • Repeat this with the mount starting looking West, at an hour angle of about 6h and again at declinations of 80, 89 and 90 degrees. The pier side should be reported as East (looking West) but again it might change close to or at the pole.
  • Repeat this for positions looking South, both before and after the meridian by a small amount.
  • And if you aren't too bored do the same thing looking North, as if you are tracking an object passing close to but under the pole.

If you think this is tedious think of the hours I will have to spend deciphering this.

Now if you can, set your mount with a southern latitude, make sure it is sucessfully operating in the southern hemisphere and repeat this, except that the declinations are negative.

Or if you are fortunate enough to be based in the Southern hemisphere just do the test I described above for the North but for negative declinations.

Post the logs to me, with a commentary describing anything you see. The full log should give me a lot of the detail.

Please try not to be too creative about this and try to remove all extraneous data. I need telescope driver and mount module data that just covers this. Somethng like a half hour, not 25 mbytes of data covering an entire night.

Read More...