×

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: 1119
  • Thank you received: 182
Whatever the issues were, they seem to have been fixed in the latest nightly installation (as of today). PoleMaster is being recognized again, and Polar Alignment routine worked as well. The solver had no problem at all this time. Took 4 s only.
I noticed the update to the 6.0.5 QHY version, that seems to have taken care of it.
Thanks, Jasem!
The following user(s) said Thank You: John Robison
4 years 4 months ago #45923

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

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

Thank you for your report. This is good news. I will check my configuration to see if this specific update was successful. Now for a clear night to come.
4 years 4 months ago #45935

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

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

I went back and reviewed all POLEMASTER.HEX files on my system. I discovered an older version. I then normalize all QHY/FIRMWARE directories with the current version. I then checked to ensure my rules were at the same date. Now, I am back in the saddle again waithng for a clear night.
4 years 4 months ago #45951

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

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

Tonight was a clear night finally. I made sure nightly updates were downloaded and installed. I also made sure all PoleMaster HEX files were normalized. I was expecting a good show.

Well, no show was the answer.

i2019-04-11T17:28:54: [INFO] Exposure aborted.
2019-04-11T17:28:54: [INFO] Exposure aborted.
2019-04-11T17:28:54: [<strong>ERROR] GetQHYCCDSingleFrame error (-1)</strong>
2019-04-11T17:28:54<strong>: [ERROR] GetQHYCCDSingleFrame error (-1)</strong>
2019-04-11T17:27:30: [INFO] World Coordinate System is enabled.
2019-04-11T17:27:30: [INFO] World Coordinate System is enabled.
2019-04-11T17:27:29: [INFO] Device configuration applied.
2019-04-11T17:27:29: [INFO] USB Traffic updated to 0
2019-04-11T17:27:29: [INFO] Device configuration applied.
2019-04-11T17:27:29: [INFO] USB Traffic updated to 0
2019-04-11T17:27:29: [INFO] USB Traffic updated to 0
2019-04-11T17:27:29: [INFO] USB Traffic updated to 0
2019-04-11T17:27:29: [INFO] Speed updated to 0
2019-04-11T17:27:29: [INFO] Speed updated to 0
2019-04-11T17:27:29: [INFO] Gain updated to 1

I attempted to use ASTAP and Astrometry. The issue is not with either apps.

2019-11-24T19:49:06 Starting solver...
2019-11-24T19:49:06 Image received.
2019-11-24T19:49:03 Capturing image...
2019-11-24T19:49:03 Solver timed out.
2019-11-24T19:46:02 Starting solver...
2019-11-24T19:46:02 Image received.
2019-11-24T19:46:00 Capturing image...
2019-11-24T19:46:00 Solver timed out.
2019-11-24T19:43:00 Starting solver...
2019-11-24T19:43:00 Image received.
2019-11-24T19:42:58 Capturing image...
2019-11-24T19:42:58 Clearing mount Alignment Model...
2019-11-24T19:42:58 Warning: Equatorial Grid Lines will not be drawn due to limited resources mode.
2019-11-24T19:42:46 Parking the mount...
2019-11-24T19:40:06 Solver aborted after 0 seconds
2019-11-24T19:40:06 Capture error. Aborting...
2019-11-24T19:40:06 Capturing image...
2019-11-24T19:40:06 Restarting capture attempt #2
2019-11-24T19:40:06 Capturing image...
2019-11-24T19:40:06 Restarting capture attempt #1
2019-11-24T19:39:02 Capturing image...
2019-11-24T19:39:02 Clearing mount Alignment Model...
2019-11-24T19:39:02 Warning: Equatorial Grid Lines will not be drawn due to limited resources mode.
2019-04-11T12:27:29 World Coordinate System (WCS) is enabled. CCD rotation must be set either manually in the CCD driver or by solving an image before proceeding to capture any further images, otherwise the WCS information may be invalid.
2019-04-11T12:27:28 World Coordinate System (WCS) is enabled. CCD rotation must be set either manually in the CCD driver or by solving an image before proceeding to capture any further images, otherwise the WCS information may be invalid.
2019-04-11T12:27:27 Detected Astrometry.net version 0.78
2019-04-11T12:27:27 Idle.

In both applets, INDI drivers for PoleMaster were firing off ERROR every time it attempted to get an image. I need to see if updates are not overwriting old HEX drivers for QHY. What is baffling is that PoleMaster_QT does not have any problem working with the device.

I set debug level to Alignment and Driver. The error is PoleMaster exclusively.

ERROR 506.271001 sec : [QHY CCD POLEMASTER-00d7] GetQHYCCDSingleFrame error (-1)

Messages preceding this error are not descriptive to point to the error. Below are the calls within the driver. This looks like the PoleMaster is using the QHY5LII-C driver to do its processing. I will check to see if I have an errant QHY5LIIC driver.

