A few weeks back I experienced capture files stored remotely as "/root/IMAGE_XX.fits" even though my sequence stated "/telescope" on the remote machine. No amount of editing the .seq file and saving different sequences seemed to fix this.
I assumed maybe there was an error in the format statement so reset to default but with no change.
I then created a sequence on my laptop and copied to my desktop and ran a scheduler sequence using this. Some improvement as it now writes to "/telescope/". I have format as "/%t/%T/%F/%t_%T_%F" but it's writing files in the form '/telescope/Light/Green/Light_Green_061.fits' ignoring the target which is set in the sequence file.
I tried copying and editing the sequence file to change the filter to red to make sure changes were taking effect, and I see the following in the logs:
2024-02-20T13:28:59 Capturing 1.000-second Red image...
2024-02-20T13:28:59 Received image 8 out of 10.
2024-02-20T13:28:59 Remote image saved to /telescope/Light/Green/Light_Green_059.fits
2024-02-20T13:28:58 Capturing 1.000-second Red image...
2024-02-20T13:28:58 Received image 7 out of 10.
so it looks like the format statement is not completely respected.
I'm at a bit of a loss as to where I should be looking to fix things so location and format are followed
Read More...
It's been quite a while since I looked at the K3 as I ended up using my K1ii for longer exposures. Could it be that the camera is still exposing when attempting to download? I just looked at my K3 and it's left in PTP mode rather than MSC, and I have a suspicion that this is how I got it to work. I also downloaded files as native/RAW rather than fits, as it was way quicker.
Read More...
ISTR that the K3 and K3ii don't work in bulb mode with the native driver and the mode has to be set to manual. That means astrotracer off, but I would assume astrotracer would compete with the driver anyway
Read More...
For OpenSUSE tumbleweed using the later release of the RisingCam IMX571 (colour)
ls -l libtoup*
lrwxrwxrwx 1 root root 16 May 23 13:30 libtoupcam.so -> libtoupcam.so.53
lrwxrwxrwx 1 root root 22 May 11 16:20 libtoupcam.so.53 -> libtoupcam.so.53.22376
-rw-r--r-- 1 root root 44642257 May 11 16:18 libtoupcam.so.53.22376
ignore the dates as I was playing around with the RisingCam libs
My offset settings are greyed out completely
Read More...
I'm seeing the same issue with a RisingCam IMX571 on openSuSE Tumbleweed latest (English)
Read More...
I just did a quick test with a run of 0.5 second flats with my ToupTek ATR3CMOS26000KPA and indi v2.01 and I'm not getting pauses with the fan in my case
What I did notice was the cooler buttons can be set to on and off simultaneously. Is this expected behaviour?
I notice I can't set Offset in the capture module, is this what you referring to? I just set black point in the settings and image stats seems to suggest this works
Read More...
Sorry, I neglected to mention that the remote machine is OpenSUSE Tumbleweed as well, and generally expected behaviour
on UN*X is to replace whitespaces with underscores
Read More...
I have an issue with filenames having / not having whitespaces.
If I save locally it does the 'right' thing and replaces whitespaces with an underscore. The same format statement saved remotely and underscores are not used
local: Kstars 3.6.4 stable on OpenSUSE tumbleweed
remote: indi v2.0.1
camera: RisingCam IMX571
AFAIK this has been the case for me for some months and causes some hassle with command line scripts and processing.
Is this something which can be fixed in settings or with a well crafted format string?
Read More...
2. FITS transfer format gets broken images :
knowing which camera driver you're using may help. Also versions of kstars and indi, whether the indi server is remote or not, and what hardware.
Siril has a dropdown to autostretch the image which may help. Also image information->statistics can give you a rough idea of image data
Read More...
If it's the SDK libs then they got posted to
RisingCam's AliExpress store
Direct link
Not sure whether linking this updated SDK lib (53.21907.20221218) in /usr/lib64 (assuming you're running Linux) will help, but has to be worth a shot
Read More...
Via Eddie at RisingCam.
He did say "I have listed new software, ASCOM driver and SDK download link in my store Home page"
files are listed as 2022-12-18, so not a lot newer
Read More...
I took delivery of a RisingCam IMX571 (ATR3CMOS26000KPA) and had something of an ordeal to get it working with Indi/Ekos.
To cut a long story short, after building and installing the latest code from Git everything worked apart from all images came out completely black. I knew it wasn't the camera as it worked with the supplied RisingView software.
As a long shot I replaced the Indi supplied libtoupcam.so with the one from the supplied SDK and everything works now.
So I assume the latest cameras are somewhat different.
lsusb reports as;
Bus 002 Device 003: ID 0547:13da Anchor Chips, Inc. USB3.0 Camera
I'd not seen the product ID 13da elsewhere when trying to get this to work
Apparently the latest SDK will be posted to the RisingCam store
Read More...