WB4SON

SGP4 is a Simplified General Perturbations mathematical model, which is used to calculate the position of satellites relative to the Earth.  The most frequently used model is SGP4, which is used with Two-Line Element (TLE) sets provided by NORAD and NASA.

SGP4 is used for near earth objects with short duration orbital periods (less than 255 minutes).  This more than covers all current amateur satellites and the International Space Station.  For example, the ISS is about 250 miles above the earth and has an orbital period of about 94 minutes, while FunCube-1 (AO-73) satellite is about 400 miles above the earth and has an orbital period of 97 minutes.

While the original SGP4 calculations were described in Fortran IV back in 1988, they have been ported to many languages, included Python.  Due to the critical nature of these prediction models, there are fully automated suites of tests that can be used to validate their accuracy.

A fully tested python version of sgP4 can be found here:  https://pypi.python.org/pypi/sgp4/

Inputs are TLE data and desired time.  Output is positional vector and velocity.

I am still learning and experimenting with the Adafruit Ultimate GPS HAT and the Raspberry Pi 2 Model B.  While I have the GPS tied into the system now, it doesn’t appear that the Raspbian NTP service is handling the GPS, at least without an active internet connection (in which case, NTP is using the NTP servers, not the GPS).  With the internet disconnected, every time I start up the RPi, the GPS is functioning, but cgps shows an ever increasing difference between the GPS time and the system time, because the system time is not updating.

I’ve tried several approaches to get NTP working with just the GPS, but so far, no joy.  I clearly have more learning to do.  (And that’s not even trying to get things synchronized to the 1PPS signal, which is another issue entirely).

That said, the system “date -u” (UTC set) command can be used to set the system clock, after fetching the UTC time from the gps and converting it into the required string format.

Here is a small Python program called gpsutcset.py that can be executed from the command line that will read the time from the GPS, build a string that is properly formatted, and invoke the OS date -u command to set the UTC time.

import os
import sys
import time
from gps import *

print 'Set System Clock to GPS UTC time'

try:
  gpsd = gps(mode=WATCH_ENABLE)
except:
  print 'ERROR: No GPS Present, time not set!!'
  sys.exit()

while True:
  #wait until the next GPSD time tick
  gpsd.next()
  if gpsd.utc != None and gpsd.utc != '':
    #gpsd.utc is formatted like"2015-04-01T17:32:04.000Z"
    #convert it to a form the date -u command will accept: "20140401 17:32:04"
    #use python slice notation [start:end] (where end desired end char + 1)
    #   gpsd.utc[0:4] is "2015"
    #   gpsd.utc[5:7] is "04"
    #   gpsd.utc[8:10] is "01"
    gpsutc = gpsd.utc[0:4] + gpsd.utc[5:7] + gpsd.utc[8:10] + ' ' + gpsd.utc[11:19]
    os.system('sudo date -u --set="%s"' % gpsutc)
    sys.exit()

Assuming that python code is stores in the /home/pi directory, then simply typing “python /home/pi/gpsutcset.py” will do the trick.  Or that gpsutcset function can be added to the /etc/rc.local file after the gpsd daemon start up like this:

sudo gpsd /dev/ttyAMA0 -F /var/run/gpsd.sock
python /home/pi/gpsutcset.py

As I continue to work on the Autonomous Satellite Antenna Tracking System (ASATS), to changes need to be made to setup the RPi so things happen automatically on power-up.  This requires two changes to the RPi:

1. Setup for Automatic Login on bootup
2. Setup to Automatically Run desired tools

Automatically Login:

Edit the /etc/inittab to comment out the original gettty tty1 line, then add a new line immediately below it to automatically login the “pi” default user.  (By the way, all the spacing is absolutely critical, and making any typo can result in a RPi that will no longer boot correctly — guess how I know!):

#1:2345:respawn:/sbin/getty --noclear 38400 tty1
1:2345:respawn:/bin/login -f pi tty1 </dev/tty1 >/dev/tty1 2>&1

Automatically Run GPS Daemon:

Edit the /etc/rc.local files, and add the following immediately before the final line of the file (‘exit 0’):

sudo gpsd /dev/ttyAMA0 -F /var/run/gpsd.sock

This will ensure that the GPS Daemon is loaded at boot time (and configured to use the serial port on the RPi).  After booting up, use the console cgps -s command to verify operation.  Just keep in mind it can take several minutes for the GPS to obtain a fix on a cold powerup.

Remote SSH using a MacBook:

I noted that the SSH services are already installed in the RPi OS.  Since I often use a MacBook for other tasks, it is very simple to use the built-in Terminal application in OS X.  Just start Terminal, and type “SSH pi@192.168.1.20”.  You will then be asked for a password.  (Note because it is still set for DHCP, my RPi address will change periodically.  Eventually I will set the Pi to use a static address that is reserved by my router).

I started today’s experimentation by loading the gpredict program.  This was written by Alexandru Csete, at http://gpredict.oz9aec.net/

While his repository has all the source code, there is no reason to do anything other than load it into the pi, at least under the default Raspbian Debian Wheezy OS, by doing the following:

$sudo apt-get update
$sudo apt-get install gpredict

The first line makes sure the RPi has all the recent OS updates, and the second obtains the gpredict program and files.  Once the files have been loaded, start x-windows and “run gpredict”.

I measured my RPi2 current when both the gpredict and xgps programs were running under X Windows (only 3% CPU utilization for both).  It was right around 300 mA at with 5.3 volts at the input to the USB power cable.  Hard to believe so much can be done for less than 2 watts of power.  I don’t expect the LCD to add much more, but the servos will certainly add to the drain, especially the elevation control which has to fight gravity (probably a good reason to eventually balance the antenna even though the servo is capable of about 4x the required torque without balancing).