Dome Position Sensor for BrewSpinDome

I am busy building a dome controller to replace the Foster Systems unit. I call it BrewSpinDome, an Arduino based controller with a more precise position sensor (2 to 3 times more precise). I use the existing Home sensor.

Mark I Position Sensor

In my first attempt, I used an IR reflective sensor from Adafruit. It has an infrared emitting LED and a phototransistor (photodiode?) to detect reflected light. The two pieces are tilted slightly; the presence of a dark or light spot in front of the sensor changes the output voltage.

The images below show the sensor wheel mounted below the dome rotation gear, with the sensor positioned to detect the dark and white zones. The mounting bracket allows positioning of the sensor precisely under the wheel. It turns out the sensor works best when it is roughly 5mm from the wheel.

Looking at the bottom of the dome gear, showing the sensor wheel. The IR position sensor is to the left, aligned to detect the white and black blocks.

Showing the gap between the sensor and the wheel.

The mounting bracket allows several rotations to position the sensor.A header shield is used as the cable connector.

An oscilloscope shows the sensor output as the blue line. The yellow trace shows the Arduino receiving interrupts when the sensor switches states.

This was working OK; I used this system to start debugging the software. However, I began to see problems; the dome was missing sensor ticks. It turns out the dome gear “wobbles” a bit as it turns. This moves the gear closer to the sensor, so the voltages are not sufficient to get the pulses shown above.

So, back to the drawing board.

Mark II Position Sensor

In this design, I have a toothed wheel under the dome gear. I obtained an IR LED / phototransistor pair from Radio Shack which are positioned so the toothed wheel breaks the beam as it rotates. Hopefully this will generate better pulses.

Plastic pail showing bottom cut off and transformed into the toothed wheel.

The toothed wheel was created by cutting the bottom of a plastic pail obtained from my standard parts warehouse (Dollar Store). The image shows the original pail on top of the bottom piece which was cut off. I used a Dremel to cut the teeth in the wheel, as well as a central hole and two cuts to facilitate placing the wheel around the axle of the dome gear.

Toothed wheel after cutting teeth with Dremel. The wheel is cut into two pieces to allow attachment around the Rotation motor shaft. 

I also modified the mounting bracket as shown to place the IR emitter/detector on either side of the teeth. The two LED holders may be adjusted to get the sensor aligned.

The new bracket. The sensor LEDs are glued into the holes at the upper right (you can see the leads of one LED at the upper right). The two LED holders may be moved laterally to position the sensor correctly between the teeth.

Schmitt Trigger

I also stumbled upon a device known as a Schmitt Trigger, or Schmitt Inverter. It takes my slow-changing pulses and changes them into sharper square pulses. Very nice! I will add this to my circuit. In the Mark I, I was getting multiple interrupts at each transition; I had to add software logic to ignore interrupts for 25-50 milliseconds after receiving one. Maybe this will eliminate that problem.

I can buy a Schmitt Trigger IC (74LS14) or implement the logic with a 555 Timer as shown in this circuit.

 

Another update to AstroMC

Hmm, in the day or so since I updated the Foster Systems software to 2.4-1 they released 2.5-1. So, I went ahead and updated to that one now. Firmware is not B9.

Sky Flat target ADU level

There seems to be a bit of minor quibbling over the desired target level for taking Sky flats.

• The PixInsight forum suggested a Target ADU = 40,000 somewhere.
• The Wodaski book uses a formula

ADU = FullWell / eGain * bin * %brightness
For 8300,
FullWell = 25,500   (spec)
eGain = 0.53  (from FITS header)
%Brightness = 0.3 – 0.5   assume 0.4  ===>    Gives Target ADU = 38000

• The sample ACP AutoFlatConfig file has a default value of 20000 +/- 4000

I had been using 38000 +/- 50000. I noticed that sometimes exposures were “overdone”, where the vignetting effect of the flat results in an “anti-vignetted” image. Dark in the center, lighter around the outsides. I think this is particularly happening with HAlpha shots, perhaps with shorter test shots. I tried making the HAlpha flats with lower targets (20000) thinking that the values were too high, causing too much offset in the image or something. However, I still noticed occasional anti-vignetting.

So, what is the effect of using different ADU targets?

• I created 3 different Master HAlpha flats with target levels of 20,000, 30K, and 40K target values. 25 frames of each, combined in Maxim DL6 using the SD Mask combination method.
• I took a single 10 minute test Halpha frame from an STF8300 with HAlpha filter.
• I calibrated the test frame with each of the 3 Halpha Flat masters. Each calibration used the same Dark and Bias frame masters; only the Flat masters were changed.

Conclusion

A big disappointment – it doesn’t seem to matter which Flat master I use! Visually the 3 calibrated frames look identical. No anti-vignetting, I can’t tell the difference between the frames. Pixel Math shows the resulting frames have the same values within +/-2 ADUs, which I assume is due to very slight variations in the Flat frames.

So, I guess I’ll go back to the 38000 range again. The odd frames must be due to some other effect. At least I don’t see the effect in regular images, just in short duration test shots. I think.

Update AstroMC, FocusMax

Updated AstroMC/B6 from 2.3.1 to 2.4.1/B8. I am hoping this will eliminate the recent spate of ACP disconnects because “dome is already slewing”. This began when I installed the replacement dome controller, which is the new format in the gray box. We’ll see.

Also updated FocusMax to 4.1.0.25. When I ran the new version it attached to Maxim (already running) and immediately clobbered the STF8300 USB port. Maxim did not see them in the camera list.

Tried repowering 8300, reseating USB cable, no luck. Finally rebooted Thor, and everything seems to work again.