Chris Rowland replied to the topic 'New forum software' in the forum. 9 months ago


Starting with a large post with irrelevant information



Would put it in a different colour but can't be bothered




 

Think it's awful. The message box that can't be cleared.  The awful chunky font.  The garish colours.  Using different shades of grey for text and background.

Then for some bizarre reason the text in the box I'm using to type this is tiny and thin.

 

Read More...

DerPit wrote:

ChrisRowland wrote: It seems to me that because the three plate solved positions are reported as unrefracted JNow positions the pole position derived from them will also be unrefracted JNow.


Hmm are you sure about that? The coordinates you get are unrefracted, yes. But what you apply is a relative correction, based on what you <em>see</em>, and that is refracted positions. That's why I assumed aligning to the pole would give you the refracted one.


I'm not totally confident.

AIUI you are saying that because the reference star you are aligning on is refracted the pole position correction must be refracted. I'm very unconvinced about that because the refraction error of the reference star will depend on where the star is. A star that's in the South will have a refraction error that is opposite to a reference star in the North.

It's pretty good when you are getting close enough that you are worying about what pole you want to align to.


:lol:

Can however well make a difference if you happen to live close to the equator. For me it's already 1.1 arc min, and I'm only at LAT 29 ;)


I think that polar aligning to a couple of arc minutes is plenty good enough for a portable set up. Getting better than that would need something like the TPoint method available with the Software Bisque mounts where a precise alignment is determined using about 100 stars, then the mount is adjusted using the high precision mount screws

Read More...

It seems to me that because the three plate solved positions are reported as unrefracted JNow positions the pole position derived from them will also be unrefracted JNow.

Assuming that is the case then the best way to get to a different pole would be to correct for refraction in the JNow coordinate system. I would be less confident correcting for refraction in the observations because it will vary according to the altitude of each observation.

It's pretty good when you are getting close enough that you are worying about what pole you want to align to.

Read More...

kengs wrote:

ChrisRowland wrote:

wvreeven wrote: The polar alignment error is an angle calculated irrespective of the used coordinate system. The correction vectors are projections in the local azimuth and altitude system but could be any other coordinate system. As long as you make sure that the selected star ends up at the other side of those projected vectors, you’re good. Whether or not the mount is level is irrelevant.

This is not correct. The axes used for the correction matter. If it didn't and any way of moving the scope to put the target star in the calculaed position was OK you could use Ra and Dec movements to do this. This would obviously have no effect on the polar alignment.

That makes no sense Chris. In effect you are saying that if the mount is out of polar alignment, e.g. because a previously polar aligned mount has been set up with a tripod leg not extended properly, then the calculated correction is going to be wrong simply because the mount alt and az do not correspond to terrestrial alt and az. If that were the case the tool would never work at all. Of course it is essential that only the alt and az controls are used and the scope is not moved from its position when the star is selected
But once the polar misalignment is known in alt/az it is fairly trivial to calculate to calculate what movement is needed for a given star in HA/Dec and display where the guide star should be moved. As long as it is moved using the alt and az controls only then polar alignment should be achieved.
It sounds like the same erroneous argument as to why a mount should be level to polar align it.

I'll try yet again.
Yes, you can rotate the mount about any set of coordinates to correct for a polar align error. But the correction indication determined by using a reference star will depend on the position of the star determined in the coordinate system of the correction axes.
There are a number of positions which need to be avoided, for example for the normal Alt Az corrections a star at the zenith will be a poor choice for the azimuth correction because adjusting this axis will not move a star at the zenith. Similarly looking East or West won't work for the elevation correction. The optimum positions are fairly close to the meridian and away from the zenith. Avoid a band running overhead from East to West.

Your tripod leg length error will have the effect of rotating the mount about an axis defined by the other legs and in theory the required corrections could be determined in that coordinate system. You could then get a correction that could be corrected by adjusting tripod legs. That's going to be tricky to determine. Simpler to determine the error in the AltAz system and correct in that system.

Not having the mount level will make a difference but as I said previously the effect will be small for small errors, about one arc minute per degree of error or level.

Read More...

wvreeven wrote: The polar alignment error is an angle calculated irrespective of the used coordinate system. The correction vectors are projections in the local azimuth and altitude system but could be any other coordinate system. As long as you make sure that the selected star ends up at the other side of those projected vectors, you’re good. Whether or not the mount is level is irrelevant.

This is not correct. The axes used for the correction matter. If it didn't and any way of moving the scope to put the target star in the calculaed position was OK you could use Ra and Dec movements to do this. This would obviously have no effect on the polar alignment.

