Lunar and Planetary Elongation Chart for 2018

{click the chart for full size view and to download}

Lunar and Planetary Elongation Chart for 2018

Several years ago our family started using Guy Ottewell’s Astronomical Calendar to guide our skywatching.  It was a wonderful and extensive mix of stories, diagrams, descriptions, and charts along with a textual calendar of events.  The last printing was for 2016;  we have not found  an adequate replacement.  I was looking through the 2016 Calendar in December and discovered the a chart of lunar, planetary, and stellar elongation for the year.  Although I had seen it before, I hadn’t appreciated the amount of information that I could get from it.  I decided to make that chart for my own use; I finally got around to doing it and decided to post it here.  Feel free to download a copy, without any warranty of accuracy; please leave a comment if you find errors, etc., have a question, or just want to leave a comment.

The earth and other planets revolve around the sun.  The moon revolves around the earth, but its phase is determined by its position relative to the sun.  The consequence of these motions is that the planets and the moon change position in the earth’s sky relative to the background of distance stars and, more importantly, to the sun.  The elongation as plotted on this chart is the angular separation of the object from the sun as seen from earth charted over time.

Here are some things you can determine from the chart:

    • The morning and evening “stars” — planets, often bright, that occur in the sky near the sun before sunrise and after sunset.
    • When the planets and/or moon are close to each other in the sky; an appulse.
      • This is possible because the planets and the moon all move in planes close to the ecliptic plane, the orbital plane of the earth.  When they have similar elongation values, they are in the same part of the sky.
    • The relative brightness of the planets. (but not the moon)
    • The phase of the moon.

Some important features of the chart:

    • The vertical axis plots the elongation; the horizontal axis plots the date during 2018
    • The vertical center of the plot is zero, the location of the sun.  Note annotations on left side.
      • The upper half shows western elongations, eg, the morning sky just before sunrise.
      • The lower half shows eastern elongations, eg. the evening sky just after sunset.
    • Phase descriptions of the moon are annotated on the right side of the chart.
      • The moon is Full when its elongation is 180° or equivalently -180°.
      • The moon is New when its elongation is 0°
      • The first quarter moon occurs at -90° , the evening sky.
      • The last quarter moon occurs at 90°, eg. in the morning sky.
    • The marker size shows the relative magnitude (brightness) of the planets (but not the moon).
    • The markers are placed every four days along each curve.

The data for the chart was calculated once a day at 00:00 UTC with a Python script using the PyEphem package.  The data was then imported into IGOR Pro to be plotted.


New Live Seismograph Display


A year or so ago, I upgraded my seismograph software from the original IRIS AmaSeis program to an upgraded version based on Java called jAmaSeis.  I ran the new software on a little Asus netbook.  The helicorder display that I uploaded to the Live Seismograph page on this site was just a screen shot of the active window every five minutes.  The little netbook was at its performance limit and the screenshot made it impossible to do any analysis anyway.

This fall I built up a Linux desktop computer running XUbuntu 14.04LTS and installed jAmaSeis on it.  I downloaded from the IRIS website and followed the basic instructions for installation given on the same site.  With a little fiddling around, I got the software running.  I plugged in the Dataq DI-145 USB Analog to Digital converter…the software could not find it.  I fiddled around with it for a long time with no success.  I could see the device appear in /dev as ttyACM0 when I plugged it in.  After giving up on it a couple of times I finally created a symbolic link from ttyACM0 to ttyS32 where the seismograph software would detect it.  I do this manually every time the computer reboots or the ADC is unplugged.  I plan to write a udev rule to do this automatically.

To get the helicorder display for the Live Seismograph page I use an open source package of seismology tools for Python called Obspy.  jAmaSeis writes the data stream in one hour long segments in sac formatted files arranged in a time based directory structure.  The Obspy stream manipulation tools allow one to easily build a continuous 24 hour data stream from the jAmaSeis files and plot it in a moderately flexible way in a Python script.  This method yields several improvements over the screen shot.  The date and time are unambiguously shown on the vertical axis and the traces alternate through four colors to differentiate the hour in which an event occurs more clearly.  The Python script runs as a cron job every five minutes.

The Obspy package also provides tools to parse QuakeML documents which I obtain from a USGS feed inside the same script that plots the data.  After parsing each event, I use the obspy.core.util.locations2degrees tool to find the distance from the epicenter to my station.  The script then annotates the helicorder display with seismic events selected using magnitudes and distances that might be detected with my seismograph.  This selection is arbitrary so there will be some that show on the trace without annotation and others will be annotated when there is nothing showing on the trace.

