I broke down and compiled indi_asi_ccd and placed it in /usr/bin. This replaces a version from 21st August.
So far, it seems to be working .
I tried a reboot in the event there was something running I didn't realize, but that didn't fix it.
I prefer to use the more stable branch, and it looks like I will need to wait for Jasem to do the necessary update to that. Fortunately, there are clouds in the forecast for the next several days.
I just started up KStars/EKOS/INDI to capture some darks. The ASI camera drivers are telling me both cameras are in streaming mode, and I cannot reset the imaging camera to 16-bit because it is streaming. On the streaming tab, stream is off.
I'm running the following packages from the PPA:
All the equipment in this profile is from ASI, two ASI cameras, an ASI EFW and the ASI EAF. One of the relevant indi_asi_ccd logs is attached for information.
I now have a Davis Instruments Vantage Pro with a Weatherlink Live connection. The Weatherlink Live device is on the LAN and can be queried using http to get information formatted as JSON. I have written a Python 3 script for one level of monitoring the weather station.
I'm willing to assist development (or do the development with some coaching) of a driver for the Weatherlink Live (LAN connection). My C++ skills are limited to what has been necessary to get some Arduino/NodeMCU (and my 3D printer) projects running.
Is there any other interest in taking this on?
I implemented backlash compensation in my moonlite-compatible arduino code at
. I always move x steps beyond the targeted amount when moving outward and then move to the target inwards. As Jasem mentioned, the focus module just waits for the moonlite driver to report that the focuser is at target position.
Feel free to use the code or logic as you see fit for your implementation.
Solved in 0.7s using standalone ASTAP after updating. Failed to solve using ASTAP from SexySolverTester.
I forgot to test with standalone ASTAP on the previous attempt.
Your example solved with the default settings in 1.559s in a single trial and average of 1.4717s for 10 trials here. It failed in my ASTAP set up. Do you have an updated .deb file?
Your image solved faster for me as blind solve (clear the position tick box) and using the scale. I am impressed with SexySolverTester's blind solving speed.
I didn't solve this file in ASTAP or with SexySolver and Astrometry either. I did, however, solve it in ~1/2s using SexySolverTester 1.3 on my desktop, which is a pretty fast processor. Try using the Internal SexySolver with the ParallelSmallScale option.
FYI and followup as appropriate.
I thought I would try a difficult solve.
I cropped from a Stellarium screenshot of M63 at my imaging FOV (+/-) and fed the jpeg to SexySolverTester 1.3.
COMMENT 1 Written by ASTAP, Astrometric STAcking Program. www.hnsky.org PLTSOLVD= F / No plate solution found. WARNING = 'Warning, too small image!! '
I'm happy to help, Rob. I duplicated your results for Han's M13, but it took my machine 1.08s to solve it .
I ran the examples you mentioned above. Changing "α" to "alpha" in the filename took care of the file loading. With that change and using FastSolving, all images but Han K's M13 solved for me. Neither SexySolver or ASTAP solved the M13 image. I also ran one of my own images of M13 which was solved by SexySolver but not ASTAP. The results of these runs are in a LibreOffice spreadsheet (zipped for the forum).
I ran your files with the FastSolving option (generally the better performer) and had the following results:
Deneb_α_Cyg_200s_20191130_175725.fits -- Couldn't open either. I did open and save as fits and jpeg in PixInsight but couldn't open the resulting files in SexySolverTester 1.2 (really strange since everything from my files loaded) M13 dec min 30 degrees.fit -- FastSolving aborted. I don't have an explanation, but a smaller FOV of M13 from my files solved in 0.552s m42_20180918_055007_0_ixdaex_l_cal.fit -- solved in 6.15s NGC_2359_Light_L_900_secs_2020-01-29T23-05-32_007 location removed.fits -- solved in 1.243s Apogee F16M IC443_444-010-R solved.fit -- solved in 8.92s IC1318_200s_20191130_183555.fits -- solved in 0.821s