Jump to content

 

1825338873_SNRPN2021banner.jpg.68bf12c7791f26559c66cf7bce79fe3d.jpg

 

NickK

Members
  • Posts

    3,804
  • Joined

  • Last visited

Everything posted by NickK

  1. I've recently been heavily involved in producing a 24Vdc -> 240Vdc boost converter for a valve amp. Let's ignore the topology discussion for now but - you're right that SMPS are an inherently noisy way of either stepping down or stepping up power. One or more switches are flipping anything from 50,000-1M times a second depending on design and configuration. It's the reason why the components are smaller (due to the high frequency switching). Also SMPS that plug into the mains typically convert from 240Vac to 390V before bucking down to the intended 24V or 12Vdc. Meanwell produce good supplies - including medical. just ensure that (a) the supply is "isolated" and (b) has over/under and short curcuit protection. A lot of the meanwell also have PFC which makes them very efficient. Their 24V supplies only have around 150mV peak-to-peak for the 24V supply. There's some noise but for audio shifting the noise up in frequency is a great way to make things quieter (easier to filter). Now to my point. It is possible to post regulate (ie using a maida regulator with an LT3080 instead of the old LM317 for example) with 1A max to 1mV ripple or below which means you're at least down to -60dBv and the supply I'm working on is around -120dBV at 240Vdc but also be efficient. That lower ripple (regardless of frequency range) means low noise for cameras - traditionally this is why APers have used linear regulated power supplies as they don't have switching noise. I have a meanwell supply on my koi pond filter controller. I've had it blow due to water ingress but it's dependable and works. New controller box to solve the water leak and no problem since. I'd certainly recommend meanwell supplies. As always - careful of humidity and water ingress ;)
  2. Another issue with wine is the support for multiple threading. It’s not brilliant for high performance work (ie real-time or games) but does work well enough for low end stuff. personally I’d have a look at Linux and INDI/Kstars. Lots of drivers and they seem good enough.
  3. That would probably work well and actually allow a faster frame rate (depending on the seeing). There is a fl vs binned pixel size but if the guide star image is large enough then a centre mass calculation shouldn’t have a problem. All my cameras are mono.
  4. The only issue is that Bayer matrix can confuse some star tracking. If the wavelength of the start if blocked by one of the colours then the tracker may loose the star or find that the star centre point moves irregularly.
  5. Right ... getting to the end of of the ODroid C2 build.. I've created a virtualbox 64bit x66 ubuntu install for cross compiling to arm aarch64 Indi, kstars and this.. so will start playing with the focuser over the next week(s). This will allow me to test using the Mac straight to the focuser (12 core Mac 32GB RAM is a lot faster!), then simply patch over the binaries. Once it's working, I'll look at adding stop switching for limits.
  6. Just rebuilding the C2.. now I remember - getting it setup as headless VNC on ipv6 .. this bit if Linux I hate.. anyways .. going off topic
  7. Just rebuilding my OdroidC2 kstars and indi platform. I’ll switch to use this with my drv8825 and uno used for the focuser. Should have this over the next couple of days.
  8. The C2 uses eMMC for system drive (16GB) so ~12sec power-ready but only has usb 2.0 - fast enough for an SSD image store. With passive cooling - no vibrations too. I use UBECs to convert from 12V to 5V - small but powerful enough Like the RPi it does everything in a box Just trying to pick up courage to reinstall from scratch! Will probably do that tomorrow.
  9. Amazing to think that something the size of this can do everything including astrometry! Just playing around - the build on this is 2016 and the first 64bit self compilation of many INDI/Kstars things.. so I’m seriously considering updating it to correct many package errors stopping upgrades etc.
  10. so; Guide Camera -> Mount rather than Guide camera -> RPi -> mount ? ST4 simply says nudge N/S/E/W and the length of pulse is how long the nudge is (the auto guider port on the NEQ6). There isn't any logic or protocol to change speeds etc. If the hand controller decides it's going todo something then it will cause a problem with the tracking. Most cameras are simply cameras - ones with an ST4 port simply pass the computer image to the computer, the computer analyses and instructs the ST4 pulses back to the camera though USB. Autoguider cameras that analyse the image inside the camera short cut that - and you'd not need to worry about the computer guiding (it doesn't know about the computer). INDI has a guider module; So basically set INGI guider up for internal guider, connect the ST4 ports up and away you go.. you don't need to remove the handset and use the PHD-style dongle to replace the handset controller. It's not as advanced as PHD2 but more info here: https://indilib.org/about/ekos/guide-module.html
  11. My initial idea was to get pure digital from PSU to headphones with possibly a passive RC filter at the end. Going through all the research it became apparent for R2R vs singlebit sigma delta, that the noise from square waves needs careful control (far beyond an active Sallon-Key Butterworth filter. Also the ladder resistances for higher bits requires higher tolerances (0.01%). Then by the time the switching on the ladder is operating at ~3MHz you're starting to get into higher frequency curcuit design.. bypass caps, track layouts etc all become too costly to simply DIY. I find the software and building digital filters relatively easy (including the fpga) but low volume cost of high precision resistors and large number of mistakes in hardware.. it would be easier selecting an OEM board. In the end I will go with a Soekris R2R OEM board (this has usb, fgpa, ultra stable clock, switches and resistors at 0.01%). The board then requires line buffer or headphone amp, power supplies and control boards. Those are easier to build or source.
  12. Lol yes - it's easy to make a filter to kill off anything outside of 50Hz from the mains, then regulate to a voltage. Most cameras I have are 12V with the fans (shock horror) also running from the same power. Just seemed like an option to provide 12V heavily filtered It's possible to run an isolated USB with the regulator providing quiet USB too.
  13. So I've been exploring the world of DIY audio.. specially making a headphone "DAC" with an R2R ladder style DAC. So effectively the headphones are connected to the power supply - thus ultra low noise stable DC power regulation is needed. Now my current power system is a supply (normally battery) that is then fed through a RC style regulator to give the required voltages and current. However the LT3045 regulator is something worth noting .. Only 500mA I hear.. well actually you can connect these in parallel and the reference design has a 4-device 2A design that pushes the heat and noise levels down further! So this would be able to run a camera at 12V but another option is to "upgrade" the internal camera power. The down side.. in singles the regulator chip itself (surface mount) is about $/£/€5 each. Just wondered if anyone had explored creating an astro "ultra quiet" power regulator that could be plugged inline for example.
  14. Catalina has some issues with USB it seems from reports too. When you connect the camera to USB can you see it in OSX? Hold down Alt when you have the apple menu open (menu from the top left) - "About this Mac" then becomes "System Information". Navigate to the USB part of the tree and you should see all the USB devices it recognises.
  15. The usb speed is usb 1.0 I believe so use a hub to stop the usb bus being pulled down to slow speeds. i have a 16 that I took my first stop images on, it then got used as a guider.
  16. Ejecting noise is done by reconstruction above but I also have a mechanism in the ObjectiveC code that looked for hot single pixels, placed them in a list then looked at the correlation with the psf - a single point is going to have a low correlation plus if the image hot pixel value is outside of the expected value deviation it simply smooths it (that's the noise removal from the first page).
  17. This is the octave code - it's pretty simple; % % Astro noise and deconvolution % Using the atmospheric turbulence convolution as a cyclic pattern to remove noise % NickK % apt-get install liboctave-dev <- required for signal % pkg install -forge control % pkg install -forge signal pkg load signal; pkg load image; pkg load fits; % create objects [mGuiderImage, guiderHeader] = read_fits_image("/media/deconvTestData/GuiderFITS/PHD_GuideStar_078_212009.fit",0); [mLongExposure, longExposureHeader] = read_fits_image("/media/deconvTestData/LongExposures/383L-jupiter00009175.fit",0); printf("guider image size is %ix%i\n", rows(mGuiderImage), columns(mGuiderImage)); % imshow(mLongExposure); hold on; mPsf = mGuiderImage; mesh(mPsf); % create correlated sub images % fft both images % cross product % inverse fft for result hw=hann(60); hannWindow = hw*hw'; fftLE = fft2(mLongExposure); fftInPSF = zeros(rows(mLongExposure),columns(mLongExposure)); fftInPSF(1:60,1:60) = mPsf(1:60,1:60).*hannWindow; fftPSF = fft2(fftInPSF); % in reality we don't need to use a full width DFT as the largest cycle length is the size of the PSF printf("fft completed\n"); printf(" long exposure image is %i x %i\n", columns(fftLE),rows(fftLE)); printf(" guider image is %i x %i\n", columns(fftPSF), rows(fftPSF)); AR = real(fftLE); AI = imag(fftLE); BR = real(fftPSF); BI = imag(fftPSF); re = AR.*BR + AI.*BI; im = AI.*BR - AR.*BI; magRe = sqrt( re.*re + im.*im ); den = magRe.*magRe + eps; correlationFFT= (re.*magRe ./ den) + j*(im.*magRe ./ den); correlation = ifft2(correlationFFT); correlationmap = sqrt( real(correlation).**2 + imag(correlation).**2 ); printf("correlation completed\n"); %imshow(correlationmap); hold on; %figure; % rescale 0 to 1 ----- min works on 1D arrays.. m = min(min(correlationmap)); rangexc = max(max(correlationmap))- m; xc = (correlationmap-m)./rangexc; % scale 0-1 to 16 bit xut16 = uint16(double(correlationmap.*(256*256))); % .*(255.0*255.0)); % imshow(out16); hold on; imwrite(xut16, "~/testOutCorrelationMap.png"); % printf(" min = %d range = %d\n", m, rangexc); printf(" xc size is %i x %i ", rows(xc), columns(xc)); %imshow(image(xc)); hold on; %figure; % bar(xc); hold on; % figure; % find is 2D, so we get a number of results [fRows, fCols] = find(real(xc) >0.9 ); % find returns index positions >90% signal stacked = zeros(60,60); printf("- Number of spikes correlated %i\n", rows(fRows)); leCols = columns(mLongExposure)-60; leRows = rows(mLongExposure)-60; for row=1:rows(fRows), %printf(" spike at (%i, %i) = %f\n", fRows(row), fCols(row),xc(fRows(row),fCols(row))); if( (fCols(row)<leCols) && (fRows(row)<leRows) ) stacked += mLongExposure(fRows(row):fRows(row)+59,fCols(row):fCols(row)+59); endif; endfor; % rescale stacked to 0 to 1 stm = min(min(stacked)); strange = max(max(stacked))- stm; stackedRescaled = (stacked-stm)./strange; % or average % stackedRescaled = stacked ./ rows(fRows); % this keeps scaling inline with large image vs stretching mesh(stackedRescaled); hold on; figure; printf(" starting gather deconvolution\n"); SR = zeros(rows(fftLE), columns(fftLE)); SR(1:60,1:60) = stackedRescaled; res = fft2(SR) ./ fftLE; out = ifft2(res); output = sqrt( real(out).**2 + imag(out).**2 ); % rescale omin = min(min(output)); orange = max(max(output))- omin; outRS = (output-omin)./orange; % scale 0-1 to 16 bit out16 = uint16(double(outRS.*(256*256))); % .*(255.0*255.0)); % imshow(out16); hold on; imwrite(out16, "~/testOutFFTDecovolution.png"); printf("starting gather kernel deconvolution\n"); summed = zeros(rows(mLongExposure), columns(mLongExposure)); startTime = time(); for leC = 31 : columns(mLongExposure)-31, for leR = 31 : rows(mLongExposure)-31, weight = correlationmap(leR-30, leC-30); % use the correlation power to define scale (offset window) w = mLongExposure(leR-30:leR+29, leC-30:leC+29); e = stackedRescaled(1:60,1:60).*weight; r = w.*e; s = sum( r(:)); summed(leR-30:leR+29, leC-30:leC+29) = s; endfor; endfor; whos endTime = time(); fprintf("Gather complete, total time %d seconds.\n", endTime-startTime); imshow(summed); hold on; % rescale gmin = min(min(summed)); grange = max(max(summed))- gmin; gutRS = (summed-gmin)./grange; % scale 0-1 to 16 bit gut16 = uint16(double(gutRS.*(256*256))); % .*(255.0*255.0)); % imshow(out16); hold on; imwrite(gut16, "~/testOutGatherDecovolution.png"); The conj() expansion is because the code I have in ObjectiveC and fftw allows for mis-matched ffts to be processed, and I use a small window (the code has a for x,y loop around it), in Octave it seems fast enough just to vectorise in parts.
  18. I have a data set that contains a number of long exposures but I recorded all the 2 second guider images (60x60). The guider camera is noisy but the guider is an OTL through the same scope. The code uses the first guider star image just so I don't have to point one out for the Octave code but uses summed sub-image PSF from the long exposure. For the original ObjectiveC code the program takes all the guide star images during the long exposure and stacks them but I've one coded that up into a function todo that yet in Octave.
  19. Putting a 2D Hanning window gives this (at max curve adjustment), so gone are the hard edges to the PSF that cause ringing and multiple aliases:
  20. I that the CLEAN algorithm is, with the original image and psf “dirty”; For each highest psf match in the dirty image, reduce the value of the psf in the dirty image, plot the match using a clean Gaussian psf into the clean output image, repeat until stopping criteria met. It is a correlation and then use the correlation map to scale a Gaussian to a clean image. In reality the correlation output is the point output (ignoring error). This is essentially the reconstruction filter I’m performing - I can make a gaussian and demonstrate later tonight. I find parameterised psf works for accurate tracking but is less successful with amateur deconvolution where the initial deconvolution from real to a parameterised form (or complete one step) is better. For upsampling - a sinc function, FIR/IIR or simply use drizzling/super-resolution (I've done this in OpenCL before, along with Richardson Lucy).
  21. This is with averaged, still got some way to go (ignore the borders - it's so I don't have to fuss with the edge detection): Averaged means the stars are on the same scale as the image - 7 stars were used for the psf. Stretched becomes darker; Still - there's something I have wrong with this given there's cycles (echos) Got it - the weird boxes are because I use the weight of the correlation map to scale the psf sampling kernel. Also I think there's some coordinate errors going on, too late now but will have a look; fixed one and it makes a large different to the image contrast. The obvious tell tale is that the image has flipped.. The obvious thing is I can Hann window to offer soft psf limits which will help but this is the same issue I've seen from the ObjectiveC code that does the same. Time for an image processing is about 5 minutes which is not bad as it's running double precision.
  22. One of the issues with using FFT (now I remember!) is ringing; in this case this is a deconv using fft stretched (this may be due to the stetted psf so I'll check that): Deconvoluted image: Original image at same scale: Now to try the technique I've used previously - reconstruction using correlation.
  23. It sounds like “gather” by reconstructing taking each image pixel then summing each scaled psf multiplied by the respective existing image value. This is done across all the image. This is the approach I have used previously. However I will try a divide and see the results too.. i think going forward an idea I want to explore is probability. The idea is to reclaim signal in the faint background noise.
  24. Certainly does work nicely in 2D for real images
  25. I could use a simple gaussian psf, however I've had batter results in the past using the stars themselves. I've also used LR (earlier in the thread I've used LR on GPUs) also implemented FIR/IIR on GPU for deconvolution. Also you can use a microsope 3D approach with the PSF to find the best point of matching - essentially finding the match for the slopes around a saturated star.
×
×
  • 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.