Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.



Advanced Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

11 Good

1 Follower

About Daggerstab

  • Rank

Contact Methods

  • Website URL

Profile Information

  • Location
  1. Combination of different projection settings and FOV values? (Stellarium by default uses stereographic projection, most camera lenses produce rectilinear pictures.) Another possibility is time zone and DST differences - most amateur-level astronomy software doesn't handle them well.
  2. The "original" interface is still in use. I haven't integrated my code yet. For the last several years, I haven't noticed anyone coming out of the woodwork to offer new drivers or an extension of the basic protocol. What I've noticed is a lot of users asking "why don't you support telescope X" or "why it can only slew to objects" or "why do I need to use StellariumScope". Do you really think that starting a separate driver executable from a command-line console is user-friendly? The reply was in relation to my post on the 13th Feb in the thread http://sourceforge.n...hread/f85ed4a2/ At first I thought that Bogdan was a particular plug-in I needed to get, only after reading a bit more via Google I found out it was a person. Innapropriate tense and preposition - "works for" should have been "is working on". I also find it hard to communicate with Alex sometimes, as my English is much better than my Russian. And yes, I am Bogdan Marinov.
  3. It looks that I'm late to the party... One thing that everybody should have in mind is the distinction between INDI - the XML-like communication protocol - and indilib/libindi, the INDI library/framework implementation for Linux that comes with a collection of default drivers (and a few "external" ones). INDI-the-protocol has no preference on what it's used, be it TCP/IP, pipes/fifos or something else, and it's not tied to a particular implementation, as the Java thing shows. I'm working on a Qt-based INDI client for Stellarium, and it's been somewhat unpleasant, partially because INDI is not pure XML and Qt's XML-handling mechanisms have to be coaxed to deal with it. It's also possible that I just suck at programming. Oh, and if you've noticed the remark on the indilib.org website about a Windows port in its very early stages, that was done by me. And given the time I can spare for it, it won't progress beyond "very early stages" soon.
  4. When was that and what did he said exactly? No ASCOM code has been released with 0.12.0. I know because it's still collecting dust in my branch... And I'm really sorry about the state of the Wiki article. When I have time for Stellarium, it's spent writing code or answering users (like here), not documentation. Status update on the ASCOM code: I have some basic functionality, but my involvement with Stellarium is hampered by lack of free time, not-powerful-enough computer and really slow Internet. (I would upload a test build with the new telescope control plug-in, but it would take me an hour to upload a 50 MB installer, and connection instability pretty much guarantees that it won't finish it in that time.) It's slew/stop/sync at the moment, as far as I can remember. The intention was at least to make StellariumScope unnecessary. First: Stellarium being a FOSS project driven by volunteers, "they" are not a monolith. People come and go, and they have different fields of expertise or foci of interest, and there are people who contribute code based on purposes they want to use Stellarium for. The original author was into 3D graphics and wanted to make a realistic representation of the sky. Telescope control was added later by another person. Then I came and made a GUI for the telescope control. And the time I could afford to spend on Stellarium has varied vastly over the last few years. As for ASCOM itself, the problem is that it is based on a Microsoft technology - COM - that is available only on Windows. Stellarium is multi-platform and the framework on which it's based (Qt + MinGW on Windows) does not use COM. There's a way to interface COM objects like ASCOM drivers with Qt, but it's unpleasant and time-consuming. For me, it's also really hard to test - I don't have a telescope and using simulators is a bit taxing for my computer (netbook + Windows 7 + Stellarium = more choppy than a cheesy martial arts movie). Another part of the explanation for the delay is that the code infrastructure was originally made only for one telescope control protocol - Stellarium's - and the target is to support three - Stellarium's, ASCOM and INDI. This requires re-writing some of it, and I've been stopped in mid-rewrite several times now. As a result, the code is a mess at the moment.
  5. AFAIK, It's the rotation angle of Jupiter's texture, relative to whatever the rendering engine considers to be the prime meridian.
  6. Is this with or without the light travel time correction? Did you check how it looks like in the test version? As far as I can remember, Alex did add some kind of empirical formula extrapolating the position of the GRS.
  7. Two things to try: - try to find out what exactly is your graphics chip, even if it's integrated, and try to download the latest possible drivers for it from the manufacturer's website. If it's an old model, they are probably in the legacy drivers section. - use Stellarium in window mode - switching between window and full-screen is done by pressing F11 or clicking the appropriate button in Stellarium's bottom toolbar.
  8. KStars supports the INDI protocol/library, which in turn has a gPhoto driver which probably is compatible with your camera: http://indilib.org/i...hp?title=GPhoto In theory, KStars supports device control scripting, though I've never tried it: http://edu.kde.org/kstars/indi.php Brief introduction to the Script Builder: http://docs.kde.org/...iptbuilder.html I know for sure that KStars also has a more immediate "capture image sequence" window: http://docs.kde.org/...di-capture.html KStars is a part of the KDE application suite, but on Ubunru and similar distros it can be installed without installing (most) of the rest of KDE.
  9. Also, the contrast with the message right after it is amusing:
  10. Actually, the first sentence is wrong - Stellarium is free/open source software, not "public domain". This leech understands the GNU GPL badly, but just enough to stay at the right side of the law.
  11. Try starting Stellarium from the "Stellarium (no OpenGL2)" shortcut in the Start menu.
  12. Any update on this? ("This" being the article in Full Circle Magazine. )
  13. Looks like an artefact in one of the higher-magnitude catalogues. There are several such errors and similar ones, such as "stars" forming the halos and diffraction spikes of brighter stars, etc.
  14. Note that to have the ocular button or the Ctrl/Cmd+O shortcut, you need to have the Oculars plug-in enabled. The plug-in's configuration window also allows you to enter the details telescopes, oculars, etc., and to enable the nice buttons panel for switching between oculars.
  15. This is a really cool/original application of Stellarium's telescope control code. Nice hack! KStars recently introduced a native star-hopping plug-in. There was a suggestion to port it to Stellarium, but nobody seems to have time even for higher priority tasks.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.