HAE29 guiding

[Boris Stromar]

Hi all,

recently I bought an iOptron HAE29, but I'm having trouble with guiding. Obviously :) I didn't do astrophotography with a telescopoe for quite a while, so it feels like I'm learning everythiong from scratch! I'm using a Pentax 105 SDP with Nikon D5500, guiding with Askar FMA180 and Player One Uranus-C.

Here's the log from last night:  https://openphdguiding.org/logs/dl/PHD2_logs_fAMk.zip

I was not imaging anything, hust trying to get good guiding. Only the last session is a test attempt on Vega. There's an unguided 13 min session. I see that dec has a periodic curve that follows RA, I'm not sure what's going on or if this is normal for strain wave mounts? Guiding speed was set to 0.5x, I'm not sure why it reports as "unknown". I'm using Stellarmate on RPi 4 8 GB for imaging. There's a big oscillation in RA, any help appreciated. The short guiding sessions was some fighting with Stellarmate, you can see from the time gaps I tried to reset and start again :)

Thanks in advance and greetings from Croatia! I hope to get this thing working, in a month I'll be going to Lastovo, a beautiful remote island with darks skies.

[Bruce Waddington]

There isn't really enough data here to get a full picture.  Strain-wave drives aren't known for very accurate tracking in RA so you will probably have to deal with that as best you can.  It looks to me like the mesh on the RA axis may be too tight because the tracking data shows a stiction-like behavior that we don't normally see in RA.  I think you've made it worse by reducing the aggressiveness value, which you shouldn't have done.  You should assume that your limitations are coming from the hardware, not from PHD2 settings or other software.  I think you should follow the procedure in this document to get a good baseline measurement of what your gear is doing:

https://www.dropbox.com/s/zrf0au7jaisvt85/How%20to%20create%20a%20baseline%20for%20guiding%20results%20using%20OpenPHD2.pdf?dl=0

It's important to create a new profile and leave all the settings alone.  The "unknown" report on the mount guide speeds is probably a shortcoming of the Indi driver but it isn't really important as long as you know what the value is.  It's good that you are already using the Calibration Assistant, doing so will continue to reduce the number of operational things you have to think about.  I recommend using 1- sec exposures for the baseline testing but be sure you have run the Guiding Assistant and adjusted the min-move values to the recommended values. 

Good luck,

Bruce

[Boris Stromar]

Thank you very muich for the reply. I'm not assuming it's the software fault. I thought I did make a new profile (you can see the name with suffix "2"), maybe I did something wrong. The 13 min session is the Guiding Assistant run and the 30 min session is just the guiding run. Here's the link to the previous session with the old profile https://openphdguiding.org/logs/dl/PHD2_logs_k9Mu.zip and also last night session  https://openphdguiding.org/logs/dl/PHD2_logs_tZXu.zip where I tried increasing aggression. I'll definitely try to make another new profile.

[Bruce Waddington]

I think you're missing the point.  I'm asking to see a series of guiding tests using the default guiding parameters - not sessions where you've been horsing around with them.  The easiest way to do that is to create a new profile and follow the procedure in the document I sent you.  That includes leaving all the guiding parameters alone.   The goal is to get a clean set of measurements, not to "fix" anything until the underlying problems are better understood.  But that's only my suggestion.  If you want to continue with a different approach, that's fine - but I won't be able to help you. I can already see the mount's native tracking in RA is pretty bad, so if you decide to run the Guiding Assistant, let it run for 15 minutes or so.

Bruce

[Boris Stromar]

The log I sent in my first message was made with new profile wizard with default settings. There's a 13 minute Guiding Assistant session. I pointed the telescope at meridian/equator intersection as suggested. The Baseline Guide also says "let it run for only 2-3 minutes" (page 4), I let it run for 2 cycles (iOptron claims one cycle is 6 minutes). Then I used the Guiding Assistant's suggested min move values. I can make a 15 or 50 minute session or whatever is needed, I didn't think 13 minutes would be a problem, especially after reading that 2-3 minutes are enough. There's a 30 min 56 s autoguiding run (row 12) made with default values, but 0.5s exposures and max duration of 500 ms. If I'm reading it correctly, the longest corrections in that session were 250 ms.  I thought this would be ok for the baseline. I only went "horsing around" after that. That last 30 min session was not intended to be part of baseline measurements. If there would be any possible way to remove the unnecessary sessions from the log file, believe me, I would remove them. I sent the session before that one so you can see I made a new profile. And yesterdays session was my attempt to deal with it the best I can. After 2 months of trying to make it work, waiting for some clear skies, I was very happy to at least get a round scatter graph. It's not a very good feeling having spent 2000+ € on a mount and having to fight it like that. And yes, I believe the mount is faulty and now I see what you mean by stiction. Unfortunately, there's very little good info on this mount, I'm trying the best I can.

