I see different behavior for x64 and ARM64 INDI servers. When I start Ekos on x64 PC I see camera resolution 6224x4168 but for ARM64 resolution is 3104x2084
PS: I remove ~/.indi directory before each test
x64 INDI version: 1.9.9+202211300741~ubuntu22.04.1, ARM64 version is same

Found this in indi_toupbase.cpp sources: github.com/indilib/indi-3rdparty/blob/ma...di_toupbase.cpp#L801
Is this hack up to date?

Another strange behavior for ARM64. My program had to force set some properties (CCD_CAPTURE_FORMAT.INDI_RAW or CCD_OFFSET.OFFSET) even they are already set to proper values after INDI server start. Is this Ok?

More problems with touptek indi driver: if to change binning mode, indi server don't inform clients about mode is changed (but mode is really changed)
This happens on both arm64 and x64.

Thanks for your feedback. I have issued pull request

github.com/indilib/indi-3rdparty/pull/707

I hope that this solves your last issue.

CS Max

I've recently done several compilations using github.com/JerryBlack/buildKstarsNightlyFromGit for several computers. I found that Kstars 3.6.2 works well with INDI 2.0.0, and toupcam basically has no problems.

But once Kstars3.6.3 is compiled, EKOS keeps reporting shooting failures. I believe the problem Jasem encountered most likely happened with 3.6.3, and I recorded the logs.

Also EKOS 3.6.3 has a very serious bug, Cature&Solve for Slew to Target will only parse once and then it won't work or try to slew to fix the error. This caused me to return to 3.6.2

How do you reproduce this issue? you mean manual rotation?

Sorry, the problem has been solved, now 3.6.3 and 2.0.0 are working fine together, toupcam doesn't crash anymore and solver is centered properly. Looks like it was a permissions issue I configured yesterday

===============
Please check reproduce video. I don't have E-CAA. I just mean normal Telescope Slew. to center the target



In the video:
First，use Sync to prove my Solver works fine.
Second, use Slew to Target solved success but dont slew and continue solving. My device has World Wide accessing VNC, if you need, you could login my device by IP port to test. ( This email address is being protected from spambots. You need JavaScript enabled to view it. )

Further testing revealed that after aborting an in-progress shot, infinite exposure failure occurs.

The test conditions were a focus module, a 1s cycle of short exposures by the camera, and stopping midway.

Lanco, would you be able to test the new driver using a usb 2.0 connection? I have never been able to get my Risingcam 2600 to work with usb 2. It connects, but any attempt to capture remains stuck in "Capturing" and nothing downloads.

indilib.org/forum/ccds-dslrs/12884-toupcam-driver.html

First of all, the use of USB 2.0 is not recommended, there may be strange problems, including readout stick, and secondly, the current need to manually copy the OEM so file for replacement, other functions are the same

Thank you for the information.

The usb 3 only restriction is unfortunate, because:

1) The camera works fine over usb 2 with the windows driver in ToupSky

2) My mount's (CEM40) through-the-mount cabling is usb 2, so I must run a separate usb 3 cable for the camera.

Back to the main point of the thread, the new High-FullWell mode:

What are your recommended settings?

HFW - On
Low-noise - Off(?)
LCG or HCG?

With the prior sdk version I was normally using LN=on and HCG Gain 100, while rarely using LCG, gain 100