Electroluminescent Flats

IMG_0622

I have been using Sky Flats in ACP for some time. They work well, but have a couple of procedural limitations:

  • I can’t always be in a position where I can kick them off at a reasonable time. I forget, then it is too late/dark to start them. I suppose I could a) start early in the day, but I don’t like the idea of the observatory sitting open all day, or b) play with the #waituntil command, although I don’t think it actually affects taking the flats.
  • There isn’t enough time to get all my filters in. I do 25 frames for each of 6 filters (R,G,B,Ha,Oiii,Sii). By the time it gets dark enough to begin taking the frames, there isn’t enough time to do all the filters. So, I have to manually edit the flat plan file for the flats I plan to use that night. Of course, I tend to mess that up, or later want to change my mind..

So, I would like to do panel flats. I have played around several times with a flat panel screen mounted on the dome. It works OK, but has problems: 1) the small dome means the panel is not perpendicular to the OTA, 2) I don’t have a way to adjust the light levels for the various filters. For example, the HAlpha filter needs a brighter light than the RGB. I have played quite a bit with different lamps illuminating the screen, but it has never worked well.

I recently ran across a post somewhere (This site is similar to the site I found) that talked about using an electroluminescent panel from Knema.com. I have looked at EL panels before, but they are pretty expensive. This panel was not as much, cost about $200.

To mount my panel I simply cut a hole in the cardboard shipping material. The cardboard folds nicely around the panel to protect it. Velcro strips hold the panel to the shelf.

IMG_0623I built a “shelf” to hold my panel. The shelf is adjustable so I can position it about an inch from the OTA, fairly perpendicular.The shelf swings back and forth on the long rod, and slides up and down.

 

 

 

The shelf angle is adjusted with the 1/2 inch PVC arm which slides up and down a wood rod which fits inside the pipe.IMG_0624

The shelf stays in position all the time; as the OTA swings around it does not hit the panel. When I take flats, the OTA swings into position. As it does, it misses the panel by about 1/4 inch. The back end of the scope (camera) also misses the panel.

The panel includes a little inverter box with a knob that varies the brightness of the panel. Originally I intended to replace the knob with a computer controlled potentiometer to adjust the intensity. However, it turns out that all the filters work when the intensity is all the way up. The only exception is the Luminous filter. If I want to do Luminous flats I need to manually turn the knob down to the minimum setting.

Note that HAlpha and Sii flats require long exposures (50-70 seconds). The panel is not white, but heavy in the blue and green spectrum.

In operation the panel power supply wall wart is plugged into my DigiLogger power supply. The ACP AutoFlatConfig file allows turning on the power when the flats are run and turning it off when done.

I can now run automatic flats anytime, except for Luminous which require me to manually adjust the panel intensity down.

Advertisements

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.

MarkIWheel

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.

MarkIGap

Showing the gap between the sensor and the wheel.

MarkIBracket

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.

ALLBUSY

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.

MarkIIPail

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.

MarkIIWheelB.JPG

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.

MarkIIBracket.JPG

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.

SchmittTrigger.jpg

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

 

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.

Shutter Fixed?

The continuing saga of the shutter controller…

In the process of testing capacitors on my controller, I somehow managed to plug power in backwards. Thought I had fried everything (Arduino Mega 2560, cc3000, and MonsterMoto shield). In the end, it turns out all that fried was the SWADJ3 voltage regulator.

So, I rebuilt the small PC board to account for a couple of changes:

  1. Added a couple of diodes to protect from idiots plugging in power backwards. The Arduino power branch has a regular N4001 diode; that path shouldn’t be seeing a lot of current. The other diode is a Power diode, handles 50A at 200V or something. Big thing, 3/4 inch square.
  2. Added headers to allow connection to SWADJ3, capacitor, switch input wires. This should allow changing things without having to unsolder wires.
  3. Added capability to add 2 capacitors after the voltage regulator, so I can play with trying to fix the original problem.

I also changed the controller logic to remove the ramping up of the PWM for the motors. I just apply full voltage to the motors.

The new schematic and wiring diagram are here:

Schematic. Dummy board used for MonsterMoto shield.

Schematic. Dummy board used for MonsterMoto shield.

Wiring layout

Wiring layout

The Problem (Review)

The problem I am chasing: when the shutter motors are activated the overall voltage in the system plummets drastically as shown in the data below. The upper shutter doesn’t drop quite as much. Opening the lower shutter is worse than the upper shutter, but is OK (system doesn’t seem to fail). However, closing the lower shutter drops the voltage the most. Sometimes, this drop causes the Arduino to reboot, so the shutter never moves.

