Jump to content

Issue with Ekos / PHD2 dithering ...


Recommended Posts

I'm having an issue with dithering in Ekos with external guiding in PHD2. I'm aware that this sort of question is probably better asked on respective development forums, but just in case someone stumbled onto something similar and/or I'm missing something obvious.
 

KStars is 3.7.1 (kstars-bleeding package in linux Mint) and PHD2 is latest from linux repo / launchpad (2.7.4-dev5 I believe).

My setup is RPi4 running Indy server and Mint laptop connected to it with KStars/Ekos and PHD2. Everything is nicely setup and running fine -except dithering. I have it setup - 3 pixels of dither, dithering after every exposure, 0.25px for settling and 16s settling time with 60 seconds timeout. This is fairly low res guiding setup at 6"/px and I'm happy with position error of 1.5" for the time being (until I tune everything).

In any case - Ekos and PHD2 seem to have totally different idea of what is happening with dithering and settling. When I look at PHD2 logs - everything "looks normal". It takes some time before it's either settling succeeded or failed (mostly depending on whether I turn on fast centering after dither), but it always takes at least several exposures (lasting 4s each) to determine if all is good or not.

On the other hand Ekos reports Dither started and right after that Dither succeeded and completed and starts new exposure. In fact it logs in guide window that this is information it received from PHD2???

Everything else works fine - exposure selection, guide start/stop, reporting of guide stats ....

I tried all different combination of settings and nothing seems to work to make Ekos behave "normally". Closest thing I can do is set guide limits - to pause sequence if guiding error is larger than some value - and even that does not work every time.

Does anyone have any sort of idea what might be the issue?

Link to comment
Share on other sites

Have you tried with PHD2 running on the RPi instead of the laptop? Does dithering work if you use the internal guider?

BTW, I used to get several small issues like this when Ekos was running on laptop so I switched to running everything on the RPi. Much less issues now.

Edited by AstroMuni
Link to comment
Share on other sites

RPi runs server version - so headless. It just runs INDI server with drivers.

I have Gigabit network between it and my laptop, so latency is at minimum. PHJD2 works perfectly normally otherwise. I could not get internal guider to guide normally at all. It manages to calibrate but I get such poor performance out of it.

It has trouble finding stars and RMS jumps to x2-x3 more than with PHD2.

Link to comment
Share on other sites

2 hours ago, vlaiv said:

It just runs INDI server with drivers.

The right way, btw. To many run the whole Ekos suite on to small hardware. I used PHD2 with Ekos in the beginning, long time ago, can't really be of any help. When Ekos offered multistar guiding I left PHD2. The internal guider didn't do a worse job then PHD2, can't claim it is better when I don't use PHD2 anymore. If I understand the Ekos/PHD2 combo right; you just start the PHD2 application and do the rest in the Ekos interface? So, all options regarding binning, exposure inetrval, settling time and so on should be the same, regardless of what does the guiding? The only difference is that PHD2 grabs the image from the guide camera, does the calculations according to your settings, and correct the mount?

Ekos own guider is fully capable of guiding well under 0.4 RMS. I have had run over 4 hours without exeeding that value once. So it can do the maths. The culprit must be either how the guider (Ekos or PHD2) aquire and handle the image from the guide camera, or how it respond to the mount.

The options in the 'Guiding' tab in Ekos are many and not so obvious. It is easy to mess up, but once you are on track you hardly need to adjust anything. The only option I touch from time to time is the exposure interval. Never below 1.5sec and never more than 2.5sec. I can start my obsy and take a few screenshots of these settings that have served me well the last three years, but I can't do any guiding. Not dark enough, and cloudy.

Link to comment
Share on other sites

14 minutes ago, Rallemikken said:

The culprit must be either how the guider (Ekos or PHD2) aquire and handle the image

Rebellious. Quote myself.  I recon PHD2 choose it's own gain and exposure settings for the guide camera, as long as it handles it on its own. Have you looked into the tab for the guide camera in the INDI control panel? This is where these settings are set on the guide camera in Ekos. I don't think you find them elsewhere.

Link to comment
Share on other sites

23 minutes ago, Rallemikken said:

The right way, btw. To many run the whole Ekos suite on to small hardware. I used PHD2 with Ekos in the beginning, long time ago, can't really be of any help. When Ekos offered multistar guiding I left PHD2. The internal guider didn't do a worse job then PHD2, can't claim it is better when I don't use PHD2 anymore. If I understand the Ekos/PHD2 combo right; you just start the PHD2 application and do the rest in the Ekos interface? So, all options regarding binning, exposure inetrval, settling time and so on should be the same, regardless of what does the guiding? The only difference is that PHD2 grabs the image from the guide camera, does the calculations according to your settings, and correct the mount?

