Gemma’s Open Research

Extraterrestrial Intelligence: An International Petition

2025-11-24T21:29:00+00:00

In a paper in 1982 [1], astronomer and science communicator Carl Sagan, together with 68 other leading scientists in the fields of astronomy and biology, published a letter in the prestigious research journal Science petitioning for an international coordinated systematic search for extraterrestrial intelligence (ETI) to begin immediately.

Here are my notes on this letter. You can find my notes on other classic SETI papers in my roundup of the technosignatures literature.

The result of a thorough search for ETI would be profound

Sagan et al. argued that public support existed for a search for ETI and that either a positive or negative result would have profound implications for our view of the universe. A systematic international effort would be low cost and a million times more thorough than any search done thus far.

The technology for detecting ETI is already available

Technology in the 80s was already able to detect radio signals from extraterrestrial civilisations, with an equivalent level of technology to our own, 1000s of light years away.

This is still true today and when the square kilometer array (SKA) is operational it will increase the searchable volume of our galaxy by a factor of 1,000.

The absence of evidence for advanced extraterrestrial civilisations is not enough

By 1982, there were several publications that argued that because intelligent extraterrestrial beings were not already here, they do not exist [2,3]. Sagan et al. argued that this line of reasoning relies heavily on extrapolation of technological capabilities. A radio search, however, assumes technology no more advanced than our own. The authors concluded that a priori arguments are not a substitute for an observational program.

The search should begin now (in the 80s)

The authors argued that detecting radio signals from ETI will become harder as time goes on due to increasing radio frequency interference (RFI) generated by humanity. They petitioned for an observational program to begin immediately.

Certain radio frequency bands are still protected for radio astronomy (including bands 1400–1427 MHz and 1660.6–1670.0 MHz that sit in the ‘water hole’, which is 1420 to 1662 MHz and argued to be a strong candidate band for beacons from ETI). This protection is orchestrated by the International Telecommunication Union (ITU). The increase in RFI has nevertheless certainly come to pass and, unforeseen in the 80s, has been exacerbated by the deployment of satellite constellations in low Earth orbit (you can see a 3D visualisation at this tracking site) – there are over 10,000 currently in orbit with many more planned. These have intentional transmissions in the unprotected radio bands as well as unintentional emissions in the low radio frequency range [4] – both can interfere with detecting faint radio signals from space.

Summary

This short letter petitioned for a systematic international search effort to detect radio signals from extraterrestrial intelligence. It summarised the main arguments and was signed by leading scientists across the globe.

References

1. Sagan C: Extraterrestrial Intelligence: An International Petition. Science 1982, 218:426–426.
2. Hart MH: Explanation for the Absence of Extraterrestrials on Earth. Quarterly Journal of the Royal Astronomical Society 1975, 16:128.
3. Tipler FJ: Extraterrestrial Intelligent Beings Do Not Exist. Quarterly Journal of the Royal Astronomical Society 1980, 21:267–281.
4. Vruno FD, Winkel B, Bassa CG, Józsa GIG, Brentjens MA, Jessner A, Garrington S: Unintended Electromagnetic Radiation from Starlink Satellites Detected with LOFAR between 110 and 188 MHz. Astronomy & Astrophysics 2023, 676:A75.

Technosignatures literature roundup

2025-11-24T21:20:00+00:00

Reviewing the literature is an important part of the research process. It gives you a deeper knowledge of the field and prevents you re-inventing the wheel. As part of my open research project (currently focussed on exoplanet technosignatures) I am documenting my review of the literature by writing summaries of important concepts and interesting papers I come across.

It is a good idea to read some historical papers when getting to know a new field. Early papers put more recent studies into context and ensure that you are not relying on citations that may or may not accurately represent previous research. There are always key references that are cited over and over again. It is also interesting to see how attitudes to different ideas change over time.

After reading a few modern studies, I decided to refocus my efforts on some classic SETI papers to get a better grounding in how the field began.

This post tracks the papers I and have read together with my core “to-read” list. This list is incomplete and dynamic since there will always be new citation trails to follow as I read more papers.

For each paper I’ve read I include links to the publication followed by links to my notes and/or notebooks.

Technosignature papers read

Kaltenegger L, Faherty JK: Past, Present and Future Stars That Can See Earth as a Transiting Exoplanet. Nature 2021, 594:505–507
- What exoplanets can see technosignatures from Earth?
Cocconi G, Morrison P: Searching for Interstellar Communications. Nature 1959, 184:844–846.
- The search for interstellar communications
- Jupyter notebook
Bracewell RN: Communications from Superior Galactic Communities. Nature 1960, 186:670–671.
- Communications from superior galactic communities
Drake FD: Project Ozma. Physics Today 1961, 14:40–46.
- Project Ozma
Dyson FJ: Search for Artificial Stellar Sources of Infrared Radiation. Science 1960, 131:1667–1668.
- Dyson spheres
Schwartz RN, Townes CH: Interstellar and Interplanetary Communication by Optical Masers. Nature 1961, 190:205–208.
- Interstellar communications by optical masers
Kardashev NS: Transmission of Information by Extraterrestrial Civilizations. Soviet Astronomy 1964, 8:217.
- Kardashev classification scheme for extraterrestrial civilisations
Drake FD: THE RADIO SEARCH FOR INTELLIGENT EXTRATERRESTRIAL LIFE. In Current Aspects of Exobiology. Elsevier; 1965:323–345.
- The Drake Equation
Hoerner SV: The Search for Signals from Other Civilizations. Science, New Series 1961, 134:1839–1843.
- Waiting times and longevity
Project Cyclops: a Design Study of a System for Detecting Extraterrestrial Intelligent Life. 1972.
- Project Cyclops Part I
- Project Cyclops Part II
Dixon RS: A search strategy for finding extraterrestrial radio beacons. Icarus 1973, 20:187–199.
- A search strategy for finding extraterrestrial radio beacons
Hart MH: Explanation for the Absence of Extraterrestrials on Earth. Quarterly Journal of the Royal Astronomical Society 1975, 16:128.
- Why are extraterrestrials not on Earth?
The Staff at the National Astronomy: The Arecibo message of November, 1974. Icarus 1975, 26:462–466.
- The Arecibo message of 1974
Oliver B M: Rationale for the water hole. Acta Astronautica 1979, 6:71–79.
- Rationale for the water hole
Tipler FJ: Extraterrestrial intelligent beings do not exist. Quarterly Journal of the Royal Astronomical Society 1980, 21:267–281.
- ETI does not exist
Sagan C: Extraterrestrial Intelligence: An International Petition. Science 1982, 218:426–426.
- Extraterrestrial Intelligence: An International Petition

Technosignature papers currently reading

Lord S, Dixon R, Healy T: Project OASIS: The Design of a Signal Detector for the Search for Extraterrestrial Intelligence. 1981.
- Project Oasis - part I

Technosignature papers to-read