[Bruce Waddington]

Ok, I'm sorry you're getting frustrated with this.  When people send us log files that are full of short sequences and lots of experimentation, it can be really hard for us to know what we're looking at.  But that's ok.  I have gone back to your original log and I can see the 13 minute GA run you did, which is certainly long enough.  This is what it looks like (RA in red) with no guiding:

You can see that the basic sidereal tracking of the mount is poor.  It appears to "drift" at a rate of 22 arc-sec/min or 6.6 px/min.  I can't recall seeing anything quite this bad before.  One thing I suggest now is to repeat the test with the mount on the east side of the pier - what you did here was with the scope on the west side of the pier.  There is the possibility that the problem isn't really coming from the RA drive system but, instead, may be caused by gross imbalance of the scope in RA, a loose clutch, or even a pulling cable.  By repeating the test from the opposite side of pier, it should help to shed more light on the problem.  The test was done at Dec = 2, so keeping the Dec position the same will avoid introducing any new variables into the picture.

Regards,

Bruce

[Boris Stromar]

Thank you, I will do that as soon as the skies clear. It would be really great to add the option of erasing all the unnecessary sections before posting it for analysis. There surely is gross imbalance in RA, iOptron HAE29 is a strain wave mount, I'm using it without counterweght. There is no clutch on this mount. Telescope (Pentax 105 SDP) has 6 kg, guidescope and cameras are max 1.5 kg. There's another unguided session here https://openphdguiding.org/logs/dl/PHD2_logs_fAMk.zip and this one has  an unguided session of 13 minutes and also 30 min 56 s autoguiding run in row 12.

I'm thinking I should try putting only the guidescope on the mount, without the telescope, to minimze cable tugging and similar.

[Boris Stromar]

OK, here's the new log https://openphdguiding.org/logs/dl/PHD2_logs_Rfu2.zip taken only with FMA180 Pro and mono guding camera. As a reminder, mount is iOptron HAE29. Now I got a new problem, I sincerely have no idea what's going on. Date is shown as 17 July which is not possible because I was imaging this sunday (23/24 July) and the time is completely wrong. I'm using Stellarmate, time and location updated, time shows correctly on the hand control. I used Calibratuion Assistant's "slew" command to point at the intersection of meridian and celestial equator, but PHD slew way to the west. It seems there's a problem communicating correct time from Ekos to PHD2 because the mount points almost exactly 45 degrees west, which is 3 hours difference from UT. I'm at +1 UT (Croatia), which is now +2 including daylight savings time. It looks like PHD2 is getting info on +2 and an additional 1 hour of DST. On the other hand, when I connect with my laptop, timing is fine, PHD slews where it's supposed to.

Anyway, I manually slewed the mount to meridian. There's a 13 min unguided session, followed by 2 guided sessions (35 and 28 minutes), on opposite sides of the pier. Please, please, any help would be apprieciated.

[Piergiorgio Licciardello]

Hi, 

Perhaps this may not be helpful but, the slew in the wrong direction with Stellarmate is something I’ve experienced more than once and I don’t think it’s related to PHD2.

What I’ve noticed, in my experience (I have an AZ-EQ6 with Stellarmate on Raspberry PI4) is that, if I start the profiles from the App (I have an iPad ) the behavior, sometimes, it’s non-consistent and the mount doesn’t point properly. Even the commands for correction, either in plate solve, and in guiding with PHD2, do not appear proper.

I’ve learnt that, when it happens, the only solution is to switch off everything, including a reboot of stellar mate, and start the services from the laptop.

Use the app only for monitoring the sequences, not to set up the system, calibrate and activate the sequence.

This is my experience but not necessarily applies to your case.

PG

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/2c5745c4-23d1-422e-a5ce-7d7a43b467ccn%40googlegroups.com.

[Bruce Waddington]

PHD2 gets the time and date from the PC, not from anywhere else.  The log files you sent have timestamps for July 17, 2023, so that's what the PC provided as the current date.  There is no ambiguity about that.  I suspect you simply chose the wrong PHD2 log files and sent those - either that or the time and date were wrong on the PC.  Reasons for slewing to the wrong sky position are typically wrong time and date on the PC or wrong latitude and longitude settings in the mount driver.  With the logs you sent, I could see a nice long GA run from the west side of the pier that showed the same huge amount of RA drift we saw earlier.  But you didn't do a GA run from the east side of the pier as I suggested so I still don't know if the excessive drift happens there or not.