Read More...

kengs wrote: And in any case the tool also shows where you have to move the guide star to. It just means the star will not travel exactly along the alt and az lines shown. But its the destination that matters in this case, not the path.

The alignment of the axes used for the correction matters because the correction is calculated in that coordinate system.
I discovered this beta testing the original Celestron Polar Align when I tried adjusting the tripod leg length to centre the PA star. It didn't work, not even close.

Read More...

The error in alignment caused by the mount not being level will be a maximum of 1/60th of the level error.
So if your mount is 1 degree out of level a rotation of 1 degree in azimuth will give an error in altitude of up to 1 arc minute.

Read More...

You may find that the only thing not working is the screen and that you can run and control the scope remotely in spite of the Press Enter message.

If you are running remotely you can't see the screen.

Read More...

The ASCOM driver doesn't use the HC sync command at all for the StarSense HCs. Instead it applies an offset in the driver to do sync independently of the HC. IIRC there is something similar in the INDI Celestron GPS driver which could be used.
I'm not in a position to do any INDI development at the moment but if someone wants to have a go... The 'm' command identifies the HC type, NexStar or StarSense. If the command fails it is a NexStar.

Read More...

I have seen this sort of thing in the past, particularly when the mount has tracked past the meridian. If you run with no scope it's possible to let the mount run indefinitely and I've seen it get to the expected position having rotated through almost 360 degrees. Usually the alignment has been destroyed though. Also seen pier flips via the South pole instead of the North.

One thing in this case is that the declination is negative and perhaps that makes a difference. Perhaps the mount is trying to get to -8 deg by going the long way round, via +90, 180, 270/-90.

One thing that may help is an earlier HC firmware version. - or use the NexStar+ HC rather than the StarSense. The StarSense implements sync is a different way,

Read More...

Thanks, that shows the crazy slew.

I get the impression this is a firmware issue in the HC. All the commands look fine except that after the mount has slewed through +90 in Dec the focus position is reported incorrectly.

I see it is Starsense version 1.20 but what is the exact version? There are three or four more numbers available on the HC Version display.

Chris

Read More...

I suspect that PoleMaster have discovered that most people can't keep the camera aligned between sessions while iOptron haven't discovered this yet, or are not admitting it. Maintaining alignment to the sort of precision people expect is not trivial.

Read More...

There may be a crazy slew in the log data but it's dificult to tell with no information about where in the log data to look.
If you can give the time of a crazy slew then it might help.


The trouble isn't the quantity of the data it's the quality. There's 15,000 to 20,000 lines in the log file and finding the relevant place in that lot is going to be time consuming. Most of it is irrelevant.

Try turning the debug logging off for the cameras, most of the junk is from them.

A video won't provide any more information. I already believe you.

Read More...

The log-29-... file shows communication with the mount but the relevent area is buried among a lot of things that are irrelevant to this.
I've found a sync command at 20:24:23, it's close to where the mount is pointing. There's a slew which completes at 20:24:30 which sems file but there is a message saying that the target accuracy is not met.
One thing is that the last position check is before the mount has finished slewing.

[2020-12-26T20:24:30.719 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] CMD <e> "
[2020-12-26T20:24:30.810 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] RES <41B5B100,09F0BB00#> "
[2020-12-26T20:24:30.810 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[SCOPE] RA-DEC ( 6:09:37,13:58:43) "
[2020-12-26T20:24:30.810 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] CMD <p> "
[2020-12-26T20:24:30.857 EST DEBG ][           org.kde.kstars.indi] - Atik One : "[DEBUG] ParDeviceLibUSB::In - OK!! "
[2020-12-26T20:24:30.876 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] RES <E#> "
[2020-12-26T20:24:30.877 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] latitude 40.9511, sop E, PierSide W "
[2020-12-26T20:24:30.877 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] CMD <L> "
[2020-12-26T20:24:30.880 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] RES <0#> "
[2020-12-26T20:24:30.882 EST INFO ][           org.kde.kstars.indi] - Celestron GPS :  "[INFO] Slew complete, tracking... "
[2020-12-26T20:24:30.882 EST DEBG ][           org.kde.kstars.indi] - Celestron GPS : "[DEBUG] raoffset 38.1, SlewOffsetRa 35.6 arcsec "
[2020-12-26T20:24:30.885 EST INFO ][     org.kde.kstars.ekos.align] - "Slew complete. Target accuracy is not met, running solver again..."

That's all I've found, No obvious problem.
One thing, what sync tolerance are you using? It seems to be an arc minute or less. Are you expecting too much from your mount?

Read More...