Cold Fronts

by Jack Sharp

Appendix A: Technical Notes


Technical Note 1, Chapter 6:

Real-time multi-tasking programming

The concept of real-time, multi-tasking computer systems is rather straight-forward, easy to understand if presented in terms we can recognize from our every-day experiences. We spend much of our lives with more than one task left to perform and constantly budget our time according to our priorities. When higher priority tasks present themselves while we’re performing lower priority, more mundane, chores, we simply suspend the lower priority one and go back to it after we’ve completed the more important one that barged in on us.

An example familiar to most of us might be a typical morning spent by a young mother home alone with her new baby. Her child’s health and well-being are obviously her number one priorities. She would most probably let the phone ring and not answer it until a baby’s urgent need is met. If she is washing the morning dishes, for instance – a much lower priority task – and junior starts to cry with any sense of urgency, she will stop doing the dishes and run upstairs to tend to him or her. If the doorbell rings before she finishes with the tot she will finish taking care of the baby’s needs before answering the door.

The visitor at the door normally has a higher priority than an unfinished sink full of dishes, so once her baby is taken care of, she will answer the door before returning to the dishes. Suppose the phone rings while she is still at the door? Depending on her priorities, she may or may not answer the phone before her visitor at the door is attended to. After taking care of both the door and the phone, she could again return to the unfinished dishes in the kitchen before she begins another equally lower priority job like vacuuming the rug or making the bed. If her child cried again while she was at the door or on the phone she would most likely say “just a minute” and go attend to her baby. She is living a real-time multi-tasked life – but then aren’t we all?

A real-time multi-tasking computer is programmed to do exactly what this young mother does instinctively. The only difference is that the computer has to be told the relative priorities of all of its possible tasks; it has no intuitive sense of responsibility – it really doesn’t care.


Technical Note 2, Chapter 7:

Not too loose, not too tight

The challenge of writing a decoder is to make it neither too loose nor too strict. For instance, if a space was inadvertently inserted in the middle of an NNNN or LLLL the decoder had to allow that the four characters might not arrive consecutively. We had already studied a lot of data and saw that this happened frequently enough that we better code for it. So how many different acceptable forms is enough? Most decoder instructions are what we call exceptional coding that handles non-standard formats.

The following amusing incident will illustrate the challenge. My first attempt at EOM recognition was to simply count the number of “N”s or “L”s in the first two words of every line. It seemed to be working well until we noticed one day that an Federal Aviation Administration (FAA) NOTAM was cut in the middle. My decoder had found four “L”s in the first two words of a line in the NOTAM, however they properly belonged there in the name of a city in the state of Washington: Walla Walla.

“Too loose! . . . Tighten it up, Jack, – but not too tight.” . . . Three consecutive “N”s or “L”s in a row with the possibility of a space inadvertently inserted in the sequence was our final solution.

This kind of work is fun for those who like solving puzzles. I enjoyed it much more than performing loops and barrel-rolls at Pensacola.


Technical Note 3, Chapter 7:

Syntax words facilitate decoding

Every weather collective starts with a bulletin heading that tells the data type, region or country of origin, broadcast station, plus a date/time group.


