So as part of a student project at the Technical University of Munich I made some changes to the LX200 10Micron driver in order to add the satellite tracking capability included in later versions. I still need to do some debugging and polishing and after that I would like to create a pull request and merge my changes upstream, I'm guessing some time around end of January. A short introduction to the project: we want to use the 10Micron mount together with a Celestron to track satellites and derive light curves from them, eventually we would like to automatically get precession and nutation information based on optical observations of uncontrolled satellites like ENVISAT.
My main concerns are as follows:
Since satellite tracking appears on a later version of the mount firmware (from 2.8. I do not want to break anything by building something version-specific. Are there version checks in INDI that I can copy? I could not find any but I did not look around that much
I made a lot of commits often with silly bugfixes or small increments. Should I clean up the history before creating the request
I worry that the status of the mount has to be broadcast somewhere else in INDI, although I could not find any sort of satellite tracking marks on inditelescope.h is there anything I should consider given that the mount is following an irregular trajectory?
I close with a question, is there any other driver that has a satellite tracking implementation? I looked around a bit but also couldn't find any
Thanks a lot in advance! I like this library SO. MUCH.
I don’t have an answer to your question, but looking forward to this update. I don’t think anyone has touched the driver in a while. Would be nice if it sync’d MBox weather data along with each plate solve to update the refraction data in the mount. Currently I use Mount Wizard or manually plug it in.
1. This is done per driver basis, so please introduce a check for the firmware (if not there) and make the satellite part work that firmware level only. Now, if the firmware version is reasonably old (more than a year ago), then I don't think it's worth the effort since you can simply ask users to upgrade. UNLESS it is not possible to update for some models..etc, then it must be firmware-dependent checks.
2. Do not worry about that, all commits will be squashed on Pull-Requests.
3. I don't think you need to do anything at this moment. Clients would see it as tracking. Maybe you can do custom tracking rates and then these update second by second? Some drivers include custom driver rates.
Really looking forward to this project, great job Perdo!
great to hear. I did some work on 10micron for doing satellite tracking. Still in beta, but already running. It's on python and works directly with 10micron mounts. It is build based on function provided by skyfield (Brandon Rhodes), which bring a lot of needs functions with it.
There are a lot of features around to update select satellites and move them to the mount:
thank you all for your replies! I will most definitely post my updates here.
@knro I will definitely take a look at those issues, I think we also had issues with the tracking after the meridian flip but it might have to do with our mount model not being that great, we have to do some adjustments still
@mworion WOW!!! Last time I took a look at the mount wizard was a looooong time ago, it has grown so much since then! You've done an amazing job there. I will most definitely take a look at it and maybe even contribute, although since I already did quite a bit of development in INDI proper I will probably keep working on the INDI-Ekos combination
yes, yes I know, I said I would create a pull request soon and it only happened now anyhow, the pull request has been created and we have been able to snap some goodies at uni. The camera is not the best for this purposes, but one can roughly recognize the H-shape of the ISS...
I just wanted to give you an update: the software works perfectly! We are just currently struggling with the mount clock, since for accurate TLE-based tracking one needs a time accuracy of within 0.2s of UTC
Attached you find a video of our last acquisition, it's an upper stage:
A (kinda) related question I have, I was trying to add the functionality necessary to synchronize from Ekos with a button that sends the current system time (which should be close to UTC thanks to NTP on a properly configured computer) because the current "update time" of Ekos creates a pop-up which in the best case introduces a 1 second delay (while the user clicks away the pop-up. Is there a more elegant way to keep the mount time updated from Ekos?
Also another problem I had, I built the library from source after changing the 10micron driver (to include the changes I just mentioned) but Ekos did not show any changes, even after I uninstalled indi completely and reinstalled it with
Thank you for your work on the driver! Regarding the changes, perhaps you have some older copy lurking in /usr/local/bin ? check where sudo make install installs stuff to.
For the time sync issue. This is interesting. Usually you set the time once automatically on first connection then the mount internally syncs to this clock and keeps ticking. You want to do this at regular intervals, say every 5 minutes for example?
So I need to write my reply again, the browser froze
So regarding the install location, I checked a million times, I guess I did not reach the level of desperation necessary for my computer to take pity of me I will keep trying
Regarding the time sync. I could not see that the mount is syncing to the computer at connection time, maybe I am missing something. I sync manually with "Site Management > UTC > Time", but between the time I click on Time and the time I click "OK" enough time will pass that the tracking of fast moving objects (for instance LEO satellites) is not so accurate anymore. So I tried implementing a manual sync button that sends the time directly on click. This only happens once, naturally.
A sync every 5min would even be more useful, a toggle that activates that would be perfect. The mount clock tends to drift over time so of course a regular update would be the optimal solution. The drift is very small though, this only makes sense for systems that run continuously, and that is not the case for us, but I a up for looking into it, as it is the more elegant solution. I would have to look into how concurrency in C++ is handled in Indi, maybe you can give me some guidance on this? Also, is this a feature that you deem relevant for other projects, i.e. should I build it at a different abstraction layer? Honestly I would prefer implementing it for the 10micron first.
Mount location/time are set if is specified in KStars settings ---> INDI and check under automatic updates. This is done the first time connection is established with the mount and it should show in the logs. It would be possible to add a configurable time sync update in Ekos, but perhaps after KStars 3.5.0 is released.
I checked that box and it seemed to have no effect (I just checked the logs). But now that I know what to expect, I will do some more digging to see if the problem is caused by the changes I just made, thanks. In the meantime I will wait for the 3.5.0 update. Looking forward!