angryowl

It’s been a while since I’ve posted on here, so here goes.

I’m currently using a RASA 11” with the Baader F2 HighSpeed filters (which I believe to have a FWHM of 10nm) and while they’re fine, I am based in Bortle 8 skies and have found that they pass just too much of the light pollution as well. This means I need rather high integration times to reach an acceptable SNR and even then, with so much LP the integrated masters are usually low in contrast.

In doing research for a new set of narrower filters, I’ve discovered that finding filters with a small enough FWHM and a high enough transmissivity is difficult for such fast f ratios due to the centre wavelength shift at those extreme angles. While I believe most of the standard filters with a bandpass between 3 and 6nm for instance would produce an image, from my research I’ve come to believe that the signal loss caused by CWS at the steepest light rays would effectively mean one was no longer taking advantage of the telescope’s full aperture and would now operate at a higher focal ratio.

I’ve narrowed it down to Chroma’s 8nm and Astronomik’s MaxFR 6nm filters. I spoke to Chroma and they’ve been very helpful and even sent me spectra graphs of their 3, 5 and 8nm filters at the 12.5-degree incidence angle for the RASA. The 3 and 5nm filters definitely suffer considerable transmissivity loss but the 8nm filter doesn’t look too bad. After seeing the graphs, I was seriously considering buying an 8nm Chroma filter to try out but then I found Astronomik’s new MaxFR range which are specifically designed for very fast optics.

On the Astronomik website they claim their 6nm filter has a guaranteed transmissivity of about 90% at F2 and the 12nm one about 85% at F1.4. After speaking with them they confirmed that the filters are preshifted and backed up the transmissivity claims.

The thing is I’ve only found about two people using the 12nm MaxFR filters but no reports or comparisons to other filters. However, I haven’t found anything on the 6nm ones.

So on to my question, is anyone out there using the 6nm filters? How are you finding them, any issues? I’m not too concerned about reflections but rather performance differences in terms of SNR when compared to other filters such as the Baaders on fast scopes.

I’m really tempted to just buy one and drop it in my filterwheel next to the Baader one and compare them during a session, but given their current price I’d like to hear from anyone that is using them before doing that.

Any input is greatly appreciated as always

12 hours ago, MarkAR said:

Could be the filter, it may be susceptible to halos at just that specific wavelength the star emits.

I got one that doubles in size with Sii filter, all other stars stay the same.

Thanks for the reply Mark

I must admit I hadn’t thought of that but now that you mention it, it makes sense. I know I read somewhere that NB filters nowadays use several coatings sometimes more than ten per filter and the idea that one or multiple of these coatings are reacting differently to light emitted from this particular star is indeed interesting.

Learn something new everyday...

Hi all,

Whilst capturing data over the last clear nights on my latest object, NGC 7822, I noticed a star with an odd profile in the OIII subs but put that down to cosmic rays or some other weird artefact. But after my usual preprocessing, I’m still seeing this strange star in all of the OIII subs and much clearer in the stacked image.

The OIII data is a stack of 54 300s subs making for a total of 4.5 hours and similar integration times for Ha and SII. What’s strange is that this only shows up in the OIII data and not the other channels. As can be seen, Ha and SII look completely normal.

At this point I’m trying to understand what might cause this behaviour only in one channel. I have thought about things such as collimation, tilt, debris on the corrector plate, tracking/guiding errors, dew, shooting through branches and filter reflections. However, none of these fit as the star in question is roughly in the center of the FOV and there are other stars around it similar in size and brightness (judging from the other two channels) which logically should show the effects as well.

These were captured using a Mesu 200, RASA 11”, Atik 414EX and Baader F2 High Speed filters. The subs were dithered and 2X Drizzle integration was used. I also rotate my exposures through the filters every imaging session. No other processing done apart from the usual preprocessing steps and an STF curve.

Having a look at the Simbad, 2MASS, Gaia DR2 catalogues reveals the star has designation [D75] 7p (Simbad) and is close in magnitude to the star at the bottom of the images.

http://simbad.u-strasbg.fr/simbad/sim-basic?Ident=[D75]+7p&submit=SIMBAD+search

Can anyone shed some light on what might be happening here? Is this an artefact due to some component in my imaging train or something that I’m missing entirely?

As this doesn’t show in any of my other stars in this image, or any other image I’ve taken with this setup before, I’m not concerned about this being an issue with my equipment at this point. I’d simply like to find out what might have caused this out of pure curiosity.