The header for a surface synoptic collective from High Wycombe England would look like this:


  • SMUK EGWH 031200Z


    SM = surface synoptic

    UK = from the United Kingdom

    EG = broadcasted in England

    WH = at High Wycombe

    03 = day of the month

    1200 = hour of the day

    Z = Greenwich mean time

  • As LNMAKR empties characters from input buffers to build data lines, it also constructs certain syntax descriptor words essential to the decoding process. Syntax descriptors for the above header would look like this:


    4 444406 110000 000000 000000


    Which means that there are four groups in the line. The first two groups, SMUK and EGWH, each have four characters – all letters, the third group, 031200, has six numerals and is followed by a fourth group containing the character “Z”. Another syntax word, not shown above, would show that there was no space between the date/time group and the “Z” character. We called this a runtogether. So with just a few easy checks of the syntax descriptor words, LINPRO can decide that the data line is probably a bulletin heading.


    A surface synoptic weather observation from an English weather station looks like this:


  • 03113 81615 32545 99845 12365 12345

    IIiii Nddff VVwwW PPPTT NhClhCmCh TdTdapp


    II = World Meteorological Organization block number

    iii = Station number

    N = Total sky cover (in eighths)

    dd = Wind direction (10’s of degrees)

    ff = Wind force (knots)

    VV = Visibility

    ww = Present weather

    W = Past weather (last three hours)

    PPP = Sea level pressure

    TT = Temperature

    Nh = Amount of low or middle clouds

    Cl = Type of low cloud

    h = Height of low cloud

    Cm = Type of middle cloud

    Ch = Type of high cloud

    TdTd = Dew point temperature

    a = Pressure tendency (last three hours)

    pp = Pressure change (last three hours)

  • Syntax descriptors for the above observation would look like this:


    8 050505 050505 050500 000000


    These descriptor words tell us that the observation contains eight groups and that each group has five characters in it, all numerals. Both surface synoptic and upper air data formats have the same syntax.

    These two examples will hopefully show how syntax indicator words facilitate decoding.


    Technical Note 4. Chapter 8:

    The wrong character

    Moscow’s four-letter call sign was received most of the time with numerals where letters should have been (but always the same numerals). It would have been simple to code for this garbled version, but letter characters in other data, including the “TT” group in vital upper air soundings were also regularly garbled. Obviously, the letters-shift character was either missing or garbled. What caused this?

    Fortunately, we had designed the system to write every character received out onto a magnetic tape before our coding (LNMAKR) was allowed to touch it. This was essential if we ever hoped to solve problems such as this. I printed out about twenty or so pages of this “raw” data from a magnetic tape and studied it and the answer was there in front of me, plain as day. Every time a header was garbled, the letters shift was missing – but another character was received in its place; an unprintable character. Luckily we had assigned otherwise unused characters to represent every possible five-level code combination. The mystery character replacing the letters-shift was an upper-case “H” that in five-level baudot coded as a zero – no bits on at all. I checked the five-level code for a letter shift and it had all five bits on. Somehow Russian transmitters would get confused and send five off-bits (zeros) in place of five on-bits (ones). Eureka again! A measly four program statements was all that was required to clear up this serious operational problem that waited two years for someone to investigate. The solution was as follows:


    1. Get the control word that contains the intercept circuit indicator bit.

    2. Was this character from an intercept circuit?

    3. If yes, make believe the character was a letters-shift.

    4. If no, drop the character – it’s only garble.


    Following are the actual assembly language program instruction cards as they appear in the programming listing:






  • As if by magic every one of the bulletin headers, upper air observation “TT”s, and all other letter characters now showed their true identity and we could proceed with our plans straight away. I called Fuchu to tell them what I had uncovered, thinking they must have been experiencing the same problem, but was told that Mr. Junichi Himi, a Japanese national working for the Air Force there, had solved the same problems already but never imagined that Wycombe hadn’t also found out about it. Mr. Himi had been in charge of Fuchu’s Punch Card Section for several years. MSG Rice and CMS Rosenberry worked with Mr. Himi during earlier assignments at Fuchu and both regarded him as a genius.


    Technical Note 5, Chapter 9:

    Sunsynchronous satellites

    Sunsynchronous means that no matter where the spacecraft crosses the equator, it is always the same time of day (local time). For instance, if a 10 a.m. bird crosses the equator heading north, the local standard time at a point on the ground directly below the spacecraft is 10 a.m. Twelve hours later, 10 p.m., the craft will again cross the equator at the same point, but this time it will be headed south. – the Earth will have made half a rotation. To picture this in your mind, imagine that these satellites travel in their near-polar orbit along the outside surface of a metal ring which is always in the same plain as the centers of both the Earth and the Sun while the Earth rotates inside the ring from west to east.

    Each orbit takes exactly one hour, during which time fifteen degrees of longitude – one twenty-fourth of the circumference of the Earth – will have passed through the ring (from west to east). In twenty-four hours, the entire surface of the Earth will have passed through the ring, so when the bird crossed the equator at the same point from the day before, it will again be exactly 10 a.m..

    I’ve always wondered how DMSP satellites stay oriented to the Earth and sun, so I asked Jim Kennedy, who has a masters degree in astro-physics, to explain this to me in lay terms. This is what he told me.

    My question was: Why don’t these satellite point ninety degrees off from the center of the sun three months after their launches – one quarter of a year later and one quarter of the way around the sun (see figure 7 below)?




    Figure 7


    His answer was:

    To keep a DMSP bird’s nose pointed toward the sun, it must be launched at a certain angle relative to the equator (98 degrees – aimed 8 degrees to the left of the North Pole) and at a specific altitude (approximately 450 miles above the Earth). These two parameters utilize the shape of the Earth, an oblate spheroid (bulged at the equator), to torque (twist) each satellite’s orbit approximately one degree to their left per day. Since there are 360 degrees in an orbit and 365 days in a year, this amounts to close to one degree regression per day. And so, clever engineers who understand orbital physics compute the necessary orbit altitude and “inclination angle” and advise the launching facility exactly how to aim these birds. The craft have no on-board means of accomplishing the above maneuver.

    But what about the orientation to its camera which must always be pointed straight down toward its sub-satellite point. If some arrangement is not made, by the time the bird reached the North Pole, the camera would be pointing out into space. Again, some clever engineering compensates. Electric wires are wrapped around the satellite, and at launch time, a current of specific amperage is run through the wire coil allowing the Earth’s magnetic field to provide a torque that twists the bird around its orbital plain, providing the needed ninety degrees every one fourth of an orbit (fifteen minutes). According to Jim, this current must be modified after every one-quarter orbit. This is, of course, very complicated, but it must work, for DMSP birds have been in sunsynchronous, near-polar orbits for well over thirty years at the time of writing.


    Technical Note 6, Chapter 11


    Lorenz perceives chaos

    “One day in the winter of 1961, wanting to examine one sequence [in a test run of a rudimentary numerical forecast model] at greater length, Lorenz took a shortcut. Instead of starting the whole run over, he started midway through. To give the machine its initial conditions, he typed the numbers straight from an earlier printout. Then he walked down the hall to get away from the noise and drink a cup of coffee. When he returned an hour later, he saw something unexpected, something that planted a seed for a new science.

    This new run should have exactly duplicated the old. Lorenz had copied the numbers into the machine himself. The program had not changed. Yet as he stared at the new printout, Lorenz saw his weather diverging so rapidly from the pattern of the last run that, within just a few months, all resemblance had disappeared. He looked at one set of numbers, than back at the other. He might as well have chosen random weathers out of a hat. His first thought was that another vacuum tube had gone bad.

    Suddenly he realized the truth. There had been no malfunction. The problem lay in the numbers he had typed. Within the computer’s memory, six decimal places were stored: 0.506127. To save space, on the printout, just three appeared: 0.506. Lorenz had entered the shorter, rounded-off numbers, assuming that the difference – one part in ten thousand – was inconsequential.”

    This sensitivity to initial conditions is sometimes called The Butterfly Effect; the conjecture that if a butterfly flaps its wings in a garden in Beijing, China, the resulting wave could grow, developing into a major winter storm that, ten days later, dumps a foot of snow on New York City.

    Back to Cold Fronts Table of Contents