“Captain's log, stardate 41153.7. Our destination is planet Deneb Four, beyond which lies the great unexplored mass of the galaxy...”

Jean-Luc Picard, Star Trek: The Next Generation, “Encounter at Farpoint”

A captain, a destination, and a timestamp from the future. Each log entry felt like a page from a history we hadn’t lived yet.

For our Starbase 430 Mission Log entries, I wanted some of that same feeling. I found my starting point in The Dragon De Monsyne’s explanation of After Epoch Astronauticum, or AEA. I’ve built on their idea with my own proposal: First Step Epoch.

From AEA to First Step Epoch

An epoch gives a timekeeping system its starting point. Choosing that point was the first decision I needed to make.

The Dragon De Monsyne drew inspiration from Apollo 11 but counted AEA from January 1, 1970 at 00:00:00 GMT, the Unix epoch.

I considered several milestones for FSE: the first atomic bomb detonation, Sputnik’s launch, Laika’s flight and tragic loss, Belka and Strelka’s safe return, or Yuri Gagarin’s historic orbit.

In the end, my choice was personal. I was born a few months before Apollo 11 launched and grew up as an American kid idolizing the Apollo crews. Armstrong’s first step captured the optimistic future I wanted Starbase 430 to reflect.

I set First Step Epoch’s zero to July 21, 1969 at 02:56:15 UTC, marking Armstrong’s first step onto the Moon.

Getting a feel for the units

FSE counts seconds. To make the numbers more manageable, I used metric prefixes, the same idea as grouping a thousand meters into a kilometer:

• 1 kilosecond (ks): 1,000 seconds, or 16 minutes and 40 seconds.
• 100 ks: about 27.8 hours.
• 1 megasecond (Ms): about 11.6 days.
• 10 Ms: about 115.7 days.
• 1 gigasecond (Gs): about 31.7 years.

These comparisons helped me get a feel for the scale. A megasecond is about a week and a half, while a gigasecond is roughly a generation. I chose megaseconds for the Log labels because the longer whole-number count feels closer to the science-fiction timestamps that inspired them. Six decimal places let each label record individual seconds.

The units don’t depend on Earth’s rotation or orbit, so they would still be useful somewhere with a different day or year. We’re counting familiar seconds, just grouping them differently.

Reading a Starbase Log label

The Pablo retrospective carries this label:

STARBASE LOG +1808.227499 Ms FSE

• + places the timestamp after our epoch; earlier dates get a minus sign.
• 1808.227499 is the elapsed count, equivalent to 1,808,227,499 completed seconds.
• Ms means megaseconds: units of one million seconds.
• Six decimal places give the count one-second resolution.
• FSE identifies the starting point: Armstrong’s first step onto the Moon.

For Pablo, that means November 7, 2026 at 11:20:45 a.m. in New York, or 16:20:45 UTC. I kept the familiar calendar date in the byline so readers don’t need to do any arithmetic.

Working with the numbers

Finding the interval between two entries

To find the time between two entries, I can simply subtract their FSE timestamps. The website-development entry has +1808.058619 Ms FSE, and the Pablo retrospective has +1808.227499 Ms FSE:

1808.227499 − 1808.058619 = 0.168880 Ms

Multiplying by a million gives 168,880 seconds, or 46 hours, 54 minutes, and 40 seconds, between their publication timestamps. Both labels use the same time scale and starting point, so there are no month lengths or time-zone changes to account for.

Counting every second

I wanted FSE to count every elapsed second, including leap seconds. That meant I couldn’t simply subtract two ordinary Unix timestamps, because Unix time leaves leap seconds out of its count.

Instead, I used International Atomic Time, or TAI, a continuous time scale based on atomic-clock measurements. UTC, the reference behind our everyday calendar dates, has included leap-second adjustments to stay close to Earth’s rotation. TAI gives FSE a continuous count through those adjustments.

The calculation is:

FSE seconds = TAI at the event − TAI at our chosen epoch

To calculate an FSE timestamp, I:

1. Convert the event’s time and our epoch to TAI.
2. Subtract the epoch from the event’s time to get elapsed seconds.
3. Divide by 1,000,000 to express the result in megaseconds.

A timeline of scientific discovery

These milestones give the FSE count a human scale, tracing exploration and scientific discovery from the early space age to today. Familiar achievements become reference points for reading the numbers.

Each card starts with its FSE timestamp and ends with the familiar calendar date. Italic values marked ≈ are approximate; their precision reflects what the historical sources document.