Ekos own guider is fully capable of guiding well under 0.4 RMS. I have had run over 4 hours without exeeding that value once. So it can do the maths. The culprit must be either how the guider (Ekos or PHD2) aquire and handle the image from the guide camera, or how it respond to the mount.

The options in the 'Guiding' tab in Ekos are many and not so obvious. It is easy to mess up, but once you are on track you hardly need to adjust anything. The only option I touch from time to time is the exposure interval. Never below 1.5sec and never more than 2.5sec. I can start my obsy and take a few screenshots of these settings that have served me well the last three years, but I can't do any guiding. Not dark enough, and cloudy.

I actually fire up PHD2 - do calibration and all the settings. I use camera in 16bit mode and set gain with low read noise (which happens to be around 240 for ASI185). I have IR pass filter because of low sensitivity of IR part of spectrum to atmospheric influence and fact that camera is somewhat sensitive above 800nm (about 30-40% QE - but enough to pick up plenty of stars). I get SNR in range of 300-500 depending on stars in FOV and which one I select.

I use 4s guide exposures - which keeps my mount in ~0.5-0.6" RMS range and together with IR pass really tames the atmosphere.

In any case - I can control PHD2 from Ekos but for most part I don't - I just use start / stop guiding and dither commands in Ekos and observe RMS/correction graphs.

With internal guider I had issues with it getting good "lock" on stars with settings I use with PHD2 - that is 4s exposure, 16bit and gain and offset settings. With multistar guiding - I need to select profile with medium or small stars - and even then it detects low number of stars and uses something like 2 or 3 out of ten stars. It also constantly changes which stars it uses for guiding for some reason.

If I do dark subtraction  - it just shows enormous amount of noise and few guide stars - much smoother background without dark calibration in internal guider - but neither work well. Other algorithms have issue with detecting / tracking stars as well regardless of search region (tried 16, 32 , 64 - if I remember correctly).

I'd be happy to use internal guider if I can get it to work. I tried switching to 8bit and it looked for a moment to improve things - but I still could not get consistent guiding with it.

 

Link to comment
Share on other sites

My normal procedure is to use the internal guider in Ekos (oag on MN190 with 1000mm fl, ASI290MM mini guide cam at bin2, multi star guiding with predictive PEC and 2.5 s exposures). I run everything from a RPi4 4GB with 64GB microSD, and connect to it with either remote desktop, or, on Astroberry and StellarMate, with VNC in a browser. So the RPi does the heavy lifting. I dither every 3rd frame, and usually get guiding RMS 0.4-0.7" depending on conditions, and where I point the scope. I can't recall ever having changed the default dither parameters, other than the dither step size. On occasion, I have used PHD2 for guiding. I then just start PHD2 and let Ekos control it. Either method of guiding works fine for me. I have noticed however, that if I use bin2 and PHD guiding, that the values in the Ekos guide module don't match those in PHD, by a factor of 2. It seems that there is an issue with communication between the programs. This was quite a while ago, and I believe that PHD showed the more realistic values. That's one reason why I prefer the internal guider.

@vlaiv, have posted about your problem on the indilib forum?

Link to comment
Share on other sites

9 minutes ago, wimvb said:

 

@vlaiv, have posted about your problem on the indilib forum?

Not yet.

I'm going to first explore if I can get internal guider to work. I might switch guide scope. Currently I'm using very small 32mm F/4 one, but might change it for 50mm adapted finder (I just need to 3d print adapter and bracket for it - Might do that tomorrow).

Poor performance on the night I tried it might have been due to high altitude clouds or wrong settings. I want to give it another go and see if I can get it to work.

Alternatively, I'm going to turn on debug log for both applications and save logs (I have guiding log from PHD2 but logging was into console for Ekos and I want it to go to a file so I can post it with question if need be).

  • Like 1
Link to comment
Share on other sites

1 hour ago, vlaiv said:

I'd be happy to use internal guider if I can get it to work.

