I'd advise you to let Ekos store the images as close to the camera as possible, meaning on the RPi hard disk or a USB drive attached to it. Transferring large files over a network connection (and in this context 32 Mb is pretty large) introduces a latency since Ekos will wait until the image has been stored. Is there a specific reason why you want them transferred automatically? If it is for inspection, for instance, then I'd advise to install some image viewer on the RPi and inspect them there via VNC. If it is for processing then you might as well wait until all images have been taken but that's up to you of course.
That was on a brand new VM without KStars and/or INDI installed from the stable PPA first. When I remove the nightly repo, add the stable repo, install KStars and INDI, add the nightly repo and update, I get this
47 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
indi-aok indi-apogee indi-armadillo-platypus indi-asi indi-astromechfoc indi-atik indi-avalon indi-bin indi-dreamfocuser indi-dsi indi-duino indi-eqmod
indi-ffmv indi-fishcamp indi-gphoto indi-gpsnmea indi-maxdomeii indi-mgen indi-mi indi-nexdome indi-nexstarevo indi-qhy indi-sbig indi-starbook indi-sx
indi-talon6 indi-toupbase kstars-bleeding kstars-bleeding-data kstars-bleeding-dbg libaltaircam libapogee3 libasi libatik libfli2 libgphoto2-6
libgphoto2-l10n libgphoto2-port12 libindi-data libindi1 libnncam libqhy libqsi7 libsbig libstarshootg libtoupcam
46 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
47 upgradable and 46 upgraded. Note that indi-full is missing. When I then have a look with dselect (an archaic package manager from Debian which works great in these kinds of situations) I see that indi-full is upgradable but there is a package missing:
indi-full depends on indi-aagcloudwatcher-ng
indi-aagcloudwatcher-ng does not appear to be available
Of course I can do a forceful installation of indi-full but at least someone (I expect Jasem) should try and find out why the indi-aagcloudwatcher-ng package appears not to be available on Ubuntu MATE 19.10.
Adding to that: even when Ekos and KStars are on the same desktop, the Ekos-related pop up windows appear in the KStars window so you have to minimize Ekos to be able to click them.
Congrats on your test run. I can’t help but notice that your mean guiding deviations in both RA and Dec are about 1.2”. Do you know how much they were without the box installed?
Since you use the camera for guiding only, you may want to try 8 bit images instead of 16 bit if you run into issues again.
I just created a new VM using Ubuntu MATE 19.10 and when I try to INSTALL KSTARS NIGHTLY IN IT I GET
The following packages have unmet dependencies:
indi-full : Depends: indi-qsi but it is not installable
Depends: indi-aagcloudwatcher but it is not installable
Depends: indi-aagcloudwatcher-ng but it is not installable
Depends: indi-gpsd but it is not installable
Depends: indi-fli but it is not installable
Depends: indi-shelyak but it is not installable
Depends: indi-nightscape but it is not installable
E: Unable to correct problems, you have held broken packages.
Can someone please have a look at this and fix the build? Many thanks in advance.
Aaah wait, you have an ASI120MM mini! That is a completely different story because this one does work with modern Linux kernels but, again to my best of knowledge, only on USB2 ports. Please next time be VERY specific as to which hardware you have EXACTLY
Sorry to hear that mactech. To be clear: I am not a Windows user and have not been for 20 years. From what I have read here and there indeed Windows 10 doesn't support it anymore as well. I may very well be wrong.
jaq1967 I understand your frustration but unfortunately you are not the only person having problems with RPi4, even the ones who don't use Stellarmate. It seems that the RPi4 hardware still is not fully supported by Linux, or at least that's my impression. Do you have a laptop or so on which you can install Ubuntu MATE 19.10? If yes, I'd advise you to give that a try at least to see the true power or Ekos and INDI because I have been using it for 2 years now (admittedly not on an RPi4 or even 3 for that matter) and it does work.
mactech, which version of ASI120MM do you have? The ASI120MM (USB2) version or the ASI120MM-S (USB3) version? The USB2 version doesn't work on modern Linux kernels (from some kernel version 4.0.x on) so it is possible that with an older Stellarmate version an older kernel (possible 3.8.x) was used and with that the USB2 version would work. Please search this forum for ASI120MM and also for ASI120MC (the same camera but a color sensor instead of mono) and you will see what I mean. There is firmware that you can upload to the camera which for some people fixes the camera but for others (like me) not. I got rid of my ASI120MC (USB2) camera and bought an ASI120MC-S (USB3) camera and then another because they work very, very well on Linux.
Please note that the situation is different for Windows since it didn't enforce the USB2 standard (which is what was the faulty part of the USB2 camera) as much as Linux. But even Windows 10 now doesn't support the camera anymore.
So, once again, please search this forum. You'll understand what I mean.
Yes you did indeed. Sorry, apparently it was too cryptic for me.
I agree that it would be nice to synchronize the home/park setting and another complication may be that not all mounts support this. I, for instance, use my SW HEQ5 without HC and I am not sure if the home position is stored on the mount or the HC. I am not saying that this therefore should not be implemented but rather that this needs to be done with care so not to break the current implementation in other telescope drivers.
AFAIK using the hand controller to move the mount should work. Park/Home position is a different thing. However, I do not own a Celestron mount so please simply try it out and see for yourself.
Adding to what Chris wrote re manual mode: make sure that the slew speed is set correctly for your mount if you want to use the automatic mode. I have a SkyWatcher HEQ5-Pro and need to set it to 800x for it to work properly. The default is 64x which works but it takes forever (or so it seems) to rotate 30 degrees.
As for having KStars and Ekos in different desktops: did you do that yourself? I have never tried that but I did try to use Ekos "in a separate window" mode and also noticed that all modal popups showed up in the KStars window. That's when I stopped using Ekos in a separate window and simply got used to opening and closing it when I need it. Perhaps opening a new topic for this if you want this fixed would be a good idea.
As for the big ERR numbers: Chris already addressed this. Ekos expects the mount to be pointed at the north pole with the RA equal to the current sidereal time (i.e. the RA culminating) and close to the pole RA is a very poor measure (to quote Chris because it is too early for me to think of another way to phrase this). The ERR boxes display the differences in RA and DEC expressed in arc seconds which very quickly become very large, especially if plate solving shows that the mount is pointed to a too low altitude (essentially giving an RA +/- 12h wrt the current sidereal time).
When using Ekos in slew mode, swithc from the Polar Alignment tab to the Solutions Result tab (to see the alignment process working) and make sure to tick the "Slew to Target" checkbox. That way, Ekos will send a correction to the mount which then should slew to the target. It will then perform another plate solve to measure the new alignment error and will send corrections again. In general it should take a few iterations to reach the target, depending on the "Accuracy" (expressed in arc sec) among other things. Be patient with this the first time you try in a night and consecutive slews should go increasingly quicker.
Clear skies, Wouter