Thank you very much for investigating. To answer your question, I believe that the upload of JPG images to astrometry.net instead of FITS files for the online solver predated my work on StellarSolver. That code was originally part of KStars until it was moved into StellarSolver to simplify and modularize KStars. I think that the reasoning was that many users image in the field or in situations where their bandwidth is not very large and so uploading a huge FITS file would take too long and a JPG would upload much faster. Since I made StellarSolver as you know, many more options exist for solving and I personally would not upload any images to astrometry.net. If I was going to use the online solver and I was concerned about bandwidth, I would probably extract the stars using internal SEP and then upload the star locations. That way you are just uploading a text file. That option did not exist in KStars before StellarSolver. Now that there are more options, we can certainly stop uploading JPEG images if it causes inaccuracies with the online solver.
Read More...
Hey guys, sorry I have been a bit busy the last few months with a master's degree. I appreciate the work you put in to diagnose the issue and I accepted the pull request. I am sorry I did not get into this discussion sooner.
github.com/rlancaste/stellarsolver/pull/127
Please let me know if this doesn't solve it or if we need to do some more.
Read More...
The other solution with the conf file is much more elegant since it is hot pluggable with monitors.
Read More...
I have tried video dummy as a solution on a number of different systems. It does work well to allow you to get a good resolution on your VNC view. Unfortunately when you bring in a real monitor or hdmi tv, generally it won’t work properly if you are using video dummy.
Read More...
Yes that is one annoying thing. The various distributions typically want a monitor to be attached to set the resolution, but of course we don’t want one to be attached. We want it to be headless and access it via VNC. Often they will have a default resolution but it is often too small of a resolution to be useful. I think the more recent Ubuntu variants have finally switched from 640x480 to 1024 × 768 which is better but it would be nice to be able to choose. We also want to be able to plug in an hdmi display in an emergency but a bunch of distributions will disable it if no monitor is detected which then leaves you no way to connect if VNC fails. There are ways to get around these issues including the one I put in that you are discussing, but they are not standardized across SBCs nor are they guaranteed to work in the future.
The annoying thing is that these are pretty important functions or settings for a computer you plan to make headless and still access via VNC. It would be nice if there were a standard way to set these parameters that will always work.
Read More...
No, I don't think that is obvious at all. I do remember that is true of a number of the config files in Linux, and as I recall, in some of my scripts I have made those files if they don't exist, but no, to a beginner, I think this is very useful info. Also to those of us who have been tinkering for a bit, it is a good reminder too.
Read More...
That is certainly a good solution especially if you don’t need that driver. I think we should bring it up as an issue for the person who wrote that driver though
Read More...
Thanks Andrew and Jean-Luc for the updates
Andrew were you able to resolve it? Perhaps for 64 bit systems, the INDI Rpicam driver's cmakelists needs to be revised so that it installs differently. Apparently, according to this post, it can stream with a different input from the raspberry pi camera.
github.com/jacksonliam/mjpg-streamer/issues/296
Thoughts?
Read More...
Just to clarify, what specific OS are you building it on and which script are you using? It sounds like you are trying to build with an object file designed for a different architecture or version of GCC. I am wondering if the wrong file was built by a different GCC on your own system, whether it was copied from a binary file in the INDI or INDI 3rd Party repositories, or if something else is going on.
Read More...
I assume you were using the CCD Simulator to simulate position information? If so, I would do the "goto" command on the simulator to fake the position and then move the scope manually. It is important that whatever system is being used for the position information is actually accurate to where the scope is pointing to the use the position option. If you uncheck the position then this won't matter, but it will be much harder for the solver to solve. It will take longer, it will use more power, and it will be more likely to fail in the solve.
If you are regularly getting crashes when you are trying to solve, I would suspect that you have an issue with your option to "load all indexes into memory." That is an option in the profile. You might edit whatever profile you are choosing to use and uncheck that box then save the solver profile. Some people are running KStars on a system that misreports the amount of memory it has available. That would be by main guess. So if you are getting crashes while using the internal solver, try unchecking that box.
Read More...