Sagan C, Newman WI: The Solipsist Approach to Extraterrestrial Intelligence. Quarterly Journal of the Royal Astronomical Society 1983, 24:113.
Townes CH: At what wavelengths should we search for signals from extraterrestrial intelligence? 1983, doi:https://doi.org/10.1073/pnas.80.4.1147.
Horowitz P, Sagan C, Horowitz P, Sagan C: Five Years of Project META: an All-Sky Narrow-Band Radio Search for Extraterrestrial Signals. ApJ 1993, 415:218.
Tarter J: THE SEARCH FOR EXTRATERRESTRIAL INTELLIGENCE (SETI). 2001.
Tarter JC, Agrawal A, Ackermann R, Backus P, Blair SK, Bradford MT, Harp GR, Jordan J, Kilsdonk T, Smolek KE, et al.: SETI turns 50: five decades of progress in the search for extraterrestrial intelligence. 2010, 7819:781902.
Shuch HP: Searching for Extraterrestrial Intelligence: SETI Past, Present, and Future. Springer Berlin Heidelberg; 2011.
Isaacson H, Siemion APV, Marcy GW, Lebofsky M, Price DC, MacMahon D, Croft S, DeBoer D, Hickish J, Werthimer D, et al.: The Breakthrough Listen Search for Intelligent Life: Target Selection of Nearby Stars and Galaxies. PASP 2017, 129:054501.
Worden SP, Drew J, Siemion A, Werthimer D, DeBoer D, Croft S, MacMahon D, Lebofsky M, Isaacson H, Hickish J, et al.: Breakthrough Listen – A new search for life in the universe. Acta Astronautica 2017, 139:98–101.
Wright JT, Kanodia S, Lubar E: How Much SETI Has Been Done? Finding Needles in the n-dimensional Cosmic Haystack. AJ 2018, 156:260.
Lebofsky M, Croft S, Siemion APV, Price DC, Enriquez JE, Isaacson H, MacMahon DHE, Anderson D, Brzycki B, Cobb J, et al.: The Breakthrough Listen Search for Intelligent Life: Public Data, Formats, Reduction and Archiving. PASP 2019, 131:124505.
Price DC, Enriquez JE, Brzycki B, Croft S, Czech D, DeBoer D, DeMarines J, Foster G, Gajjar V, Gizani N, et al.: The Breakthrough Listen Search for Intelligent Life: Observations of 1327 Nearby Stars Over 1.10–3.45 GHz. The Astronomical Journal 2020, 159:86.
Sheikh SZ, Siemion A, Enriquez JE, Price DC, Isaacson H, Lebofsky M, Gajjar V, Kalas P: The Breakthrough Listen Search for Intelligent Life: A 3.95-8.00 GHz Search for Radio Technosignatures in the Restricted Earth Transit Zone. AJ 2020, 160:29.
Wright J: Dyson spheres. Serb Astron J 2020, doi:10.2298/SAJ2000001W.
Traas R, Croft S, Gajjar V, Isaacson H, Lebofsky M, MacMahon DHE, Perez K, Price DC, Sheikh S, Siemion APV, et al.: The Breakthrough Listen Search for Intelligent Life: Searching for Technosignatures in Observations of TESS Targets of Interest. AJ 2021, 161:286.

Online lists of technosignature papers

Technosearch is an online tool tracking SETI papers since 1960.
List of SETI papers from a Penn State graduate course in SETI. I am planning to read as many of these as possible. A talk by Jason Wright from Pennsylvania State University as part of a technosignature seminar series hosted by the Sellers Exoplanet Environments Collaboration (SEEC) at NASA’s Goddard Space Flight Center gives a nice overview of SETI research and points towards the course site for further resources. There is also some nice perspectives on some of these papers by previous students there.

My software development process

2025-11-07T09:47:00+00:00

I am a big fan of process mapping. I used it a lot in my role as a consultant in machine learning and have previously written about mapping out my research process. It helps to clarify muddy waters when it comes to how things are done in practice. Lately I have been thinking about the software development process and wanted to map this too. This will give me a handy reference for when I am starting new projects and encourage me to reflect on how I can improve my software development process, how it relates to my research process and how best to integrate the two.

This post is a summary of my software development process. I will use it for working on my first software package for technosignatures research. As I execute each step I will document more details on the process as well as my results and reflections.

I am also experimenting with (mermaid) for creating the final flow chart.

My software development process

Here is the result of a few evenings mapping my software development process using the mermaid live editor. I have used a flow diagram that starts with the event ‘Domain chosen’ and ends with ‘Continuous Delivery Cycle’. It results in working software that can be iterated upon in endless opportunites for development! For the steps inbetween, I have cherry-picked the practices that I have found most useful in my career so far, new practices I want to try and practices I want more practice in. As I follow this process, I will refine it and reflect on what worked and what didn’t.

I have outlined more details on the main steps below.

flowchart TD
  START@{ shape: circle, label: "Domain chosen" }
  DDD@{ label: "Explore Domain" }
  OUT_DM@{ shape: lean-r, label: "Domain map" }
  OUT_GL@{ shape: lean-r, label: "Glossary"}

  PRIORITISE_PROB@{ label: "Identify Key Problems" }

  IM@{ label: "Map Impacts" }
  OUT_IM@{ shape: lean-r, label: "Impact map"}

  PRIORITISE_DEL@{ label: "Prioritise Deliverables" }

  REQ@{ label: "Elicit Requirements" }
  LIST_BDD@{ shape: lean-r, label: "BDD scenarios" }
  OUT_UT@{ shape: lean-r, label: "Utility tree" }

  DOCS@{ label: "Outline Docs" }
  PROTO@{ label: "Prototype" }
  ARCH@{ label: "Evolve Architecture" }
  
  ARCH_VIEWS@{ shape: lean-r, label: "Architecture Views" }
  ARCH_DECISIONS@{ shape: lean-r, label: "ADRs"}

  CD@{label: "Continuous Delivery Cycle"}

  OUT_SW@{ shape: lean-r, label: "Working Software" } 

  START --> DDD --> OUT_DM & OUT_GL 
  DDD & OUT_DM  --> PRIORITISE_PROB --> IM --> OUT_IM
  IM & OUT_IM --> PRIORITISE_DEL --> REQ
  REQ --> LIST_BDD & OUT_UT
  REQ --> DOCS & PROTO
  PROTO & DOCS & REQ & OUT_UT--> ARCH
  ARCH --> ARCH_VIEWS & ARCH_DECISIONS
  ARCH & ARCH_VIEWS & ARCH_DECISIONS --> CD 
  LIST_BDD --> CD
  
  CD -.-> |Learn| DDD
  CD -.-> |Evolve| ARCH
  CD -.-> |Refine| REQ
  CD -.-> |Evaluate| IM
  OUT_GL --> REQ
  OUT_GL --> ARCH
  OUT_GL --> CD
  CD --> OUT_SW --> CD

Explore Domain (DDD)

The first step is to identify what problem to solve. I have previously described the method I used to choose a research topic. I will use a similar approach to choosing a problem to solve (by developing software) within that topic. This means first exploring the domain, creating a domain map and then prioritising any problems identified by ranking them by a) impact b) tractability c) neglectedness and d) personal fit. That way I will develop something that: solves an important problem; is within my capabilities and interest; and not many others are working on.

As part of this domain-driven design (DDD) approach, I will also generate a glossary of terms that I will use for aligning to the domain language when designing and coding my software. This will make communication with domain experts and users much easier (this is one of the hardest parts of developing software in a domain you are not expert in yourself and can make or break a project).

Map Impacts

After identifying the key problems, the next step involves formulating them into a set of goals and mapping these to actors (the people or entities affected), impacts (behavioural changes) and deliverables (the solutions that will define user stories – see below). This map provides many routes to tackling a problem with measures of success (defined by the impacts) that can be used to evaluate progress towards the goals. This is an approach I would like to gain more experience in.

Prioritise deliverables

I will prioritise deliverables by mapping them onto a value vs. effort chart and rank by value/effort, taking quick wins (high value, low effort) first to build momentum.

Elicit Requirements

Once I have a set of top deliverables, I will spend some time specifying requirements for each. These will include:

Functional requirements (what should the software do?) that I’ll formulate as user stories (“As a user role, I want some capability so that reason or benefit”) that I can use to derive behaviour driven development (bdd) scenarios (“Given I have something when I do something then something happens”) that will form the basis for BDD tests. I have used the BDD approach before and found it very useful.
Non-functional requirements (how should the software do it?) that define quality attributes (such as maintainability or scalability) that I can use to derive quality attribute scenarios (“When stimulus occurs, and the system is in context, the system shall response with measure” for standard use cases and cases covering both expected and unexpected changes), some of which can be used to derive automated tests. As part of this step I will create a utility tree. This maps quality attributes to concrete testable quality attribute scenarios. This is one of the practices in the Architecture Tradeoff Analysis Method that I want to practice and learn more about.

