angryowl

Thanks for replying Olly. You're absolutely right with regards to the Mesu's abilities and I’m sure my relatively ‘light’ scope poses no problem. Yeah, the brick wall test was more or less done to confirm something in the scope or the scope itself is flexing when sitting perfectly still. As you say, what is flexing or why it’s flexing so much still needs figuring out.

Thanks for the reply Fabio, unfortunately I don't have another scope at the moment as that would indeed have helped in eliminate the mount as the source of the issue. I might be able to borrow a C8 though so that may well be my next step in troubleshooting this. On my last imaging session, I tried using the 60mm guider as a standalone scope mounted to the Mesu with a improvised metal plate, but couldn’t get balancing right and the clouds rolled in.

I’ve been struggling with elongated stars for the past few months now and have tried numerous things and read through similar threads here and on other forums with no success. This is really starting to get to me as I’ve lost track of the number of clear nights wasted so far. The elongation direction is not consistent at all and varies over different parts of the sky. The kit: Mesu 200, Celestron RASA, 60mm StarGuider guidescope, QHY5L-II guidecam, Atik 414EX main imaging camera, Baader UFC, Baader F2 High Speed narrowband filters. Things tried so far: Tested for cable drag and recently started routing all cables coming off the scope at the back of the dovetail. Both RA and DEC balance is spot on. This was performed several times with a digital fishing scale and the balance points marked. I’ve always used SharpCap for PA but also tried several runs of PHD static and drift alignment with the same results. Read the entire SiTech Operations manual for the Mesu as at one point I was getting elongation mostly in Ra and though the mount may not be tracking at a correct sidereal rate. There’s a method of calculating the proper track rate and have spent a couple of imaging sessions doing this with limited success. The method involves measuring the drift of a star in Ra in an interval of 10 minutes. Then after some clever math, one can change the Ra motor ticks in the ServoConfig configuration for the mount. This worked, but only for the position in the sky where the drift was measured and as soon as the mount was pointed to another part of the sky, the issue would immediately reappear. What’s worse is that the same tracking rate would no longer give round stars on a different night in the same position in the sky it did for the night before. Short exposures of a minute or shorter in any position in the sky give perfectly round stars. This eliminates collimation, issues with the camera or any other optical element in the light path as I see it. Differential flexure between the main scope and the guide scope is a non-factor as I get elongation during unguided exposures. Tried tweaking the settings in PHD2 thinking I might be able to guide it out. Results, again, vary depending on the night and position the scope is in. Sometimes guiding would give almost acceptable stars and some improvement over unguided and other times it would simply make matters worse. Additionally, rotating the camera 90 degrees results in the direction of elongation being rotated as well. The camera is coupled to the front corrector plate via screw adapters which I simply can’t see flexing. The only time I can get round stars is with the scope pointing near the Zenith. I’m at a point now that the only thing making sense is flexure within the RASA or imaging train. I know the camera is tightly fixed to the corrector plate so there can’t be any play there. The only place where flexure could occur would be at the main RASA Losmandy mounting plate. The plate is screwed in to the front and back aluminium holders by four M5 screws I believe. Thought these might have loosened over time but after checking, they’re as tight as they’d go. Not sure how solid a RASA should be and I didn’t really test or look at this when I got the scope as there was no need, but when fully mounted, the scope can be easily rocked by applying light pressure to the top mounting plate. This is not an issue with the Mesu head as it’s simply rock solid and can’t move it at all regardless of the force applied. At this point it’s all pointing to the scope/mounting plate flexing due to gravity as the scope is not exactly light. This could explain the odd behaviour throughout different parts of the sky as the scope is flexing in different directions. Trying to determine if it is indeed the scope flexing, I’ve done some testing yesterday. Setup everything as usual during the day and focused on a brick wall roughly 30 meters away on a day with no wind. Mount was off and both axes were locked with the mount hooks, so mount tracking errors or movement would be eliminated this way. Started with 5 short consecutive exposures, then at 10 minute intervals another 5 exposures were taken until 40 minutes elapsed. Each set of 5 exposures were integrated in PI using an average combination with no normalisation or any pixel rejection algorithms. This was done with the scope on both the East and West side of the pier pointing at the same brick wall and with the mirror both locked and unlocked. Combining these integrated images into GIFs and plotting the Ra and Dec orientation clearly shows considerable drift over the course of 40 minutes. As can be seen the drift is not purely in Ra or Dec, but a combination of both. Mirror locked. Scope on East side of pier. Mirror unlocked. Scope on East side of pier. Mirror locked. Scope on West side of pier. Mirror unlocked. Scope on West side of pier. These next four GIFs show the result of pushing on the scope’s top mounting bar. The direction of movement when applying pressure on the scope is very similar to the direction of drift in the first two GIFs. If I’m not mistaken this would indicate that the RASA is indeed flexing/sagging due to gravity. The scope was purchased from FLO about two years ago. Would this be considered normal behaviour or am I just barking up the wrong tree here? Mirror locked. Scope on East side of pier. Before and after pressure applied on scope mounting bar. Mirror unlocked. Scope on East side of pier. Before and after pressure applied on scope mounting bar. Mirror locked. Scope on West side of pier. Before and after pressure applied on scope mounting bar. Mirror unlocked. Scope on West side of pier. Before and after pressure applied on scope mounting bar. I find it hard to believe that the image should drift this much over the course of 40 mins, but then again, I may be wrong and this isn’t out of the ordinary??? Any help with this from the awesome and knowledgeable SGL comunity would be greatly appreciated as I’m simply out of ideas and things to try.

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?

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.

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

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.

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.

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!

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

Yes it should, provided you have the SPI version

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.