Planning Astro-Photography Sessions

After weeks and weeks of clouds, I do have some clear nights in the forecast – time to do some planning and also explaining how the planning is done.

Weather

Weather is an important part of the planning – no need to plan if there is nothing to see. There are two great web sites that can help with a sneak preview of what is to come for your local place. The first one is clearoutside.com. Simply enter your home location and enjoy the forecast.

“My Forecast” at clearoutside.com – expand the individual days to learn more about the actual conditions.

The second one is windy.com – you need to tweak the settings a bit (see the bar at the lower edge of the screenshot) but this is my “backup” weather forecast, just to get a different opinion.

The temperature chart and forecast at windy.com.

Observation Planning

The next step is observation planning – to know up front what you will be after means less time during the observation window wasted on deciding on targets, etc.

I am using a software called KStars – but that is really only because I also run KStars/Indi to control my telescope and observation sessions. Any planetarium software will do, preferably one that allows eyepiece and camera-Field of View (FoV) simulation.

The first decision is which equipment to use – I got a choice of running a ZWO ASI 533 with a Nikon Lens of my choice (35mm. 50mm, 105mm, 300mm) or the ZWO ASI 533 with a Skywatcher 72ED Refractor. The latter is equipped with a ZWO EAF Motorfocus and a Skywatcher 0.85x Flattener, giving it an effective focal length of 357 mm.

With this data, KStars is simulating the FoV and I just need to set the time for the observation window. I am looking at three “time boxes”: one that starts as early as it is astronomically dark (which mid of February here is 19:30 hrs. local time), one that is 4h plus (23:30 hrs.) and one that is “early morning”, maybe 02:00 hrs.

KStars for the 19:30 hrs. Observation Time, February 10, 2021