Outline documentation

This is where the process gets a little unconventional compared to what, in my experience, is the usual way of developing software. In most projects I’ve worked on in the past, we’ve taken user stories and gone straight to coding. But this sometimes led to implementing something that wasn’t quite what the users wanted and having to refactor, rewrite or build in unnecessary complexity later. I want to try documentation-driven development as a way of clarifying what the final result should be and streamlining the implementation.

This mirrors the research process that I landed on as I gained experience as a postdoc – I started to outline the paper before doing any experiments. So, for my software projects, I will first write the README, then outline the docs. I will use the diataxis framework and start with some explanation followed by tutorials and how-to guides. That way, all I have to do is design the software to do what the documentation says it does. I will iterate on these docs, ideally getting feedback from users, until they represent what I have to implement at a high level.

Prototype

Inspired by design thinking I will also do some prototyping alongside writing the documentation outline. This will ensure that the final outcome will have the desired impact – i.e. it will be something that a) solves a problem that people care about and b) people actually want to use.

I will sketch some designs for the user-interface and generate example outputs to check that this is what a user actually needs and wants to use. This might include the design for a dashboard with mock plots, the outline of a notebook, a mock log file or a simple script that includes a call to a CLI.

Evolve Architecture

By this stage I’ll have a clear idea of what the software will do and how a user will interact with it. I’ll have an outline for the documentation and some basic prototypes for the user interface and outputs. The next step is to decide how the software will achieve this functionality given all the forces at play and the quality attribute scenarios I defined earlier in the process. For this I will research and select candidate architectural pattern that seem to best fit then I’ll create architecture views using the C4 model (Context → Container → Component → Code) for each. I’ll then identify sensitivities, tradeoffs, and risks to create a tradeoff matrix that I can use to make decisions, documented in Architectural Decision Records and updated architectural views.

I plan to learn more about evolutionary architecture to ensure that the architecture design an iterative process and in a feedback loop with the continuous delivery development cycle (i.e. it evolves along with the code) with automated tests using fitness functions to ensure the code aligns with architectural decisions.

Continuous Delivery Cycle

This step is where I write the code, starting with a minimal viable product (MVP) and creating a scaffold based on my architectural views.

I plan to follow Extreme Programming (XP) practices as far as possible, with test-driven development (TDD), short iterations, (AI) pair programming, continuous delivery and small, frequent releases. The whole process then becomes iterative in order to respond to change.

I will evaluate progress based on my impact map, refine the requirements and evolve the architecture regularly. I will also add anything new I’ve learnt about the domain to my domain map and adjust the impact map as needed.

Reflections on using Mermaid

I used the mermaid live editor to create my software development process map and found it a really nice tool to use and much more efficient than other tools I’ve used before (including miro, omnigraffle, powerpoint). There are lots of options in mermaid that I haven’t explored yet and there are some issues with the way the layout is rendered so I’ll continue experimenting with it (including for my software documentation and architecture views).

There are also several advantages of having diagrams as code that I like, including how much easier it is to see changes using version control and how it makes them more AI-friendly and so can be used as context for AI assistants/agents that can both help improve the diagrams themselves and make better recommendations when assisting with code development (since you can point them to your process to show how you want to work).

Do you have any thoughts on mapping processes or the software development process? Let me know in the comments below!

How to migrate from Poetry to uv

2025-10-27T21:34:00+00:00

I have recently been working on a template for new Python projects and of the first decisions I had to make was which tool to use for packaging and dependency management. I initially chose Poetry since I am already familiar with it: Poetry is a mature tool that is widely used and works well. But several people have recently recommended uv as an alternative so I decided to try it. This post documents the steps I had to take to switch from Poetry to uv.

Read more about what decisions are involved in setting up a new Python project in my post on the template
Check out my template on GitHub
Read the ADR I created to document the rationale for my decision to switch to uv

To summarise the outcome of my testing: uv is extremely fast (it is written in rust), manages python versions in addition to dependencies and is likely to become the new standard so I am adopting it for my new projects.

From a google search, I saw that there are tools to automate this migration (e.g. migrate-to-uv) but for a simple Python repository there are not that many steps to do it manually so that is what I did.

I also had to make additional changes to use uv in my CI/CD (GitHub workflow) pipelines, readthedocs configuration, dependabot configuration, pre-commit hooks and just recipes and to get release-please (which I am using to automate releases) to bump the version number in the uv lock file.

You can see the actual changes I made to some of the files in this pull request.

How to switch from Poetry to uv

I was using Poetry version 2.2.0 and switched to uv version 0.9.4.

Pre-requisites

A Python project managed using Poetry (with a pyproject.toml file listing your dependencies)
Access to a terminal

Basic steps

Open a terminal and navigate to the root of your repository.
Create and switch to a new branch.
Delete the poetry.lock file:
```
rm poetry.lock
```

Install uv:

curl -LsSf https://astral.sh/uv/install.sh | sh

Check installation (should show usage details):
```
uv
```
Create a uv.lock file:
```
uv lock
```
Test uv run with a development tool in your repository (e.g. ruff, black, pytest):
```
uv run ruff check .
```

Change the build backend in pyproject.toml to uv_build (or use another build system to suit your needs):

[build-system]
requires = ["uv-build>=0"]    # or pin a version
build-backend = "uv_build"

Add a module name for the build (replace package_name with the name of your package):
```
[tool.uv.build-backend]
module-name = "package_name"
module-root = ""
```
Commit your changes.

Additional steps

These will be different for different repositories. Test that everything works as expected after each change.

Change `poetry run` to `uv run`

Change all poetry run commands to uv run in files that use them, e.g.:

justfile (see my template’s justfile for examples)
makefile
devcontainer.json
GitHub workflows
Pre-commit configuration file

Add a pre-commit hook for uv sync

You can add a pre-commit hook from uv to check that the uv.lock is up-to-date:

repos:
  - repo: https://github.com/astral-sh/uv-pre-commit
    # uv version.
    rev: 0.9.4
    hooks:
      - id: uv-lock

Use uv in your Dockerfile

If you use a Dockerfile, you can install uv by adding the following:

COPY --from=ghcr.io/astral-sh/uv:latest /uv /bin/uv

Then install your dependencies using uv instead of poetry:

uv sync --all-groups

Use uv in GitHub workflows

To use uv in GitHub workflows, replace your poetry setup with the following:

- name: Install uv
  uses: astral-sh/setup-uv@v7
  with:
    version: "0.9.4"
    enable-cache: true

- name: Install dependencies
  run: uv sync --all-groups

Update dependabot config file

If you use dependabot, update the config file:

- package-ecosystem: "uv"

Edit release-please configuration

If you use release-please, add uv.lock as an extra file in the release-please-config.json so that the version number of your package listed there will be bumped:

"extra-files": [
    {
      "jsonpath": "$.package[?(@.name.value=='package-name')].version",
      "path": "uv.lock",
      "type": "toml"
    }
  ]

Edit Read the Docs configuration

If you are using Read the Docs to host your documentation, edit your readthedocs.yaml to use uv to install docs dependencies:

jobs:
  pre_create_environment:
      - asdf plugin add uv
      - asdf install uv latest
      - asdf global uv latest
  create_environment:
      - uv venv "${READTHEDOCS_VIRTUALENV_PATH}"
  install:
      - UV_PROJECT_ENVIRONMENT="${READTHEDOCS_VIRTUALENV_PATH}" uv sync --frozen --group docs

Update your README

Update your project README with instructions for how to use uv and optionally add the uv badge ( ):