DEBUG 628.961326 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|UNLOCKIMAGEQUEUE.CPP|Put| len 12c000
DEBUG 629.290361 sec : [QHY CCD POLEMASTER-00d7] GetQHYCCDSingleFrame Blocking read call.
DEBUG 629.290518 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|IsQHYCCDControlAvailable|START
DEBUG 629.290580 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|IsQHYCCDControlAvailable| CONTROL_ID=8 return value=0
DEBUG 629.290627 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYBASE.H|ExposureRemaining|Not implemented
DEBUG 629.290673 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal| #1 readnum,badframenum,ret 0 0 -1
DEBUG 629.290721 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal| #1 flagquit 0
DEBUG 629.290762 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|Enter While Loop
DEBUG 629.290806 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|Call GetSingleFrame in Camera Class START
DEBUG 629.290857 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame begin
DEBUG 629.291788 sec : [QHY CCD POLEMASTER-00d7] GetQHYCCDSingleFrame Blocking read call.
DEBUG 629.291828 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame ret=-1 chipoutputsizex * chipoutputsizey * cambits / 8=1228800
DEBUG 629.291931 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|IsQHYCCDControlAvailable|START
DEBUG 629.291980 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|IsQHYCCDControlAvailable| CONTROL_ID=8 return value=0
DEBUG 629.292037 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYBASE.H|ExposureRemaining|Not implemented
DEBUG 629.292081 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal| #1 readnum,badframenum,ret 0 0 -1
DEBUG 629.292128 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal| #1 flagquit 0
DEBUG 629.292175 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|Enter While Loop
DEBUG 629.292217 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|Call GetSingleFrame in Camera Class START
DEBUG 629.292274 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame begin
DEBUG 629.293015 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|Call GetSingleFrame in Camera Class END
DEBUG 629.293145 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|CMOSDLL.CPP|ReadAsyQCamLiveFrame| END SUCCESS
DEBUG 629.294689 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|UNLOCKIMAGEQUEUE.CPP|Put|Get len 12c000
DEBUG 629.294852 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame ret=1228800 chipoutputsizex * chipoutputsizey * cambits / 8=1228800
DEBUG 629.294929 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame ReadAsyQCamLiveFrame success
DEBUG 629.295213 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|Call GetSingleFrame in Camera Class START
DEBUG 629.295313 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame begin
DEBUG 629.296468 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame ret=-1 chipoutputsizex * chipoutputsizey * cambits / 8=1228800
DEBUG 629.297686 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|Call GetSingleFrame in Camera Class END
DEBUG 629.298505 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|no debayer
DEBUG 629.298808 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|roixsize 1280 roiysize 960 camxbin 1 camybin 1
DEBUG 629.300128 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|Call GetSingleFrame in Camera Class START
DEBUG 629.300521 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame begin
DEBUG 629.302062 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHY5LIIBASE.CPP|GetSingleFrame|GetSingleFrame ret=-1 chipoutputsizex * chipoutputsizey * cambits / 8=1228800
DEBUG 629.303194 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|Call GetSingleFrame in Camera Class END
DEBUG 629.303339 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal| #2 readnum = 1 badframenum = 0 flagquit = 0
DEBUG 629.303443 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|Call GetSingleFrame in Camera Class END
DEBUG 629.303564 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|ret w h bpp channels 0 1280 960 8 1
DEBUG 629.303746 sec : [QHY CCD QHY5LII-C-61f7e] QHYCCD|QHYCCD.CPP|GetQHYCCDSingleFrameInternal|END
DEBUG 629.303814 sec : [QHY CCD POLEMASTER-00d7] GetQHYCCDSingleFrame Blocking read call complete.
DEBUG 629.303857 sec : [QHY CCD POLEMASTER-00d7] Download complete.

To recap, the camera equipment within the EKOS profile includes these items.

1. QHY5L II-C
1. PoleMaster
1. ZWO 120M

This leads me to believe that the QHY5II driver is the problem. The RET=-1 seems to suggest that the PoleMaster is working but KSTARS sees the QHY5II driver error out as it is not in use. It is the QHY5II driver throw the exception.

Does Astroberry 2.0 resolve the QHY driver issues better? 2.0 is a flatten and rebuild.
Last edit: 4 years 4 months ago by John Robison.
4 years 4 months ago #46209

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

  • Posts: 983
  • Thank you received: 375
Please test it with Astroberry 2.0.0. I do not own QHY so I cannot test it myself.
BTW. Support for QHY cameras are directly related to libraries from QHY. If some cameras do not work it probably comes from the fact that there are no available libraries from QHY that support these cameras. We cannot do anything about it.
4 years 4 months ago #46237

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

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

To answer my own question, NO. The problem would still be there. Here is “why”.

In words of Foghorn Leghorn, “Ask a silly question, get a silly answer.” Technology is ask and receive everywhere. How you ask is important. What you get may not what you want.

