Jump to content



  • Posts

  • Joined

  • Last visited

Everything posted by NickK

  1. I've already implemented this already - one fast option that works with GPU is phase correlation. Do 2D FFT on the image and the PSF, then do a image wide phase correlation. There will now be a pixel by pixel map - look at the phase correlation for the suspected hot pixel and volia! In the case below I'm using the guide start as the PSF rather than gaussian. Here: If you look at the first image - at the top you see noise (hot pixel), if process you get without using PSF phase correlation to detect the local noise you get image 2 where you can see noise processed into the image.. then with psf phase correlation noise removal you get the 3rd.. the 4th is an image from aladin.fr to demonstrate what is noise vs signal. In this scenario I use a quick detector to find the suspects then apply as needed for speed.
  2. Nice use of convolutional networks to remove point noise: https://arxiv.org/pdf/1612.04526.pdf although this can also be done against the PSF (ie point noise appears not affected by the same PSF that affects the rest of the image).
  3. A nice summary of nice - including this depth of focus using coded apertures. http://kiss.caltech.edu/workshops/imaging/presentations/fergus.pdf Which got me thinking ... if we use a coded aperture, could we remove near field issues such as atmospheric distortion? If we can detect the ranges of objects we could reject those outside of the range over time, thus we could then remove the error. For lunar images - this would be interesting.. using a split prism, it could be possible to have one camera with a coded aperture to estimate the error, the main camera then produces the image. Post processing then delivers the corrected image. For deep space - the image is at infinity, thus coding outside of this indicates non-deepspace data.
  4. You could use that stacked raw PSF and deblur images affected with it...
  5. Careful - the drv8825 will take more voltage, less current. I use a 3.8V 650mA stepper with 100:1 gearbox but use a 12V supply. Set correctly the 8825 chops the current automatically so you get no heat in the stepper and the 12V step overcomes back EMF.
  6. Hi, Just had a look at the code whilst I have a biscuit and drink break. I see you're using SLEEP pin by default: power to the H bridges is cut so if the load requires the current rather than friction to hold that could mean the the focuser moving especially with momentum generated by speed with mass. re-enabling after a sleep, although it doesn't reset the microstep count in the driver, the stepper motor itself may step to the next winding (ie 1/2 or full step) there's a 1ms delay before the DV8825 before the stepper driver is ready to take any instructions such as a STEP operation, there's a 250us delay using operations in call in step() before attempting the step in the 4988 driver. In the end the DRV8825 doesn't get that hot, even when micro stepping so it may be better defaulting to not sleep. It should be an easy exercise to create the 8825 from the 4988 by a subclass and override of a delay method.. (or a little refactoring to make a DRV base class for both drivers).
  7. Started playing with GNU Octave. Given my MacBook pro memory slot has died I'm down to 8GB and slow CPU.. this makes the entire thing more portable and a damn sight more elegant. Guider image:
  8. Using a 3D printer with masking ink.. then let dry (put a heater under the bed).. and etch at leisure. You could then easily switch out for a drilling head.
  9. Sorry not this year.. I am considering next year
  10. Probably a little late in responding I deliberately kept with the C2 because it's passively cooled, thus no cooling fan vibration on the mount/scope. I don't see why this wouldn't simply move straight over to the XU4 or the N.
  11. Yes - I rebuilt Kstars/INDI and the tools in 64bit too although it's 2GB on chip, using 64bit expands the number of registers and opens up other optimisations. I used the C2 because it's passively cooled. More info in the original thread:
  12. I've been using a 64bit ODroid C2 running ubuntu with everything running on it - including astrometry (132GB of SSD based indices)! I don't use a seperate client-server topology - instead simply keep it all on one system then remote desktop into it from which ever system over WiFi.
  13. I thought you needed some oil cycled to keep the bit and piece cool? Interesting
  14. Ahhh.. this the twist I didn't get to make it accelerate or finalise it - life got in the way. For example - steppers values only sync up at specific steps in the cycle. At 1/32 micro stepping - only at step 17 does the step sync with 1x stepping. So to switch you would need to 1/32 micro step to step 17 before switching the 1/16 etc (which is now step 9)- this also impacts the reset position: // on reset the step position homed depends on microstep mode #define RESET_HOME_STEP_POSITION_1 1 #define RESET_HOME_STEP_POSITION_2 2 #define RESET_HOME_STEP_POSITION_4 3 #define RESET_HOME_STEP_POSITION_8 5 #define RESET_HOME_STEP_POSITION_16 9 #define RESET_HOME_STEP_POSITION_32 17 Now imagine switching between micro stepping like an automatic gearbox on the car depending on the velocity of focuser- with the stepping knowing it has 400K microsteps to do it may be better to sync through to 1x stepping then operate in 32 step leaps at 1x speed before slowing down to 1/32 again for the final sets of steps. Yes - I use micro steps for counting, however the step count is a max of 0x0000-0xFFFF or 65K steps. Which when you have a 1:100 gearbox and 1/32 stepping on a 1.8deg step and 2.8 turns of the focuser .. results in about 1.6 million steps limit to limit An extreme example.. however 65K for a full range isn't good. Lastly I was researching an 'automatic' way of detecting the range of the focuser. It attempts to find each limit switch and then calculate the full range of counts. So that way it will not attempt to move and hit the limit - it already knows there's a limit that will be hit before it accepts the move. I agree the MF protocol isn't great - many of the protocols in the industry aren't designed but evolved..
  15. Interesting the DRV8834 only does 2.5-10.8V max. The reason I went with the specific stepper and DRV8825 (sorry 2285 was my mistake!) was that it handled 12-14V which means you get good back EMF resist and is easily powered from a car battery/PSU that's powering the rest of the hardware (cameras, filter wheels etc). "1.9 us; they can be as short as 1 us when using the A4988." this is something to be weary. "DRV8834 only has two pins for setting its microstep mode" the DRV8825 has three pins M0,1,2 like the 4988. So basically the DRV8834 is a low voltage high current. Whereas the 8825 is a high voltage and medium current. You need some voltage headroom to overcome the EMF so the step is a solid positive step rather than having it fail to step when under physical load. The 3.8V stepper is recommended to have 12V to step but you do need to set the chopper part of the driver to limit the current or the stepper gets really hot The other thing I was looking at is adding an IR remote control for INDI for the apple mac IR remote then you can manually move the focus without touching the scope.
  16. I'd be happy slotting into to the driver for the DRV8825 - a current chopper driver. Only thing I couldn't see at the moment in the code is the stepping sync points when micro stepping. So when you change down to 1 then 1/2 then 1/4 .. 1/32 for example the point on the stepper when the stepping align is specific to the microstepping driver. Thread, development and sources:
  17. Ahh I've already done just this! I have the INDI based moonlite controller (ODroid C2) --USB--> Arduino Uno -> DRV 8825 -> 3.8V 650mA stepper motor with 100:1 gearbox I made the moonlite focuser protocol have a few better commands. Torque on this is stupidly high - hence the need for a couple of stop switches. However it means I can hang a heavy set of cameras off the focuser. The Pentax only has a 1:1 focuser - hence the need to have both high torque and accuracy. The system can also step in 1/32. Quite happy to slot into this - can share the code if you'd like. Note entirely finished (ie it won't shift between stepping speeds) so will detect limit stops. Issue here is how to signify to INDI that the limit stop is achieved. These are some of the shortcomings of the moonlight focuser protocol.
  18. You may find that you need additional dependencies - sometimes you can apt get the source packages. Judging by your original post - it sounds like there's a piece of code or a configuration that is needed. Sometimes drivers installed only detect each other at start up so also worth trying a reboot.
  19. Well I'm getting bored .. with the cloudy winters night.. so I think I may pic thus up again I need some maths in my life and sometimes it's good to take a step back and view with fresh eyes. I may be also tempted to look at using AI on the residual noise layer in detecting if a pixel is noise or not. At this pixel value level, this is critical - the focus is not if this pixel is noise or not but how much of the pixel value is noise. So I will start researching the AI noise estimation and see if there's any mileage. Additionally I will start looking at some improvements for performance. I don't think it's worth hitting the GPU yet but there's definitely some algorithmic speed ups that could be done.
  20. Surely it's just recompiling the OpenCV .. as long as it has a back end for SIMD instructions. There is an OpenCL variant of OpenCV but the issue there is, again, the GPU code needs to be specific for the architecture to get any real performance boost - especially with the shared memory systems on embedded (such as PI and Odroid etc).
  21. I have upgraded to HS.. the install was 'interesting' with multiple restarts to get the thing operational.. I use a Odroid C2 for everything - why? because I find not have the mac available.. a pain in the behind lol! I do like the programming in OSX though.
  22. I switched away from using OSX for astro, simply because they kept changing the USB model.. causing things to break every release.
  23. My thinking here is - if the image rate of rotation is known, it can be transformed by sampling. So you take an image Isub, that is captured during a period of Tsub when a rotation of Rarcsec rate occurs. The output image Isub has trails, however by applying sampling using grid that rotates and takes a weight based on Tsub and Rarcsec then the output is stacked into a final frame.. after derotation, the result would be a normal image. Note this is simplified in that it's a straight rotation rather than a sweep..
  24. I had an APC UPS for a home file server a while ago, very good idea considering the housemate pulled the power to plug in the vacuum.. Shutdown handling, the APC I had used a serial connection to alert the computer that the power (a) was on battery power, and (b) was reaching a critical level to trigger a graceful shutdown of the server. not many astro systems can invoke a park process, close the roof and shutdown the PC etc automatically. Noise added to output, as the 12V systems we use are sensitive to noise finding the right inverter not to add noise into a AC-DC>battery->DC-AC->PSU->12V for a camera for example is going to be worth investment of the time to look for good options. My (unqualified) thinking is that having a 12V battery being charged by a charger that leads to the 12V equipment is like having a capacitor over a motor in that it should reduce noise.. Especially with PWM style charging that limit/chop the current to shape the current delivery. Lastly - deep cycle leisure batteries would be best. Although new cars have AGM style for the stop/start functionality. Although a car battery.. I have a Bosch S5 100Ah that I have used for astro.. you can get two days of astro out of it however on the second day the noise level on the camera caused by the deeper discharge dropping the 12V line increased enough to be visible.
  25. You need a current chopper controller. The arduino and even the arduino servo shield aren't/can't deliver chopper style control. I tried the shield, I tried writing a software chopper driver but in the end the rate of current control is too low. I have a stepper rated at 3.8V 680mA and I use 12V on it with a DRV8825 (IIRC that was the number) and it sits there with no heat - you can calibrate the maximum current delivery using the variable resistor on one of the pins and at that point it will deliver 12V that firmly overcomes back EMF but limit the current so it will never burn out. The DRV also supports 1/32 micro stepping IIRC the DRV will go up to 30V with a heatsinks so can cope with pretty much anything It also have thermal other cutout protection.
  • 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.