Answer my own question might help someone else.

The problem were:
1. On some distributions, the 85-qhyccd.rules was missing in /etc/udev/rules.d (despite repositories, strange!)

2. On one distribution, the line:
ATTRS{idVendor}=="1618", ATTRS{idProduct}=="0715", RUN+="/sbin/fxload -t fx3 -I /lib/firmware/qhy/QHY5III715.img -D $env{DEVNAME}"
was missing.

3. On MeLE fxload didn't support microcontroller fx3, I had the get the source for that and compile it.

So it was a mess, but now it works.Looking forward for some moon and planetary shots!

Håkan W

Read More...

Håkan Wahlberg created a new topic ' USB or QHY5III715C problem?' in the forum. 5 months ago

I guess this may not be an indilib/kstars problem, mor of a USB-problem, but let's try it anyway:

I recently got a QHY5III715C planet camera. It works OK in Kubuntu 22.04 (indilib 2.0.3) and Windows 10 (N.I.N.A).
But on the same PC (which I triple-boot) it doesn't work on OpenSuse Tumblesweed.

On Kubuntu 22.04 I test with dmesg -w which gives me:

[ 766.173935] usb 4-5: USB disconnect, device number 4
[ 770.541945] usb 3-10: new high-speed USB device number 8 using xhci_hcd
[ 770.690377] usb 3-10: New USB device found, idVendor=1618, idProduct=0715, bcdDevice= 1.00
[ 770.690381] usb 3-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 770.690382] usb 3-10: Product: WestBridge
[ 770.690383] usb 3-10: Manufacturer: Cypress
[ 770.690384] usb 3-10: SerialNumber: 0000000004BE
[ 770.773374] usb 3-10: USB disconnect, device number 8
[ 771.053960] usb 4-6: new SuperSpeed USB device number 5 using xhci_hcd
[ 771.078525] usb 4-6: LPM exit latency is zeroed, disabling LPM.
[ 771.079195] usb 4-6: New USB device found, idVendor=1618, idProduct=0716, bcdDevice= 0.00
[ 771.079206] usb 4-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 771.079211] usb 4-6: Product: QHY715U3G20-20230106
[ 771.079216] usb 4-6: Manufacturer: QHYCCD

Seems OK and it works..

On Opensuse the output is only:
[ 766.173935] usb 4-5: USB disconnect, device number 4
[ 770.541945] usb 3-10: new high-speed USB device number 8 using xhci_hcd
[ 770.690377] usb 3-10: New USB device found, idVendor=1618, idProduct=0715, bcdDevice= 1.00
[ 770.690381] usb 3-10: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 770.690382] usb 3-10: Product: WestBridge
[ 770.690383] usb 3-10: Manufacturer: Cypress
[ 770.690384] usb 3-10: SerialNumber: 0000000004BE

and there it stops!

Some USB-driver problem or what?

I have the same problem on a Mele mini-PC running Kubuntu 23.04.

Håkan Wahlberg

Read More...

Hi Wolfgang.
Thanks for your answer!
No, I am not using the Telescope Simulator, I am using the EQMod-driver.
And the telescope coordinates are changed to the east coordinates immediately I push the Polar Alignment Start-button.
So I guess it doesn't matter whether i check the "Manual slew" or not. The plate solver fails and no slew to next position.
I understand that resetting the Alignment Model will delete all alignment points, but where does the east coordinates come from?
I see nothing corresponding in the control panel tabs for the mount.

HTH
Håkan W

Read More...

I am trying to polar align using Ekos Polar Alignment routine, but is failing!
The mount is a Star Adventurer 2i wifi, which as you know only moves in RA direction.
The driver is the EQMod-driver.

So my initial steps are:
- physically move the scope (by loosen the knobs) to a star slightly west of the meridian, then fasten the knobs.
- syncing the scope's coordinates to that star (by right click on the star, EQMod Mount -> Sync)
- doing a plate solve (with sync as solver action), with success. So we seem to know where we are in the sky.


So far so good?

Then when I start the Polar Alignment procedure, the scope's coordinates suddenly moves away to some value
in the east, warning me "This could cause the telescope to cross the meridian!" !
Which also means that the solver will fail when the first image taken is so far away from the telescope's east coordinates.