On wider screens, the timeline shows elapsed time proportionally. On smaller screens, the cards form a compact chronological list, with spacing adjusted for readability.

November 12, 2026 · Timeline reference date · +1808.600654 Ms FSE

Following the trail

The Dragon De Monsyne’s page started this journey, and I’m grateful that the archived explanation of AEA is still available. FSE is my own variation, but their idea gave me a different way to think about time.

If you’d like to explore further:

• Atomic Rockets’ discussion of metric time connects alternative timekeeping with science fiction.
• Wikipedia’s metric time article introduces other ways to measure and organize time.
• Armstrong’s first steps on the Moon returns to the moment I chose as FSE’s starting point. The 62-second video includes captions.

The BIPM references earlier in this article explain the units and time scale, and each timeline heading links to its historical source.

For me, FSE connects an everyday habit with something that still inspires me. Every Log entry counts forward from humanity’s first step onto another world. I like having that reminder of what curiosity and determination can accomplish.

It never really seemed to matter what I was creating. Duct-taping old office chairs together into the jankiest soapbox derby car ever, baking over-the-top cakes for my family and friends, and playing with robotics and programming all seem to scratch the same deep-seated desire to bring something new to life. The more bizarre and interesting, the better.

Pablo the Polargraph is a great example of this. I want to revisit what it took to create it as a reminder of the kind of projects I want to start making again.

Pablo began during the early days of Knox Makers, while we were still located in Oak Ridge near ORNL. The number of new members had plateaued, and we were looking for ways to introduce more people to the makerspace. We'd been discussing taking interactive exhibits to local craft and science events to show people what a makerspace could offer. We really needed something easily portable that would catch someone’s eye and give them a reason to stop and talk.

While randomly surfing the web, I stumbled upon an article about a Polargraph Drawing Machine on Instructables and just had to build an art robot. A robot drawing pictures seemed like a fantastic conversation starter.

Getting something moving

A polargraph moves a pen across a drawing surface by changing the length of two suspended lines. Pablo used ball chain driven by two stepper motors, with an Arduino running the motor-control software.

I started mostly on my own, and there wasn’t much interest at first. That changed once I had something physically sitting in the makerspace. Having an actual contraption to poke at gave people a reason to wander over and get involved.

Our first group working session was April 11, 2014. I’d spent several weeks pushing the idea forward and doing much of the early work solo. That session was when other Knox Makers members really started helping turn it into a finished machine.

Only a few parts of that early prototype lasted through the final version, including the stepper motors and the ball chain. Other parts needed a lot more work.

The first printed drive gears slipped against the chain. We went through what I remember as three or four versions before finding a shape that worked reliably with ordinary ball chain from a home-improvement store.

We also added weights to keep the chain engaged with the gears. At first, we used fishing weights or whatever suitable weights we could find. Later, I replaced those with heavier decorative ceiling-fan pull-chain weights. They helped stabilize the mechanism and looked much more polished.

Learning to lift the pen

The first pen holder was a clear plastic spacer disc from a package of writable CDs. Being able to see through it was handy. Unfortunately, it couldn’t lift the pen off the paper, so every drawing had to be one continuous line. That became a pretty significant limitation almost immediately.

Looking at other Polargraph projects gave us the solution: a small servo to lift the pen. We connected one to the Arduino and added control over when the pen touched the paper. That let Pablo move between separate lines without drawing a connection between them.

I remember using GIMP to prepare the images. By the time we had it working well, preparing a new image was fairly quick and required few extra steps. There’s no way I could walk someone through the whole software setup from memory now.

Pablo itself worked at a more leisurely pace. A drawing usually took a few minutes.

Becoming Pablo

Moving the prototype around made it clear that it needed a stand.

The drawing surface was a large piece of plywood with embedded magnets to hold the paper. Putting it on a wooden artist’s easel was the point where it really became Pablo. The easel also gave us a theme for the whole project. It looked like a robotic artist, so we committed to the idea with white paint and vinyl graphics identifying Pablo and Knox Makers.

The easel, lettering, and finished surface brought the separate components together into something that felt ready to exhibit.

By April 24, 2014, the first complete working version had taken on Pablo’s full form. There were smaller updates afterward, but that was the point when it became the finished machine I remember.

Finding an audience

Pablo had mixed results at general craft fairs. Some people noticed it and came over to talk, but it attracted much more interest at events focused on technology and making.