Software Defined Radio — Installing the NooElec NESDR Mini 2 for Linux


I will take the opportunity now to stop and review where I am with the Satellite Tracking project that my older son and I started several years ago. In 2009 we recorded several passes of a now decommissioned amateur radio satellite named HAMSAT (VO-52). With attention to the timing accuracy of the recording, I was able to estimate slant range from the receiver to the satellite as a function of time using a simple Doppler Shift model. I have then recently developed a Python script to estimate the actual location (eg. latitude/longitude of the ground track, altitude, and azimuth/elevation) of the satellite given the range/time data from three ground stations of known latitude and longitude.

The project now has some momentum in the direction of a real test sometime in the future raising the question of what radio receivers I should consider. My son has suggested the use of Software Defined Radio, a concept I like very much because it is in line with one of the unstated goals of most of my projects to do as much as you can with as little financial cost as possible. A month or so ago he mentioned Gnu Radio and a hardware device known generically as a DVB-T Dongle based on a Realtek RTL2832U circuit. The interface between GNU Radio and the dongle uses the RTL_SDR codebase as discussed at and I invested $25 to see if I could make it work. It is not a plug and play device and it does take a little work to get it operating so I am documenting what I had to do as a blog post here.

Acquiring and installing the NooElec NESDR Mini 2

While there are a lot of DVB-T dongles available, I purchased the NooElect NESDR Mini 2  on Amazon plus a PL-259 pigtail for it. Dongles from some suppliers take a long time to ship and defective devices are reportedly common.



I am programming this project in Python and decided that the best platform for the project was Linux so I installed the radio on a Dell Vostro notebook with 2 GB RAM and a 2 GHz Intel core duo processor running a brand new installation of XUbuntu 14.04 LTS. After reading several websites it looked like most pointed to osmocomSDR. There is a lot of information there. I have extracted only what I did to get up and running. My inexperience with Linux will become evident.

I downloaded the software as a package release as described on the website and extracted the archive. I tried to build the software following the instructions at osmocomSDR but the build threw several dependency  errors. Save yourself some time and install these before you start.

Here is the build sequence using cmake:

cd rtl-sdr/
mkdir build
cd build
cmake ../
sudo make install
sudo ldconfig

cmake was not installed so I did a

sudo apt-get install cmake

and tried again. This time the error was that the libusb1.0 library was not installed. The osmocomSDR website very explicitly says this is required. In my previous experience with Linux I have used the synaptic package manager to download things like this but it is no longer installed by default. Most of this stuff could have been install from that…I have installed it now, after the fact. I downloaded the build package for libusb1.0 from SourceForge and extracted it. It threw an error in the configure step that libudev was not installed. I installed it from the Ubuntu Software center.

After that the build as described on osmocomSDR went smoothly to completion.

The installed codebase has several command line programs so I ran the first one described on the website

rtl_fm -f 96.3e6 -M wbfm -s 200000 -r 48000 – | aplay -r 48k -f S16_LE

I was greeted by the gentle hiss of a radio that was tuned to dead air. I exited and edited the command to

rtl_fm -f 95.3e6 -M wbfm -s 200000 -r 48000 – | aplay -r 48k -f S16_LE

our local FM station. This time I was greeted by the local high school girls basketball game at the some kind of state championship or something. I must admit that I was never so happy to hear a basketball game as I was this one.

Then I installed a SDR called GQRX from the Ubuntu Software Center. After fooling with the controls (mainly the receiver gain which is set to automatic by default) I got it working too…the blue LED in the lower right is the dongle.  Shown here tuned to a nearby repeater for our regional NPR station.



Finally, I downloaded Gnu Radio from the Ubuntu Software Center and prepare to build the rtl_sdr source block for it.  I ran the Gnu Radio Companion first though and was surprised to find the Osmocom rtl_sdr block already there.  I had installed Gnu Radio on another identical install of XUbuntu and there were no sources shown.

Here is a screen shot of Gnu Radio Companion ready to build a radio based on the rtl_sdr dongle.  I will describe that too once I figure out how to do it.




A New Page — Passive Tracking of Satellites using only Range Data