Just thought I'd add my recent experience with debayering an ICX453AQ sensor for those interested.

The sensor in question came from a Nikon D50 which was listed as "taking black pictures" and while I hoped it was a shutter failure, it turned out it was two of the very fine golden wires inside the sensor that had come off the sensor array. While this meant the sensor was beyond repair I thought I'd open it up and have a go at debayering it since I've heard Nikon sensors are supposedly easier to tackle.

The top glass came off easily after a quick blast with a hot air gun. For debayering, I've used toothpicks to gently scrape away at the surface until both the CFA and lenses were removed. Upon close inspection, the toothpicks did not seem to scratch the underlying surface at all. But I was impressed at the sheer ease at which the CFA came off with the lightest of pressure on the sensor.

Sadly, I threw away the sensor and have no images of the final result and obviously testing the sensor after debayering would have not been possible, but just wanted to add my experience to this massive thread. 

I have also previously successfully debayered a Canon 20D sensor using this exact method, but was a lot more involved which resulted in many leftover scratches.

A bit late to the party but I too have been interested for quite a while in debayering DSLR sensors.

I had a go at a Canon 350D sensor first which ended up in a complete disaster but that was a few quid off Ebay so didn't really break the bank.

Mt second attempt was with a Canon 20D sensor and was completely successful! Went scraping carefully with a toothpick and got all of the CFA and lenses off and somehow managed not to touch or damage any of the small wires at the edges of the sensor. Glued the glass piece back on with epoxy and all looked well.

Tried it back on the camera and of course there were some scratches and other debris left on the sensor but those can de easily removed via a flat frame.

https://imgur.com/a/C4hMw

Third image is a pure flat showing the scratches and imperfections
Fourth image is a light sub exposure in which the scratches are still visible with no flats applied
Fifth image is a proper integrated and calibrated image made up of 21 lights and 13 flats. As can be seen after calibration and integration all of the scratches and imperfections have been completely removed leaving a great looking monochrome image. These were processed in Pixinsight

Read somewhere that the 20D has an estimated 30% QE which isn't too bad, but I sort of abandoned the project and I've had the sensor for about a year and now deciding whether or not to buy a cheap 20D off Ebay, replace the sensor and actually make some use of it. Only problem is the dimensions of the 20D are huge and considering my RASA scope, the camera body would take up quite a bit of space. Then of course there's the noise in the sensor, meaning another DIY TEC cooling project for which I don't have the time for.

A bit late to the party but here goes...

My first ever astrophotography image of Pleiades was with a FinePix S5700 7.1 MP camera using the full 10x optical zoom on it, 800ISO, F3.5. 22 images in total, each of 4 seconds done on a tripod stacked in DSS and no further processing done on it. So plenty of field rotation there... Taken on the 7th of November 2015.

I know, laughable compared to the stunning ones seen here but still take a bit of pride in it and shall be keeping it as a memory.

So you manged to get the IRLZ44N Mosfets working directly from the 3.3V logic? If so, that's great as less components are always more desirable in a circuit...

As to what the issue might be, still can't really understand why an unmodified HAT that's designed and tested to work with the RPi could burn through two devices as it so clearly did. Plus you checked the HAT for solder whiskers so it's not like it could be down to a short somewhere on the board. Weird...

So you have separate voltage inputs for the HAT and RPi, and the HAT does not then output voltage via any of its pins to drive the RPi directly. Trying to understand how the HAT works and that you're not powering the RPi through two sources. 

Regarding the dew heater circuit, mine is a bit different/simpler as I can run the N03G N-Channel Mosfet straight off an Arduino digital pin outputting 5V, thus only needing one 10K resistor on the gate. I've the same circuits for the two fans just with the addition of a diode in parallel across the fan inputs. Looks to me like your dew heater circuit shouldn't be the problem?

42 minutes ago, Gina said:

Please see my ASC Blog for all my test results.  I'm stumped!

Went through the blog and if I understand correctly you have the buck converter run off 13.8V then the 5V output of that goes into the HAT which then powers up the RPi as well. I'm not very familiar with RPi HAT modules, but could you not just split the output from the buck converter with one going to the HAT and another to the RPi? Would that not circumvent the HAT from the RPis point of view? Of course you'd have to find a way of stopping the HAT from transmitting power to the RPi...

I had a similar problem with my strip board when testing it. I destroyed a DHT22 sensor in the process and had numerous issues with connections, solder points and things just not working as they should. Ended up spending a lot of time going each and every connection and component then testing things separately. At one point I was considering re soldering everything on a proper printed PCB board but I'm now glad I persevered and it paid off!

