About Paleoferrosaurus

Context is everything.  For the few people on Earth that actually read this drivel, most will not know me personally.  We probably share some common interests that led you here, but sometimes a little bit of background information is helpful in interpreting what you find.

My name is Micheal Harve McCabe.  I’m presently 49 years old and live in northwestern Pennsylvania in the United States of America.  I’m married. I have three adult children.  I’m a graduate of Edinboro University of Pennsylvania.  If population demographics are an interest of yours, I’m a fat, middle-aged, white male. I’m not religious, and the current political climate of the United States disgusts me.

I am presently employed by two public-safety agencies in Erie County:  The West County Paramedic Association where I serve as an IT specialist and part-time paramedic; and the Central Erie County Paramedic Association where I serve as a full-time paramedic and general purpose technical wizard — involved in the care and management of computers, radio communications, and biomedical electronics.

I am a hacker and a tinkerer.  I write a lot of code for embedded devices that find use in communications equipment and medical devices.  Most of that stuff is pretty boring. The stuff that isn’t boring (from my perspective) are the “vintage” and “classic” computers that I tinker with and (occasionally) find useful applications for.

My hobbies include amateur radio (call sign: KB3NJY), model rocketry, firefighting, local history, and cellular biology.  I enjoy reading and writing both fiction and non-fiction.  I am sometimes employed as a teacher at the post-secondary level where I’ve taught classes as diverse as Medical Terminology, Human Anatomy, Medical Laboratory Practices, and Health Information Technology.

The content of this blog and associated web pages will reflect, to a greater or lesser extent, the total scope of my interests.  You will find articles on topics ranging from pre-hospital medicine to retrocomputing to railroad history and anthropology.  While I’m an expert in none of these fields, I tend to write whatever crosses my mind in a given moment.  As always, take everything with a grain of salt and consider the source!

Chest Pain / STEMI Candidate

The patient is a 66 year old white male presenting with substernal chest pain he rates an “8” on a 1-10 scale. He reports an acute onset at appx. 11:00 hrs this date while at rest.

The pain is described as a heaviness or “crushing” chest pain and is similar to pain the patient experienced during a prior heart attack. The patient states that the pain does not radiate, nor does anything make the pain better or worse. The patient denies SOB.

The patient has an extensive cardiac history with four prior stents.

Upon EMS arrival, patient is conscious, alert, and ambulatory. The pulse is 78 and bounding. Respirations are 18 and non-labored. The blood pressure is 160/78. The skin is pale, warm, and dry. Pupils are dilated and sluggish. Breath sounds are clear, present, and equal. Heart sounds are abnormal with a pronounced S4 Gallup. The pulse oximeter reads 98% on room air. The EKG shows a sinus rhythm with left atrial enlargement, a possible anteroseptal infarct, and ST changes suggesting and inferior wall MI.

Automated ECG interpretation software reports suspicion of an acute MI.

smaller_acute_mi

Treatment:

The patient was placed on the stretcher and moved to the ambulance. Med Comm was contacted and asked to relay the possible acute MI to <BLANK> Medical Center. An IV was established in the Left AC running Normal Saline TKO. Blood was drawn as per the ALS protocol. The patient was given 0.4 mg sublingual nitroglycerine at 1230 with a second dose of 0.4 mg given at 1236. The patient reports already having taken 4 x 81 mg Aspirin prior to EMS arrival. The patient was transported to <BLANK> aboard <BLANK> using lights and siren, arriving at the hospital within 20 minutes of leaving the scene. Upon arrival at <BLANK>, the ambulance was met at the ER door by Dr. <BLANK> and other members of the hospital staff. Verbal reports were relayed immediately while walking directly from the ER door to the Cardiac Catheterization Laboratory. The patient was directly transferred from the ambulance stretcher to the procedure table within the cath lab and the patient’s blood samples were relayed to laboratory staff at that time. Transport was without incident.

 

November 1, 2016 – End of the Retrochallenge