My KStars already has a bunch of photo targets marked, at this time, Orion will be high in the southern sector so that is a perfect target. Orion is rich on interesting objects, but I think, I will go after two of them with 4h of data each (I got more than one night, so it will be 2h for the following for the first two nights: M42 (the “Orion Nebula”) and IC434 (the “Horsehead Nebula”).

A rough framing in KStars shows: both targets are fitting the FoV of Camera/Scope nicely.

KStars with the FoV for the Skywatcher 72ED with the Reducer and the ZWO ASI 533 Camera

A much better planning comes with CCDGuide (available at www.ccdguide.com) which is provided by the Astronomischer Arbeitskreis Salzkammergut in Austria for a small price.

CCDGuide allows for two important things: a FoV Calculation with a reference image and calculation of the image center and a look into images provided with the software incl. their image data.

CCDGuide 2021 with the Orion Nebula FoV Image

There are round about 30 images of M42 included with the current release of CCDGuide and I have added my own one to the user database.

Being able to keep track of images, equipment, filters, exposure times, etc. helps tremendously

Being able to keep track of images you have taken yourself and those that others have taken, to compare the exposure times, focal lengths, filters used, etc. is a tremendous help in planning your own sessions.

As the night continues, Orion will move westward and sooner or later it will vanish behind some trees in my garden. I am not even sure I can get the 4 hours between 19:30 and 23:30 but I have a next target: NGC 3189 and a group of galaxies near the head of the Lion.

Again, CCDGuide will help to determine if the target isn’t too small for my focal length… the group of galaxies is actually a target for telescopes with twice and more my focal length, but this is what CCDGuide “predicts”:

An annotated “Field-of-View” for NGC 3189 – I can now decide if it is worth it or not…

This is a good target to spend about 30-60 minutes on at first, just to see if I am capturing enough information to make it worthwhile… I can later add more time, if the verdict is positive.

The last image that I am planning for uses a faint galaxy by the name of IC 3393 as the center. This covers parts of the constellation Virgo and the southern edge of Coma Berenices. This area of the sky is “full of galaxies” and what I am after is referred to as Markarian’s Chain.

Field-of-View for Markarian’s Chain – although the individual galaxies are not showing to big, the wide field serves the full stretch of the chain well.
Posted in Allgemein | Leave a comment

Arduino & BME/BMP280 Environmental Sensor

For a bunch of projects, I am envisioning the use of the BME/BMP280 Environmental Sensor. After having received a bunch from AZ Delivery, I hooked them up to an Arduino Nano – and failed. So just to make sure that the sensor and the code are actually working, I switched over to an Arduino Uno board.

Wiring up the AZ Delivery BME/BMP280 to an Arduino Uno.

I decided to use the lower 3.3V power supply, wired this one up and connected GND. The unit is addressed via the I2C-Bus, consequently, the other two wires for SCL and SDA are going to their respective counterparts on the Arduino Uno.

Coding the Sensor

I actually did not expect much issues accessing the sensor through the code – but the battle was a bit harder than anticipated: the sensor was not identified at first.

Using the two libraries Adafruit Sensor (Version 1.1.4) and Adafruit BME280 Library (Version 2.1.2), the initial code is as follows:

#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>

The sensor is then defined as

Adafruit_BME280 bme;

It was expected that the only thing that was required now would be to initialize the BME280:

bool status = bme.begin();

But apparently, that was a bit too naive – there was no response from the sensor at all. After a bit of searching and trial & error, it turns out that the circuit board has three solder jumpers next to the chip and they are responsible for defining the I2C Address of the sensor.

Almost all libraries are assuming 0x77 as the default address but the solder jumpers – at least on this circuit board – are set to 0x76.

The BME/BMP280 Breakout Board with the three Solder Jumpers and the jumper closed between the upper two, giving it 0x76 as address!

Which means the only thing that really needed to change (in my case) was the following correction to the last line of code:

bool status = bme.begin(0x76);

With this, the sensor initialized and started providing values immediately. Just three calls are required to read the data – temperature, pressure, and humidity.

void loop() {
  
  Serial.print("Temperature = ");
  Serial.print(bme.readTemperature());
  Serial.println(" *C");

  Serial.print("Pressure = ");

  float fPressure = (bme.readPressure() / 100.0F);

  Serial.print(fPressure);
  Serial.println(" hPa");

  float compensation = bme.seaLevelForAltitude(658.0,fPressure);
  Serial.print("Adjusted Pressure = ");
  Serial.println(compensation);

  Serial.print("Humidity = ");
  Serial.println(bme.readHumidity());
  Serial.println();

  delay(10000);

}

The seaLevelForAltiude compensation is required to convert the air pressure appropriately, taking the sensors actual height into consideration. At some later point in time, I hope to combine the BME280 with a GPS Sensor and provide the value automatically. For the moment, the 658m of my home location are hard-coded into the sketch.

…and back to the Arduino Nano V3.0

After I was sure the sensor was working, I wanted to see why I had failed to do the same on the Arduino Nano V3.0 – so I exchanged the Arduino Uno for the Arduino Nano again.

Wiring up the BME280 Sensor to the Arduino Nano V3.0

Long story short (and for all those that don’t know: the I2C Pins on the Nano V3.0 are A4 (SDA) and A5 (SCL) and I have no clue why it did not work before… now, it simply compiled and worked…

CoolTerm connected to the Arduino Nano and displaying the sensor values.
Posted in Arduino | Tagged , , | Leave a comment

Skywatcher Evostar 72ED & ZWO EAF

Ever since I started taking images of the nightly skies, one of my biggest issues was “focus”. Not the focus on the topic itself but literally getting the stars into perfect focus. One of the difficulties was buried in my setup: I am using a Raspberry Pi and I am doing a remote desktop session to control it – unfortunately, setting focus manually also means that there is a significant delay of the image from the ZWO ASI Camera to the Raspberry to the Cell Phone running Teamviewer…

The software I am using on the Raspberry, StellarmateOS, supports an auto-focus feature with a motorized focuser and although I initially planned “to build my own”, I eventually succumbed to simply buying the ZWO EAF (Electronic Automatic Focuser). Here are the images of mounting the device to my Skywatcher Evostar 72ED telescope.

Step 1: Make sure your scope is secure!

You want to make sure that your scope and all your other equipment is secure and cannot be damaged or dropped during the installation. The best possible way: put the scope on a table in front of you and remove any attached equipment. It may rest in its mounting plate, but you want to turn it upside down to see the underside of the manual focuser.

Step 2: Remove the Manual Focus Unit

This might sound a bit awkward at first but trust me, this us nothing more than four screws and a basic mechanical disassembly/assembly.

It is worth paying attention to the use of the screws: the four red ones are the mounting screws that are fixing the unit to the telescope. The blue ones are the actual “fix focus” screw and a blind screw (no use). The three green ones control the pressure used to press the axle against the focus unit, the center one is pressure, the left and right ones are balance.

To remove the unit, unscrew the four red ones and carefully lift the unit from the scope. There are four rubber rings below the red screws, make sure they are staying in place on the telescope!

You are now holding the Manual Focus Unit and you can see just how simple the mechanism really is: the axle is pressed to the underside of the moving tube any by rotating it, it “rolls” the tube in and out.

If you turn the unit 90°, you can also see how the pressure of the axle against the moving tube is controlled.

See? A very simple mechanism (but as long as it works…) – keeps Skywatcher’s prices lower than a more complex mechanism here. But back to the installation of the ZWO EAF unit.

Step 3: Remove the single-speed Focus Knob

In order to attach the ZWO EAF to the Manual Focus Unit, you need to remove the single-speed focus handle.

The knobs are fixed to the axle by a screw you can access through the small hole (red circle above) but in order to find the screw underneath, you need to turn the handle until screw and hole are lining up. Then slightly losen the scew and pull the knob away from the axis.

Step 4: Installing the Flexible Coupling

The removed knob is replaced by the flexible coupling device that came with the ZWO EAF. Pick the one that fits the diameter of the axle best.

Things could have been so easy but unfortunately, the Skywatcher’s focus axle is either too long or too short, pick your choice: in order to fasten the telescope-side screw, it needs to either sit outside the focuser’s mounting or it needs to line up with the hole as the knob’s did. You can push it back in enough, no problem but then the axle also blocks the second screw.

The solution: also loosen the other side of the axle and push the axle out enough to fix the coupling dead center. Then shift the axle back into its original position (the coupling will nicely move inside the housing) and tighten the screws on the other side as well. If you now rotate the focus knob that is left, the flexible coupling should also rotate.

Step 5: Fixing the Bracket to the ZWO EAF Unit

This is a preliminary step so don’t fix it to tight. This is merely to make sure that bracket and focus unit can be attached properly – we are doing some fine adjustment later.

You can also to a “test assembly” with the Manual Focus Unit to see that everything falls in place and the two outer center holes (the one with the blind screw and the one that originally took the Fix Focus Screw) are lining up with the bracket’s mounting holes. But do not attach the two units to each other now!

Step 6: Putting the Manual Focus Unit back onto the Telescope

First, the Manual Focus Unit goes back to the telescope, and you need to put in the four mounting screws. Make sure the rubber rings stay in place!

Step 7: Mount the ZWO EAF Unit

In a final assembly step, mount the ZWO EAF Focuser using the two outer center holes and the two screws mounting the bracket to the ZWO EAF focuser unit. Makre sure all screws are sitting tight also make sure that the flex coupling is not touching the Manual Focus Units’s metal frame (you might have to push the ZWO EAF a little bit “down” before tightening the two screws on the side.

Some additional Notes

When the ZWO EAF Unit is assembled, the manual focus will no longer work! However, for testing (and in case you do need it) you can simply loosen the two screws on the ZWO EAF’s flex coupling device.

My focus unit gave some “eerie sound” once everything was reassembled and that came from the flex coupling device actually had contact with the metal frame of the Manual Focus Unit. So a bit of playing with the screws (including the Manual Focus Unit’s Pressure and Balance screws!) might be required.

Operational Test

Finally, I had everything put back together, connected the camera to my Raspberry Pi and configured by EKOS/INDI Profile to include the ZWO EAF Focuser. Started, connected, and did a manual focus in and out…

Posted in Astronomy | Tagged | Leave a comment

Flight Simulator 2020 & Real World VFR

Microsoft has just released the latest version of Flight Simulator – after an absence from the market for about a decade. And although there is a lot of frustration and a general feeling “the product has been released too early” and some bugs indeed impact the experience quite negatively (e.g. the infamous CTD – also known as “Crash to Desktop”) – the general question remains: how good is the flight feeling really?

My example is a tour I made with a friend in 1996 – it took us from Denver in Colorado all the way to San Francisco in California (and beyond). The tour is described in detail in other blog posts but this one puts the focus on comparing the scenery I have captured in my photos with the scenery rendered by Flight Simulator 2020.

Two Add-Ons are installed – KDEN Denver International Airport and Carendado’s Cessna CT182T Turbo Prop. Flight Planning is done with Little Navmap. The screenshots deliberately have the cockpit instruments visible so the details of the current flight situation are documented.

Our Cessna CT182T at Denver International Airport – KDEN

Heading out of KDEN, leaving on Runway 17 and then turning west, the flat lands east of Denver and the gigantic barrier the Rocky Mountains are presenting is more than obvious and very well rendered in FS2020.

Airborne leaving KDEN from Runway 17 – one of the more fancy Flight Simulator 2020 Bugs hit a bit earlier: a sudden loss of the avionics incl. a loss of the Autopilot.

Here are a few images taken in Denver in 1996. the first one is a photo taken from the stairs of the State Capitol and showing the Civic Center and the Civic Center Park. The second one shows the Civic Center Plaza building and the third one is an image of the St. Elisabeth of Hungary Church.

Denver – out of the box Flight Simulator 2020 – does not show the buildings in such a great detail but they are recognizable: State Capitol and Civic Center (1), the Civic Center Plaza (2) and St. Elisabeth (3).

Downtown Denver in the standard out-of-the-box rendering of FS2020

And there are some more downtown buildings that we visited way back when – and their counterparts in FS 2020.

These are from the images above: 18th Street / California, the Independence Plaza with the 950 Curtis Street Tower next to it, the Daniels & Fisher Tower, and the Holy Ghost Church with the 1999 Broadway Building behind.

All of the aforementioned buildings in downtown Denver

From Downtown Denver, the route takes us right up to the foot of the mountains, Boulder is our gateway into the Rockies.

Boulder and the Rocky Mountains

Following Highway 36 from Denver to Boulder, we are pulling over to the curb in 1996 – and we are enjoying the same view from the Cessna in FS 2020.

It is amazing how well the terrain is represented – the small hill slope left of the route marker is actually visible “in real life” in the 1996 photo.

From Boulder, things start getting “mountainous” – the Highway 119 is cutting into the Rockies, following the valley the Boulder Creek has cut into the stone throughout the ages.

The first images shows a stretch of the Highway 119 around the Boulder Falls area – the valley and Boulder Falls are recognizable from above as well.

Highway 119 (1) and Boulder Falls (2) from “above”

Further up Highway 72, the St. Catherine’s Chapel on the Rock is not picked up very well – but maybe, that is a bit too much to ask.

The St. Catherine’s Chapel on the Rock does not really exist – and you need to know where to look for it.

A little bit up the road Highway 72 runs past Lilly Lake, a very scenic little lake and our first entry into Rocky Mountain National Park. And although the early morning flight finds the little lake in the shadows, it is there and the view into the distance also is reflected pretty well.

Lily Lake with the positions the original photos were taken in 1996.

Following a night in Estes Park, the first target of the new morning was Bear Lake in the Rocky Mountain National Park.

Bear Lake in the Rocky Mountain National Park

The rendering of the steep cliffs above the lake is a little bit mellowed by the Flight Simulator’s terrain mesh but all in all, the trerrain itself is very convincing.

Bear Lake in the Rocky Mountain National Park

From Bear Lake, it is back to the Beaver Meadows Entrance Station and then up to Deer Ridge Junction to intercept the Trail Ridge Road. Trail Ridge Road is a 31 km / 19 mi high alpine road that has its highest point at 12.183 ft. / 3713 m just behind Lava Cliffs. At that hight, it runs at the top of the mountain ridge, above the tree line.

If you need a map of the park, you can download one here – which might be easier to follow the individual spots the images were taken.

The first image was taken around Deer Ridge Junction while the road is still running through the large forest areas. The second one is taken from Many Parks Curve and the thrid one is captured at Rainbow Curve.

And in FS 2020: Deer Ridge Junction (1), Many Parks Curve (2), and Rainbow Curve (3).

And because Rainbow Curve is a bit far out (and we need to look back to re-enact the photo), here it is a few seconds later:

Looking back from Rainbow Curve (1)

From there on, Trail Ridge Road runs above the tree line – and even in early September 1996, we had traces of snow left and temperatures around 0°C.

The Flight Simulator’s recreation of the country is stunningly accurate as you can see in the next gallery section. The locations of the above images are marked with their respective numbers in the FS 2020 photos.

From 12.000 ft., it is now all downhill to Shadow Mountain Lake, Lake Granby and the town of Granby, the local airport – KGNB – at 4.975 ft. We have crossed the first mountain range of the Rockies. From here, it is “go west”, with places such as Hot Sulphur Springs, Kremmling, Steamboat Springs, and Craig, our final destination for today. All following Highweay 40.

Again, those images can be directly related to the screenshots from FS2020 – numbered accordingly.

We got Lake Granby (1), Wolford Mountain Reservoir (2), Whiteley Peak from a distance (3) and close-up (4). By the way: only this flight allowed me to geo-tag the last image – I originally was under the impression that it was taken in a different location… but a Street View check in Google Maps confirmed what Flight Simulator 2020 had suggested…

I ran out of light on our trip – but the rest of the flight in FS2020 shall no go undocumented. There was some extreme low-level flying which provides a good change to get an impression of the impressive graphical handling of trees, meadows, water, etc.

Some extreme low-level flying in the Lake Catamount area – check the individual trees rendered by the system

While in the mountains, the scenery was dominated by the steep mountain ranges and the green of the forests – just a little bit past Steamboat Springs, the countryside changes, both in my photos and in Flight Simulator 2020.

Around the Yampa Valley Airport – the green is restricted to the areas around the rivers, a brownish grasland with Sagebrush starts to dominate the view.

Back in 1996, we spend our night in Craig, in what is today the Bear Valley Inn of Crag (1) – I am not sure it wasn’t a Best Western Motel back then but anyway, the building is still there and the photos confirm the aerial view from above.

Craig and the Bear Valley Inn

I am finally taking the Cessna into Craig Moffat Airfield (KCAG) after a flight that had taken some 90 minutes in the air (but two days on the road). Worth to mention: there was not a single glitch in the simulator after I had to deal with the “loss of avionics bug” right at takeoff. And given that my old computer is not the fastest one, the flight had a remarkable performance in terms of frames and fluent display.

Parked and secured at today’s destination

Conclusion: Flight Simulator 2020 has its quirks and bugs. But once you know what to expect, you can get around them until they (hopefully) are fixed in one of the next releases. The quality of the terrain rendering and the mapped satellite images provide for a real-time VFR flying experience – if you want to add in IFR for navigating a predefined flight plan, that is also possible and works quite well.

You need to be prepared for the occasional bug, even a “Crash to Desktop”. But it is far from happening “on every flight” and “every few minutes”. When it happens, it is upsetting, of course. But the joy of VFR and light IFR Flights still outweighs the problems. However, you need to have the right expectations: the Flight Simulator (even in the past) was never published to provide the ultimate experience when it comes to realistic aircraft handling – that was always left to the add-on developers. Same with the landscape, the scenery: the overall scenery is good (in terms of FS2020 even great) but additional scenery packages by the community or add-on developers will make the difference. In other words: if you buy, make sure you are having your expectations set straight – or the system will do it for you…

Posted in Flight Simulation, FS2020 | Leave a comment

Flight Simulator 2020 – Back in the Skies

About ten years ago, I wrote a blog post about Microsoft Flight Simulator FSX and an Add-On called “ChicagoX”. The old post can be found here. A little while afterwards, I had been giving up flight simulation, mostly because Microsoft withdrew from the market and other simulators were not mine to work with. Yesterday, Microsoft published its brand-new Flight Simulator 2020 – and of course, I had to visit good old Chicago.

The photo above is taken at about the same location than the two photos in the old post – one from Flight Simulator 5 and one from Flight Simulator X with the ChicagoX Add-On. Once more, the technology has leaped ten years ahead – literally. Microsoft is now using web-based AI and its own Bing Maps service to render a photorealistic landscape including the matching buildings. Live!

Flying into the downtown area coming from the south not only shows how far flight simulation has come in the 30 years since the very first images taken in Flight Simulator 5, it also shows what is the currently best possible result – and makes you wonder what another ten years might add?

Trying to get into a similar position to where I took my screenshots ten years ago, I probably violated a ton of flight rules but the images were worth it. Downtown, the level of detail shown by the buildings is just stunning.

Yes, it is true that this is not the same for every place on Earth and yes, the results are best for the Unites States and some other well-digitized areas – but hey, we are here to enjoy the moment!

So what have we gotten in addition? A brilliant graphics engine that work on my six-year-old PC (although I have provided it a good graphics card two or three years back). A photo-realistic ground and very detailed skylines. Live weather and air traffic. Light effects where the sun can actually shine through the clouds.

Later this year, Microsoft wants to add support for Virtual Reality Headsets – I am curious if my old one will work. For the time being, I will enjoy the scenery a bit, explore the world from the cockpit of a Cessna or other small aircraft and this time, I will focus on the VFR Flights… “visual flying” is what this simulator is made for!

Posted in Flight Simulation, FS2020 | Leave a comment