Hy Murveit replied to the topic 'Headless KStars' in the forum. 17 hours 16 minutes ago

FWIW re black screens, I do get them from time to time (i.e. just now). However, I've found a workaround which is to quit the NoMachine client on my macbook, restart the mac's NoMachine program, and reconnect to my Raspberry Pi. (I don't do anything to my Raspberry Pi.)  It always has returned to normal after I reconnect.

Read More...

Scott--thanks for testing the terrain feature. I guess, on the bright side, since you had an artificial horizon already there, it was easier to set your azimuth correction. I have set a keyboard shortcut to turning that artificial horizon on/off.

The terrain downsampling is mandatory if you're using a slower CPU, like an Raspberry Pi, which is why I defaulted it to 4, but I guess if you're using a fast MacBook, it could work with less. The real issue is that the KStars display code doesn't use the GPU. That apparently is a big project, and not something I'm familiar with.

I have also reworked the artificial horizon feature to get it ready for scheduler integration. The nice thing is now you can now edit your artificial horizon by clicking on the skymap while viewing your terrain image. E.g. see invent.kde.org/education/kstars/-/merge_requests/263   That work should also be in the release you're testing. I even have some artificial horizon / scheduler integration working in my private code. However, releasing the scheduler integration is on hold until the scheduler folks and I add more testing to the scheduler to make sure nothing breaks when new features are added. I'd like to add it in the next release, but want to make sure I work with them to make sure nothing regresses.

Hy

Read More...

I see. Interesting idea--3.3.4 I guess. 

To tell you the truth, I almost never change my terrain background. It's like my telescope's focal length, or which camera I'm using. Set it once and it stays. I guess that's because I view the main benefit of the feature in showing one's own custom background, as opposed to those Mars ones. (Of course, I did change it all the time when I was developing the feature.) However, if I moved my telescope around to the same standard locations, or if I had multiple telescopes, then being able to change that would make a lot of sense--where someone used those spots enough to go through the bother of making custom panoramas for them. Do you think that applies to many folks?

Also, FYI, the ability to turn the feature on/off is in the View menu. There's a "Show Terrain / Stop Showing Terrain" View menu item that I actually bound to a keyboard shortcut (control-shift-T).

Have you made your own custom background? Definitely a game-changer for me.

Hy
 

Read More...

Thanks for taking a look, Rob.

A couple comments:
Re preloaded backgrounds. We did provide 2 sample backgrounds. You can get them from the "Download Extra Data" portion of the "Startup Wizard". See the two Mars backgrounds (Curiosity & Perseverance panoramas) below. People could contribute more downloadable backgrounds through that same mechanism, though I believe the most valuable backgrounds are the personalized ones--the ones of your own imaging spot.

 



Re "select through different backgrounds" like HIPs: I agree that the UI could be better, e.g. showing a preview, but you can select different backgrounds by choosing them from the file picker in the terrain settings page. The key is to make sure you store all your backgrounds in the default terrain directory (on Linux: ~/.local/share/kstars/terrain) For instance, in the screenshot below:

 

Hy

Read More...

Hy Murveit replied to the topic 'Plate solving and WCS?' in the forum. yesterday

Magnus,

I've recently run across this too, in looking at polar alignment issues. I believe (but am not positive) that CD1_1, CD1_1, CD1_1 & CD1_1 are the elements of a 2-D matrix which defines the angle of rotation and pixel scale of the image. They are the "modern" way of doing this (i.e. as of a long time ago) but we seem to use the previous setup, where we use older versions of the keywords (that should still be respected).
It seems that we use CDELT1, CDELT2, CROTA1, CROTA2.

If you research the proper values of CD* given CDELT1,2 CROTA1,2, then I'd be happy to try and submit a merge request adding those keywords.
You might start with www.atnf.csiro.au/people/mcalabre/WCS/ccs.pdf

Hy

Read More...

Hy Murveit replied to the topic 'Save PEC from GPG to the mount' in the forum. 3 days ago

Well, as I mentioned, I asked Edgar and he said it's possible but not straight-forward.
FYI, here's a technical paper explaining what he did:
ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7105398

Best,
Hy

Read More...

Hy Murveit replied to the topic 'Save PEC from GPG to the mount' in the forum. 3 days ago

Rene,

You can save the overall period, details here:
indilib.org/forum/mounts/8645-how-does-p...uiding.html?start=12

Unfortunately, you can't save the GPG model at this point:
indilib.org/forum/mounts/8645-how-does-p...a-guiding.html#66295

I agree it would be great, but apparently it's not a straight-forward task. 

Do you have a background in signal processing? 
Hy
 

Read More...

Hy Murveit replied to the topic 'Mount won't change pier side' in the forum. 6 days ago

Matt,

This is usually an issue related to wrong date/time/timezone or longitude/latitude in the mount or ekos. You should triple check those settings.

Sometimes also could be your mount confused about how its set up, fixed like this:
stellarmate.com/support/faq/mounts.html?view=faq&faqid=33

Hy

Read More...

@legnol: Here's the way things work, as I understand them:

The internal guider in Ekos, in order to be able to correct guiding errors, needs to know the effects that DEC pulses it sends to the mount will have on the DEC motor. It gets this information when calibrating. That is, it pulses the DEC motor, and sees which direction and how far a given guide star moves.  When the calibration is saved, whatever was measured is stored and reused later. However, some mounts are tricky and change the direction a dec pulse moves the dec motor, depending on the side of the mount. The internal guider needs to know if the mount is being tricky in this way. That is the function of the checkbox labeled "Reverse DEC on pier-side change when reusing calibration."  If the box is checked, the internal guider negates the pulse it thinks it should send, if it is on the opposite side of the pier from where it was calibrated.

The proper setting for that checkbox depends on your mount. You can find out the correct value experimentally:  Calibrate in a nice spot (e.g. a bit west of the meridian near the equator), guide for a while making sure you have some DEC corrections, (it should work), slew to somewhere else on the west side, (should still work). Now slew to somewhere on the east side. If it still works, great, you guessed the right value for that checkbox. If not, repeat the experiment, but this time use the other value for the checkbox. Hopefully it will work this time.

There is a very similar checkbox in PHD2, for the same reason. It is explained in the PHD2 doc here:  openphdguiding.org/man-dev/Advanced_settings.htm Search for 'Reverse Dec output after meridian flip'.

Hy
 

Read More...

Jean-Claude,

I envy your dome! I have no experience with a dome, but it seems to me that dome and mount could probably share a line, since you probably aren't slewing etc while the mount is closed--that is, their timelines most likely don't overlap. Would you agree? What signals would you like to see on a dome timeline?

If you could, share with me a log that has debug logging with mount and dome, that represents a typical dome-based session you'd like to see. It would be fine (even better than fine) to make it artificially short. E.g. startup, open dome, do whatever to slew somewhere and take a few shots, then do whatever that winds up parking and closing the dome. If you do this, please send me a side note with approximately what happened (e.g. opened the dome at 21:00, started up the mount at 21:03, ....).

Hy

Read More...

Hy Murveit replied to the topic 'Scheduler Start/Stop Times' in the forum. 1 week ago

Mark,

We think alike! I have been working on something that basically addresses your request. It is composed of two parts. 

  • Being able to more easily specify the parts of your view which are obstructed
  • Making the scheduler aware of those obstructions.
The first part is complete and available in the nightlies. It itself is composed of two components. (1) the Terrain backgrounds ( indilib.org/forum/general/9035-new-featu...ckgrounds.html#68500 ) which allows you to view your obstructions on the skymap. (2) The ability to outline the obstruction in a way that the scheduler could take advantage of. See this merge request  invent.kde.org/education/kstars/-/merge_requests/263  which has already been merged into the nightly codebase.

The next part, then, would be making the scheduler aware of these constraints. I have a little code in my personal space that I've been experimenting with that does this, at least in a limited fashion so far (here's a draft merge request, not ready for submission, containing the changes for that: invent.kde.org/education/kstars/-/merge_requests/271). I've been imaging with it the past week and it seems to work and is an improvement to my workflow. 

However, the scheduler is a complex piece of code that touches all modules, has complex timing interactions with those modules, and has a history of hard-to-foresee side-effects. Therefore, the folks managing it, Eric, Wolfgang, and Jasem rightfully feel that any new scheduler features need to both be carefully vetted and tested, and also need to add to the overall automated testing of the scheduler.  My plan is to try and do this for this change in the next month or two, and then propose that these changes be merged into the general release.

If you are the type that compiles your own code, and are willing to compile and run new software, I can share my changes to you, and we can perhaps iterate on this together. But it is not ready for general testing by folks who do compile their own code.

Hy
 

Read More...

Hy Murveit replied to the topic 'New Internal Guider Features' in the forum. 2 weeks ago

Sorry I haven't cleaned this up yet, and thanks for your question. My intention is to make this more obvious.

GPG, when enabled, completely controls the response to RA error (but not the DEC error). So, RA Proportional Gain, RA Integral Gain and RA Minimum Pulse from that Control Tab are ignored when GPG is used (the DEC values are used, as GPG is not involved in DEC guiding). It turns out the RA Maximum pulse is used for RA and DEC. Maximum pulse is sort of a safeguard that wasn't implemented in the Klenske's GPG code , and so I kept it in place.

The GPG parameters themselves are a bit tricky. I did not modify them from their original form, and you can see how they're used in the code we got from Max Planck Institute / Edgar Klenske:
invent.kde.org/education/kstars/-/blob/m...cess_guider.cpp#L344

Here's a summary of the gory detail from that link:

Basically it blends the control error:
    line 344:    

control_signal_ = parameters.control_gain_ * input;
where "input" is the arcsecond guiding error in RA, and control_gain_ is that parameter in the GPG RA Guider Menu you showed
and combines it with a predicted error it's learned from its history
  lines 363-364:
prediction_ = PredictGearError(prediction_point + time_step);
control_signal_ += parameters.prediction_gain_ * prediction_; // add the prediction

and then backs off a bit more if it hasn't had enough time to be confident in its predictionslines 368-374:
if (get_last_point().timestamp < parameters.min_periods_for_inference_ * period_length)
{
double percentage = get_last_point().timestamp / (parameters.min_periods_for_inference_ * period_length);
percentage = std::min(percentage, 1.0); // limit to 100 percent GP
hyst_percentage = 1.0 - percentage;
control_signal_ = percentage * control_signal_ + (1.0 - percentage) * hysteresis_control;
}

Read More...

Hy Murveit replied to the topic 'New Internal Guider Features' in the forum. 2 weeks ago

Sorry I haven't cleaned this up yet, and thanks for your question. My intention is to make this more obvious.

GPG, when enabled, completely controls the response to RA error (but not the DEC error). So, RA Proportional Gain, RA Integral Gain and RA Minimum Pulse from that Control Tab are ignored when GPG is used (the DEC values are used, as GPG is not involved in DEC guiding). It turns out the RA Maximum pulse is used for RA and DEC. Maximum pulse is sort of a safeguard that wasn't implemented in the Klenske's GPG code , and so I kept it in place.

The GPG parameters themselves are a bit tricky. I did not modify them from their original form, and you can see how they're used in the code we got from Max Planck Institute / Edgar Klenske:
invent.kde.org/education/kstars/-/blob/m...cess_guider.cpp#L344
Basically it blend the control error:
    line 344:    

control_signal_ = parameters.control_gain_ * input;
where input is the arcsecond guiding error in RA, and control_gain_ is that parameter in the GPG RA Guider Menu you showed
and combines it with a predicted error it's learned from its history
  lines 363-364:
prediction_ = PredictGearError(prediction_point + time_step);
control_signal_ += parameters.prediction_gain_ * prediction_; // add the prediction

Read More...