Oddly, running the voltage directly into the controller does not lead to as large a voltage drop, so generally the shutter does not fail. However, running the power in through the contact junction causes a bigger voltage drop, leading to frequent failures. I don’t know why this is. I measured the resistance of the junction: 0.7 ohms through the red wire, 1.1 ohms through the black side.

Voltage drops measured after the SWADJ3 voltage regulator.

Voltage drops measured after the SWADJ3 voltage regulator.

Solution?

I tried a variety of capacitors before the regulator and after the regulator. As seen above, none of these seemed to help. In particular, running through the junction contacts causes a very large voltage drop.

In discussions on the SAC forum, it was suggested that my capacitors may be too old. OK, they are probably 30-40 years old… So I went to Radio Shack and picked up a couple of new ones. For power applied directly to the controller, the effect was dramatic! A small blip could be seen, but nothing like the previous situation.

Unfortunately, running power through the junction contacts is better, but still pretty severe. I am concerned that as the dome rotates the contacts may have better or worse contact, still leading to intermittent problems.

I cleaned the copper surfaces, and re-fastened one of the connecting cables to try and improve the connectivity. This helped a little bit. Now the voltage drop is not as severe – it is not going below 5 volts, at least.

Future Possibilities

I am hoping that these changes will allow the shutter to operate successfully. If the problem continues, the following options might be useful.

  1. Maybe I should adjust the SWADJ3 regulator to a higher voltage. I currently have it at 7.2 volts; perhaps if I run it up to 8.0 volts this will raise the dropped voltage the corresponding amount. This leads to more heat dissipated in the Arduino, but perhaps that is not a problem.
  2. Maybe I should experiment with moving the 470 uF capacitor back before the regulator. Forum members have suggested both cases, before and after the regulator. I don’t know why one or the other would be better.
  3. If I understood why the junction causes a problem, perhaps I could redesign it to fix it.

Thoughts on Junction Voltage Loss

The Arduino typically pulls less than 200 mA in normal mode – motors not running, checking for communications every second. In this mode, a 2 Ohm resistance in the junction would give a 0.4 volt drop. Thus, the input 12.8 Volts might be dropped to 12.4 V. This voltage would be constant, and the regulator would easily drop it to 7.2V for the Arduino.

However, when the motor kicks in it pulls perhaps 3-4 amps? 4 Amps would give an 8V drop, leaving only 4 V going into the regulator. It sounds like I need to redesign the junction with much less resistance…

Changes for the shutter

The shutter is still having trouble closing. Opening is always fine, but sometimes the close operation fails. The lower shutter gets power, but never moves. The Arduino goes into reboot mode, as though power was re-applied to it.

My theory is that firing up the motors maybe causes a momentary power surge / voltage drop, so the Arduino thinks power has been cycled. Perhaps the shutter in the closed position requires more power/torque from the motor to get started, due to the angle of the activator pulling the shutter closed.

Connecting power directly to the shutter (bypassing the “brush/ring” mechanism) works.

Things to try:

  • Perhaps the copper tape on the track, used to distribute power to the Arduino, is torn or worn. I replaced the tape in the park position area. The brush/tape system now has a resistance of around 5-10 ohms.
  • I notice that the shutter failure occurs when the park position does not place the dome in the exact correct spot. The Foster is often off by 6-12 inches when it parks the dome. In fact, I am seeing potential problem here – sometimes the position is 3 feet off! Oh, boy, another Foster problem to debug.

On the other hand, the home sensor is fairly accurate since it works by detecting the sensor magnet. It will be a couple of inches off depending on which direction the dome turned to find home, but it is consistent. So, I moved the home sensor so that home is in the same position as park. Foster version 3.2.3 has a checkbox that indicates Home is the same as park, but Parking does not use the magnet. It just goes to where it thinks the home sensor should be; this position can be off several inches.

Incidentally, the inaccurate positioning started happening with version 3.2.2. Updated software/firmware to 3.2.3, same problem.

I re-synced the telescope so the rotation is consistent with the new home sensor position.

  • I changed the Arduino code to ramp the pulse width modulation (PWM) from 512 (doesn’t move the motor) up to 1023 (full speed) in steps of 64 every 50 msec. I thought maybe this would help avoid the power drop. I can hear a slight change in the motors starting up.
  • If these things don’t work, my last idea is to install 2 large capacitors on the the Sparkfun MonsterMotor board. They leave spots on the board for these capacitors, but I can’t get any information from them on what they are for or how one would size them. Maybe these capacitors would avoid the power drop. If one even exists:)

