Jump to content

 

1825338873_SNRPN2021banner.jpg.68bf12c7791f26559c66cf7bce79fe3d.jpg

 

kens

Members
  • Posts

    921
  • Joined

  • Last visited

Everything posted by kens

  1. It does work best with short exposures and those provide more scope for tuning. At longer exposures it still works well but offers no specific advantage over the default algorithms. It is designed for mounts that respond well to frequent, small corrections. I think the Mesu would qualify there. Large deviations due to wind will cause a relatively slow response but it will be smooth. In some cases it responds better because there is no ringing. Slow response in Dec is most noticeable as I normally recommend a low frequency response (typically a factor 8 of exposure time) This minimises or even eliminates dec reversals but step changes take longer to recover.
  2. I know how it works - I wrote it It is a digital Bessel filter with a tuneable cutoff frequency. Unlike the other algorithms it has flat response in the pass band and no nodes in the stop band and being a Bessel filter has linear phase response. The filter is fourth order so approximately 24dB per octave suppression above the cutoff. It is the ability to tune the cutoff frequency as a function of exposure time that makes it useful. By allowing short exposure times you can reduce latency but still filter out the high frequency seeing-related deviations.
  3. The Mesu could well benefit from the Z-filter algorithm with a shorter exposure time - especially if you are getting good enough guide images to saturate stars. The exposure factor can be set so you don't chase the seeing.
  4. It's full moon time now so a great time to experiment and learn. Follow vlaiv's advice about and just get in some guiding time. The target doesn't matter but ideally near declination 0; and 45 to 60 degrees elevation. Just use default settings and don't mess with them - this is a data gathering exercise. At minimum collect a guide log over 20-30 minutes long. If possible at least one typical sub. And ideally save a typical guiding image using the File > Save Image... option anytime during the session. You could also run the guiding assistant for around 20 minutes. That should provide enough information to diagnose your issues. Either post them here or on the PHD2 support forum for advice.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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
  10. 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.
  11. 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.
  12. 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.
  13. Can you attach the guide log? It will help with the diagnosis.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. What is your imaging sequence? If you do all R, then G then B you can get different sky gradients on each filter as the scope rotates.
  20. If you are getting backlash in RA then your balance is off. In RA the mount is constantly moving west so backlash should not be an issue Some other data points from your guide log: Your PA error is not very good - over 20'. Shouldn't be a cause of your issues but should work on it Around 00:03 the mount appears to have stopped responding to RA guide movements. All the pulses from there are westwards until the problem becomes obvious around 00:19 In addition to losing control of RA, Dec also moves off sharply. Edit: The RA and Dec drifts both started (slowly) just after the glitch near 23:52 If backlash is at the root of your problem then also look at your RA balance. The RA response could be due to being west heavy and when it causes the gears to unmesh you get the backlash effect. Also look at your guiding setup. Make sure the guide scope and camera are secure. You might have had a rotation of the guide camera which would explain the dec response.
  21. That's an artefact of his problem. The guide star has rifted so far from its lock position that PHD2 has to issue huge corrections that exceed the set maximum.
  22. Binding is when imperfections in the gearing cause excessive load on the motor causing it to stall or cog. The simple way to test is to point the scope near where is was when it had the problem and slew through that position while listening for noises and watching for the mount to stall. Another, more comprehensive, is to remove the OTA and slew through 360 degrees. But if the issues was caused in part by balance then this could show everything is ok but with the OTA on board you could still get binding.
  23. My mistake. I had in mind EQMOD which has meridian limits to stop the mount tracking too far past the meridian. If it wasn't cables or tripos strike than another possibility is the gears binding. Your issue is mechanical, not PHD2. PHD2 was just responding to a movement too large for it to control. By the way there was a big glitch about 30 mins before things went totally pear shaped. PHD2 brought that one back but it may have been a precursor to the later issue.
  24. Astroberry and Stellarmate both use much the same technology. And you can roll your own if you wish. With Stellarmate you are buying a pre-built kit (hardware and software) or you can buy just the operating system to download. For your money you get support from the vendor. Astroberry is a downloadable operating system for the Raspberry Pi for free. Both run on Ubuntu 16.04 and use the INDI framework and other freely available software which you can download and install yourself. However, there are some issues with Ubuntu on the Pi3B+ which I understand are resolved with Stellarmate - Astroberry I'm not sure. You don't need to install on a Raspberry Pi. I use an Aaeon-Up Core which is actually smaller and has the advantage of eMMC memory and USB3 port. Its harder to get up and running than a Raspberry Pi but performs better. You could really try any sort of computer that runs Linux. The main advantage of INDI is that it is designed for distributed computing. So you can run the INDI device drivers on one or more Raspberry Pis and run the client software like KStars/EKOS, CdC, PHD2 etc on your laptop. I run PHD2 on the Aaeon and Kstars/Ekos on my Windows Desktop connected through Wifi. Some folks run everything on the Raspberry Pi although I would not recommend that. You can find out more at indilib.org which also has a forum for asking questions.
×
×
  • 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.