×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Polar Alignment issue with EKOS and Astrometry

  • Posts: 43
  • Thank you received: 4
There is an issue with GPS dongle together with chrony/ntpd.
I wonder whether you have met such issue or not
indilib.org/forum/development/5231-indi-...from-gpsd.html#40677
Last edit: 4 years 6 months ago by ecloud.
4 years 6 months ago #43857

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.
4 years 6 months ago #43878

Please Log in or Create an account to join the conversation.

  • Posts: 4
  • Thank you received: 0
Last edit: 4 years 5 months ago by snow jhon.
4 years 6 months ago #43972

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.
4 years 6 months ago #43992

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375
What about sharing the solution with others? Might be useful if anybody faces similar issue
4 years 6 months ago #43994

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.
Last edit: 4 years 5 months ago by John Robison.
4 years 5 months ago #44077

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello.

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.

[2019-10-01T00:54:05.827 EDT DEBG ][ org.kde.kstars.indi] - QHY CCD QHY5LII-C-61f7e : "[DEBUG] QHYCCD|QHY5LIIBASE.CPP|GetLiveFrame|GetLiveFrame pW=0 pH=0 pBpp=8 pChannels=1 "
[2019-10-01T00:54:05.830 EDT DEBG ][ org.kde.kstars.indi] - QHY CCD QHY5LII-C-61f7e : "[DEBUG] QHYCCD|QHY5LIIBASE.CPP|GetLiveFrame|GetLiveFrame pW=0 pH=0 pBpp=8 pChannels=1 "
[2019-10-01T00:54:05.837 EDT DEBG ][ org.kde.kstars.indi] - QHY CCD QHY5LII-C-61f7e : "[DEBUG] QHYCCDRD|CMOSDLL.CPP|QCamImageParsing|RawDataLen = -1 frameLen = -1 l = 76800 "

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.
Last edit: 4 years 5 months ago by John Robison. Reason: added new informaiton
4 years 5 months ago #44416
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.
4 years 5 months ago #44667

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.
Last edit: 4 years 4 months ago by John Robison.
4 years 4 months ago #45276

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.
4 years 4 months ago #45886

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226
Try giving it an FOV to work from.
4 years 4 months ago #45887

Please Log in or Create an account to join the conversation.

  • Posts: 389
  • Thank you received: 15
Hello,

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.

I am looking at ASTAP as an alternative.
4 years 4 months ago #45898

Please Log in or Create an account to join the conversation.

Moderators: Radek Kaczorek
Time to create page: 1.609 seconds