[![uv](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/astral-sh/uv/main/assets/badge/v0.json)](https://github.com/astral-sh/uv)

The importance of documenting architectural decisions

2025-10-25T21:14:30+01:00

Decision-making can be complex. It involves weighing up different options and considering various tradeoffs. The rationale for what is decided is not always documented. This makes decisions harder to understand and harder to change later and can determine the success or failure of a project.

In my previous role as a consultant in machine learning and data engineering, I was generally hired to build something new in what was (at the time) unchartered territory. Machine learning was just taking off and many companies were unsure how to use it and had neither the infrastructure nor the data to support it.

It was my job to design and build data pipelines for training and running machine learning models that would output useful information for use in making business or engineering decisions – either in real time or on a schedule.

Unless the company was a brand new startup, there was already existing business logic in place to help with these decisions, which usually involved a lot of manual work to analyse data and create reports and/or dashboards. Part of the drive to implement machine learning was to automate a lot of this and free up time for working on other problems that could not be automated.

While documentation existed for how things were currently done, what was often missing was documentation for why things were done a certain way.

There were usually two camps – one that wanted to stick with the current way of doing things and were deeply sceptical of “black box” models (often domain-experts who crafted the existing logic and analysed the data) and another that wanted to embrace these models, as long as they could be verified and validated (usually the people making the decisions). A lot of friction, miscommunication and politics resulted from this, which is a shame since domain expertise is critical for the success of machine learning projects.

One thing that would have helped both sides reach a mutual understanding would have been a written record of why certain choices were made in the first place. Most likely, there were very good reasons for the choices that were made initially as well as risks and limitations that were accepted at the time. But technology evolves rapidly and those same people may have chosen differently in today’s technology landscape (or not – they may have specific knowledge that is not obvious to others).

When the rationale (and pros and cons) for earlier choices are forgotten there is no way to know whether they are still good choices today. This means that in the worst case, people are either afraid of changing something in case it breaks (and risk the project becoming hard or cotstly to maintain, outdated and/or outcompeted) or change something that should not be changed and break it (and waste time and energy implementing and then reverting it, potentially putting the whole project in jeopardy).

Inspired by the decision-making process for software development at SKAO (where I now work), I’ve recently been learning about architectural decision records (ADRs). ADRs have been around since the 90s and provide a solution to the problem of lost knowledge. They were popularised in a 2011 blog post by Michael Nygard. An ADR is a structured way to document rationale for software design choices for your future self and future colleagues. It can include all the alternatives you considered and any known risks. When someone new to your project comes in and wonders why things are done a certain way you can point them to these records. If they disagree then they have the complete history available to them to confidently propose a new ADR to change the earlier decision. You can also use them as context for AI assistants to help them make better recommendations.

As part of my python project template, which I’ve created to streamline starting new open source projects, I have an ADR on using ADRs, which lays out my rationale for using them, the alternative solutions I ruled out and how I will adopt them in practice. I have also added a template for new ADRs.

Documenting decisions in this way would also be useful in other domains – I ran into similar problems when working in a molecular biology lab. Everyone followed a particular protocol and no one I worked with had tried to optimise any of the steps. Why it was done this way was knowledge that had been lost over time and no one wanted to change the way it had always been done… Deciding what research topic to work on is another example. I documented my rationale for using a decision matrix in an earlier post but I could have used something like an ADR for this.

My opinionated template for new Python projects

2025-10-21T12:54:30+01:00

Over the years, I’ve experimented with different tools and learnt about various best practices in software engineering. These things are always in flux and so, in order to have a central place for collecting and updating the tools and practices I’ve found most useful for Python projects, and to help streamline starting future projects, I’ve created an opinionated template on GitHub that anyone can use:

Python Project Template (GitHub)

Using this template will save time doing the initial set up and avoid decision fatigue and analysis paralysis that can consume time and energy which is better spent getting stuck straight into the software development process.

This post briefly describes some of the decisions involved in setting up a modern Python project – starting with a minimal package, then adding tools that help ensure code quality and finally automating workflows for continuous integration and delivery.

The template’s README and Architectural Decision Records (ADRs) have up-to-date details on the choices I’ve made.

A minimal Python package

Setting up a minimal Python project is fairly straightforward. You need a pyproject.toml file (to specify dependencies and configuration for packaging), a licence file, a README file and the actual Python source code and tests. You can follow a tutorial from the python packaging site to learn more details. You’d end up with the following directory structure:

my_project_name/
├── LICENSE
├── pyproject.toml
├── README.md
├── src/
│   └── my_package/
│       ├── __init__.py
│       └── example.py
└── tests/
    └── test_example.py

It is also useful to include a CITATION.cff file so that others can easily cite your work and a directory for Jupyter notebooks that you can use as tutorials or demos of your project.

There are already some decisions you have to make when completing the steps to set up this basic structure:

What licence to choose (e.g. MIT, BSD 3-Clause)
What build backend to use (e.g. hatchling, uv_build)
What Python versions to support (e.g. >=3.11)

Documenting your project

There are several tools (e.g. sphinx, MkDocs) available to help you generate html documentation for your project. You also need to decide where to host the documentation (e.g. GitHub pages or Read The Docs), and how best to communicate the rationale for your design choices to your future self or other developers (e.g. using ADRs).

Tools to make developing Python code easier

There are also many tools that make your life easier when developing your project. The main ones are:

Linters to check your code and flag any issues (e.g. pylint, flake8, ruff)
Formatters to ensure consistent code style (e.g. black, ruff)
Testing frameworks to run your tests (e.g. pytest)
Dependency managers (e.g. Poetry, uv, pipenv) to install and resolve other packages you want to use in your project (including the linters and formatters)

Automating your workflows

Running your tests as well as the linters and formatters requires several steps that you may or may not remember to do when you commit your changes or merge to your main branch. Several ways exist to automate this, including:

A Justfile or Makefile – allows you to create short commands to make it easier to run common tasks.
Pre-commit hooks – scripts that run automatically whenever you try to commit a change and can include running your linter and formatter and checking your dependencies are in sync.
GitHub workflows (or equivalent on other platforms) – these can be configured to run automatically on GitHub whenever you push your commits or open a merge request. They can run your pre-commit hooks, tests, publish your package, generate test coverage reports and build your documentation. This forms a key part of continuous integration, which is a practice that helps ensure new changes don’t introduce errors.
Dependabot (from GitHub) – automates updating dependencies.

Releasing your software

Creating a release of your project allows you to tag, package, document and distribute a specific version to a wider audience. There are a number of different approaches for when and how to release, and how to label each version. This can also be automated for continuous delivery (e.g. via release-please and using conventional commits and semantic versioning).

Managing your project

Templates for GitHub issues and pull requests allow you to standardise processes when managing a project. This is useful when collaborating with others and when working alone (your future self may not remember all the details of a bug you found last week or a feature idea you had a few months ago and templates will help you document these in a more thorough and structured way).

Using the template

Follow the instructions in the template’s README if you’d like to use it – and feel free to leave a comment here or open an issue in the repository if you have any ideas for improvements.

Project Oasis: Part I

2023-10-27T20:29:00+01:00

Project Oasis was the second SETI-related Summer Faculty Fellowship Study in Engineering System Design funded by NASA in cooperation with the American Society for Engineering Education (ASEE) and was conducted at the University of Santa Clara and the NASA Ames Research Center in 1979, eight years after Project Cyclops in 1971 (I have notes on the Project Cyclops report [1] in two previous posts: part i and part ii).

The primary focus of this second project was on the design of a signal detection system for SETI and its name was inspired by the region of the radiomagnetic spectrum thought to be a prime target for finding signals from extraterrestrial intelligence: the “water hole” (proposed in the Project Cyclops report [1] and later expanded on in a paper [2] by one of its co-directors, Bernard Oliver).

Oasis, a patch of green in a vast expanse of arid desert, with its water hole providing the source of life.

Project Oasis involved a group of 22 people who were tasked with solving the following two problems:

How to process 1/2-terabits (\(10^{12}\) bits) of data in 1000 seconds (about 16 minutes)
How to detect a completely unspecified signal with acceptable sensitivity

The group wrote a report [3] detailing the design of a signal detection system to meet the needs of the SETI field at the time. This was published in 1981 and was digitised by NASA in 2013 – it is publicly available online:

Project Oaisis: The Design of a Signal Detector for the Search for Extraterrestrial Intelligence

Since the Project Oasis report is 443 pages long, I am splitting my notes into multiple posts. Here are my notes from reading chapter one (of seven), which gives a nice overview of the state of the SETI field at the time and an outline of the proposed signal detection system.

You can find my notes on other classic SETI papers in my roundup of the technosignatures literature.

Progress in the SETI field

The introduction to the report highlights the progress and discoveries made in the previous decades that enables the search for extraterrestrial intelligence (SETI) to move from science fiction to science fact:

The organic molecules necessary for life (on Earth) are found all over the universe.
The Sun and Earth are average members of the galaxy: there is nothing unique about them.
Technology has advanced enough that we are capable of interstellar communication.

Current state of the SETI field

The rest of the first chapter summarises background information on the field, including the consensus at the time on:

Where to look
How to look
Why look
How to understand a signal
The current status of the search

The authors also provide an outline for the design of the Oasis Signal Detection System, which would be able to find and recognise a signal emitted by extraterrestrial intelligence (ETI) using multi-channel spectrum analyzers (MCSAs).

Where to look

The most likely places to find life, and therefore the best candidate stars to search, are around parent stars that are:

Not too large (or it would burn out too quickly for intelligent life to evolve).
Not too small (or a planet must be so close to the star to have enough heat to be habitable that it would become tidally locked, causing the atmosphere on the dark side of the planet to freeze).
Rotating slowly, which indicates most of the initial angular momentum (98% in the case of our solar system) has been lost to a planetary system.
Second generation or later since the heavier elements needed for life are only found in the exploded debris of stars.
Single star systems, since the planets of multi star systems are less likely to have stable orbits.

There are around 20 million such stars in our galaxy.

How to look

Radio signals

Signals using electromagnetic radiation are the most cost-effective (in time and energy) means of communication across interstellar distances. In the 70s the most popular view was that the radio region of the spectrum was the best place to search. Optical signals were seen to have two major short-comings in that they are likely to be:

Outshone by the parent star
Absorbed by interstellar dust

Radio signals do not have these problems and the technology of the late 70s was already capable of transmitting and receiving radio signals over distances of 100,000 light years.

Anticryptography

Transmissions from ETI can be grouped into two categories and the Oasis signal detection system is designed to find both:

Internal transmissions that leak out into space (like our TV and radio broadcasts). These are weaker and harder to find.
Beacons that are intended for attracting the attention of other civilisations, which are likely to be optmised for easier detection.

If a signal is designed to be as easy as possible to decipher (anticryptography), then if a dimension of the search space can be reduced it will be. An optimal signal will therefore be:

Omni-directional
Transmitted continuously
Circularly polarised
Narrow band
Doppler corrected

We can use this to focus the search.

Why look

We are more likely to detect signals from more advanced civilisations than our own (less advanced civilisations are not yet able to communicate and the chance of finding a civilisation at the same stage of development as us is small).

If we found another civilisation, therefore, we would benefit from the following:

We’d have evidence that not all civilisations destroy themselves before reaching maturity.
- This might inspire us to work harder on reducing our own existential risks.
- We may gain knowledge to help us achieve this goal ourselves.
It would change our perspetive on the smaller problems we have.
New frontiers and challenges will prevent “cultural stagnation” of our civilisation.

How to understand messsages

An initial message is likely to be built around the common knowledge or experiences of all civilisations in the galaxy in order to have the best possible chance of being understood. Numbers and counting would be one example. The report refers to Lingua Cosmica (Lincos) to show that this is possible. Lincos, a language created by Hans Freudenthal in the 60s, uses messages with a counting sequence to define numbers and then introduces one new mathematical symbol at a time, which are then used to build more complex messages as a means of establishing communication with another civilisation.

The status of the search

Several studies and small scale searches had been conducted, using existing telescopes, from 1960 to 1979 (the first, Project Ozma, by Drake looked at two stars for two weeks as a proof of concept). Most spent a few days or weeks searching. The longest was an ongoing 6 year all sky survey. Most observatories at the time did not look for extraterrestrial signals at all. The authors of the Oasis report likened this effort (compared to what was possible) to conducting a survey for earthquakes in California by standing outside for 10 minutes and noting any vibrations.

Previous SETI projects searched for two types of signals:

Wideband pulsed signals (very few projects):
- Widely separated receivers (thousands of km) with non-directional antennas used to record pulsed signals that are cross correlated to remove interference. Any signal that remains is likely to be of extraterrestrial origin.
- Pulsar detection equipment were also being used to detect wideband pulses.
Narrowband continuous signals from specific targets (most projects)
- Banks of analog filters for moderate bandwidth (10 kHz) and number of channels (50)
- Autocorrelation receivers for more channels (1000) that digitally compute the Fourier Transform of the autocorrelation function of the incoming signal (either in real-time or later using computers or a laser and lens system)
- The resulting power spectrum of the signal is then inspected for peaks

The all sky survey in Ohio, which was ongoing at the time of Project Oasis, used the following strategy:

Ignore signals from large astronomical objects and short-time peaks by cross-correlating with the antenna pattern
Ignore that occur in more than one channel (i.e. wide-band signals)
Use a narrowband filter to re-examine any remaining signals at higher resolution
Ignore signals that are present in two different beams (beam-switching) to remove interference from radio sources on Earth

Several other studies had re-examined data collected for different purposes or used “parasitic” receivers on telescopes to examine signals from wherever the telescope happened to be looking.

The next step

The authors of the report argue that further advances in the search require receiving equipment designed and constructed specifically for SETI. These new receivers can be used with existing radio telescope antennas.

In order to design such receivers we need to:

Determine what type of signals to expect
- Beacons as well as unpredictable signals (e.g. from leakage)
Design optimum search algorithms to detect them
Plan for a full-time, long-term search at several observatories

Since there is increasing radio interference, particularly from artificial satellites, that will eventually make the search impossible without moving into space or the moon it is urgent to start now.

The receiving system

The system designed as part of Project Oasis consists of:

A radio telescope examining a target star for up to 1000 seconds
- Two orthogonally polarised feed anntenas
- Two separate receivers
- Two separate Multi-Channel Spectrum Analyzers (MCSAs)
  - A device specially designed for SETI purposes that can analyse 8 MHz of bandwidth at 1 Hz resolution
    - The 8 MHz band is split into 120 bands using a digital bandpass filter bank
    - Each band is subdivided into 1 Hz bands by 120 microprocessors that compute the Discrete Fourier Transform of the filter outputs
    - Output data rate will be 16 Mb per second, requiring a total of 16 Gb of data storage
The Oasis Signal Detector that searches the final output for possible intelligence

The purpose of Project Oasis

The purpose of the study was to begin the next step in the search for extraterrestrial intelligence: design the part of a specialised SETI receiver that finds and recognises a signal. The authors were confident that the system would eventually be constructed after some refinement.

The Oasis Signal Detection System

The Oasis system embodied three separate signal detection philosophies for seeking different types of signals:

Carrier Wave Signal Detector
- Near zero bandwidth, may be drifting slowly with time (extreme case)
Pulse Signal Detector
- Broad bandwidth, may be pulsed in time (other extreme case)
Battery of Tests
- All signals in between the extreme cases (unpredictable cases). These include:
- Complex Coherence
- Polarization
- GCV by Row
- ANOVA Row
- ANOVA Column
- ANOVA Interaction
- Total Power
- Goodness of Fit
- Narrowband Pulse

Summary

Following on from Project Cyclops eight years earlier, Project Oasis focussed on the design of a signal detection system that would find both intentional (beacons) and unintentional (leakage) signals from extraterrestrial civilisations. The first chapter of the 443-page long technical report from this project summarises the state of the SETI field as of 1979 and outlines the design of the Oasis signal detector. The authors were confident that the search was both feasible and urgent.

The following chapters provide further details and I will document my notes on these in separate posts. Chapter two covers the characteristics of signals and noise and how to differentiate between them, which is the main task of the Oasis signal detector.

References

1. Project Cyclops: A Design Study of a System for Detecting Extraterrestrial Intelligent Life. 1972.
2. Oliver B M: Rationale for the Water Hole. Acta Astronautica 1979, 6:71–79.
3. Lord S, Dixon R, Healy T: Project OASIS: The Design of a Signal Detector for the Search for Extraterrestrial Intelligence. 1981.

ETI does not exist

2023-10-05T20:29:00+01:00

In a paper in 1980 [1], mathematical physicist Frank Tipler presented his argument that if extraterrestrial intelligent beings exist they would already be in our solar system since they would inevitably develop technology that would explore the galaxy in less than 300 million years. As they are not here it follows that they don’t exist.

This argument had been expressed before. Five years earlier, Michael Hart published his reasons for rejecting the many explanations for why extraterrestrials are not already on Earth [2], in a paper that was the first to formalise what is now famously called the Fermi Paradox (if there are so many extraterrestrial civilisations then where are they all?) Tipler felt that the force of the argument against the existence of extraterrestrial intelligence (ETI) had not been appreciated and wanted to give it more weight in his paper.

Here are my notes on Tipler’s 1980 paper. You can find my notes on other classic SETI papers in my roundup of the technosignatures literature.

The evolution of intelligence is rare

According to Tipler, in 1980, most leading experts in evolutionary biology thought that the evolution of intelligence in our galaxy was unique to Earth since there are many more alternate “pathways” evolution could take that do not lead to intelligence. He claimed that it was primarily astronomers that thought otherwise.

Tipler agreed with the biologists and he put the probability of another technological civilisation emerging after 5 bilion years of evolution at less than \(10^{-10}\) (i.e. 1 planet in 10 billion: he estimated that there are 10 billion planets in our galaxy that host life and only one of these (Earth) has intelligent life).

Any communicative species would also have developed rockets and computers

If we assume another civilisation is capable of interstellar communication via radio waves, then we must also assume they are capable of interstellar space travel and are likely to use sophisticated computers. Tipler went one step further and proposed that they would be capable of exploring and/or colonising the galaxy within 300 million years using machines, with an initial cost less than operating a microwave beacon for several hundred years:

They will also develop a self-replicating universal constructor with intelligence comparable to the human level

Maximum information for the lowest cost

Minimising cost involves using:

“Off-the-shelf” technology to reduce research and development costs
Resources that would not otherwise be used (“useless” materials in other (uninhabited) stellar systems)

Space exporation with von Neumann machines and extrasolar resources

Tipler proposed sending a probe to another stellar system with:

An engine for slowing down
An engine for travelling within the target system
A self-reproducing universal constructor with human-level intelligence (a von Neumann machine) as a payload.

This probe would initiate galaxy exploration or colonisation in the following stages:

The von Neumann machine seeks out construction material (meteors, asteroids, comets etc.) it can use to make several copies of itself and the orignal probe and engines
Copies of the initial probe are launched at nearby stars
The von Neumann machine starts exploring (and, using available resources, conducting scientific research in) the stellar system it is in and relay information back to its system of origin
When new probes reach their target system the process is repeated until all stars in the galaxy have been covered

Once in another system, a von Neumann machine can use resources there to conduct projects that would otherwise be too expensive. Some projects Tipler suggested include:

Building an O’Neill colony (a proposed construction for settlement in space comprising two rotating cylinders) in systems with no planets to colonise
Creating new inhabitants for the system by synthesising fertilised eggs and artificial wombs, together with robots to raise the children to adulthood (avoiding the problem of damage to living cells during interstellar travel)
Receiving updates, via microwave, with instructions for building the latest devices developed on the system of origin (particularly if the journey time is very long)
Constructing second generation probes with faster travel times
Constructing an artifact in the target system that would be detected by any technological civilisation present in order to initiate communication

Getting a von Neumann machine to another stellar system

Tipler argued that the main problem is getting a von Neumann machine to another stellar system. This was already possible with rocket technology of the time, with journey times of \(10^4\) - \(10^5\) years. Faster travel times require more cost, almost all of which is rocket fuel.

Tipler proposed sending an initial low speed probe with a von Neumann machine that could use resources at the target system to construct and fuel faster second generation probes to send to the next targets. This requires the species at the system of origin to wait a long time before it gets any information back but the cost would be minimised (since von Neumann machines would be developed anyway for other purposes). Tipler estimated the exploration of the galaxy in this way would cost about 3 billion dollars in 1970s money (one tenth the cost of the Apollo program).

Time to explore the galaxy

Tipler estimated a minimum time of 4 million years, given a high speed probe and 100 years for von Neumann machines to self-replicate. For rocket technology of the time he estimated a more conservative 300 million years.

Strategies for exploring the galaxy

Applying the mathematical theory of island colonisation to galactic colonisation, Tipler argued there are two strategies for exploration:

The r-strategy

The net reproductive rate, r, is maximised at the expense of all else. This would be the strategy used in the early stages of colonisation.

The K-strategy

The carrying capacity of the environment, K, is used to secure the ecological niche in the target system. This would be the strategy used once the system had been colonised for some time. Fewer probes would be sent in this phase.

We are the only communicative intelligent life in the galaxy

Together with his argument for the inevitability of galactic exploration using von Neumann machines, Tipler used the Drake equation to argue that we are the only technologically advanced civilisation in the galaxy.

He used the following assumptions:

Any intelligent species that attempts interstellar communication will begin galactic exploration within 100 years after developing the technology required
It takes 300 million years to explore the galaxy
No probes from another civilisation are present in our solar system
It takes 5 billion years to evolve intelligence and develop technology for interstellar travel (Earth is average)
The probabilities of the Drake equation (that a star has planets, that the planets are habitable, that life evolves, that intelligence evolves and that communicative civilisations evolve) do not vary with time / age of the galaxy
The galaxy is 11 - 18 billion years old and contains \(10^{11}\) stars
The rate of star formation has been decreasing exponentially since the initial burst of heavy element formation
The rate of earth-like planet formation is constant

From the above, Tipler argued, it follows that:

All stellar systems older than 5.3 billion years are candidates for hosting technological civilisations, which is around the number of stars in the galaxy (\(10^{11}\))
Of these \(10^{11}\) candidates, none have succeeded in colonising the galaxy
The probability of an intelligent civilisation existing in our galaxy is less than 1/\(10^{11}\)
The number of existing communicating civilisations in our galaxy is less than or equal to this probability multiplied by the number of stars in our galaxy = \(10^{-11} \times 10^{11} = 1\) (i.e. us)

Longevity is irrelevant

As long as a civilisation has time to construct and send its initial probe containing a von Neumann machine, Tipler argued, the exploration of the galaxy would happen automatically, regardless of the longevity of the original civilisation.

There is no good reason for choosing not to explore

Tipler argued that there is no good reason to believe an intelligent civilisation, interested in interstellar communication, would not explore the galaxy. Any argument for interstellar communication is an even stronger argument for galactic exploration, given the initial investment is for only one probe carrying a von Neumann machine.

Exploration improves long-term survival of the species

All life on Earth tends towards dispersal into new environments. For an intelligent species, this dispersal is limited only by the level of technology.

Colonising the stars increases the probability that a species will survive the death of its star and other existential risks.

Keeping control of the machines

Tipler proposed three ways of ensuring the machines don’t become independent from the species that created them:

Coding the control program such that its failure triggers failure of the entire program
Probes are programmed to form colonies of the species that created them, colonies which could destroy any machines that slipped out of control
The machines are an extension of the biological species and heir to their civilisation: losing control over them is accepted

Are ETI already here?

Tipler considered the possibility that probes from extraterrestrial intelligence(s) are already in our solar system: we just haven’t detected them. He argued that if this was the case, it is most likely that they arrived a billion years ago and, since there was no intelligent life on Earth at that time, they would have no reason to hide and would already have used up the materials in the asteroid belt.

Tipler equated a belief in the existence of extraterrestrial intelligence anywhere in the galaxy with the belief that UFOs are extraterrestrial spaceships.

The Anthropic Principle

He ended his paper by referring to the Anthropic Principle. Original reasoning based on this principle went that because we are here, the Universe must be compatible with the existence of (intelligent) life. Tipler defined it as:

Many aspects of the Universe are determined by the requirement that intelligent life exists in it.

He then argued that it follows that the Universe must contain \(10^{20}\) stars in order to contain a single intelligent species and that we should not therefore be surprised that it contains only one (us).

This kind of argument for the fine-tuning of the Universe for intelligent life to exist is controversial because it reverses cause and effect. The Universe seems fine-tuned for life from our perspective only because we have evolved and adapted to (a very tiny part of) it (via natural selection). Tipler published more on this, together with John Barrow, in a book called The Anthropic Cosmological Principle.

Summary

Tipler’s conclusion that intelligent extraterrestrials don’t exist is based on the assumption that any intelligent species interested in interstellar communication will also develop self-replicating machines that would be sent out to the nearest stars, at low cost, to rapidly and autonomously explore the entire galaxy. Given this assumption, these machines would already be in our solar system. His paper complemented the paper by Hart, published in 1975, that rejected a series of explanations for why technologically extraterrestrial civilisations aren’t already here.

This was another paper expressing a pessimistic view of SETI and was an interesting read, especially given the current acceleration of progress in (and interest in risks from) artificial intelligence. Tipler perhaps underestimated the concern a biological species might have in sending von Neumann machines with human-level intelligence out into the Universe with the goal of colonisation.

References

1. Tipler FJ: Extraterrestrial Intelligent Beings Do Not Exist. Quarterly Journal of the Royal Astronomical Society 1980, 21:267–281.
2. Hart MH: Explanation for the Absence of Extraterrestrials on Earth. Quarterly Journal of the Royal Astronomical Society 1975, 16:128.

Rationale for the water hole

2023-09-28T11:10:00+01:00

Searching the ‘water hole’ for extraterrestrial signals had already been proposed nearly a decade earlier as a result of the 1971 Cyclops Project [1] but in 1979, several navigational satellites were planned that would create noise in this frequency band. In response, co-director of the Cyclops project, Bernard Oliver, published a paper titled “Rationale for the water hole” [2] to make the case for keeping the water hole free from interference so that we are not “blind” to the signals from other technologically advanced civilisations.

It would be a bitter irony if the desire to know exactly where we are at all times on Earth were to prevent us from ever knowing where we are with respect to other life in the Galaxy.

Here are my notes from reading this paper.

You can find my notes on other classic SETI papers in my roundup of the technosignatures literature.

What is the ‘water hole’?

The water hole is a frequency band in the electromagnetic spectrum that lies between the hydrogen line (1420 MHz) and the hydroxyl radical emission line (1662 MHz): hydrogen (H) and hydroxyl (OH) are the dissociation products of water (H\(_2\)O), which is essential for all life that we know about.

The hydrogen line is the frequency of radiation emitted by the reversal of the spin of the electron (a spin-flip transition) in neutral hydrogen atoms (corresponding to a wavelength of 21 cm). Radiation at this frequency can penetrate interstellar dust and since hydrogen is the most abundant element in the universe it is likely to be detected by any technologically advanced civilisation. It was the region around the hydrogen line that was originally proposed and targetted by early SETI researchers when other emission lines had not yet been discovered [3,4,5].

Bernard Oliver and the other members of the Cyclops Project [1] later suggested that the region between the hydrogen and hydroxyl lines forms a poetic place for water-based life to meet: life on Earth gathers at water holes.

Why focus on the ‘water hole’?

Oliver argued that the basic premise leading to the water hole is that a civilisation wishing to make contact with others will choose the least expensive method that guarantees success.

Radio waves are the most efficient means of communication

Like others before him [3,6,7,1], Oliver excluded communication via space travel or probes on account of the time and energy they would require. This left communication via radiation. Oliver listed two main requirements that this radiation must have in order to detect it as an artificial signal: it must be significantly stronger than background radiation and have some property that is not found naturally. He also listed seven other properties:

Requires the least radiated power
Not absorbed by the interstellar medium or atmospheres
Not deflected by galactic fields
Readily collected
Efficient generation and detection
High travel speed
Normally radiated by technological civilisations

This ruled out any particles with mass (since they would travel slowly and require too much energy to generate) or charge (these would be absorbed and/or deflected). It also excluded gravitons and neutrinos since they are not readily collected nor efficiently or normally radiated. Only low energy photons (radio waves) met all the criteria (they can be modulated such that they are not confused with natural sources).

Maximising the signal to noise ratio

There are three contributions to background noise in received signals, which are similar everywhere in the galaxy:

Synchrotron radiation (produced by electrons travelling in spirals along magnetic field lines) (at frequencies < 1 GHz)
Cosmic microwave background radiation (produced just after the big bang)
Quantum noise (at frequencies > 60 GHz)

These define a quiet region from 1 - 60 GHz (the free-space microwave window).

On the surface of an Earth-like planet there are additional sources of noise from molecules in the atmosphere re-radiating noise:

Water vapour (around 22 GHz)
Oxygen (around 60 GHz)

These further narrow the window to 1 - 10 GHz (the terrestrial microwave window). This is where the detectable received power is at its lowest.

Other advantages of the microwave window

Oliver listed further advantages of focussing the search in the (low) microwave region.

Lower cost per unit of collecting area
Greater collecting area for the sharpest usable beam
Greater freedom from H\(_2\)O and O\(_2\) absorption
Higher beacon powers easier to achieve
Narrower bandwidths are possible

Accounting for Doppler drift

Planetary rotations and revolutions cause a change in the frequency of a signal. The motion at the receiver end can be corrected for but is more difficult at the transmitter end if the signal is omnidirectional (although ways to do this had been proposed [4]).

Oliver showed that the optimum bandwidth for a signal (too high and there is too much noise; too low and it will be not be received) increases in proportion to the square root of frequency. Correcting for this narrows the quietest region of the microwave window to a 2 GHz region containing the water hole.

Chauvinistic and romantic nonsense?

The minimum noise after correcting for Doppler drift occurs at 1.5 GHz but, Oliver argued, this does not increase much within a 2 GHz band. This is too wide to search or to keep free from interference and there is no technical reason to prefer a particular frequency over another. It does, however, include the water hole proposed by the Cyclops team due to water’s significance for life on Earth.

Oliver admits that it is both romantic and “chauvinistic to water-based life” but argued that it is not nonsense. We can expect water to be a common feature of habitable planets and he stated that “water-based life is almost certainly the most common form and well may be the only (naturally occurring) form”. Today the search for life on other planets is largely driven by the presence of conditions suitable for liquid water.

Oliver also argued that romance itself may be “a perception peculiar to intelligence” and that intelligent extraterrestrial life may also perceive it.

Summary

In this 1979 paper, Bernard Oliver re-examined the case for focussing our search for signals from extraterrestrial intelligence on the ‘water hole’, a region of the electromagnetic spectrum bound by the emission lines of hydrogen and the hydroxyl radical. His main motivation was to argue for protecting this region against interference from e.g. navigational satellites. He concluded that, while there may be reasons for choosing another region of the spectrum or another method of communication that we don’t know about yet, this should not stop us from searching the water hole since “progress requires us to proceed on the basis of what we know, and not forever wait for something now unknown to be discovered”.

References

1. Project Cyclops: A Design Study of a System for Detecting Extraterrestrial Intelligent Life. 1972.
2. Oliver B M: Rationale for the Water Hole. Acta Astronautica 1979, 6:71–79.
3. Cocconi G, Morrison P: Searching for Interstellar Communications. Nature 1959, 184:844–846.
4. Dixon RS: A Search Strategy for Finding Extraterrestrial Radio Beacons. Icarus 1973, 20:187–199.
5. Drake FD: Project Ozma. Physics Today 1961, 14:40–46.
6. Drake FD: THE RADIO SEARCH FOR INTELLIGENT EXTRATERRESTRIAL LIFE. In Current Aspects of Exobiology. . Elsevier; 1965:323–345.
7. Hoerner SV: The Search for Signals from Other Civilizations. Science, New Series 1961, 134:1839–1843.

The Arecibo message of November, 1974

2023-08-29T15:44:00+01:00

In 1974, the Arecibo Observatory became capable of transmitting radio signals at a maximum effective power that was twenty times the combined power of all power plants on Earth at the time (\(2 \times 10^{13}\) W). A transmission at 1 Hz bandwidth or less would have been detectable by similar radio telescopes all over the Milky Way.

The first use of this transmitter (at 1700 GMT on November 16, 1974) was to send a brief message to the globular star cluster M13 (the Great Cluster in Hercules, NGC 6205), which lies 25,000 light years away and contains several hundred thousand stars. This was to demonstrate the advanced level of radio astronomy on Earth, rather than a realistic attempt to initiate interstellar communication with another civilisation. A paper published in 1975 by the staff of the Arecibo Observatory gives more details about the message [1].

Here are my notes from reading this paper. You can find my notes on other classic SETI papers in my roundup of the technosignatures literature.

Message transmission

The message was transmitted by the Arecibo telescope at a frequency of 2380 MHz (a higher frequency than the 1420 - 1662 MHz ‘water hole’, a quiet region of the spectrum recommended by the authors of the Cyclops report [2] as a convenient band for communication with extraterrestrial intelligences), a bandwidth of 10 Hz (which is broader than what others had proposed [3]) and at a rate of 10 characters per second. It took 169 seconds to send and 5 hours and 20 minutes to pass Pluto.

The effective power in the direction of transmission was \(3 \times 10^{12}\) W and by the time it reaches M13 (in about 25,000 years) it will make the Sun appear to be the brightest star in the Milky Way.

Message content

Constructed primarily by Frank Drake, Richard Isaacman, Linda May and James Walker, with suggestions for improvement by others that included Carl Sagan, the message described characteristics of life on Earth with 1679 characters in binary format (using two transmission frequencies that were continuously corrected for the Doppler effect of the orbital motion and rotation of Earth). The message was laid out in a grid, arranged from top right to bottom left in 73 rows of 23 characters per row (two prime numbers were used to facilitate decoding the message).

Binary number system

The first 4 rows give the numbers 1-10 in binary format. Each number is read from bottom to top, starting on the third row down (the 1s), followed by the second row (the 2s) then the top row (the 4s) (with the fourth row indicating a “number label”). A single column can represent numbers from 1-7 and an adjacent column to the left is used to continue the binary format (third row represents the 8s, second 16s and top 32s). A blank row was left between each number.

Terrestrial biochemistry

Using the binary number system described by the first four rows of the message, rows 6-10 (row 5 was blank) contains the numbers 1, 6, 7, 8 and 15, the atomic numbers of hydrogen, carbon, nitrogen, oxygen and phosphorus. Twelve groups of five numbers then give the numbers of each of these elements in the building blocks that make up a DNA double helix: four units of deoxyribose, four phosphate groups and an adenine, thymine, guanine and cytosine, arranged in the same configuration that they occur in DNA.

The double helix conformation is illustrated in the next part of the message together with the number 4 billion (the approximate number of DNA base-pairs in the human genome) encoded in binary down the centre of the helix.

Human form

The DNA helix leads to the head in a picture of a human and to the left is the number 4 billion representing the size of the human population on Earth. To the right is a vertical line from the head to the feet of the human and a horizontal line, representing the number 14 when read right to left, which gives the number of units of length of a human (one unit being the wavelength of the transmission: 12.6 cm)

Planet Earth

Underneath the encoding of a human form is a diagram of the Solar System with the Sun to the right. Planet Earth is highlighted by displacing it upwards compared to the other eight planets (Pluto was still a planet back then).

Our technology

A telescope is depicted underneath the Solar System together with a number indicating its size (2430 units).

Summary

The Arecibo message was never supposed to be a serious attempt at communicating with extraterrestrial intelligence, and has a very small chance of being detected, but it demonstrated that humans had reached a level of technological advancement that made this a possibility. We are capable of sending information out into the galaxy for the benefit of other civilisations or to respond to, or initiate, interstellar communication.

References

1. The Staff at the National Astronomy: The Arecibo Message of November, 1974. Icarus 1975, 26:462–466.
2. Project Cyclops: A Design Study of a System for Detecting Extraterrestrial Intelligent Life. 1972.
3. Dixon RS: A Search Strategy for Finding Extraterrestrial Radio Beacons. Icarus 1973, 20:187–199.

Gemma’s Open Research

Extraterrestrial Intelligence: An International Petition

The result of a thorough search for ETI would be profound

The technology for detecting ETI is already available

The absence of evidence for advanced extraterrestrial civilisations is not enough

The search should begin now (in the 80s)

Summary

References

Technosignatures literature roundup

Technosignature papers read

Technosignature papers currently reading

Technosignature papers to-read

Online lists of technosignature papers

My software development process

My software development process

Explore Domain (DDD)

Map Impacts

Prioritise deliverables

Elicit Requirements

Outline documentation

Prototype

Evolve Architecture

Continuous Delivery Cycle

Reflections on using Mermaid

Share your thoughts

How to migrate from Poetry to uv

How to switch from Poetry to uv

Pre-requisites

Basic steps

Additional steps

Change poetry run to uv run

Add a pre-commit hook for uv sync

Use uv in your Dockerfile

Use uv in GitHub workflows

Update dependabot config file

Edit release-please configuration

Edit Read the Docs configuration

Update your README

The importance of documenting architectural decisions

My opinionated template for new Python projects

A minimal Python package

Documenting your project

Tools to make developing Python code easier

Automating your workflows

Releasing your software

Managing your project

Using the template

Project Oasis: Part I

Progress in the SETI field

Current state of the SETI field

Where to look

How to look

Radio signals

Anticryptography

Why look

How to understand messsages

The status of the search

The next step

The receiving system

The purpose of Project Oasis

The Oasis Signal Detection System

Summary

References

ETI does not exist

The evolution of intelligence is rare

Any communicative species would also have developed rockets and computers

Maximum information for the lowest cost

Space exporation with von Neumann machines and extrasolar resources

Getting a von Neumann machine to another stellar system

Time to explore the galaxy

Strategies for exploring the galaxy

The r-strategy

The K-strategy

We are the only communicative intelligent life in the galaxy

Longevity is irrelevant

There is no good reason for choosing not to explore

Exploration improves long-term survival of the species

Keeping control of the machines

Are ETI already here?

The Anthropic Principle

Change `poetry run` to `uv run`