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_globular_clusters_winners.thumb.jpg.13b743f39f721323cb5d76f07724c489.jpg

kens

Advanced Members
  • Content Count

    792
  • Joined

  • Last visited

Community Reputation

277 Excellent

2 Followers

About kens

  • Rank
    Proto Star

Profile Information

  • Gender
    Male
  • Interests
    Deep sky, fly fishing, cycling
  • Location
    Melbourne, Australia
  1. The Hobbyking UBEC I use is regulated and has reverse polarity protection. I think a fuse on the 12V side of the UBEC should be sufficient. And care in connecting it the right way to the GPIO.
  2. The Ekos internal guider uses the INDI driver. PHD2 can use either the native driver or INDI and could possibly use either the Altair or Toupcam drivers. Can't speak for the Altair driver but the Toupcam driver in PHD2 operates in what is called trigger mode where each exposure is triggered by the software. The alternative is streaming mode which sends a constant stream of video images. PHD2 prefers to use trigger mode for all cameras now as some issues were found with streaming mode with backlash compensation and long corrections causing streaking of the guide star. My personal preference was for streaming mode but the software needs to work for everyone. I suspect that the internal guider uses streaming mode. In PHD2 you could try using the INDI driver (IND Camera) and select the option in the settings for "Camera does not support expsoure time". This should force streaming mode. Can't guarantee it will work but its worth a try. If you can reproduce the connection problem then post on the PHD2 support forum with your debug log.
  3. As far as I know the USB hub on the ASI1600 is not powered from the 12V power -that is solely for the cooler. My experience is that LAN is way more reliable than Wifi. Wifi on Linux in general is problematic in terms of which chipsets work, don't go to sleep etc... Having said that I've found the Pi wifi to be amongst the ones that work fairly reliably. But it is going to be slower than the LAN. Network speed is the main issue with the ASI1600 with its 32MB files. At gigabit/USB3 speeds the transfers are close to instantaneous, at 480Mb/s (USB2) it takes a few seconds, at 100Mb/s you are watching the clock waiting for the download to complete and any slower you start to wonder if anything is working. I prefer to use Wifi despite the problems so I focus, preview and platesolve at 4x4 binning to cut down the download times. And I save the files to the UP Core (called local on EKOS) and download at the end of the session once I can connect the LAN. If I want to check the images during the session I use VNC and run Siril on the UP Core to view them. Certainly StellarMate and ASIAir are INDI based. With the ASIAir what you are paying for (IMO) is the client software running on iOS. If you aren't interested in that you may as well get a StellarMate or roll your own. AtikAir I'm not sure about but I think it uses native drivers only and operates just the camera. The GPCAM on Linux has some problems. It is a rebadged Toupcam and the Linux drivers are not very good. In fact it was only recently they produced a Linux driver for ARM devices. The way they distribute the Linux driver is eyeball rolling stuff. Getting it (Toupcam) to work in PHD2 and INDI has been a bit of a struggle but I see it has been recently re-enabled. PHD2 has separate drivers for Altair and Toupcam whereas on INDI they have converged. There may be an opportunity on PHD2 to converge them and pick the best bits out of both to get something that works well. Meantime you might want to see if the native Toupcam driver in PHD2 works with your GPCAM and failing that try the INDI driver.
  4. Nothing you said is surprising. Running everything on the Pi is a big ask. So running Kstars/Ekos on your Windows machine is a better way to go. That is how the system is supposed to be used. I'm interested to know where you encountered performance issues using Ekos on Windows. Was it during image download? If so, make sure you are saving your images to local rather than the client so you save then to your USB stick rather than transferring over ethernet. I don't use a Pi - had one but upgraded to a faster device with USB3. I run PHD2 on the device to get best performance as there is no guide image download over the network and I can use the native ZWO driver. The main downside to running Ekos on the client is that it doesn't like network dropouts. I normally connect over wireless but the dongle drops out from time to time and I need to restart Kstars. At least PHD2 keeps running and INDI stays connected. The INDI control panel is not really meant to be used on its own. The layout is determined entirely by the driver (and whoever wrote that particular driver) so there is not a lot of consistency from device to device. It is made available so you can use non-standard settings but to do that it has to show you everything available whether you are interested in it or not. Another thing to watch for is that you are connecting everything to the Pi USB ports. Given that Bluetooth, Ethernet and Wifi also connect internally through USB you might be overloading that part of the system. Are you seeing the lightning flash on the top right of the screen? That indicates low power. That could be why you needed to disable Wifi for things to work. A powered USB hub would be a better way to go. Also, how are you powering the Pi? I use a UBEC to convert 12V to 5V and connect it straight onto the GPIO port.
  5. kens

    New PHD2 Z-filter algorithm

    I don't think so. Metaguide has a unique guiding algorithm and centroid calculation. It is not open source so I can't comment beyond that. Z-filter uses the normal PHD2 centroid calculation as input. It differs from the default hysteresis algorithm in that it is designed (and I mean designed) to give flat response in the pass band with a sharp cutoff, minimal lobes in the stop band and linear phase. It is a digital version of a Bessel filter. And the cutoff is adjustable so it can be adapted for different exposure times to give a consistent response
  6. kens

    New PHD2 Z-filter algorithm

    Shorter exposures with bad seeing will always give bad looking graphs but you need to look at the end result to see if it is better or not. If you look at the corrections you can see see how Z-filter does not chase the seeing and instead gives a smooth correction. The normal use case for Z-filter is with a mount that responds well to small, frequent corrections.
  7. With INDI on the RPi you can use any camera supported by an INDI driver. Normally USB connected. Since you have DIY mount controller that becomes harder. If it is coded to use LX200 commands then it should be possible to get it to work. You can certainly run PHD2 on the RPi and you also have several native camera driver options there too.
  8. A hot pixel usually results in no corrections at all. This is a fast moving pixel. Maybe it locked onto a satellite. A guide log would be really helpful.
  9. Can you attach the guide log? It will help with the diagnosis.
  10. kens

    Eq6 guide speed nn x sidereal

    Guide speed is adjustable from 0.1x to 0.9x in EQMOD and PHD2 should be able to read it from the mount. Otherwise adjust it with your handset where the available settings are 0.125x, 0.25x, 0.5x, 0.75x and 1.0x and enter that value in PHD2. 0.5x is a good starting point. i'm pretty sure EQMOD defaults to 0.1x which is way too low for most situations.
  11. kens

    RA Runaway in PHD2

    I just want to clarify what you mean when you say the motor doesn't stop. Are you saying you can actually hear it moving even when it has gone off the rails? The reason I ask is that a fast movement such as you are seeing is often due to the motor stopping and failing to track the stars. If the mount is losing power then the motor will stop but if it i indeed still moving that rules out power as an issue. You should familiarise yourself with the orientation of your guide camera in PHD2. Start tracking (not guiding) and watch what happens on screen when you turn off tracking. You'll see the stars moving quickly off screen. If you see them move the same way when you are guiding then you know its from the motor stopping or slowing.
  12. It all depends on whether you are shot noise limited or not. If you are shot noise limited then the main effect of increasing gain will be to reduce dynamic range but SNR wont be altered much for a given integration time. If you are still read noise dominant then longer subs would work better for SNR. You are shot noise limited when the peak of your histogram corresponds to 5x to 10x read-noise squared or higher. At unity gain (for 10xRN^2) that equates to a 16bit value of 440 plus 16x your offset. Assuming offset of 50 that's 1240. For a gain of 200 and offset 50 its 1440. Don't be fooled by the higher number because with the higher gain the number is reached faster. With NB, even with strong light pollution its hard to get to 10xRN^2. So you might even want to increase the gain AND increase your sub length.
  13. kens

    RA Runaway in PHD2

    That is what I'd expect. The handset sends a command to the motor controller to tell it to start tracking. The only things that can stop it electronically are loss of power to the motor controller, loss of pulses from the motor controller to the motor or the stop command being sent from the handset. The ST4 port could cause the mount to stop tracking if the East wire shorted somewhere between the camera and motor controller causing to stay on. Guiding east can stop the mount but as you are guiding at 0.5x sidereal a continuous east guide signal would slow it to half the speed. Looking at your last guide log it is inconclusive. During the fast drift it was moving sometimes faster the 0.5x and sometimes less. On average it was a bit above 0.5x sidereal. If you remove the ST4 cable and is still not moving then that is not the problem. It sounds like the motor controller itself is ok. It either works or it doesn't. But its quite possible the motor connectors are loose - maybe not seated properly when it was replaced. Or the act of replacing may have damaged one of the small wires to the motor and it has now started to fail. When it fails are you near the mount? If so, if its binding you would hear it clearly - not a happy sound. If its electrical you might hear the motor stop. If its power supply you would see the power led flicker or go off.
  14. kens

    RA Runaway in PHD2

    It could be an electrical connection problem. My working assumption is that the mount stopped tracking in RA although the Dec response goes against that and is more indicative of a mechanical problem. If it's tracking and electrical then its either power or the motor wiring as the handset does not directly control the motors and its hard to imagine a glitch causing the handset to send the command sequence to stop tracking. You could think about getting an EQDIR cable and take the handset and ST4 cables out of the equation. Plus you'll have better data for diagnosis.
×

Important Information

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