I have added a new page to the Earth orbiting satellites section of Murmurs from the Earth…Whispers from the Sky.  Passive Tracking of Satellites using only Range Data continues the project started several years ago to study the Doppler shift of satellite radio beacons.  The page describes a method to determine the ground track and other information about the position of a satellite as it passes over three ground stations recording the satellite radio beacon.

While I am certain that this has been done in the past and replaced with other techniques, I developed the method and Python scripts from scratch, to the extent that is possible…obviously I scavenged code and ideas from wherever I could to make a lot of the cranks that needed to turn.  I used a  very simple geometric approach.

Lacking actual data I generated four artificial and hence, internally consistent data sets using the PREDICT pass prediction software that provide the range input data and the location check data.  I was quite pleased with the initial results.

Magnitude 6.3 & 6.0 – BERING SEA

Magnitude 6.3 - BERING SEA

Magnitude 6.3 - BERING SEA

Magnitude 6.3 earthquake in the Bering Sea last evening.  A second, Magnitude 6.0 tremor occurred about 5 minutes later in the same location.  The travel time curves are placed based on the first, larger one.  The unmarked arrival to the right of the SS curve is the SS arrival for the Magnitude 6.0 event as shown below.  In this image the travel time curves are placed based on the second Magnitude 6.0 event.  Overlapping returns are usually more difficult to extract from a single trace than these signals.

As an aside, I have Amaseis running on an old HP/Compaq notebook computer with Windows XP Pro.  Even though Windows provides a mechanism for updating the system clock using some variant of internet time, it doesn’t allow the user to set the frequency of the update.  The clock was running about 2 minutes fast when these earthquakes took place so I have to compensate for the actual time difference in the analysis.  I need to find a better way to update the system clock.   Postscript:  I had used a program called NMEATime in conjunction with a GPS receiver to set the time on my previous logging computer.  I couldn’t use it with the GPS on the notebook because it only has one serial port.  However, the program can also synchronize to network time servers at a user programmable interval so I installed it to synchronize the system clock.

Magnitude 6.0 - BERING SEA

Magnitude 6.0 - BERING SEA

Moving Up in the World

A couple of weeks ago, in a telephone conversation, my older son mentioned that it would be interesting to see if we could measure the Doppler shift in a satellite radio beacon as it passed overhead. He suggested, if I was interested, that he could bring along a radio and we could try it when they came home to visit at Christmas. Of course I was interested!

After supper on Christmas evening, he found a candidate satellite and set up the radio. We fed the audio from the radio to the line input of my MacBook to make the recording and do the analysis. The long and the short of it was that we picked off a nice Doppler shift on two passes, one on the evening of the 25th and one on the evening of the 26th. The Raven Lite software was great for monitoring the signal, both visually and audibly but it had the shortcoming of limiting the recording time to only a minute. For the pass on the 26th, we split the signal and used his MacBook to record the full pass of several minutes into one file using Audacity while keeping Raven Lite running on mine. Since the frequency shift was greater than the radio’s passband, it had to be retuned a few times.

I picked several points off of each file and manually adjusted each point for the time and any retuning of the receiver as needed. Then I used my linear path model for the curve fit after replacing the speed of sound with the speed of light. The first pass data fit very nicely. I haven’t done the fit on the second pass yet. Once I do a little more analysis, I’ll put up a page on it.

My son reminded me that there was a docudrama on PBS’s Nova many years ago (December 1989) called “The School Boys Who Cracked the Soviet Secret” about a science class in a private boys school in England that did a similar analysis on the Sputnik satellite right after it was launched. It would be interesting to watch that again.

This is a very interesting subject that has lots of avenues to study in more detail. We’ll have to see what develops as time passes. For right now though, the basic process was pretty easy, gives me a lot of things to think about… and was very cool.

Home Page Hijacking

Is it my imagination or is Home Page Hijacking increasing?

I went to the Dell Support pages looking for information on an old Dell computer. They loaded up several tabs and windows. When I tried to go to my Home page it had been replaced by a Dell/Google page…kind of like stepping on someone’s discarded chewing gum. I replaced it with my preferred Home Page, this one of course, and then deleted all of my cookies, history, and temporary files…you know, like scraping your shoe on the first sharp edge you can find. I have already vowed not to buy another Dell computer due to their poor handling of the Vista fiasco. Now I may never even look at their website again.

Is there a setting buried deep within Internet Explorer that says “Disable Home Page Hijacking”?