Ask Robert Brown (author) directly on
if no answer here
1. Use use INDISERVER in command line mode only (NO EKOS/Kstars) - so just drives your devices (Astroberry will do this simply via Panels) - and run CCDCIEL/CDC on a remote Windows laptop. The latter will automatically download the files to your Laptop and control all the devices,plus includes Platesolving via a number of ways(you have to set up the Platesolving software - ASTAP,ANSNVR etc). Then use Astrotaoster (uses DSS) on your laptop to create/show real time stacked images.
2. Do the "normal" Kstars/Ekos local set up and monitor via VNC but place your image folder in the Public area - if you are using Astroberry this automatically shares this area via Samba and you will be able to see the files from Windows. Then run Astrotoaster ,on your laptop, and use the inbuilt Rsync function to sync and monitor the image folder on the RPI. Platesolving would be done on the RPI,
You didn't say what your kit was so this is a "general" solution assuming No guiding just a Image camera and Mount. It also assumes you have a Windows device and are not an Apple person.
Live Image stacking ,IMHO, just does not work well on a RPI(any) as it needs resources (CPU etc) that the poor old RPI cannot provide and run everything else.
You could of course just try adding a 2nd "imagine Rpi" RPI4 (1gb maybe) and run the camera on that RPI by itself.
Its just a case of then "chaining" the 2 Indiserver's together if you use Ekos (dont need to do this with CCDCIEL or if you use Firecapture Oacapture stand alone on the "imagine RPI4"). As the comms between the 2 RPI's would be using ethernet(preferably wired) the USB device "hogging" the "Imagine Rpi" will not matter as much.
Indi has the ability to "chain" by default - unless it has been removed since I last used chaining a couple of years ago now.
There is of course a limit to what the RPI4's hardware can do no matter what you do to limit bottle necks! - then its upgrade time to something else more powerful.
Just a thought!
What does the command line command LSUSB (lowercase) produce when all your hardware is connected - doesn't have to be running any software just powered on.
Look thru the "system" logs - filter errors which have anything to do with USB - does anything stand out?
Just to add that many Ard Nano are clones which use CH340G /Prolific and other cheap chips which all have the same problem - They do not have a unique serial number so if you have 2 or more chips of the same type it is impossible (other than position) to write Udev rules for such devices. You can see this if you do a lsusb
. However as Eric has said this is something "not for the faint hearted" and i would suggest you the changes on a copy of your SD card (or take a backup first) and takes a little time to get your head around. Of course after doing the "udev by position" you will ALWAYS have to plug the device into the same port/hub.
Simpler way,if this is the problem, buy an genuine FDTI chiped device that has a unique serial number - for the Ard Nano the code will of course not need to be altered but most likely you will need the Autoreset /cap trick - I did and the problem went totally away
Glad you getting there
As to the failed solve when in object is in full view - I too get this now and again but I also have had this with Platesolve2 and ASPS on Windows - never got the bottom of the problem but put it down to changing "Sky quality" (improved - so too many stars = timeout or deteriatored sky since previous image) .
I have already stated I use CCDCIEL which allows automatic Platesolving backup (use ASTAP first but if it fails it uses Astrometry version to retry platesolvong on that image) so its not a major problem for me and this process works well for me especially on a Sequencer type run.
But without sending images to someone like Han it would be unfair to say what the problem was (me or the software) and impossible for a developer to solve
I guess thats why ASTAP now has the "slow" solve tick box. This is because, IMO , local Astrometry versions(Linux,Windows orothers OS) solve 99% of the time but are generally a lot slower on the same type of hardware. Whereas ASTAP and the like "cut corners" (sorry could think of a better phrase ) to improve speed - the later comment is not a critisim and I accept the fact "faster" this could be less reliable (even says this in the manual and on screen) - "swings and roundabouts"
Clear skies and reliable platesolving
Never used the flats as part of platesolving so I just ignore the "warning" and use it normally.
I would suggest you send some of the images to Han and see what he makes of it - he is the expert as the author.
Once you have the basic settings correct ASATP works 95% of the time and very very fast. Luckily I use CCDCIEL which enables me to automatically switch to another platesolver during the platesolving phase. This I do in live mode and using the excellent Sequencer that CCDCIEL provides - so its simple ,quick ,effective and 99.99% fool proof - subject to sky quality of course. I hardly ever have to change anything except when I change harwdare, which is only to be expected.
In the end,rightly,you go with the process that you feel happiest with and suits you .
like ALL platesolving having the correct parameters help.
If you have trouble start ASTAP as stand alone and load the image.
Click the "stack" menu so the Stack window appears.
Choose Alignment tab is not already selected.
Set the correct FOV height - it should set this automatically after a sucessful solve - if not or its not working use Astrometry.net upload to get the correct value or set Auto (but this takes a long time first time)
Use the Down sampling and Max stars to maximise speed but setting a too small a value will cause Platesolving to fail on occasions. suggest default 500 stars and auto for first run - but it will change depending on the image - as with ALL Platesolving
Tick "calibrate prior solving" - this will help with "noisey" images
Obviously "blind solving" will take longer so for testing set the RA,dec of the object so that platesolving is "near" not "blind" - do this via the RA/Dec on the first Window by double clicking the mouse in either Dec or RA area. And yes I didn't know what the signs were - Come on Hans it should be for all not just experts in Greek
As you can see times vary but it can vbe very fast 2.3 secs to 106+ for blind solving - on my example I used m81 via double click object name for M31 and it rook 106secs on images that were not great.
If all else fails post image to Hans he will help after reading the manual - which of course we all read dont we LOL
ASTAP is the only Platesolver,I know of, to work across the board natively on Windows,Linux and MacOS and doesn't require index's to be loaded per FOV.
But I admit it can be "fussy" - but the latest version can do "slow" plateslving (tick box) for most images that it didm't solve before.
64bit Raspbian beta released too!
Note hardware layout changes - "which doesn't effect anything" - Famous last words - perhaps the USB3/Wifi etc is finally sorted on these boards. Just have to see what the new ones are if any. £24 extra for 4gb isn't that bad !
Cant say I am expecting much improvement until software catches up!
Should also mean 64bit Raspbian is released !