I'm still stuck with the horizontal lines in the captured image on my 490ex. I tried to experiment a little bit using different OS and drivers: RPI3, RPI4, Ubuntu 16, 18, 19, Raspbian buster, etc.
Found only when I use cloudmakers Atik driver 1.17 (which is pretty old already) there're no horizontal lines.
When I use Cloudmakers 1.30, libatik (the new driver) both having the horizontal lines, at different position s though.
Short captures like 10 sec the lines are visible after autostretch. At long exposures like 300 sec the lines are not visible but I didn't stack them so I don't know if that'd affect the final output or not.
Can someone help please?
there's an FAQ in Atik website about the horizontal lines saying it's the USB transfer problem. I'm not sure if this is due to the USB in RPI4 causing this.
I tried ubuntu 19.10 kstars, raspbian. All same in RPI4.
I've installed the cloudmakers driver and note the differences on the lines. Two lines instead of 3.
I tried to see if this is a general problem by connecting to ZWO ASI camera and there're no lines in the image when it's taken from ZWO ASI
Sorry for cross-posting
There found a few horizontal lines appearing in the images taken by the latest atik driver: www.indilib.org/forum/ekos/5864-horizont...-indi-3rd-party.html
I've compiled indi 3rd party from the source code and found that the captured image from my Atik 490ex contains 3 horizontal lines. See screen. This didn't happen in Artemis software nor the ppa distribution.
Thanks I did went to the thread - yet it's kind of long. I managed to build the drivers and make the EKOS works.
I have to build indi-core from source too. Simply apt-get indi-bin would not work - some shared libraries/headers were not installed for building the 3rd party drivers.
Few basic tests: Looping frames in focus module with my Atik, no problem. Connect to Temma2, no problem.
Yet I've found there're 4 horizontal lines at the captured image of my Atik - It may be the driver problem.
To solve the issue I also build and install indi-core from the source, then build the 3rd party drivers again.
I was trying to build the 3rd party indi drivers in raspbian buster but I've encounter following errors:
error: ‘ccdBufferLock’ was not declared in this scope
Can somebody help?
pi@raspberrypi:~/Projects/build/indi-atik $ make -j4
[ 25%] Building CXX object CMakeFiles/indi_atik_ccd.dir/atik_ccd.cpp.o
[ 75%] Built target indi_atik_wheel
/home/pi/Projects/indi-3rdparty/indi-atik/atik_ccd.cpp: In member function ‘bool ATIKCCD::grabImage()’:
/home/pi/Projects/indi-3rdparty/indi-atik/atik_ccd.cpp:843:10: error: ‘unique_lock’ is not a member of ‘std’
/home/pi/Projects/indi-3rdparty/indi-atik/atik_ccd.cpp:843:10: note: ‘std::unique_lock’ is defined in header ‘<mutex>’; did you forget to ‘#include <mutex>’?
/home/pi/Projects/indi-3rdparty/indi-atik/atik_ccd.cpp:843:27: error: ‘mutex’ is not a member of ‘std’
/home/pi/Projects/indi-3rdparty/indi-atik/atik_ccd.cpp:843:27: note: ‘std::mutex’ is defined in header ‘<mutex>’; did you forget to ‘#include <mutex>’?
/home/pi/Projects/indi-3rdparty/indi-atik/atik_ccd.cpp:843:40: error: ‘ccdBufferLock’ was not declared in this scope
/home/pi/Projects/indi-3rdparty/indi-atik/atik_ccd.cpp:843:34: error: ‘guard’ was not declared in this scope
make: *** [CMakeFiles/indi_atik_ccd.dir/build.make:63: CMakeFiles/indi_atik_ccd.dir/atik_ccd.cpp.o] Error 1
make: *** [CMakeFiles/Makefile2:110: CMakeFiles/indi_atik_ccd.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
I've got my RPi4 yesterday. Installed raspbian buster and was able to compile Kstars and make it work.
The trick is that you'll have to install all of the dependencies, including the optional one. When you perform cmake it will show you which dependencies are not installed.
Make sure you also install astrometry.net.
During my first attempt to run the program appears to be fine, but then when I connect to the CCD simulators the program crashed. Then I run kstars again in shell and look at the error it has and it said it's missing QtQuick.*. So I installed qml-module-qtquick-*
and now appears working well.
Next I will be installing the drivers and run a few tests with my camera and mount.
Interesting Idea... the first thing to look at is the tempfs
then tweaking Stellarmate to configure it to output the files to the ramdrive - I don't own a Stellarmate but I think it's linux based and wouldn't be too difficult.
However I'd also think the bottleneck would be on the USB transfer speed from the camera to the RPI4.
It depends - I have an USB2 camera so putting things in ramdrive would not make much differences to me
Then look at rsync to copy the files from the ramdrive to permanent storage
Just a feeling that the performance gain will be limited - rsync would also need CPU + mem to operate
Yet writing to ramdrive would cause less writing to the SD card to avoid the SD card wearing..
I have the same problem running on pi3. I thought it was a memory problem but it happens still after I added 3Gb swap.
And the problem appears to happen more frequently when it's connected to the mount.
I've located where the problem is. If I select Hong Kong. China from the city list it appears KStar mistaken there's a daylight saving.
If I select Canton, China (which Canton is the province of Hong Kong) and the problem is gone. Then i've found in the DST rules which is incorrect:
#"HK": DST starts 2nd Sun in May, reverts 3rd Sun in Oct (3:30)
# (Hong Kong)
There's no daylight saving rules in Hong Kong. Can I change the DST rules file by myself? Thanks!