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.
Starting with a large post with irrelevant information
Would put it in a different colour but can't be bothered
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.
It's pretty good when you are getting close enough that you are worying about what pole you want to align to.
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
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...
I'll try yet again.kengs wrote:
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 selectedChrisRowland wrote:
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.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.
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.
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.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.
The alignment of the axes used for the correction matters because the correction is calculated in that coordinate system.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 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..."