The reason for the east coordinates seems to be that the alignment module is being reset.
I don't know from where these east coordinates comes from, seems to be some initial value?
And why the reset? How can I keep the solver coordinates? What am I doing wrong?

Has anyone succeeded in doing a polar alignment with Ekos on a Star Adventurer, and if so how?

Håkan Wahlberg

Read More...

Håkan Wahlberg created a new topic ' Support of QHY5III715C?' in the forum. 8 months ago

I am thinking of trying the new QHY5III715C planetary camera for both planetary imaging
but also for DSO lucky imaging for some targets.

So far I am using only ASI indidrivers so I have no experience of QHY indidrivers.
Can I expect that this camera QHY5III715C is supported?

++Håkan Wahlberg++

Read More...

I updated indilib from repository today and compiled it. But I got an error when compiling indiserver:
"/usr/include/ev++.h: ISO C++1z does not allow dynamic exception specifications"

After som DuckDuckGo-ing (I don't use Google Search...) there was some tips on "too old source vs make/compiler versions".

I tried to change CXX_FLAGS from commandline (make CXXFLAGS=-std=c++14) with no success.
So I did it the quick-and-dirty (and wrong!) way by hardcode the settings in indiserver/CMakeFiles/indiserver.dir/flags.make file:

From (-std=gnu++1z):
CXX_FLAGS = -D_FORTIFY_SOURCE=2 -Wa,--noexecstack -Wall -Wextra -Wno-format-truncation -g -DHAVE_MREMAP -g -fPIE -std=gnu++1z:
To (-std=c++14):
CXX_FLAGS = -D_FORTIFY_SOURCE=2 -Wa,--noexecstack -Wall -Wextra -Wno-format-truncation -g -DHAVE_MREMAP -g -fPIE -std=c++14

Then it worked! The version c++14 was just taken by chance, I didn't dig into versions :) !

I run latest OpenSuse Leap 15.4 with GNU Make 4.2.1 and gcc version 7.5.0.

This may not be a big issue, I just wanted to mention it in case someone else has the problem.

Håkan Wahlberg

Read More...

Ah..thanks Jasem!

I use to look at this documentation docs.kde.org/trunk5/en/kstars/kstars/index.html, never the Stellarmate-docs :)

++Håkan W++

Read More...

Thanks for the answers!
Yes, I understand what the ST4 cable is, what was (and still is) not clear to me how to configure whether to use the ST4 cable or connect directly to the mount using USB.
Yesterday I got guiding to work by specifying the guiding camera as the Guider in the optical train for the guiding scope/camera, so probably using the ST4 cable.
Specifying EQMod mount as the Guider didn't work.

The optical train configuration needs more documentation, please.

++Håkan W++

Read More...

Thanks Steve.
Yes, I switch Guider to my guidecamera in the optical train for the guider and it worked!

So, if I understand it correct, guide pulses are now sent via my guidecamera through the ST4 cable to the mount?
But if I specify my mount (EQMod mount) as the Guider, pulses are being sent directly to the mount, not via ST4?
As far as I know this is the preferred way (according to PHD2 people) ?

++Håkan W++

Read More...

I have a HEQ5-Pro mount and connect using EQMod-driver.
I used to guide via the guide camera and ST4 cable, it was configured in a dropdown menu in the guide-module..

In Kstars/Ekos 3.6.1 there in no such option and I can't get the guiding to work.
The log just says "Calibration started" then "RA drifting forward", then nothing, it just hangs forever.
What can be the problem? Am I using the ST4 cable or not. How do I configure how correction pulses will be sent to the mount?

++Håkan Wahlberg++

Read More...

Thank You!
Yes, in Kubuntu 22.04 it is already installed, I missed that!
Now I will see how I can get it in the openSuse (my standard platform) also, maybe compile sources.

Read More...

Yes, I have read a number of threads about GSC but nowhere is it mentioned how to install the binary and the catalog(s).
I am running openSuse Leap 15.4 but I don't find any of it in the repository Astrophotography_Software.
Any tips of where to get it is appreciated!

++Håkan Wahlberg++

Read More...