Looking at the Mega pinout I don't see pins 3, 4, 5 as being SPI pins but I may be wrong. I did however just tested the chip again with the following pins and changed the sketch to match and worked fine.

Arduino D10 - SS

Arduino D11 - SCK

Arduino D12 -  MOSI

The link to the video, ignore the beginning of it. The range begins from 11 seconds into the video.

22 hours ago, Gina said:

I can see why I think   Wrong baud rate

I would change the Baud rate on the Serial Monitor to match the sketch one rather than the other way around.

22 hours ago, Gina said:

Testing...  Have Arduino Nano connected to Win 7 laptop and displaying Serial Monitor but just getting a high speed run of strange characters which I don't think is right

This may be the issue as I get the same output when setting the Baud rate to 9600 instead of 115200 as in the sketch!

Gina, I'm sorry to hear you're having issues with the chip. I re-tested mine this morning with the same wiring as before and works perfectly fine. This is where I got the code and the diagram from. Wiring the chip exactly as illustrated in the diagram on the site works for me. Make sure your Baud rate is the same on the Serial Monitor as it is on the sketch. I am testing with an Arduino Mega, but another thing you could try is adding a pullup resistor as mentioned here.

I never received an output of -1 so don't know what could be causing that. Another possibility is that Mouser may not have shipped the SPI version? On my order it says MLX90316EDC-BDG-100-SP, maybe worth checking.

This is how I have mine setup on the breadboard

I'm also in the process of uploading a video showing the range of motion from 0 to 360 degrees via Serial Monitor.

8 minutes ago, Gina said:

The same board with links removed still won't let me upload a sketch.  On Win 7 with all the same settings.

Okay so the CH340 works so there's not much point in reinstalling the driver for it or changing the IDE version I think. I'm thinking there's something wrong with the Atmega chip or an issue between the Atmega and CH340 as it does not seem to be responding to the USB to serial converter.

To me sounds like it's a corrupted boot loader although I can't imagine how it would have gotten that way. Another possibility would be a fried Atmega chip. Problem is to re-burn a boot loader I think you need a working Arduino...

Another thing you could try is keeping the reset button pressed for a few seconds just before an upload and see if that works?

I may however be totally wrong and it could just be something simple and easily fixable as you get the same behaviour from three boards. 

Yeah, I would try Win7. Maybe reinstall the CH340 serial driver, if that doesn't do it perhaps you could try upgrading or downgrading the IDE version on the Win7 machine. Another possibility would be that the boot loader somehow got corrupted but on all boards seems very unlikely.

3 minutes ago, Gina said:

No.  Just the red LED on continuously.

But when connecting the Nano to the PC it was identified as a COM port, right? The loopback test only tests the USB serial converter on the Arduino and not the Atmega. Is the Nano a CH340G clone or has it got the FTDI chip? If you haven't already I would completely remove the serial driver from the PC and re-installing it. It's strange that this is happening on multiple boards on multiple computers!

6 minutes ago, Gina said:

I linked RST to GND and TX to RX on a new Nano but the loopback didn't work.

Whilst you were typing was the RX LED echoing your keystrokes?

1 minute ago, Gina said:

If your setup works with just MISO connected mine should too

Yes it should, provided you have the SPI version 

5 minutes ago, Gina said:

Do you have the MOSI & MISO mixed up?  MOSI goes through the FET in the diagram.  I'm confused still

Yes, my apologies, meant only MISO need be used and leave MOSI out.

Alternatively, if you can't read the sensor after having wired it as in the above diagram you could give this a go. This uses both MOSI and MISO and replaces the FET with a transistor but requires a bit more coding to get it running. I can't guarantee this works as I haven't tried it but if you've no luck using the first diagram it might be worth a shot.

In SPI mode you don't need the MISO connection through the FET and R2 as shown in this diagram from the datasheet. Only MOSI is needed as a direct connection to a digital pin and of course the SCK and SS to have their own separate digital pins on the Arduino. So you can wire it as illustrated in the below diagram with the exception of the MISO connection and associated external components. HTH

I would try doing a loopback test as the next troubleshooting step.

https://forum.arduino.cc/index.php?topic=73748.0

I second tekydave's suggestions, also might not apply here but have seen this behaviour when there are connections to the RX/TX pins. 

I had this exact same issue with my Uno a few weeks back and turned out to be a bad USB cable.