I'll attach my settings, for both INDI and Ekos. Maybe someone can benefit from them. I use an ASI 120MM, same pixel size as yours, but 1,2mp contra your 2.3mp. And yours are color. Both are 12bit native. As you can see, INDI treats mine in RAW 16bit. Don't ask me how. I never bin, and use box sizes of 8 or 16 pixels. Once running, it reports between 50 and 100 stars available. Most settings are visible in these images. I think it is crucial to have an almost black image, with enough stars clearly visible as sharp points. Turn your guide camera to your imaging camera for a while, and toogle the settings until you get frames that looks good for this purpose, and use that as a base? I did this tonight, and the fits viewer reported 1 sec exposure time, 32 in gain and zero offset, as in the settings. Maybe I could increase the gain, and get shorter exposures. Could be beneficial if I guide on shorter intervals, but "if it ain't broken, don't fix it". And I don't think Ekos waits until the last image is processed before it initiates the next. As you can see, I have the 'Delay' settings at zero. Never happened that the guide frame have had oblong stars. But if the exposure time is near or the same as the interval, this must be set in some way.

No expert, in any way, but I have run KStars/Ekos/INDI on many configurations and on different hardware. Learned two or three things: If you update, clone your SSD and tuck away the backup. And do it before the season. And on the Ekos side, CPU cycles are king, especially when it comes to guiding. It is the first thing that starts to suffer. And last, if you run a headless INDI server, you can do with a RPi3 B+ as long as you use USB2,  as I have done until now (ASI 120MM and Canon DSLR's) but you can NOT rely on wifi. Not even on a Rpi4 or 5. Take the trouble of stretching a network cable, it will save you a lot of grief. I use a INDI headless server and wifi when I start up my StarTracker, but that's without guiding, the worst that can happen is that the images takes a little long to reach my laptop.

EKOS.png

INDI-control_panel.png

Link to comment
Share on other sites

2 hours ago, Rallemikken said:

you can NOT rely on wifi

So true. Use (wired) ethernet if you want stability.

2 hours ago, Rallemikken said:

If you update, clone your SSD and tuck away the backup. And do it before the season.

Also good advice. I learned the hard way to never update during a season. But instead of cloning the old card and updating the system, I use a fresh install on a clean card. When I had Ekos/Kstars on a Rock64 (that was before RPi 4), I had two identical Rock SBC's. If one crashed, I could just swap the computer and be up and running again in no time.

Btw, @Rallemikken, I see that it's not just the swedish locale that has poor translations on the Raspberry Pi. 😄

Edited by wimvb
  • Haha 1
Link to comment
Share on other sites

Just a little report.

I managed to get internal guider to play along. I changed guide scope for 50mm finder with 3d printed adapters and mountings. It looks like Ekos internal guider is very sensitive to high altitude clouds (in a bad way - by doubling or even tripling RMS error due to measurement issues), so that must have been the issue on the first night. In fact - it does report slightly worse RMS figures compared to PHD2 - but the question is, which one can be trusted if any?

In any case, I'm happy with current performance - but I do have a follow up question. It's settling time again. There is option for settling time - but during that period guiding is simply stopped - there is no RMS measurement. There is also no way to specify any other settling parameter.

Well, that is not quite true - I can still use guide limits. I can say to suspend imaging if guide error is above some threshold value - and that seems to work to an extent - but I can't say how long it must stay below that value (say 12 seconds or something like that - and if it's not - then proceed with suspend).

How do you handle settling with internal guider?

Link to comment
Share on other sites

On 03/08/2024 at 23:50, vlaiv said:

How do you handle settling with internal guider?

Good to hear that you managed to get the internal guider working. If I recall correctly the settling time is for the dither and there is a delay timer for how long to wait after sending a pulse. Those are the two parameters that I have encountered.

 

On 03/08/2024 at 23:50, vlaiv said:

I can't say how long it must stay below that value (say 12 seconds or something like that - and if it's not - then proceed with suspend).

There is the Abort if guide deviation is > x, n number of times, which may help achieve this. I havent used this parameter TBH so perhaps someone who uses this can comment.

Edited by AstroMuni
Link to comment
Share on other sites

47 minutes ago, AstroMuni said:

There is the Abort if guide deviation is > x, n number of times, which may help achieve this. I havent used this parameter TBH so perhaps someone who uses this can comment.

I think that just aborts the sequence completely.

Other parameter can be used to delay the start of exposure until guide deviation is < certain threshold -but it does not "wait" certain time to see that actually being sustained.

Link to comment
Share on other sites

22 minutes ago, vlaiv said:

Other parameter can be used to delay the start of exposure until guide deviation is < certain threshold -but it does not "wait" certain time to see that actually being sustained.

I do use this but I am not aware of how the guide deviation threshold is measured behind the scenes. Worth asking on indilib forum and perhaps a wish list item even !

EDIT: Just a thought... as its a mean value anyway it would need several large deviations for it to move significantly away from this value. So is the question on sustain practically needed?

Edited by AstroMuni
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.