ajh499 wrote: I bet it's all the same issue as I'm seeing with an ASI183MM and a NanoPi M4.
The problem is Linux kernel related, I see errors reported in dmesg when the camera fails to download the image.

I can find later kernel versions that fix the problem with USB3 cameras, but (so far) break the WiFi at the same time.

Then it's at least something different in my case. I'm running kernel 5.2.8. And nothing in the kernel logs that I could relate to camera or USB issues.

Read More...

CWB = Counter Weight Bar.
Try this: Park the telescope in 'default position', the telescope looking at the NCP (North Celestial Pole), and the CWB pointing down(*). Then unpark, and use the INDI mount control to move the telescope (only in RA, don't move in DEC) until the CWB is pointing towards the east horizon. Set this (in INDI control panel) as park position (-> current). Now park.

(*)you probably can also use the 'Goto Home/Zero' for this, without parking the mount

Read More...

calberts wrote: Slew with mount control to a position where you want your OTA parked then set park position in INDI control under site management Current and then Write, works correctly. will end alway on the site you defined

No, not if you are pointing at the pole. Try slewing so that DEC is 90 degrees and the CWB points horizontally towards the west. Store this as park position, and park. Any other position works (well, likely the SEP won't work either), because there's a unique transformation between RA/DEC and AZ/ALT. For the pole(s), there isn't, any RA value will lead to park position AZ=0, ALT=latitude.

For the new ieqpro driver, it doesn't matter what park position you set with the HC, because the EKOS park command will always overwrite it with the values defined in KStars/EKOS. I.e., if you define it with the HC and park with the HC, it goes there. Park once with EKOS, and also the HC will now park to that position.

Read More...

No real idea what it is, but every now and then I have a comparable(?) problem with my ASI1600MMPro (also running via USB3): I can start an exposure, it will count down the time, Progress notice changes to 'Downloading' - and there it sits, not downloading, until I hit 'Abort'.
I can then well start another exposure that would count down, but not download.
I can fix things by disconnecting and reconnecting the camera in INDI control panel. Physical unplugging so far was never needed.

Read More...

wvreeven wrote:

DerPit wrote: Interesting. While I do have libsecret installed, it's not used for kstars at all (nor is it mentioned anywhere in the kstars sources). So it seems to be a sub-dependence from another lib. And it obviously is distribution-dependent (or *buntu specific)

Note that libsecret is a different package than libsercret-dev.

Of course it is. One is the actual library, the other the header files and .so link. And without the .so link the compiler will not find the library to link. But the point is that on openSUSE it does not try to link that library in at all.
Any Arch or Fedora people around? Would be curious to know if they need it.

Read More...

Bummer. I cannot reproduce it anymore. Wonder how I goofed up this time.

I had started KStars on the mount computer, and there started a local indiserver. I connected to that remotely from my laptop, and then ended the session on the mount computer, which left the mount computer kstars running, but hang the laptop one. But as I said, now I also get the disconnect notice and everything continues running.

Read More...

Interesting. While I do have libsecret installed, it's not used for kstars at all (nor is it mentioned anywhere in the kstars sources). So it seems to be a sub-dependence from another lib. And it obviously is distribution-dependent (or *buntu specific)

Read More...

No, this is already the current git, so it's not the 'Sorry' dialog, but something else.

Also, with this bug it is not using CPU. It just seems to wait for some answer from indiserver, without any(?) timeout. At least I had left it sitting there for at least half an hour

Read More...

Just to be sure: Directory ~/Projects/build/kstars did not exist before? If it still has old cache files things go wrong. I'd use a
$ rm -rf ~/Projects/build/kstars
as first line. Other than that, I'm out of ideas

Read More...

Strange. Are you compiling in a separate build subdirectory? If not, try that, and/or remove any CMakeCache.txt files before calling cmake

Read More...

When EKOS is connected to a remote indiserver, and that one vanishes, EKOS (and with it KStars) will hang indefinitely, not reacting to any input other than sending a terminate signal.
Restarting a new indiserver instance at the remote location will not bring it back to life.
This is with the latest kstars (3.3.5-706_g669835dae), so it's not due to the 'Sorry' dialog issue as suspected here

Read More...

Have you compiled successfully before? Installed all dependencies (See INSTALL)?
Just built latest git on my machine, no problems/changes to before.

Read More...

Gonzothegreat wrote: In my last polar alignment session, I was able to do 0°0'12" well I am not going to try to best it.

But maybe try to confirm it with drift scans?

Read More...

There's also one in the capture tab/module, between the 'Preview' and the 'Live Video' Buttons
(if you prefer the display in a separate FITS viewer window)

Read More...