One of the first strong responses I remember was at a mini Maker Faire at Pellissippi State. We were exhibiting beside a makerspace member demonstrating 3D scanning and a local library developing its own maker activities.

I think that setting helped. Visitors could see a group of related exhibits, and Pablo’s polished appearance gave them something approachable to stop and watch.

Those were the events where Pablo did what we’d hoped: gave people something interesting to watch while we talked about Knox Makers.

Why I’m revisiting it

Pablo is one of the projects I’m most proud of because of how finished it became and how long it lasted.

I’ve built plenty of small electronics and robotics projects over the years. Many had useful lives measured in months. Pablo was sturdy enough to move between events, and we took it around for at least seven or eight years. Throughout that time, it kept doing its job: sitting at an easel, making art, and attracting attention.

I still need to check where it is today and when it was last used. This account comes from my recollections and the photographs I kept, so some details remain uncertain. Although I’ve now found the original inspiration, I no longer remember exactly which design details or instructions we used.

That’s what I wanted to revisit: an odd idea that became something useful, with help from other people and a lot of tinkering. It kept making art for years. I’d like to get back to making things that give me that same feeling.

Interactive simulation

Further reading

• Polargraph Drawing Machine on Instructables: the article that originally inspired me.
• Polargraph software and hardware designs on GitHub: the related repository from that original inspiration.

That led me to Eleventy, a tool that turns Markdown and page templates into ordinary static files. I kept the writing in readable text and avoided the need for a database or an application server. I wanted a change of hosting to mean moving files, not rebuilding our project stories around another publishing system.

A visual identity with a simple foundation

I wanted the site to feel like a futuristic outpost workshop, so I used green accents, silver borders, rounded frames, and dark reading panels to give it that character while leaving the writing at the center. For the backdrop, I chose soft nebula colors and dense stars made with CSS gradients. That gave me the atmosphere I wanted without a background image download. I used system fonts to avoid another download.

I kept the main navigation compact. Numbered chapter links sit beside longer pages when there is room and move into a top-down reading flow on smaller screens.

Keeping the pages small and usable

I made reading and navigation work without JavaScript. Ordinary headings and links were enough for those jobs. I also left out advertising and tracking. Neither fits the optimistic future I wanted the site to suggest.

I used the Web Content Accessibility Guidelines, WCAG 2.2 AA, to guide decisions about keyboard focus, contrast, responsive layouts, reduced motion, and readability without stylesheets.

I set a preferred budget of 100,000 uncompressed bytes for a page and its required resources, with a hard ceiling of 512,000 bytes. I wanted small pages to be a design constraint from the beginning, rather than an optimization task left until the end. I added a checker that counted HTML, styles, images, and other required local resources, including every responsive image alternative.

One Log for project stories and updates

I initially separated Projects from the Log, then realized I was creating two publishing paths for closely related writing. I brought project stories, retrospectives, and smaller updates into one Log instead. That gave me one workflow without requiring every entry to be the same length or follow the same structure.

I chose one RSS feed at /feed.xml for the 20 newest published Log entries and included the full text. I wanted people to be able to read in their feed reader, not just receive a link back to the site.

I gave each entry an explicit slug, the short name used in its URL, so renaming a source file would not change its published address. I also separated publication dates from original project dates. That will let me document an older build as a retrospective without pretending I had published an account of it years earlier.

Making room for unfinished writing

I made drafts part of the normal workflow rather than keeping unfinished writing somewhere outside the site. A draft appears in the local preview with its photographs and other assets, while the production build excludes it from pages, indexes, and feeds. Draft-only assets are excluded too. That gave me a way to review the whole entry without making the writing or its images public.

Sharing the useful parts

I chose the MIT License for the reusable site code because I wanted other people to be able to learn from it, adapt it, and use it in their own projects, including commercial ones. I'm comfortable allowing private modifications rather than requiring people to share every change.

I kept our writing, photographs, artwork, and identity assets separate from that software license. Being willing to share the machinery behind the site did not need to mean granting blanket reuse rights to everything we put on it. I also made sure to keep other creators' work under its own permissions and credits.

I treated code licensing, making the source public, and publishing the website as separate decisions. That gave me room to review the writing, images, and technical checks without turning a source-code update into an accidental launch.

Taken together, these choices gave our projects a home I could understand and maintain. The point was to spend time telling the stories of what we made, what changed along the way, and what we learned. The Colophon has more detail about how the site was made.