Yes, sorry if I am not being too clear. I only have experience directly using the Stellar Mate OS. I also believe the initial question is specific to kstars/ekos for MacOs. For a brief period I running individual pieces of INDI, in a ARM version of fedora, but I moved to Stellar Mate OS to help support Jasems product to use on my own RPi, as well as have support since I am more of a linux admin than I am a developer, and I am unfamiliar with how all of the pieces come together to form Ekos, so I decided to use the packaged OS. I ran and lsb_release -a and noticed that the output was Raspbian 16.04 LTS. Then I checked Jasems PPA, which feeds updates to Stellar Mate here :
. On the last page it lists LibRaw : 0.19.6~202002010816~ubuntu19.04.1 0.19.6~202002010816~ubuntu19.10.1 0.19.6~202002010816~ubuntu20.04.1 and 0.19.6~202002010817~ubuntu18.04.1. So I downloaded the latest Stellar Mate OS 1.5.1 which appears to be using the 19.10 base, and sure enough dpkg shows libraw 0.19.6 and my EOS R is working.
So, this may be helpful to anyone else having the same issue. I was browsing the Repos and noticed that the newest LibRaw .0.19.6 with CR3 support are in the repos for all versions of the ubuntu/raspbian base, except for 16.04. I Have been using Stellar Mate v 1.3.0 which has a 16.04 base for several years. I found another SD card and put 1.5.1 on it and started setting it up and using it last night. CR3 and the EOS R work fine in this release. I ran into some other issues which I opened a ticket on, but I don't think they are directly related to CR3 so I wont include them in this thread. I think that for most people using 1.5.0 or 1.5.1 (using 19.04 base) with an EOS R/RA/RP will probably work fine. Check with the command lsb_release -a if you are on 16.04 this is probably the reason for now CR3 support, and I would suggest upgrading to a newer version of Stellar Mate OS.
Side Note, I realize looking back that the original question was for a Macbook Pro. I am not sure what needs to be done here to get CR3 support, if you are directly connecting your equipment to a macbook pro. I use my macbook pro to remotley connect to a stellar mate OS device, and since upgrading it to 1.5.1 I haven't had any issues using my MBP for all features. However these days I prefer to remote into the Stellar Mate OS device and setup everything on the device itself, that way I can disconnect and it will continue to run until finished, so I don't use kstars on my MBP so much anymore. I wish I could be of more help in that area.
I found this thread over the same subject.
, I hope this is not more trouble for you than it is worth to get it into the repos, and functioning with the OS to the masses. Perhaps I should attempt a compile and rename to librawcr3 on my own as to not put anyone elses builds at risk? I am sorry for not finding this thread in the beginning, my search skills aren't very good.
It looks like CR3 support is in libraw's latest snapshot that was released in October. The current stable release looks like it is 0.19.5 however the repos contain 0.17. Is there a best practice for upgrading just the libraw piece in conjunction with the rest of the stellarmate packages? I am comfortable downloading the snapshot and compiling it from source, however im not as familiar with Unbuntu as I am with other RHEL and RHEL clones. Is there a best way to verify that the system is using the snapshot, perhaps a "which libraw" command or a way to add the snapshot to a different path, and fallback by removing that path from $PATH, in order to avoid a complete restore from backup? I am curious to see if it works with CR3. This is currently my main camera, I would like to use it to compare to my previous 1300D aps-c photos.
There is a small work around however it looks. If I use my guide scope from polar alignment and object centering, then switch it over to guiding. I can use the EOS R by setting the preview to no, and the setting 1 to 1 photo sequences. Example setting 30 different individual single 3 minute exposures. This will still save each exposure to the cameras SD card, which can be processed. It is a pain not having a preview and test shots, especially considering my guid scope and cam are considerably wider FOV than the make scope, but it does work until libraw can be updated.
I am having the same issue with the regular EOS R, any advice would be a great help.
Hi Jasem, sorry this question was answered by you in another thread:
I made a newb mistake of not knowing the first posts I made on this forum would have to be approved by a moderator, and I double posted. Sorry! But thanks for all of your help.
I am experiencing a few odd issues in regards to my iOptron SmartEQ Pro+
First, Id like to address a newb question. Can anyone give me some advice on how to correctly set the time in kstars? I setup my time site with the wizard, but it did not apply DST. I am using stellarmate OS, and the time on the system is correct. I've found myself manually setting the time, before connecting or starting INDI to prevent kstars from sending the wrong time to the mount. When I got into the altitude and time settings, everything appears correclty, except the DST dropdown is set to --, when I try to change it to Y, it tells me the time site is ready only and that I must create a new one to modify this setting. This happens both remotely from MacOS kstars/ekos, and locally on the RPi. Is there a standard to setting this time to DST?
Secondly, after some troubleshooting from observing my mount slew all of the commands upside down and backwards, I looked to ensure that DST was set to N on my hand controller, it was and the correct time was in kstars/ekos/INDI control, before starting INDI. So I checked the site settings in the INDI iEQ mount control panel. Inside this control panel it displays the correct latitude, but the longitude is 272 degrees. Is there some sort of 360 degree translation happening here? If I change it manually from 272:HH:MM to -87:HH:MM it works as normal. Ive found that no matter how many times I set this, and save the config that I have to enter this manually every time. All of the other settings are saved. Is there something that I am missing here? Sorry if these are newb questions but I coould not find any instances exactly like mine from searching the forum or the FAQ.
Thank you for any insight into these issues.
I am having a few issues running Ekos on my mac. Specifically just 2 parts.
1. I messed up and reset the solver options to defaults. I browsed through the kstars.app package and found the paths to the astrometry, and put the paths back into the fields, however now the online solver works, but the offline solver fails immediately. The fields are as follows, the only reason that I think this could be the problem is that the offline sovler worked fine until I accidentally pressed the "Restore Defaults" Button, so nothing else has changed. I searched for more advanced logging other than "solver failed" I have most of the index files for my FOV downloaded locally.
I have attached a picture of the solver options for review, and here is a paste of the script:
# This is a config file for the Astrometry.net 'astrometry-engine'
# program - it contains information about where indices are stored,
# and "site policy" items.
# Check the indices in parallel?
# -if the indices you are using take less than 2 GB of space, and you have at least
# as much physical memory as indices, then you want this enabled.
# -if you are using a 64-bit machine and you have enough physical memory to contain
# the indices you are using, then you want this enabled.
# -otherwise, leave it commented-out.
# If no scale estimate is given, use these limits on field width.
# minwidth 0.1
# maxwidth 180
# If no depths are given, use these:
#depths 10 20 30 40 50 60 70 80 90 100
# Maximum CPU time to spend on a field, in seconds:
# default is 600 (ten minutes), which is probably way overkill.
# In which directories should we search for indices?
# Load any indices found in the directories listed above.
## Or... explicitly list the indices to load.
2. When I run Ekos from the RPi the FOV is reported as 238' x 159'
but on the Mac the FOV is reported as 192' x 128' with the same camera. This seems a little odd has anyone else noticed any similar behavior. It might not make much of a difference, as long as the right index files are available, but it did catch my eye and seems odd as it is the same camera (Canon Rebel T6 (1300D)). I am trying to get the RPi profiles to be identical to the Mac profiles as I will not always have my Mac with me in the field, so using my tablet to vnc, or kstars lite is needed.
If anyone has any insight it will be greatly appreciated.
I have had a similar issue, it stemmed from the polar alignment assistant. If I run a refresh of 1.000 second exposures, or another increment that is a default on the camera's dial, while adjusting my polar alignment, I noticed that, that value (1 Second, 2 seconds etc.) if it is a factory default timer increment on the camera's wheel it will stay that way after completing the polar and alignment. Then I have to manually scroll the camera's dial to BULB, as it will be stuck on 1 sec, or 2 etc. Now if I do a refresh with an exposure of say 6 seconds during the polar alignment, the camera will stay in BULB as 6 seconds is not an exposure option on my Canon T6 (1300D). It was frustrating at first, but after I figured out the correlations, I just remind myself to set the refresh exposure to 6 seconds, or remind myself to check the exposure timer setting on the camera, before setting up a capture sequence. Sorry if that doesn't seem too clear but its the best way I can describe it for now.
Thank you this is good to know however I am still having trouble getting it to accept the DST. Please see the attached photo, Is there a way to get the dst change to stick in kstars?
I have a few questions regarding kstars and the ekos iEQ driver.
First of all I have a rather noob question about the time settings in kstars. I setup my time site with the setup wizard, and noticed that it did not apply DST. I looked into the altitude and time settings, and noticed that my lat/long are correct, but the DST was set to --, and when I try to set it to yes, it gives me an error that the time site is read only and I need to create a new one. However the error seems to persist no matter how many I setup. Is there a correct operation procedure for getting the DST to stick? Once I manually correct the time, ekos then relays the correct information to my mount.
Second, when I launch ekos, and check the site settings on the INDI control panel for the iEQ mount, it shows my longitude as 272 degrees, my standard longitude is -87 degrees. Is that normal? Is it doing some sort 360 degree translation? I noticed that even with the correct time set, that while the longitude is set to 272 everything happens upside down, and backwards. After setting it manually in INDI control panel to -87 degrees HH:MM, it performs as normal. I've found myself having to do this every time despite saving the configuration. Is there another operating procedure to correct this that I need to be aware of in order to help keep both the time and longitude settings?
Thanks for any help, and sorry if these questions have been asked, I did a search and could not find anything that was exactly similar to what I am experiencing, outside of the FAQ on make sure your time site is correct.