TESTED V 285 - OK PROBLEM not on test rig now on Obsys I5 8gb ssd Win 10.
Tried live stacking using files created by CCDCiel (on Windows) and Indiserver on a Gigabyte Ubuntu 64 bit connected to DSLR - so straight FITs
See attached screen dump - first file added then every files rejected - files ok via DSS/AT - not in same folder!
After renaming all files back - checked a couple with FITSAV no problem it loads them ok.
Tested out latest version results :-
1. CR2 picked up fine but also picked up TIFF file (used same AT files i used the other tests - it drivers ASTAP mad - see attached screen print
2. Remove tiff files and thumb nails and CR2 images picked up ok and ASTAP ran fine.
Image displays on my Samsung TV from ASAP Live Stack are very pixelated ! - Dont get that with AT
How about a compromise - add direct connection from Top Menu to the Live Stacking Window
Use of Jpeg - As politicians should know - "never say never" - would give speed increase I would have thought and maybe other uses I can't think of (others might ) If its not much extra work and no extra difficult support needed then why not !
OK same tests but using v283
1. Dreaded blue spinning wheel of death gone from ASTAP - a lot more responsive - tick
2. 5 x 35mb FIT files were processed and stack displayed in 2 mins - initial stack displayed in 15secs - faster than AT for FULL display - tick
3. Images with NO darks so same files (only one set RAW and the other FIT) produced finished images as attached but with col adj in AT - could find equiv in ASTAP - Sliders and or Stretch auto or otherwise didn't help.
4. Loss of Colour - but maybe down to the convertion of RAW to FIT's - see note (a) below
So far better experience for me than first test but still nots some refining but hell pretty good in a couple of days - big slap on your back Han's
Would I change fro AT (or that matter DSS Live) - yes if it runs on a RPI4 and the user interface was tidied / simplified - I would like the Col Adj to be a popup modal window that appears/disappears without the other "clutter" so its like DSS Live or AT.
Dont want a lot do I - LOL
So its getting there , from my point of view. Thanks Han's
Haven't got a RPI4 so cant help you with testing else I would.
A - I haven't any FIT's files on my test machine so I used ASTAP to convert my 5 RAW(CR2) files used in the test so this may or may not have caused colour loss.!
Thanks for your efforts - goes without saying really
Thanks for the reply and I note the "error" which is only to be expected in testing - I will download the newer version (using stand alone version of ASTAP not the installer versionanyway)/
The added delay of using DCRAW could / would be removed if you processed images directly in RAW mode as EKOS can provide either if my memory serves me ! I think CCDCIEL converts or receives FIT anyway so CCDCEIL would need to be changed to allow RAW DSLR files - I am using Indiserver on Linux with DSLR attached but running CCDCIEL on Windows so that I can do live stacking via AT - works very well !
CCDciel ,which I have started using live ,does not work too well on RPI as PC says on his site - not sure how well it works on RPI4 - so that really means off OTA processing IMO.
Of course being Indi ,ASTAP Live stacking could be run on a separate RPI (or other hardware) by itself if CPU/Memory is a problem or interrupts workflows (older RPI) it only needs to access the files where Ekos stores images. I have done this before with AT picking up images from Ekos across a wired network (wireless too slow) or using a File sync application.
Still to get a "live Stacking" application in Linux is a big plus.
I will let you know how my testing goes
Some personal observations - sorry but it was a Windows version of ASTAP running on my test rig - an older AMD A6 8GB Win 10 64bit with SSD. I used a DSLR and no Scope set up. Old stored images were used for he live stack. Nothing else out of the normal being used except MQTT broker on Windows!
1. Too complicated IMHO - by that I mean you just need to set the folder where the images are going to be stored and allow the user to end the session and change the stacking source does matter that the scope has slewed in the mean time as I would expect the Live stacking to "Lag" behind by a number of images anyway - ok more difficult when using automated sequence. Plus Astrotoaster allows a fair amount of simple changes,in real time, to the stack (well the viewers displayed image) just by using simple sliders on various parameters via a simple cild window called "Col Adj" - something like that would be great in ASTAP
2. On my test rig ,which runs DSS Live and Astroaster ok ,I was unable,once live stacking started, to do anything within ASTAP as it kept displaying the dreaded revolving circle and "no responding". Task Manager showed very high processor usage but no more than either DSS or Astrotoaster - figure shown was around 34% with only 2.7gb out of 7gb of memory used.
3. I could not find a way to just monitor RAW (CR2 files) as per DSS etc and let ASTAP do the conversion if required to FITS. I know ASTAP will convert RAW files to FITS for normal stacking,
4. Personally I would prefer the Live Stacking to be a separate application and NOT part of ASTAP - simple and clean which both DSS Live and Astrotoaster are ,even though they use DSS in the backgound - but I never need to start or see DSS !
5. The ability to reject some images in the Live Stacking list and restack would be nice.
As I say this is my EAA personal observations and know it will be used in other ways ,so it is a blinkered view
Plus what is the hardware testing set up beings used by others - RPI ? or other - obviously running ASTAP on new faster kit and maybe Linux OS would my problem as noted by point (2) but would be interested on what others are using during this test / development phase.
A Lot of EAA users , which I am one, also use very fast OTA's , sensitive CMOS(but DSLR works as well !) or add Hyperstar which enables very short <10 secs exposures which are stacked and produce good details even after 3 or 4 images and not just one bright objects like M42.
it does not need to be a fully integrated into Ekos but an application that runs along side EKOS e.g. it could just be set up to monitor a folder of exposures - e.g. Astrotoaster style (Deep Stacker). Perhaps as PC CCDCIEL works well with Indi you could persuade PC to produce a stand alone (i.e. not part of CCDCIEL) application using just his "stacking" code. NOTE Astrotoaster allows real time colour (Color) etc adjustment.
Bottom line would a RPI 3/4 cope with stacking and not hinder other processors ?
Short exposure stacked images examples (especially see HiloDon from Hawaii) stargazerslounge.com/topic/276321-first-...ith-hyperstar-on-c6/
Maybe of use to some - especially Rasp Buster/Stretch - but on an old RPI3 I had slow boots and reboots for REALVNC server connections.
However it seems its not the vnc server but a headless problems - no mouse seems to be the problems reading the thread below. Any how installing HAVEGED cures this problem and now vnc sessions (especially on reboot) and faster (alot). Dont know if it works on other O/S on RPI.
If it helps someone great.
Are you sure the cable isn't snagging on something ?
IMO Its sounds like a cable or power spike/drop off or adapter problem nothing to do with Linux OS - as you say you have been using it fine for several hours and over a year ok.
Here I was doing the normal Platesolving when things started to go a bit wrong and Platesolving (any type - ASTAP,Astrometry local etc) starting failing - some weird errors and even core dumps from segmentation failures.
Anyway after pulling all of the little hair left out I found the problem - on 1 Index Platesolving gave some saying "Invalid Star ID" - trouble is unless you scroll through the whole log you wouldn't necessarily see it as you get the segmentation fault or iotclt fault info. It appears the index had become corrupted ( I did have a lock up once - but reading ! ) so replacing that single index cured the problem.
Still perplexed / worried why reading should corrupt files on a newish SSD .
So if you have a weird set of errors (think I had error 139 and error 256) and /or segmentation fault / core dumps when running platesolving - check the log closely for any "Invalid ID" it might help
Perhaps this might help others !
If you go to the follow and scroll down to "how to make my own etc" you will find a tried and tested ,over a good number of years by many people,the correct details of wiring ,plugs and voltages.
. Personally I would stick to the std TTL voltages ,as described ,even if it says "tolerant" !
FDTI cables are the best for another good reason they have unique serial numbers which allow Linux via Udev to assign ports to devices. CH340 work too and come with 5v/3.3v switch but with the Udev problem.
Prolific and CH340 ,to name a few, do not any unique identification and so there is no simple way , other than position (as far as I am aware) in the USB hub to create a udev rule - but this is messy and prone to "cock ups".
But most would NEVER use a working set up to "try" something out - learn't that a long time ago on any computer system.
At least you had a back up.
Instructions to create KDE Desktop version on RPI4 - Not tried them
Haven't tried it on RPI4 but i used this version which includes KDE on RPI3b+ and my 5ghz Wifi problem disappeared but it wasn't very stable then. It now runs on RPI4 as well as RPI2,3,3B+ if someone cares to try it and there is an image ready to download.