Once again, I’ve failed to accomplish much during the month-long celebration of Retrocomputing.  My Apple ][ programs can simulate simple ballistic motion and orbital insertion, but fail miserably when trying to realistically simulate Earth Orbit or (an order of magnitude harder) a transfer from Earth orbit to lunar orbit.  I can safely say I’ve reached the limits of my own understanding, if not the capability of the Apple ][+!

Looking at the other entrants, I’m amazed (as always) at both the breadth and depth of retrocomputing as a hobby!  Good luck to the judges when it comes time to pick a winner!

-Paleoferrosaurus

 

Orbital Mechanics

Just starting to think about how I can simulate the spacecraft orbiting the Earth.  Sure, I can draw some pretty little ellipses on the screen, but I’d like that to have some relationship with the actual orbital path of a spacecraft.  My understanding of orbital mechanics is pretty limited at this point, and I’m planning on spending most of this evening studying. Till then, here’s a nice diagram of what I have to simulate:

orbital_mechanics

Flight Dynamics

Spacecraft Flight Dynamics is the study of spacecraft performance, stability, and control. If you ever listen to mission audio from the American Space Program, the flight controller responsible for this particular aspect of the mission has the call-sign “FIDO.” In terms of popular culture, “FIDO” was the guy in the film Apollo 13 who determined that the mission could still make orbit after the second stage center engine cut out prematurely. In that case, Apollo 13 was able to make orbit by extending the burn time of the four remaining J-2 engines.

Every rocket, ranging from simple fireworks to the mighty Saturn V have the same four basic forces acting on them: weight, thrust, lift, and drag. Simulating the behavior of the rocket mathematically requires us to quantify these forces and establish mathematical relationships between them.

rocketWeight – is the gravitational force acting on the rocket. This is distinct from the mass of the rocket and is dependent upon the local gravitational field.

Thrust – is the reaction force generated by the engine and is determined by the mass of propellant burned in the engine and the velocity with which the exhaust gas is expelled through the engine’s nozzle.

Lift – is an aerodynamic force generated by air flowing past the surface of the rocket. Lift is the component of this force that is perpendicular to the oncoming flow direction. This becomes confusing when the rocket’s flight-path is more vertical than horizontal and we begin treating lift as a lateral force rather that the usual vertical force seen in airplanes and helicopters.

Drag – is a similar aerodynamic force, this time exerted in a direction parallel to that of the airflow.

Ultimately, the behavior of our rocket – and its simulation on the Apple ][ – come back to Sir Isaac Newton and his laws of motion. In particular, the second and third law find application here since our rocket’s thrust is dependent on his third law (“For every action, there is an equal and opposite reaction.”) and the motion of the rocket is dependent on the second law:

F = ma

Where F is the sum of all forces acting on the rocket, m is the current mass of the rocket (constantly changing as it expends fuel and rocket stages), and a is the acceleration vector, the instantaneous rate of change of velocity (v), which in turn is the instantaneous rate of change of displacement. Solving for a, acceleration equals the force sum divided by mass. Acceleration is integrated over time to get velocity, and velocity is in turn integrated to get position.

The weight of the rocket is computer by multiplying its mass (in kg) by the acceleration imparted by the local gravitational field. Although gravity varies as the distance from the center of mass changes, according to the inverse square law, we can assume that for objects near the surface of the Earth, the gravitational acceleration is approximately 9.8 ms2.

w=mg

As we are using metric units to simplify our arithmetic, we should note that while mass is expressed in kilograms, weight (like thrust) will be specified in a derived unit, Newtons.

As mentioned above, thrust is the reaction force generated by the rocket engine and is determined by the mass of propellant burned in the engine and the velocity with which the exhaust gas is expelled through the engine nozzle. The basic equation for finding the thrust of a rocket is:

Fn=mve

Where Fn is the thrust (in Newtons), m is the mass of the fuel and oxidizer burned in the engine and ve is the velocity of the exhaust gas.

Without spending too much time on the mathematics, our simulation has to integrate all four of these forces acting on the rocket.  The BASIC source code here is a little rough and is still in a very preliminary stage, but is an attempt at simulating the flight dynamics of a rocket attempting to reach orbit.  Again, we’re sticking with the early space program… In this case, the weight and general characteristics of our rocket is a Mercury-Atlas similar to MA-6 that put John Glenn into orbit on February 20, 1962.

launch_of_friendship_7_-_gpn-2000-000686Friendship 7

Launch Date:  02/20/1962 14:47 UTC
Pilot:  John Glenn
Launch Vehicle Mass: 120,000 kg
Payload (Spacecraft) Mass:  1,224.7 kg
Approximate Fuel Mass:  114.420 kg
Main Engine (Sustainer) Thrust: 300 kN
Booster Engines - Thrust:  1,300 kN
Main Engine Burn Time: 300 seconds
Booster Engines Burn Time:  134 seconds
Velocity at Orbital Insertion: 7,844 m/s
Altitude at Orbital Insertion: 248 km

2016-10-23-2 Running this simulation on the Apple IIe Emulator (Source code below), it appears we get the time, range, altitude, and velocity approximately correct, but our translation on the X, Y, and Z axes is way off.  Apparently, I’m not resolving the forces correctly in all three dimensions…

I’ll review the code and post more later…  I need to check my arithmetic!

]LIST

 1000 REM PROGRAM MAIN
 1010 GOSUB 1390: REM INITIALIZE STATE VECTORS
 1020 GOSUB 1630: REM INITIALIZE LINEAR INCREMENTAL CHANGE
 1030 GOSUB 1230: REM DRAW THE PLOT AXIS
 1040 GOSUB 1280: REM PLOT THE COURSE
 1050 GET A$: IF A$ = "" THEN 1050
 1060 END 
 1070 REM RESOLVE FORCE IN THREE DIMENSIONS
 1080 REM 
 1090 LET TZ = 90 - T: REM T IS ANGLE THETA FROM 6000
 1100 LET TY = A2: REM LAUNCH AZIMUTH FROM 7000
 1110 LET TX = T: REM CURRENT PITCH FROM 5000
 1120 LET R9 = (22 / 7) / 180: REM PI OVER 180
 1130 LET FX = F * COS (TX * R9): REM FORCE ALONG X AXIS
 1140 LET FY = F * COS (TY * R9): REM FORCE ALONG Y AXIS
 1150 LET FZ = F * COS (TZ * R9): REM FORCE ALONG Z AXIS
 1160 LET F1 = SQR (FX ^ 2 + FY ^ 2 + FZ ^ 2): REM CHECK YOUR ANSWERS!
 1170 REM 
 1180 RETURN 
 1190 REM CALCULATE ACCELERATION GIVEN THRUST AND WEIGHT
 1200 REM 
 1210 LET A9 = T9 / VM
 1220 RETURN 
 1230 REM DRAW SCALE
 1240 HGR : HOME : HCOLOR= 3
 1250 REM 
 1260 HPLOT 0,159 TO 279,159
 1270 RETURN 
 1280 REM PLOT INITIAL BOOST PHASE
 1290 VTAB 21: HTAB 1: PRINT "INITIAL BOOST PHASE:"
 1300 LET PX = 0:PY = 0:R = 159:PI = 22 / 7
 1310 FOR T = 0 TO 90
 1320 LET X = R * COS (T * (PI / 180))
 1330 LET Y = R * SIN (T * (PI / 180))
 1340 LET PX = 279 - X:PY = 159 - Y
 1350 HPLOT PX,PY
 1360 GOSUB 1680
 1370 NEXT T
 1380 RETURN 
 1390 REM INITIALIZE STATE VECTORS
 1400 SX = 0: REM POSITION X METERS
 1410 SY = 0: REM POSITION Y METERS
 1420 SZ = 0: REM POSITION Z METERS
 1430 VX = 0: REM X VELOCITY MPS
 1440 VY = 0: REM Y VELOCITY MPS
 1450 VZ = 0: REM Z VELOCITY MPS
 1460 MT = 0: REM MISSION TIME SECONDS
 1470 A1 = 0: REM ALTITUDE MSL
 1480 R1 = 0: REM DOWNRANGE METERS
 1490 V1 = 0: REM NET VELOCITY
 1500 FM = 114420: REM FUEL MASS KG
 1510 AX = 0: REM ATTITUDE X AXIS
 1520 AY = 0: REM ATTITUDE Y AXIS
 1530 AZ = 0: REM ATTITUDE Z AXIS
 1540 RX = 0: REM RATE CHANGE X AXIS
 1550 RY = 0: REM RATE CHANGE Y AXIS
 1560 RZ = 0: REM RATE CHANGE Z AXIS
 1570 VM = 120000: REM VEHICLE MASS KG
 1580 A2 = 57.5: REM LAUNCH AZIMUTH (90 DEG DUE EAST)
 1590 LET G = 9.8: REM ONE G OF ACCELERATION
 1600 LET FR = 384.1: REM FUEL CONSUMPTION PER SECOND
 1610 LET T9 = 160000: REM THRUST IN NEWTONS
 1620 RETURN 
 1630 REM LINEAR INCREMENTAL CHANGE TO STATE VECTORS
 1640 DIM D(4): RESTORE 
 1650 DATA 320,188000,248000,7844
 1660 FOR I = 1 TO 4: READ D(I): LET D(I) = D(I) / 90: NEXT I
 1670 RETURN 
 1680 REM UPDATE STATE VECTORS
 1690 LET MT = MT + D(1)
 1700 LET A1 = A1 + D(1) * V1 * COS (T * (PI / 180))
 1710 LET R1 = R1 + D(1) * V1 * SIN (T * (PI / 180))
 1720 LET V1 = V1 + D(4)
 1730 GOSUB 1190
 1740 LET F = T9
 1750 GOSUB 1070
 1760 LET VX = VX + (FX / VM) * D(1)
 1770 LET VY = VY + (FY / VM) * D(1)
 1780 LET VZ = VZ + (FZ / VM) * D(1)
 1790 LET SX = SX + VX * D(1)
 1800 LET SY = SY + VY * D(1)
 1810 LET SZ = SZ + VZ * D(1)
 1820 LET VM = VM - (FM / 90)
 1830 HOME 
 1840 VTAB 21: HTAB 1: PRINT "TIME: "; INT (MT)
 1850 VTAB 22: HTAB 1: PRINT "RANGE: "; INT (R1)
 1860 VTAB 23: HTAB 1: PRINT "ALTITUDE: "; INT (A1)
 1870 VTAB 24: HTAB 1: PRINT "VELOCITY: "; INT (V1);
 1880 VTAB 21: HTAB 20: PRINT "POS X: "; INT (SX);
 1890 VTAB 22: HTAB 20: PRINT "POS Y: "; INT (SY);
 1900 VTAB 23: HTAB 20: PRINT "POS Z: "; INT (SZ);
 1910 RETURN 
 1920 REM DELAY LOOP
 1930 FOR N = 0 TO 2000
 1940 NEXT N
 1950 RETURN