The “why” here is in the ask. In the polar alignment process, EKOS asks the driver to get a picture. The driver says I am taking the picture, bit 1 thru end. Driver says completed. EKOS asks the driver to get a picture. Driver says, “GetFrame ret -1.” This is the drivers NULL value.

The driver yields 1 completed return and 10,000 “ret -1”. If EKOS is expecting ERRORLEVEL=0, that was the “File transfer completed”. Looking to Getframe buffer for answers is the problem. EKOS continues asking and times out.

In the alignment window, I see Solver timed out, Captured failed, and capture aborted. This why I say AstroBerry 2.0 will not be any better. As further proof, the timing of this dance is 5 minutes. As soon as the errors happen, I shut down and pack up. I am expecting a specific file size. The logs are huge for the driver. Pluma pages a while to get to the bottom of a 57MB file. They are filled with “ret -1” messages.
4 years 4 months ago #46260

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

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

I am happy to report, after yesterday’s KSTARS update, Polar Alignment is working again with QHYCCD products. In AstroBerry 2.0, Polar Alignment is working with QHYCCD products. Thank you for updating KSTARS.
4 years 3 months ago #46358

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

  • Posts: 983
  • Thank you received: 375
I'm glad it works for you. So what version of Kstars you have now?

BTW. this means that you have used old Kstars before, because yesterday no Kstars update was released. Unless you use nightly builds, but they are not available on Astroberry 2.0 so I assume you don't
4 years 3 months ago #46374

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

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

Thank you. I setup nightly as encouraged by fellow INDI users. I push updates before attempting anything. I pushed yesterday and tested connecting as if I was outside. I looked for the ret -1 errors and they were gone. This was a KSTARS only update. Nearly daily, I would receive KSTARS and drivers update. This was a welcomed update. I will check what version the 1.1 is at.
4 years 3 months ago #46376

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

  • Posts: 983
  • Thank you received: 375
There are no nightly updates for Astroberry Server, which uses Rasbian Buster as a base operating system (see indilib.org/download/raspberry-pi.html)
What you probably did is setting up nightly updates from Ubuntu. This can screw your system as these are different distributions. (see indilib.org/download/ubuntu.html)
4 years 3 months ago #46409

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

  • Posts: 389
  • Thank you received: 15


Hello,

I must have been sleep writing when I wrote this. Tonight is a clear winter's night. I setup the scope and got INDI running. I fired up PolarAlign and set to PoleMaster. I clicked on Start. I am back to square 1.

Actually, I was inside and out of the cold when I wrote this. The outside temperature was in the 30’s Fahrenheit. The hub was supposed to be 60 Watt. After several abortive attempts, I found my motor controller not functioning.,must be the hub. Time to rethink a better solution.
Last edit: 4 years 3 months ago by John Robison.
4 years 3 months ago #46670

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

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

After a bunch of INDI driver updates and a rethink of my equipment layout. I think I have a solution for the COLD and USB traffic control.

Design

The minimalist in each of us want the smallest footprint. Moving a bunch of equipment is never enjoyable. Creating messy setups just lengthens the time to setup and tear down.

Old designs

USB 3.0 dongle HUB are easy to think about minimal designs. The trouble is the POWER needs of the USB devices. Depending on the PI to supply the power hungry needs of CCD, GPS, and Mount drivers is like asking a moped to pull a 30,000 pound weight.

Powered USB is needed. Out with the dongle'ed USB HUB and in a 7 Port 60W USB 2.0 HUB. Cheap is the other way we like to think. Cheap includes plastic housing. The HUB could support the 6 devices now crowding for power. 60W divided by 6 means 10W per device, theoretically. Cold? 60W is quite warm.

Another concern is BandWidth. USB cables are designed for a 1 to 1 relationship. Unfortunately, most hub junction cables are just like individual USB device cables. 6 devices are all needing to talk. Talking under cold conditions is a different matter.

New design

Segregation of duties works in multiple areas. To segregate, device types can be used as an option to segregate devices. Finding a communication balance is the goal. I selected the RSHTECH Powered 4-Port USB 3.0 hub. The HUB supplies 5V 2A to the HUB. This gives 5V .5A to 4 ports or 5V 1A to 2 ports. CCD types need some power. Mount Controllers and GPS devices need more.

Two RSHTECH were purchased. This gives the following

RSHTECH 1 RSHTECH 2

1 - AstroEQ 2 - QHY5LIIC
1- GPS 2 - PoleMaster
2 - ZWO ASI120M
2 - USB 32GB stick
With Aluminum cases, using VELCRO will not be a problem to attach these to the tripod. The footprint of these devices are 86.9 x 42.5 x 21.6 mm.

I just tested the config inside. Everything is working. PolarAlign now shows an image pretty quickly. The test will be the next free and cold clear night.

Clear Skies.
Last edit: 4 years 3 months ago by John Robison.
4 years 3 months ago #46816

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

Moderators: Radek Kaczorek
Time to create page: 1.135 seconds