Iris Nebula NGC 7023

Click to enlarge

Click to enlarge

Common Name: Iris Nebula
Formal Name: NGC 7023
Date: 6/23/2015
Constellation: Cepheus
Location: Casa Grande
Hardware: Takahashi Sky90 on Paramount, SBig ST2000XM Camera/Filter Wheel

unguided exposures

Temperature: -0C
Bin Mode: 1×1
Images: (x) x 15 minute Red exposures
(x) x 15 minute Green
(x) x 15 minute Blue
Total Time = x hours
Sky Flat fields 
Processing: This version uses only RGB exposures (Synthetic Lum by integrating RGB).
Reduced in Maxim, Aligned/Stacked/Processed in PixInsight
Notes: The Iris Nebula, also NGC 7023 and Caldwell 4, is a bright reflection nebula and Caldwell object in the constellation Cepheus. NGC 7023 is actually the cluster within the nebula, LBN 487, and the nebula is lit by a magnitude +7 star, SAO 19158. It shines at magnitude +6.8. It is located near the Mira-type variable star T Cephei, and near the bright magnitude +3.23 variable star Beta Cephei (Alphirk). It lies 1,300 light-years away and is six light-years across.. (Wikipedia)

PixInsight versus Maxim: Subframe Calibration Comparison

Introduction

While trying to process some images taken with my SBig STF-8300M in PixInsight I was encountering problems; PI would not
correctly read images from my SBig STF-8300M, either the original image collected by Maxim or the calibrated image. This seems to have to do with whether the images are saved in 16-bit signed or unsigned format; there is a lot of discussion in the PI forum about how this should be done, Maxim using non-standard FITS files, etc. In the end it appears the “fix” is to manually reformat all of the calibrated light subs in Maxim into 32 bit floating point format.

During the forum discussion people made statements like

      It’s a really bad idea to let maxim touch your files at all… the less maxim does, the better.
      Stop letting maxim calibrate images and do it all in PI. the results are superior anyway.
      Avoid MaximDL like the plague once it has captured the image.

Interesting. Until now, I have been happy with Maxim calibrating the images. It is easy, happens automatically under ACP/Maxim, and the only problems encountered were caused by Some Idiot using bad flat or dark subs. Googling around, I do not find any studies showing the relative performance of Maxim versus PI in the calibration of images. I don’t know the source of these statements indicating the superior performance of PI in calibration.

On the other hand, my earlier tests on image alignment showed that PI was superior to Maxim and Registar. Maybe PI has better performance in calibration? Would this offset the extra manual work required to prepare and calibrate the images for PI
calibration (compared to almost no effort in Maxim calibration)?

So, here goes my test. Does PixInsight calibrate light subs better than Maxim?

Test data

I assembled a test data set of bias, dark, flat, and light frames. I use the same frames for calibrating under both PI and Maxim.

  • 1 light frame (an OIII light sub, 30 minute exposure). This is the image to be calibrated. The camera is trying to get to -10C, but the ambient is high enough that the actual temperature is -4C. I just grabbed a sub from last night’s imaging run. Maxim calibrates using the original file. Since PI cannot open this file correctly, it uses a copy of the same file saved as 32 bit floating point.
  • 20 Dark frames at -10C, 30 minute subs each. Collected in Maxim.
  • 25 dusk sky flats with OIII filter collected in Maxim under ACP’s control. These flats are between -5 and -10 degrees C; at dusk the ambient temperature is still around 100 Fahrenheit so the camera can’t quite cool to -10C.
  • 40 Bias frames at -10C collected in Maxim.

In PI, I set the probe to display values in 16 bit integer mode. Hopefully this allows comparison of “ADU” units with the
corresponding Maxim values.

The Maxim calibration involved using “Set Calibration” to load the various calibration individual subs into Maxim and clicking
the button that creates Masters for the groups of files (Bias, Dark, and Flat). I then opened the raw file and clicked “Calibrate”.

Maxim Calibration results showing the nebula (upper left) and the 3 master files. Click for full size.

Maxim Calibration results showing the nebula (upper left) and the 3 master files. Click for full size.

In the fight to get PI to calibrate the images, I tried several different cases as listed below. The various cases are variations on using floating point versions of the various calibration files for PI.

Note that only Case 4 adequately calibrated the images.