Simulating Simple Ballistic Motion on the Apple ][

The very first flights of the American space program were the Mercury-Redstone Ballistic flights.  A total of six Mercury-Redstone vehicles were launched between November 21, 1960 and July 21, 1961 on sub-orbital ballistic trajectories that carried the Mercury Spacecraft from Cape Canaveral Air Force Station to splashdown in the North Atlantic.  Two of these missions were crewed by humans — MR3 on May 5, 1961 carried America’s first Astronaut Alan B. Shepard into space in his capsule Freedom 7; and MR4 on July 21, 1961 piloted by Astronaut Gus Grissom in his capsule Liberty Bell 7.

LIFTOFF OF MR-3 (MERCURY-REDSTONE 3) FREEDOM ¦, MANNED SUBORBITAL FLIGHT. ASTRONAUT SHEPARD, ALAN, FIRST MAN IN SPACE. MAY 5, 1961 REF: LOD 61C-884 (MIX FILE)
LIFTOFF OF MR-3

Unlike later Mercury missions, these Mercury-Redstone flights did not go into orbit around the Earth; rather they “went up like a cannon ball and came down like a cannonball.”  From an engineering perspective, these flights were important because they facilitated the development of an attitude control system that could orient the spacecraft in a given direction, life-support systems that could keep an astronaut alive in the vacuum of space, heat-shields that could protect a spacecraft and its occupants during re-entry, communications, and tracking systems.

From the standpoint of simulating the basic physics of spaceflight, these missions are an ideal starting point — we can disregard the complexity of orbital mechanics and concentrate on the relatively simple physics of ballistic motion.  This first attempt at creating an Applesoft Program to simulate ballistic motion is pretty bare-bones:  it doesn’t take air resistance into account, nor does it attempt to simulate the attitude of the spacecraft or any of the systems therein.  For all intents and purposes, we are simply simulating ballistic motion, be it a baseball, a cannon shell, or a spaceship.

100 TEXT : HOME : SPEED= 255
110 HGR : HCOLOR= 3
120 VTAB 21: ONERR GOTO 5000
130 LET HS = 2.74400055E - 03
140 LET VS = 6.26803705E - 03
150 GOSUB 4000
160 PRINT "SIMPLE BALLISTIC MOTION FOR THE APPLE ]["
170 PRINT 
180 INPUT "INITIAL VELOCITY: ";V0
190 IF V0 < > 0 THEN 210
200 NORMAL : TEXT : HOME : END 
210 IF V0 < 1000 THEN 240
220 PRINT "EXCESS VELOCITY. TRY AGAIN!"
230 GOTO 180
240 INPUT "LAUNCH ANGLE: ";TD
250 GOSUB 1000: REM CALCULATE FLIGHT DATA
260 GOSUB 3000: REM PLOT FLIGHT DATA
270 GOSUB 2000: REM DISPLAY FLIGHT DATA
280 GET A$: IF A$ = "" THEN 280
290 GOTO 170
1000 REM CALCULATE FLIGHT DATA
1010 LET G = 9.8
1020 LET PI = 22 / 7
1030 LET T = TD * (PI / 180)
1040 LET VX = V0 * COS (T)
1050 LET VY = V0 * SIN (T)
1060 LET H = (VY ^ 2) / (2 * G)
1070 LET TP = VY / G
1080 LET TT = TP * 2
1090 LET R = ((V0 ^ 2) * SIN (T * 2)) / G
1100 RETURN 
2000 REM DISPLAY FLIGHT DATA
2010 HOME : VTAB 21: HTAB 1: INVERSE 
2020 PRINT "ANGLE: ";
2030 VTAB 21: HTAB 21
2040 PRINT "VELOCITY: ";
2050 VTAB 22: HTAB 1
2060 PRINT "HEIGHT: ";
2070 VTAB 22: HTAB 21
2080 PRINT "RANGE: ";
2090 VTAB 23: HTAB 1
2100 PRINT "P TIME: ";
2110 VTAB 23: HTAB 21
2120 PRINT "T TIME: ";
2130 NORMAL : VTAB 21: HTAB 12
2140 PRINT INT (TD);
2150 VTAB 21: HTAB 32
2160 PRINT INT (V0);
2170 VTAB 22: HTAB 12
2180 PRINT INT (H);
2190 VTAB 22: HTAB 32
2200 PRINT INT (R);
2210 VTAB 23: HTAB 12
2220 PRINT INT (TP);
2230 VTAB 23: HTAB 32
2240 PRINT INT (TT);
2250 RETURN 
3000 REM PLOT TRAJECTORY IN HIGH RES
3010 REM 
3020 FOR ET = 0 TO INT (TT) STEP 0.5
3030 LET X = VX * ET * HS
3040 LET Y = VY * ET - (0.5 * G * ET ^ 2)
3050 LET Y = Y * VS
3060 HPLOT X,160 - Y
3070 NEXT ET
3080 LET PX = VX * TP * HS
3090 LET PY = (VY * TP - (0.5 * G * TP ^ 2)) * VS
3100 HPLOT INT (PX), INT (160 - PY) TO INT (PX),159
3110 RETURN 
4000 REM PLOT SCALE ON MONITOR
4010 HPLOT 0,0 TO 0,159
4020 HPLOT 0,159 TO 279,159
4030 FOR I = 0 TO 159 STEP INT (159 / 25)
4040 HPLOT 0,160 - I TO 5,160 - I
4050 NEXT I
4060 FOR I = 0 TO 279 STEP INT (280 / 100)
4070 HPLOT I,159 TO I,154
4080 NEXT I
4090 RETURN 
5000 REM ERROR HANDLING ROUTINE
5010 PRINT CHR$ (7);"RANGE ERROR -- VALUE EXCEEDS PLOT RESOLUTION."
5020 END

When the program begins, it draws a reticle on the screen used to scale the display.  In the vertical direction, output is scaled to approximately 26 kilometers and in the horizontal direction, output is scaled to approximately 101 kilometers.  Although this is not enough resolution to simulate the flight of the Mercury spacecraft, it is intended as a proof of concept for work that will follow.  In this case, the degree of scaling was chosen in order to simulate the flight of an object launched at up to 999 meters per second at a launch angle of 45 degrees.

After preparing the display, the program prompts the user to enter the initial velocity and the launch angle.  It then calculates the flight parameters, attempts to plot them on the screen, and displays the final parameters of the flight at the bottom of the screen.  The program then waits for a keystroke and returns to the initial prompt for velocity.  The user can then either enter a zero to terminate the program, or enter another set of launch parameters.  The display is NOT cleared for subsequent plots, the previous flight path remains on the display. This is intended to allow for comparison of multiple runs.  The sample shown below demonstrates three individual runs — each run used a velocity of 999 meters per second at a selection of launch angles at 15 degrees, 30 degrees, and 45 degrees from the horizontal.

ballistic_plot

As you can see, the program calculates that an object launched at a 45 degree angle and a velocity of 999 meters per second will reach a maximum height of 25,475 meters in 72 seconds and will travel downrange a distance of 101,836 meters in 144 seconds total elapsed time. These figures are approximate and in general agreement with the values found by various online ballistic calculators.

One online resource that was used to confirm these calculations is:  http://hyperphysics.phy-astr.gsu.edu/hbase/traj.html

There are several obvious objections that come to mind when considering how closely this sort of simulation corresponds to the behavior of actual spacecraft.  First, a rocket begins with a velocity of zero and actually accelerates as it is boosted upwards. True ballistic motion does not begin until acceleration ceases.  Secondly, large rockets (and spacecraft) are launched vertically at an angle of 90 degrees to the horizontal and then maneuver in order to obtain the desired trajectory.  Finally, this simulation is strictly two-dimensional whereas real rockets and spacecraft travel through three dimensions and have to deal with things like atmospheric resistance, lift, drag, and variable gravitational fields.  These are subjects for future experimentation.

 

The Spacecraft Coordinate System (Borrowed from Apollo)

Before simulating a spacecraft, we need to establish certain conventions that serve as an absolute reference for our position and attitude.  To this end, I’m planning to borrow the coordinate system used by the Apollo Spacecraft.

csmaxes

Using this model, we can describe spacecraft motion and maneuvers as either translation along a particular axis or rotation about one or more axes.

  • Roll is described as rotation about the X axis.
  • Pitch is described as rotation about the Y axis.
  • Yaw is described as rotation about the Z axis.

Spacecraft attitude, then, can be described by giving three angular measurements that describe the current degree of roll, pitch, and yaw. Likewise, we can describe rotation or tumbling of the spacecraft as a series of vectors that describe the rate at which the spacecraft is revolving about each axis.

Translation of the spacecraft along a particular axis describes how the overall mass of the spacecraft is moving – regardless of attitude.  In the initial boost phase following launch, the principle motion of the spacecraft is “upward” – describing positive translation along the X axis. Likewise, the force of gravity is found acting in opposition to thrust along the X-axis.  Wind can act upon either the Y or Z axis and cause the craft to deviate off course.

Shortly after liftoff, the spacecraft performs a roll maneuver to align the spacecraft on it’s heading relative to the Earth’s equator. Likewise a pitch maneuver marks the beginning of a gravity turn that allows the spacecraft to move in a particular direction as well as “up” away from the surface of the Earth. These initial maneuvers will determine the ballistic (and hopefully) orbital trajectory the spacecraft takes.

In order to describe the spacecraft’s absolute position and movement away from its point of origin, we need to measure its movement along each of the axes and maintain a record of its velocity along each axes.  We also need to estimate the current mass of the spacecraft to determine the properties of thrust and acceleration. Obviously, the mass of the spacecraft is constantly changing as fuel and oxidizer are expended. Likewise, the overall thrust of the craft is changing due to changes in atmospheric pressure and expansion of the gasses at various altitude.

Overall, our first task in simulating the flight of a spacecraft involves the integration of these and other parameters to describe the motion of the spacecraft.  Wherever possible, the mathematics will be simplified so that the Apple II Plus can calculate these values in real-time (or at least approximate them in real-time.)

drawingskey_12

Retrochallenge 2016 / 10

Greetings, Retronauts!

As always, participation in the annual Retrochallenge begins with nostalgia for those computers whose time has come and gone; it usually ends as an exercise in masochism.

My goal, this time around, is to convince my aging Apple II Plus that it can simulate a spacecraft with some degree of fidelity.  Having said that, I’m setting my sights pretty low since I’m only seeking to simulate the flight dynamics and underlying physics of ballistic and orbital flight. Unlike Kerbal Space Program or the mighty (and inscrutable) Orbiter, I’m not looking for photo-realistic graphics or high-end animation.

The core of the simulation is a data structure representing the spacecraft’s overall status at a single point in time:  Three-dimensional coordinates for its present location, a set of state-vectors indicating its relative motion, and spacecraft attitude (roll, pitch, and yaw.)  Other information describing the vehicle status includes its internal and external environment, fuel and oxidizer status, electrical power system status, communication parameters, and general spacecraft “health.”  At the moment, I’m trying to develop a spreadsheet (in VisiCalc, of course!) that brings all this data together in a single place.  From there, actual software development begins — mostly in Applesoft BASIC but may also entail 6502 assembly language and FORTRAN (if I can get the UCSD Pascal System running on real hardware.)

Here we go!

 

Determining the Altitude of a Model Rocket

Before we try and simulate a “real” spacecraft in flight, it might help to consider the problem of tracking a model rocket, or similar “simplified” ballistic problem. Using a single tracking station, with a known distance from the launch point, we can estimate the altitude using a single measured angle and some simple trigonometry:

diagram1

 

When we code this particular exercise in Applesoft BASIC, we need to remember to convert our angles (typically measured using degrees) to radians by multiplying by PI/180.

 1000 REM SINGLE STATION TRACKING OF A MODEL ROCKET
 1010 REM DETERMINES ALTITUDE BY MEASURING ANGLE AT
 1020 REM APOGEE GIVEN A KNOWN BASELINE.
 1030 TEXT : HOME : SPEED= 255
 1040 PRINT "MODEL ROCKET - SINGLE STATION TRACKING"
 1050 PRINT 
 1060 PRINT "DETERMINES ALTITUDE AT APOGEE GIVEN A KNOWN BASELINE AND SIGHT"
 1070 PRINT "ANGLE AT APOGEE."
 1080 PRINT 
 1090 INPUT "ENTER BASELINE (DISTANCE FROM LAUNCH PAD TO TRACKING STATION: ";B
 1100 PRINT 
 1110 INPUT "ENTER SIGHT ANGLE (REF GROUND) AT APOGEE: ";A
 1120 PRINT 
 1130 PRINT "THANK YOU."
 1140 PRINT 
 1150 REM CONVERT DEGREES TO RADIANS
 1160 LET PI = 22 / 7
 1170 LET A = A * (PI / 180)
 1180 REM NOW CALCULATE THE HEIGHT
 1190 LET H = B * TAN (A)
 1200 PRINT "THE ESTIMATED HEIGHT AT APOGEE WAS ";H
 1210 PRINT 
 1220 PRINT "END PROGRAM."
 1230 END

The program works pretty much as expected – given a known baseline and several “convenient” angles, we get results that are both intuitive and mathematically correct.  As long as the rocket’s flight path is perfectly vertical, we obtain a good approximation of the altitude at apogee.

screenshot_alt1

Since it’s unlikely that an Apple II computer will be portable enough to drag along on a rocketry field exercise, a better approach to this particular problem might be to create a table of baselines and sight angles that can be printed and carried afield when launching rockets.

 1000 TEXT : HOME : SPEED= 255
 1010 PRINT "TABLE OF ALTITUDES FOR MODEL ROCKETRY:"
 1020 PRINT 
 1025 PRINT TAB( 17);"BASELINE"
 1030 PRINT "DEG","100","200","300","400"
 1040 FOR I = 0 TO 79: PRINT "=";: NEXT I
 1050 FOR A = 5 TO 85 STEP 5
 1055 PRINT A,
 1060 FOR B = 100 TO 400 STEP 100
 1070 LET A1 = A * ((22 / 7) / 180)
 1080 LET H = B * TAN (A1)
 1090 REM TRUNCATE THE ANSWER
 1100 LET H = INT (H)
 1110 PRINT H,
 1120 NEXT B
 1130 NEXT A
 1140 END

A screenshot of the table-formatted output is shown below.  This can be easily printed on a half-sheet of paper and carried into the field.

screenshot_alt2

Warming Up for the Retrochallenge

telescope_41073Simulating a spacecraft — or more accurately simulating spaceflight — will involve any number of astronomical calculations.  At the minimum, for a simple simulation of a ballistic or orbital spaceflight, one must solve the “two body problem” when finding the spacecraft’s trajectory.  Long before Galileo, Newton, Copernicus, or Kepler dared to challenge conventional wisdom or the church itself, the clergy found themselves with a similar problem:  What is the date of Easter?

Easter is normally defined as the first sunday after the fourteenth day after the first new moon following the Vernal Equinox… Since the date of Easter is determined by the date of Passover and we’re mixing both a solar and lunar calendar (courtesy of the ancient Hebrews) with the modifications to the solar calendar courtesy of both Julius Caesar and Pope Gregory, the problem becomes one not only of Sun, Moon, and Earth but one of Political whim and Ecclesiastical dogma… Are we sure they didn’t have computers back in the middle ages?  Oh, yes!  They were called “Monks!”

Anyway, the best definition for Easter (and the means by which one can calculate the date) can be found in ‘The Explanatory Supplement to the Astronomical Ephemeris and American Ephemeris and Nautical Almanac.”  Otherwise, there are some nice tables in the ‘Book of Common Prayer (1662)’, and an algorithm found in ‘Butcher’s Ecclesiastical Calendar’ published in 1876.  A variant of this algorithm, prepared for use with a handheld calculator, was printed in ‘Practical Astronomy with Your Calculator’ by Peter Duffett-Smith in 1979.

Applesoft Source Code Follows:

]LIST

 1000 REM FIND THE DATE OF EASTER
 1010 REM WORDS FOR ANY YEAR IN THE GREGORIAN CALENDAR FROM
 1020 REM 1583 ONWARDS
 1030 REM 
 1040 REM ALGORITHM IS TAKEN FROM THE BOOK 'PRACTICAL ASTRONOMY
 1050 REM WITH YOUR CALCULATOR' BY PETER DUFFETT-SMITH, COPYRIGHT
 1060 REM 1979 BY CAMBRIDGE UNIVERSITY PRESS.
 1070 REM 
 1080 TEXT : HOME : SPEED= 255
 1090 PRINT "CALCULATE THE DATE OF EASTER:"
 1100 PRINT 
 1110 INPUT "PLEASE ENTER THE YEAR (POST 1583 AD): ";Y
 1120 PRINT 
 1130 IF Y > = 1583 THEN 1170
 1140 PRINT "SORRY, YEAR MUST BE GREATER THAN 1583."
 1150 PRINT 
 1160 GOTO 1110
 1170 LET A = Y - ( INT (Y / 19) * 19)
 1180 LET B = INT (Y / 100)
 1190 LET C = Y - (B * 100)
 1200 LET D = INT (B / 4)
 1210 LET E = B - (D * 4)
 1220 LET F = INT ((B + 8) / 25)
 1230 LET G = INT ((B - F + 1) / 3)
 1240 LET H1 = 19 * A + B - D - G + 15
 1250 LET H = H1 - ( INT (H1 / 30) * 30)
 1260 LET I = INT (C / 4)
 1270 LET K = C - (I * 4)
 1280 LET L1 = 32 + 2 * E + 2 * I - H - K
 1290 LET L2 = INT (L1 / 7)
 1300 LET L = L1 - (L2 * 7)
 1310 LET M = INT ((A + 11 * H + 22 * L) / 451)
 1320 LET N1 = (H + L - 7 * M + 114)
 1330 LET N = INT (N1 / 31)
 1430 LET P = N1 - (N * 31) + 1
 1440 PRINT "MONTH: ";N
 1450 PRINT "DAY: ";P
 1460 PRINT 
 1470 PRINT "END PROGRAM."
 1480 END

]

easter_2017