Bruce

[Boris Stromar]

I'm telling you again, the session was recorded last sunday, 24./25. july. There's a 13 min unguided session, followed by 2 guided sessions (35 and 28 minutes), on opposite sides of the pier (west and east). I had to manually (with the hand controller) slew the telescope to meridian/equator intersection and then again manually make a meridian flip to turn it to the other side. Here's a screenshot when connected to Stellarmate:  https://ibb.co/chM8wMX You can see Kstars showing the correct location where the mount is pointing, just after I connect everything. It in the zero position, it is pointing to the pole. The Calibration Assistant is showing coordinates dec +90 (correct) and meridian offset 133 degrees (wrong, it should be 180). Time on the mini PC is correct. The pointng info (and time) on PHD2 is not. Same equipment connected to Windows PC shows correct pointing info in PHD2 (dec +90, offset 180 degrees).

[Bruce Waddington]

Yes, I know you ran active guiding sessions on both sides of the pier but you didn't run the Guiding Assistant on the east side.  That's an important element of the test, it makes it abundantly clear how much RA drift you're getting.

I will try again to explain the pointing situation.  PHD2 determines the meridian offset by comparing the local sidereal time with the RA reported by the mount.  Local wall clock time including timezone, is gotten from the OS running on the PC, local sidereal time is read from the mount.  If the calculated value of meridian offset is wrong, the error is coming from one of those two terms - wall clock time or local sidereal time.  The calculation of local sidereal time - not done by PHD2 - also uses two values: the wall clock time and the site longitude.  Some applications may ask you to configure the longitude so they can calculate local sidereal time directly.  PHD2 doesn't do that.  You will have to figure out why the mount's calculation of local sidereal time or RA is wrong.  You were talking about universal time in an earlier message but that is not local sidereal time.

// LST degrees = (280.46061837 + 360.98564736629*JulianDate + longitude) mod 360 where longitude is in degrees, west negative

In the end, none of these problems really have anything to do with PHD2 and I don't think there's any way we can know what's fouled up with your setup.

Good luck,

Bruce

[Boris Stromar]

Yes Bruce, I did. I ran it on west and east sides, but due to this pointing error, PHD2 reports only west side. I will try to another session from my Windows PC if this rain decides to stop.

[wave...@talktalk.net]

Just an observation about time settings for telescopes in general.
Most users of PHD2 probably use a laptop or mini-computer dedicated to the task, at least I do.
So, why not have the mount clock and the computer running on Universal Time? I've done this for years, with the laptop referencing a UTC internet server. I never understood why local time conventions should need consideration and the complications they can cause. If I need to know when it's bedtime, I check the wall clock. Where's the falacy?
Cheers,
- Jack

[Bruce Waddington]

One substantial problem with that is that all the file system operations – including all the logging – will be using and recording timestamps in UT.  People like us who analyze the logs then don’t know what the local time really was.  The imager will be thinking in terms of local time – “I had a problem around 22:30” - and we won’t know where that is in the logs because we don’t know where the person is located.  It’s just an unnecessary complication.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/ea8568a2-f098-4248-b095-051695bd9985n%40googlegroups.com.

[wave...@talktalk.net]

Of course - I hadn't thought of that - thanks Bruce.

Cheers,

= Jack

[Pict...@earthlink.net]