Case 1 – All files float

+ all files (bias, dark, flat, light) are exported in floating format from Maxim
+ FITS configured to rescale with 0-65535

FITS file config used to access floating point files.

FITS file config used to access floating point files.

Result: the PI conversion runs, but is not correct.

All individual subs (light, dark, flat, bias) exported from Maxim as 32 bit float. PI builds its own masters. Click to enlarge.

All individual subs (light, dark, flat, bias) exported from Maxim as 32 bit float. PI builds its own masters. Click for full size.

  • Calibrated image is too dark, zeros in background, no nebulosity.
  • flat is wrong; it looks a lot like the bias.
  • values in the PI created calibration master files are different from Maxim.
  • Bias ranges 40000..15000..40000 across frame.
    Maxim => 19500..1900..1950
  • Flat ranges 0..6000..0 across frame
    Maxim => 15500..18000..15500
  • Dark values around 1000 across frame
    Maxim => around 300 across frame

Case 2 – Fits configuration at 32767

This was the same as Case 1, except that the FITS configuration is set to 0..32767 instead of 65535. This was tried in an attempt to address image values being off by a factor of 2.

Result: PI Conversion fails to run.

After PI calibrates the individual flats the integration process tries to stack the flats to make the master. This process fails because one of the calibrated flats is “open in another process” and cannot be opened. On different runs, it will be a different file that is open in another process.

Case 3 – Use Maxim calibration masters

It turns out the Maxim calibration masters are already in float format. This case uses those masters directly PI, rather than converting the individual subs to float for PI to create its own masters.

FITS is configured as 65535 again (for the light frame).

  • Result: Calibration runs, but it looks like the flats are not correctly applied.
  • Dust motes are visible.
  • Darker center of image. Looks like flats are too strong?
  • Values (flat, dark, bias) of the masters when opened in PI match those reported by Maxim.

Case 4 – Use original individual 16 bit Maxim calibration files

Another weirdness – it turns out the individual calibration subs created by Maxim are readable by PI, even though they are in the same 16-bit format which doesn’t work for the light frames. For unknown reasons the calibration files can be read.

So, in this case allow PI to use the original Maxim individual subs to build it’s masters. The only thing different between PI and Maxim processing in this case is PI starts with the float version of the light sub.

+ Calibration files (bias, dark, flat) are left in “16 bit” state as created by Maxim. No conversion performed.
+ Light file is exported in 32 bit float format. Can tell this is necessary because PI does not open this 16 bit file correctly.
+ FITS configured to rescale with 0..65536

Result: As seen below, the calibration looks pretty good, very similar to the Maxim result.

PI calibration using Maxim individual calibration subs directly to create its own masters.

PI calibration using Maxim individual calibration subs directly to create its own masters. Click for full size.

  • Dark master displays around 2000 “ADU”, versus Maxim’s 300.
  • Bias master is slightly lower than Maxim: 1870..1800..1870
  • Flat master is similar to Maxim, 15800..18000..15800
  • Bias has much larger values than dark. I don’t understand this. However, the same thing is true in Maxim, so OK.

Comparison of PI versus Maxim calibrated light sub

So, how does the case 4 calibration of the light frame differ between the Maxim process and the PI process? The image below shows the two images, where the left image is the PI result and the right image is the Maxim result (converted to float).

PI and Maxim calibration results. Click to enlarge.

PI (left) and Maxim (right) calibration results. Click for full size.

Visual results:

  • The Maxim file is smaller, 2Mb versus 8Mb for Float form. The PI result is also an 8 Mb xisf file. I don’t know how Maxim got the file down to 2Mb, maybe that is a clue why PI can’t open it?
  • PI result has more hot pixels.
  • PI result has more noise (much grainier to my eye).
  • Stars look the same (roundness, brightness) even when zoomed in significantly.
  • Maxim result may have more dark pixels; a little hard to tell because of the increased noise in the PI image.

Tool Measurements

I used several PI tools to measure the noise and SNR for the converted images. Measurements for the Maxim result used the Maxim calibrated image converted to 32 bit float.

Statistics tool results:

Maxim K    PI K
count (%)   99.75290    99.95980
count (px)  2116573    2120963
mean        0.0072616    0.0075407
median      0.0071210    0.0072508
stdDev      0.0068079    0.0073814
avgDev      0.0011528    0.0013096
MAD         0.0009753    0.0009751
minimum     0.0000006    0.0000476
maximum     0.9739980    0.9766412

  • PI has more pixels?
  • PI has slightly higher background (median)
  • PI has larger deviations

