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.

sgl_imaging_challenge_banner_the_milky_way.thumb.jpg.dbd8b15e81d11e9303c8d6ef1898ac08.jpg

kens

Advanced Members
  • Content Count

    710
  • Joined

  • Last visited

Community Reputation

258 Excellent

2 Followers

About kens

  • Rank
    Proto Star

Profile Information

  • Gender
    Male
  • Interests
    Deep sky, fly fishing, cycling
  • Location
    Melbourne, Australia
  1. kens

    New PHD2 Z-filter algorithm

    Do one run with order 1 or 2 and another with order 4. Keep all other parameters the same. If you can also provide a sub taken from each run that would also be helpful. With good guiding the graph really only shows the seeing. So what really matters is small round stars in your subs.
  2. kens

    New PHD2 Z-filter algorithm

    Hi Bernard It would be useful if you provide some example guide logs. During testing we found that the order did not make much difference so to keep things simple I fixed it at 4. Note that with the new setup that the old corner factor 4 or 8 is now an exposure factor of 1 or 2.
  3. kens

    Startools help

    In DSS, try saving the output as a FITS file. I've found 32 bit FITS load faster in StarTools
  4. kens

    The insanely faint...

    Calibration should sort out that mess
  5. kens

    PHD2 "guidelog" vs "debug log" files?

    The guide log records the guiding activities in a structured format for review in programs like PHD Log Viewer. This helps you work out your guiding settings and diagnose issues with your setup. The debug logs are for use by PHD support and developers to track down more technical issues like why your camera isn't connecting and such like. The debug log and guide log come in pairs. There should be one for each time your start PHD2. If there is a debug log with no guide log it might be because you didn't do any guiding. I'd have to look at the debug log to work that out.
  6. kens

    New PHD2 Z-filter algorithm

    To help explain (maybe).... The current guiding algorithms used in PHD2 rely heavily on setting the guiding exposure time to smooth out the seeing. But that means the corrections to the mount are delayed accordingly and don't correct as well as they should. With this algorithm you can use faster exposures and use the exposure factor parameter to smooth out the seeing. But the corrections are sent more quickly and are smaller so they work better. The main caution is that when you use longer guide exposures your graph looks smoother. But with this algorithm and shorter exposures your graph looks like a mess because it shows up the seeing. You need to look at the corrections to see how smoothly the algorithm it is working. Or better still, look at the stars in your images
  7. kens

    New PHD2 Z-filter algorithm

    I'd start with a factor of 4 to 8 on RA and 6 to 12 on Dec. The algo is specifically meant to be an improvement on the LowPass algos recommended for the Avalon mounts so it should work well for you.
  8. This follows on from In the latest PHD2 dev release 2.6.5dev4 the algorithm has been tweaked to simplify its configuration. The former "Order" has been fixed at 4 as testing showed that to be the optimal and other values made little difference anyway. The "Corner" value concept has been altered to an "Exposure Factor" to make it simpler to understand. Multiplying your guiding exposure by the Exposure factor gives a "virtual exposure time" where the guiding response is similar to choosing that exposure time with a hysteresis algo. Finer control for the exposure factor has been added and it can be adjusted directly on the graph. So lets say you normally use 3 second exposures with Hysteresis algo: you could instead use a 1 second exposure with Zfilter using an exposure factor of 3x. This has the advantage of smaller corrections with less lag time. If the guide star brightness drops you can increase the exposure time to, say, 2 seconds and reduce the exposure factor to 1.5x In most cases, a MinMo of 0.0 is recommended. If you are guiding with OAG at small pixel scale or have severe backlash a small MinMo may be helpful but in general, increasing the exposure factor works better. Using the on-graph control you can see how the algorithm works to smooth out the guiding as it is adjusted. If you choose the "Corrections to scale" option in the graph menu you can see the size of corrections in relation to the movement of the guide star. The algorithm is still a beta release so any feedback is welcome
  9. I do much the same as vlaiv. Main differences: Use offset 50 at all gains Gain 75 for L, gain 139 for RGB, gain 200 for narrowband At gain 75 expose the histogram peak to 1100+, at 139 to 1200+, at 200 to 1400+ (if possible) - all in 16 bit values. Typically, under my skies, that means 30s exposures in LRGB and 3-5 minutes NB The flats, darks and flat darks are most important. Flats I expose to 20000 (16 bit) and I take 40 of each
  10. Its easier to align the two back legs East-West with a straight edge. First align the straightedge by compass then set up the back legs along the straight edge. And in the southern hemisphere a compass is really the only option as there is no bright pole star.
  11. kens

    PHD2 Sanity Check

    Please post the guide log with the calibration causing a problem. You can find them from the help menu option to open the log files folder.
  12. kens

    PHD2 Drift Align Result

    The exposure time for drift aligning doesn't really matter. All you need is a long enough drift to get a stable trend line.
  13. kens

    PHD2 Drift Align Result

    Its just the trend that matters. For a long drift the start point could well be off the graph. So set the graph to show 40 points. Even then with exposures of 2 seconds or less they wont all fit after 15 minutes
  14. You could also use your imaging camera. The focal length of your main scope should be more accurately defined.
  15. kens

    migration windows to linux

    I'm running it as an Indi server and PHD2 server. For me the purpose of using these SBC's is as a form of embedded computer. So its not a Linux versus Windows question. I treat the Linux device as just a part of my telescope. I switch it on and connect to it via KStars/Ekos running on Windows like I would the camera or mount. If anythings acts up I switch it off and switch it on again like any other device. Linux is ideal for this use and dominates embedded systems due its reliability and small footprint. So far the Aaeon works well and boots up quickly and reliably even when shut down very ungracefully. The RPi is a bit flakey when it is not shut down gracefully. BTW moving the RPi to boot from USB is not one way. Just a small change in one file on the SD card. You still need the SD card but the Boot sector is on the USB stick.
×

Important Information

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