I have discovered one more time keeping wrinkle.  I bought a small diskless PC to run my equipment a while back.  It works great, but it apparently it lacks a battery to keep a clock running.  So, either I leave it on 24x7 (I don't), or I wait until it syncs its clock over the network, or I manually command it to sync its clock over the network (I do this).  If I don't do this, there are very interesting and unexpected results because the PC thinks it is some other day and time.  That would really make for confusing logs!
Manning B

[mj.w...@gmail.com]

"2 guided sessions (35 and 28 minutes), on opposite sides of the pier (west and east). "

I noticed:

The 35 min session was at Az = 120, pier side reported as W .

The 28 min session was at Az = 131, pier side reported as E - should that be W too ?

Michael

Wiltshire UK

[Boris Stromar]

Hi all,

I managed to get a good session (I hope!) yesterday. It seems Stellarmate was trolling me with date/time issues. It didn't update the time from my iPad to RPi4 - but it managed to update it when I used the app from my iPhone! Seeing that everything was fine, I continued testing on Stellarmate RPi. Here's the link: https://openphdguiding.org/logs/dl/PHD2_logs_rLCa.zip

#2 and #4 are Guiding Assistant runs on west and east sides of pier. I was testing with only Askar FMA180 Pro and Mars-M II mono camera (462 sensor).

#7 and #8 are approx. 20 min guiding sessions on east and west sides of pier, both at the meridian/equator intersection. Sessiion #8 has a gremlin at 00:51 which is where a police car just had to drive and stop right by my setup. #9 is a short guiding session pointed to Vega, chosen just to test guiding on random part of the sky. RMS looks good, but I still see the scatter graph is elongated in RA.

Any opinions are more than welcome.

[Bruce Waddington]

Ok, now that we have some clean data I think we can see what's going on.  It looks like the native sidereal tracking of the mount is quite poor, something not uncommon for these strain-wave mounts that aren't equipped with high-precision encoders in RA.  Here's the unguided tracking on both the west and east sides of the pier:

The direction of drift - as much as 14 arc-sec/min - is always in the same direction, so we know it isn't coming from weight imbalance, flexure, and probably not from cable routing problems.  Basically, the mount requires a constant stream of west guide pulses to keep it tracking on an astronomical target.  This means you will have to use a fast guiding cadence and hope that multi-star guiding can keep you from chasing the seeing.  It looks like PHD2 is actually doing a good job of correcting for the problem and the statistics for your guided runs indicate you should still be getting round stars. 

Good luck,

Bruce

[Boris Stromar]

Thank you Bruce. This is the first time I got decent guiding, previously it was elongated in RA and stars in photos were not good. That's why I got a mono guiding camera, I will try 0.5s exposures with multi star. I also found out guiding was better with higher aggresivity.

I have a few more questions because I would also like to understant log viewer graphs better so I can try to help others in my astronomy society (noone is using calibration assistant or making baseline measurements). When I right click on a guiding session and choose "analyse raw RA" I see a very irregular see-saw pattern. This is not the case in friend's AM5 graph. please find both attached, first is HAE29, second is AM5. I'm not saying it's wrong, I would just like to know where the difference comes from. Also, AM5 graph goes +/- 15", HAE29 +/- 5", roughly. Why is that?

Also, in frequency analysis, I do not see the 360s worm rotation period at all. Unguided section shows a peak around 490s, but you can clearly see the 360s peak to peak in drift-corrected graph analysis.

Thank you all in advance.

[Bruce Waddington]

No two mounts are the same, not even when they come from the same manufacturer.  The smoother RA tracking error is preferred because it makes guiding easier and is more amenable to various kinds of periodic error correction.  The high-frequency tracking errors in the upper graph are more difficult to deal with.  These things typically arise from small machining inaccuracies in the RA drive system although they may also be related to gear mesh.  The upper graph is an example of the shortcomings of these types of mounts - the native tracking isn't very accurate and it isn't particularly periodic or predictable.  You should perhaps be asking these questions of iOptron.

Bruce

[Boris Stromar]

Well the bottom mount is AM5, which is also "this type of mount". As I said, I'm trying to understand where these differences come from. It's probably better to find this out before asking iOptron, don't you think? So far I've never seen a see-saw pattern like the one on my mount.

[Jens Scheidtmann]

Boris, 

Well, you‘re using different scales on these two pictures, so the wiggle might be hiding in the second graph. 

Best, Jens

[Boris Stromar]

There is some, but much less, screenshot below. I also don't understand why HAE29 shows error of +/- 5" but in the unguided session (Guiding Assistant) it's +/- 15".

[Ana Ta]

IOptron sold you “lemon”. I have seen this before. 

--

You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/26a15033-85b9-4a50-beb2-da64f0b538c6n%40googlegroups.com.

[Boris Stromar]

Lemon or not, it's still useful to analyze mount's behavior, especially when reporting errors to manufacturer.

[Ana Ta]

I thought the same way as beginner; fighting with an IOptron product asking here questions after every repair by IOptron. 

guiding assistant shows reality; Nothing to analyze their. It is faulty product. Just get refund and buy proper mount from reputable manufacturer: Paramount, AP,  10um, or rainbow astro 135E, if you like this type of mount. 

All the best!

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/cd0c5752-f85e-4128-8cfe-cb3edda9c073n%40googlegroups.com.

[Boris Stromar]

There are plenty of satisfied iOptron users. I'm not keen on calling a product faulty if I don't understand what the fault actually is. It may well be the difference between a strain wave and a regular mount. I still don't know how to interpret various graphs, that's why I'm asking here. If I decide to return the mount as faulty, I must know what the fault is, or I risk receiving an answer that everything is fine and there's no mechanical fault.  And believe it or not, I don't have an infinite amount of money laying around just to throw them around for astro gear. Also, as I wrote before, I'd like to understand various other things, for example the question I wrote earlier: why does HAE29 guided graph show error of +/- 5" but in the unguided session (Guiding Assistant) it's +/- 15".

[Ana Ta]

Yes, there are few satisfied user, and equal number unsatisfied. Sort of 50:50. What do you think will be these ratios for AstroPhisics mounts or lesser expensive Avalon and SkyWatcher EQ6 or 8pro?

Of course guided is better than unguided, but 5” rms is not good. Right? You need <1-1.2” RMS 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/1ffa0a3b-2cad-4bdd-8504-8147ed4f5917n%40googlegroups.com.

[oliv...@gmail.com]

hi Boris

I would suggest :

Verify the basics in the simpliest configuration in order to provide ZWO with not contestable data

- use the ST4 port if possible to avoid PC driver interaction (ambiguity about time, location, etc…)

you will have to manually enter the DEC position in PHD

- manualy point to the meridian ensuite equator

- manualy enable the sideral rate on the mount I don’t know the AM5 but on some mount/drivers you can fine tune the sideral speed. Also some mount may themselves change from sideral to moon speed for instance and stay in that speed resulting in a constant AD drift which PHD2 struggle to nullify it.

- run the drift alignment tool in PHD in oder to get a precise polar alignment (a poor polar alignment will also impact not only the DEC but also the AD drift

Once it is precisely aligned, you can run an unguided session on the equator or close and just after the meridian in order to avoid any mechanical or optical flip. 

In fewer words, an important AD drift can result from a poor polar alignment or inappropriate mount tracking configuration.

Basic tests will help in closing doors. 

Few returns of experience  in case:

Recently I faced an horrific AD drift on my AP1100 for the first time in 10 years. The root cause was the use of a new AP which had a mirrored reticle so the polar alignment was of and PHD could not fully compensate the AD drift with my parameters.

On the EQ6 the most common AD drift causes I faced are :

- either it stays in moon tracking rate after a goto moon from the hands controler and PHD can’t fully compensate the drift

- or the sideral rate fine tuning parameter/offset of the Ascom driver EQmod is not properly set (should be 0 or close, sometimes 1 gives better results, but this is not common)

My 2 cents…

Olivier 

Le 9 août 2023 à 10:29, Boris Stromar <boris....@gmail.com> a écrit :

Lemon or not, it's still useful to analyze mount's behavior, especially when reporting errors to manufacturer.

[Boris Stromar]

Hi Olivier,

I don't think there's a need for all of that, I can do great polar alignment with Stellarmate and PHD2 can point to meridian/equator intersection by itself with no problem. I do not own the AM5, I have iOptron HAE29. I don't know what "AD drift" or "AP" means. Thanks about the suggestion to check the tracking rate, although I think Stellarmate adjusts this by itself, but it's worth checking.

[Ana Ta]

AP is abbreviation for legendary telescope and mount company - Astro-Physics.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/010279fe-0166-4dc6-b3b1-75fea8dc3171n%40googlegroups.com.

[Boris Stromar]

Just to post an update of the problem with wrong mount position being communicated from Kstars/Ekos to PHD2 on Stellarmate, it was a PHD2 issue. Details here: https://github.com/OpenPHDGuiding/phd2/pull/1089

[bw_m...@earthlink.net]

The changes you’re referring to have not been merged or released by us.  Are you saying you built your own version of PHD2 and tested the changes? 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/3024bcf0-e80d-40b3-97da-f028a5b84078n%40googlegroups.com.

[Boris Stromar]

Unfortunately, I don't have the knowledge to understand any kind of code and I didn't test anything.

[bw_m...@earthlink.net]

Then why are you asserting that the pull request you referenced was the cause of your problem?  I don’t think it was.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/3359e780-38dd-455b-b784-8b61154b7cefn%40googlegroups.com.

[Boris Stromar]

You are welcome to contact Jasem for any clarification.

[Boris Stromar]

Hi all,

just an update, I found out what was causing the drift. Well, it's really stupid on my part - the mount was set to solar tracking! I did a solar imaging session and for some reason I expected the tracking rate will revert do sidereal after power off, but it didn't. So PHD2 had a hard time correcting solar tracking which resulted in elongated stars. Now it seems fine, but PHD unfortunately still doesn't get correct time or coordinates in Stellarmate, so I'm using the internal guider. Log is here if anyone is interested: https://openphdguiding.org/logs/dl/PHD2_logs_mumT.zip