Polar Alignment issue with EKOS and Astrometry #43878
ecloud, I appreciated the link. I followed it to another link. The child link provided a Stellermate tool called Serial Port Mapper. No tool like this is included with Astroberry. This should be a similar tool with AstroBerry. The Vendor ID and Product ID with SIMLINK+ = "Mount" should work but the parser wants the full text. I am seeking a solution for USB devices.
I attempted to use Rules to setup the GPSD and AstroEQ. SIMLINK failed miserablely. I seem to be on the correct path as KSTARS now shows the GPSD coordinates. However, Observation Planner still does not know where it is at. I have my coordinates tied to a city. So, I help it. This looks like an absolute match for the GPS and CITY to match. Clicking on the GPS button pulls up a blank city. The good news is the GPSD is functioning.
Polar Alignment issue with EKOS and Astrometry #43992
I am happy to report the SYMLINK issue is resolved. Loose nut behind the keyboard is a good analogy. I am seeking a clear night to have everything working as design. AstroEQ and GPSD are now on more solid footing. I am interested in what Astrometry will provide.
Polar Alignment issue with EKOS and Astrometry #44077
Thank you the challenge. I stated in another of my quests that devices powering motors cannot depend on USB power. USB is for control. When setting up EKOS devices, ensure all devices are properly powered.
Use RULES.D to SYMLINK devices to specific use of limited OS resources. On a RPI 3b+, without modification, two RS232 capable devices are available. The OS can play leapfrog with serial ports. RULES.D allows control need for INDI and EKOS.
With the configuration settled, the next step is to test the implementation. Clear nights are needed for these actions.
Polar Alignment issue with EKOS and Astrometry #44416
With the SYMLINK solution in place, I was able to test this configuration and see if Astrometry was operational on October 1. I always consider the first issue as operator error. The night was very clear. I captured the Astrometry sequence. This is included in the images and in the TXT file. Unfortunately, I did not capture the QHY errors which mirrored the errors in the TXT file. Every abort had a corresponding QHY error of -1. What was puzzling was the image in the 37.png. The abort messages must refer to something else. The last line is this section of my INDI log showed purple in INDI. Here, it looks innocuous. Every -1 event is directly linked to an Astrometry abort event.
Of particular concern was PHD. The 56.png image shows that PHD could not see the QHY 5LDII device in INDI. The PoleMaster is not in an OTA device. Both the ZWO 120 and QHY 5LII are each installed in an OTA. I would like to focus them with EKOS. But, errors between INDI and PHD say not that night.
As I see it, INDI shows all devices working. None show errors or conflicts. Why Astrometry is aborting does not make sense. My goal is to have the ZWO 120 to capture, the QHY 5L-II to guide and the PoleMaster to align KSTARS. I am reviewing any configuration steps which could be causing these errors.
Polar Alignment issue with EKOS and Astrometry #44667
I went back to the FOV calculator and looked up my equipment for to calculate some FOV values. The PoleMaster is always 11 x 8. The ZWO and QHY 5L-IIC are roughly the same in between the QHY Mini scope and the ZWO 60mm F/4.,6. I will try these values next clear night.
Polar Alignment issue with EKOS and Astrometry #45276
Finally, a clear night has occurred and I was ready. Unfortunately, PolarAlign with EKOS failed. This time the issue is with the QHYCCD driver. I can confirm the QHYCCD driver for PoleMaster is aborting Solver. There is a direct correlation between the -1 messages and aborted Solver messages. I will send a portion of INDI session with the error. I aborted the session as I could not set the alignment.
PoleMaster works fine outside of EKOS With PoleMaster QT. Under EKOS the QHYCCD driver immediately throws an error when getting an image.
Oh, FOV is set by the primary scope. However, the FOV website calculates a different FOV because a eyepiece is included. Having individual piece parts does not assist.
Polar Alignment issue with EKOS and Astrometry #45886
Finally, a clear night was in my area. I ensured the nightly build was installed on my PI for ZWO and QHY products. All systems were a go. EKOS was communicating well with all of the devices. I went to polar alignment and this error started popping up in KSTARS bar. ERROR GETFRAME -1 with Polemaster. Mutilple errors showed up in the console of PoleMaster.
Now, the kicker... I set up Astrometry to be Offline. I had the PoleMaster to be the tool of choice. Capture to Solving was 3 secs and a beautiful shot of Polaris. 3 minutes later, Solver timed out. Second attempt. Same result. Astro was the plate solver. I am puzzled. What is preventing Plate Solver for Polar Alignment from not resolving. Every Astrometry file is installed on this system. It should find where it is. GPSD is working. INDI is working. But, Polar Alignment is not.
Polar Alignment issue with EKOS and Astrometry #45887
Try giving it an FOV to work from.
INDI/KStars on Raspberry Pi 4, 4gb
Raspbian Buster with AstroPi3 script configuration
Skywatcher HEQ5 Pro Mount
Canon 600D Camera
Orion SSAG/ASI120mm @280mm Guide Scope
Adafruit Motor Hat shield
Adafruit GPS Module
Generic Bluetooth Joystick.
Startech 7 port powered USB Hub.
Polar Alignment issue with EKOS and Astrometry #45898
Thank you for this reply. In this thread, it was said, the FOV is calculated. Ok. EKOS says 88’ x 70’.
I went to the offered FOV calculator and plotted three options specific to my equipment. All where significantly less than the lower limits of FOV in EKOS. I accepted the provided EKOS value
This leaves me with do I pick a band in Astrometry of guess at a FOV? The PoleMaster is fixed and explicitly stated by QHY. This value is not accepted by EKOS. PoleMaster_qt has no problems with the PoleMaster device. If only, PoleMaster_qt and EKOS were aware of each other then polar Alignment is one issue.
I am then thinking about plate solving there after. I think the INDI driver might not be getting updated by Nightly Builds. I saw an error message about 85_camera_qhy.rules the last update. Clear sky events are a long shot for a while. These errors generated during solving with the PoleMaster are the root of the problem, possibly? ERROR getframe -1 is many during the session.