Noise comparison script:

The NoiseEvaluation tool was used after performing a linear fit on the PI image to match it to the Maxim result.

PI    = 8.6e-4
Maxim = 9.34e-4

  • Maxim has slightly more noise? This does not jive with what I see visually.

SNR Calculation:

Calculated the SNR ratio as SNR ratio = MAD / Noise
PI = 1.13   Maxim = 1.044

  • Again, the PI result seems to have a slightly better SNR ratio by 0.09, although visually I wouldn’t have thought so.

ContrastBackgroundNoiseRatio tool:

Parameters: Background percentile 100th  cycle-spins 8
Maxim    PI
Median        466.48    475.15
Contrast        61.31    68.67
Background Mean    466.41    481.45
Background Noise    66.63    77.95
CBNR        0.92    0.88

  • This tool indicates the Maxim result has a better contrast (0.92 vs 0.88) and less noise (66.63 vs 77.95).

Conclusions:

Visually it seems clear the Maxim result is better. The various PI tools indicate that the two calibrations are fairly close; some tools indicate the Maxim image is better, some indicate the PI image is better. One might suspect I am not running the tools in the correct way:)

Case 5 – Case 4 plus Superbias and optimized dark frames

I turned on the optimize dark frames parameter (0.004) in the Darks frame screen. I also created 2 Superbias frames, one based on the Case 1 Bias master (from float format bias frames) and one based on the Case 4 bias master (based on master created from original Maxim bias subs).

Adding Superbias and dark frame optimization. Click to enlarge.

Adding Superbias and dark frame optimization. Click for full size.

This did not work. The background is over-reduced (lots of zero values). Somehow the superbias is not working correctly. Both superbias files had the same result.

I also tried only setting the Optimize Darks parameter = 0.004. This is the only difference between this frame and the Case4 result. It is fairly indistinguishable from the Case4 result; optimizing the darks didn’t seem to help any.

Thus, it seems that

  • the superbias makes things worse, and
  • optimizing dark frames does not help appreciably.

Final Conclusions

  1. The Maxim calibration appears to be at least as good as the PI calibration; I think it is better.
  2. There may be further fine tuning possible in PI to improve the results.
  3. Using PI for calibration requires a lot of manual operations compared to the almost automatic operation of Maxim. I see no reason to change to PI for calibration.

Accessing my internal system using brew.my-sky.com

ACP provides a neat feature where you can get a no-ip address which allows you to access your observatory using a unique name (mine is brew.my-sky.com).

I have the problem of not being able to access my observatory using my-sky.com from within my home network. Access works fine from outside the home, but within your LAN you have to address the observatory as 192.168.x.x. This leads to awkward coding of web pages/twiddlers, bookmarks that don’t always work, etc.

Solutions
1) Supposedly, buying a fancier router that supports NAT loopback can resolve this issue. I was preparing to do this; the model I was looking at costs about $130. I did not test this out since solution 2 worked.

2) Change the etc/hosts file on your home computer. This file resolves name addresses before the system goes out to the Internet for DNS resolution.

In my case, the observatory computer 192.168.1.10 hosts the ACP server. My home computer is where I mostly work from. I want my twiddlers, and my blog entries, to use brew.my-sky.com to access a couple of web pages I have created. These do things like show current weather, forecasts, and operate the power controller in the observatory.

The hosts file is located in c:\Windows\system32\drivers\etc. I added the line
<code>
192.168.1.10 brew.my-sky.com
</code>
There should be no leading spaces. A single space or tab separates the IP address and the name.

Caveats:
1) When you edit the hosts file, Windows will not let you save it back in the etc directory. Save it into your Documents directory, remove the .txt extension Notepad insists on adding, then COPY (don’t move) the file to etc.

2) In theory the system immediately starts using the new hosts file. To make sure, use a cmd.exe window and enter “ipconfig /flushdns” to clear the cached entries.

3) test by pinging your domain name.    “ping brew.my-sky.com”
a) If the host file is not active, you will see your remote IP address (like 75.67.23.110).
b) If it works, you will see the local address 192.168.1.10.

4) You may need to restart your browser? I did not need to, but several net posts indicated this was necessary. Firefox in particular may cache DNS entries.

5) One system continued to have problems (a laptop with Windows 8.1). I found that I needed to add permissions for Users to the hosts file (Properties/Security on file hosts). It would only let me add a particular setting, but that worked fine.