How “We” Built Special Signals

Getting Started

When I retired from the Signals Intelligence community, I began collecting vintage radios, particularly the old vacuum-tube receivers that had fascinated me for years, as a way of weaning myself off the work.

As I built my collection I happily discovered there are a lot of parallels between my old community and the ham radio/vintage radio community: technical pride, vast skill, perseverance, meticulous attention to detail, process, procedure, and a sense of community.

And as my collection grew, interest in it from the Elmers (experienced ham-radio mentors) I met at hamfests grew, too.  The initial concept for my website was to build some sort of skin (similar to the old WinAMP skins, but much more interactive), that would faithfully emulate each of my radios, offering site visitors the opportunity to operate each, and have each perform within their respective performance parameters.  Meaning, a radio from the 1920s will have a feel/sound that is very different than a radio from the 1950s.  This is still an end state I want to achieve, too, but along the way I started to have ideas on how I might share what I have in my collection.  The mentor/trainer in me always wants to share the “why” behind the “what”, (meaning I like to gab until folks get glassy-eyed.)  That is how the user experience sections of the site came to be.

I wanted a way to share the collection beyond simply posting photographs of radios sitting on shelves. These receivers were once part of people's everyday lives. They brought news, entertainment, music, and voices from around the world into homes, offices, and listening posts.

Why not put them back into those settings, at least virtually?

That idea eventually became Special Signals — A Museum of Listening.  Why “Special Signals”?  In my old Navy world, special signals is more of a grab bag than anything actually special.  I was a Cryptologic Technician, Collection (aka “CTR”).  CTI are Interpreters, who do clear speech of foreign language.  CTT are Technical, and they cover RADARs.  CTR had two types of technicians: Manual Morse intercept/analysis, and Special Signals, who collected and analyzed everything not covered by CTI/CTT/CTR Morse ops.

I spent 20 years in the U.S. Navy and another 24 years in federal civil service, much of it working in signals intelligence. I'm comfortable with technology, but I'm not a professional website developer. I had an idea of what I wanted the site to do, and I needed help making it happen.

Enter artificial intelligence.

Choosing the Tools

While I had done some very minor HTML work in the past, I’m basically a coding brick.  Sure I have the capacity to learn, and I have picked up some stuff since starting this project, but the fact is ChatGPT is a great tutor.  I asked it to outline the steps in creating and maintaining a website, and it laid out the breadcrumb trail.  Any time I had a question/got lost, I would paste a screen shot of the tool I was using, and it would get me back on track.  

The first order of business was establishing a home on the internet.

I paid Namecheap to register specsigs.com as my domain name — essentially the website's address.  This is a recurring cost.

For website hosting, I chose Netlify, which I find affordable.  Netlify publishes the site/site updates, and makes it available to visitors.

I use the free GitHub to store the website's source files and maintain a history of site changes. GitHub Desktop for Mac provides a relatively simple way to manage those files without having to learn a collection of command-line instructions.  And GitHub may be linked to Netlify, making updates fairly seamless.  So linked, when I push to GitHub, Netlify detects the updated repository, builds the site, and deploys it.  I then refresh my Chrome web browser and ensure my changes were properly implemented.

For coding, I enlisted ChatGPT and Claude, both of which are monthly subscriptions.

As the creator and artistic director of the site, I describe, in detail, what I want, provide the relevant images and associated files, and thematic description.  Then ChatGPT does the initial coding.  I then hand the resulting code over to Claude for a second set of eyes.  Note, at this time the two can’t be directly linked together, so I have to cut-and-paste their comments to each other.  This has proven to be a very effective way to use AI, as they do make errors, they do make assumptions, and thus they do need human intervention.  When we settle on a good update, I commit and push the changes to GitHub, which triggers Netlify to deploy the updated website, normally in seconds.

That's the basic process.

I'm happy to recommend the tools I've used, but they aren't the only choices. If you're comfortable with Google's Gemini or another AI assistant, investigate what it can do. The important thing is understanding the process and maintaining control of your own website.

Lesson Learned: Know When to Stop

Long AI editing sessions can become circular. When everything is working properly, stop and have the AI summarize the current workflow, file structure, and outstanding tasks. Save that summary separately. It gives you a reliable starting point when you return.

Building the Museum

The heart of Special Signals is its collection of historical room scenes.

I initially began with a simple matrix of stylized plates that led to a photo and description.  The thought occurred that the radios would look nice in custom, period-appropriate room scenes: a 1930s living room, a wartime listening post, a postwar kitchen, or perhaps a shortwave enthusiast's radio shack.

I research each receiver, establish a plausible year* for the room scene, review what was happening during that year, what were typical furnishings for the time/place/culture/lifestyle, and use AI to generate the room illustration from my research and direction. I review the results and request changes until the scene looks right.

* A humble home can have an old radio.  But a new radio can’t go into a room scene which predates the radio’s year of manufacture.

Once I approve the image, I save it as a WebP format image file.

Then comes the interactive part.

After I built the first few rooms, I initially tried to offset some of the costs through Amazon Associates and eBay Partner Network commissions. In October 2026, I discontinued those affiliate arrangements to keep the museum noncommercial and make appropriate use of Creative Commons NonCommercial audio more feasible.  I retooled some of the images, then found exemplar items on Amazon or eBay.  I make a list of the URLs for these items, as well as the URLs for the item images.  I then upload the room scene WebP to a free online tool called image-map.net to draw polygons around the radio and other objects in the scene. What this means is you carefully put points around each item, forming a polygon.  Each polygon is named.  When you have your polygons completed, you hit a button and a box of code appears.  I copy that code into the same note as the products URLs, as well as the polygon for the radio in the room scene, and the directory location for the photo of my radio, and then paste all that into ChatGPT, along with the saved WebP image.  ChatGPT converts those coordinates into the format used by the website.

ChatGPT creates a mouseover box for each polygon.  Selected objects can open a description, historical information, or a link to an appropriate reference or product.

That turns a static illustration into something visitors can explore.

Heads Up: Don't Move the Furniture

Once the polygons are mapped, changing the image's dimensions or moving objects around can throw the hotspots out of alignment.

We learned to finalize the room illustration before mapping anything.

Working With the Website Files

The site uses ordinary HTML, CSS, JavaScript, and JSON files. You don't have to become an expert in those languages to use AI assistance, but it helps to understand that each file has a particular job.

For example, index.html provides much of the desktop site's structure and functionality. radios.json contains receiver information, while roomsData.js holds the historical room scenes and their interactive details.

When something needs changing, I provide the current files, or maybe a screen shot of the GitHub directory holding all the site files, and explain what I want. The AI returns complete replacement files rather than expecting me to locate and edit individual lines of code.

I download those files, add an “_old” suffix to the existing versions in my local GitHub folder, then put the replacements in place. In GitHub Desktop, I deselect the temporary “_old” files so they are not included in the commit. I commit and push the replacements, check the Netlify deployment, and then delete the temporary copies once everything works. GitHub keeps the earlier committed versions, and Netlify retains previous deployments as another recovery option. I have to check those selections each time: deselecting a file does not permanently exclude it from future commits.

NOTE: I’m using a decent iMac desktop computer.  I work with one downloaded file at a time, making sure each transfer or file operation has completed before proceeding. It may sound overly cautious, but I've learned that patience prevents mistakes. I also wait until file operations have finished before pushing changes to GitHub.

Netlify then deploys the updated website.

Heads Up: The .js Download Trick

We've occasionally encountered problems downloading JavaScript files directly from ChatGPT.

The workaround is simple: tell ChatGPT to give you the .js file as a .txt, then rename it to .js before placing it in the repository.

Make sure the filename and extension match the original. On a Mac, turn on Finder → Settings → Advanced → Show all filename extensions, so you don’t accidentally end up with a file named something like file.js.txt.

Lesson Learned: Keep the Originals

Before making significant changes, retain a working copy of the files. GitHub also maintains a history of previous versions.

If a change causes trouble, it's much easier to recover when you know what was working beforehand.

GitHub Desktop asks for a commit description. I make that description specific to what changed, so I can recognize a good version later. GitHub timestamps commits automatically; if you also add a date, YYYY-MM-DD is easier to sort.

What This Radio Heard

One feature I particularly wanted was the ability to hear what a receiver might actually have picked up in its historical setting.

Finding suitable recordings turned out to be much, much more complicated than I anticipated.

First, there's historical accuracy. A recording must fit the room's date and circumstances. A radio in a 1955 living room shouldn't be playing a broadcast from 1961*.

* BUT - If I’m curating a room scene with a ham radio, then general tuning sounds with odds & ends signals getting tuned through doesn’t really need to adhere to the year too strictly.  In this instance, atmospheric ambiance outweighs year accuracy. 

And not every radio was tuned to news about wars or international crises. People listened to comedy, music, sporting events, and everyday entertainment, too.

Second, there's copyright.

A recording being old, or freely accessible on the internet, doesn't necessarily mean it's free to reuse on another website.

My primary source has been the Internet Archive, which is amazing.  Many Internet Archive uploads carry a Creative Commons label, but that label is only as reliable as the uploader’s authority to apply it. The Archive doesn’t individually verify every rights claim, so I check the provenance and permissions rather than treating a label as proof.

Also, AI can compound this.  Case in point, I found Google’s Gemini was really adept at scouring Internet Archive, so I used it to complete the first tranche of 51 audio files.  Gemini assured me that all usage rights were in place.  I then had ChatGPT review the spreadsheet, and it threw a big bucket of ice water on me, pointing out many assumptions, presumptions, and flat-out wishful thinking.  I took those comments back to Gemini and it hemmed and hawed and finally conceded.

So far, I have 15 audio files hooked into my room scenes.  I've searched historical archives, contacted collectors and rights holders, and requested permission to use short excerpts. I maintain a spreadsheet, noting by-room audio selections, recording its date, source, rights information, and permissions.  I may make this spreadsheet available for viewing on the website.

Finally, the recording has to sound reasonably good.

My rule is straightforward: I'd rather leave an audio slot empty than use something historically misleading, legally questionable, or boring to listen to.

Some recordings are hosted on Special Signals with appropriate permission. Others may be accessed through their original hosts.

The audio collection remains a work in progress, and probably always will.

Keeping the Site Running

GitHub and Netlify handle the basic publishing process.

I also use GoatCounter, a lightweight visitor analytics service, to see how people find and use the museum.

It helps me see how many people visit, which pages attract attention, and what devices they use. I’m not running a marketing department here; I’m just curious whether people are finding the museum useful.

I pay the bills for the site myself. I tried affiliate links for a time, but stopped earning Amazon and eBay commissions in October 2026. Any shopping links still on the site are ordinary reference links, not a source of income.

Why I made that change: The museum’s audio exhibits benefit from recordings that are available under Creative Commons NonCommercial licenses. Dropping affiliate commissions supports the museum’s noncommercial purpose. It does not, however, automatically give me permission to use every recording marked NC. I still check each license, attribution requirements, source permissions, and any underlying rights. I keep those decisions in the audio provenance worksheet.

I intend to publish a breakdown of what this has actually cost me. Domain registration, subscriptions, and all the little extras do add up, and a real-world accounting may help the next fellow decide what to take on.

Building Your Own Website

If you'd like to try something similar, here's the general sequence I'd recommend.

1. Decide What You Want to Build

Start with a reasonably clear idea of your website's purpose.

It doesn't have to be elaborate. A personal portfolio, collection, hobby project, or family-history site is a perfectly good starting point.

2. Register a Domain Name

Choose an available name and register it through a domain registrar.

I used Namecheap, but there are plenty of alternatives.

A domain is your address on the internet. It isn't necessarily where your website files are stored.

3. Establish Your GitHub Repository

Create a GitHub account and a repository for your website files.

I use GitHub Desktop to manage the files on my computer.

The repository becomes the working source for the website and provides a record of changes.

4. Build Your First Page

Use an AI assistant to help create a simple index.html file.

Explain what the website is for, what you'd like it to look like, and what information it should contain.

Ask for complete files and plain-English explanations. Make changes gradually, checking that each one works before moving on.

5. Arrange Hosting

I use Netlify, connected to my GitHub repository.

Once configured, updating the repository can automatically trigger a new deployment.

Other hosting services may work just as well. Compare their features, limitations, and costs.

6. Test the Website

Open the published site and try everything.

Check links, images, navigation, and interactive features. Test on a phone as well as a computer.

Don't assume that code is correct simply because an AI assistant says it is. I’ve learned to check the live page myself, even after both assistants agree that everything looks fine.

7. Add Analytics, If Useful

I use GoatCounter to understand visitor activity.

Analytics aren't essential, particularly when you're just getting started. They're simply another tool that may become useful as the site develops.

8. Maintain Control

Keep your account credentials secure, retain backups, and understand which service performs which function.

Your domain, source files, and hosting arrangements should remain under your control. You should be able to change providers without having to rebuild everything from scratch.

Final Thoughts

Special Signals has been an enjoyable retirement project. It's allowed me to combine my interest in vintage radio, history, and technology while learning something entirely new.

There have been mistakes, unexpected complications, and more than a few occasions when something that should have been simple wasn't.

But that's part of the process. When something goes sideways, I usually learn a little more about how the site works while putting it right.

If you've got a collection, a creative project, or simply something you'd like to share, you don't necessarily need professional web-development experience to put it online.

You need an idea, some patience, a willingness to experiment, and a few useful tools.

And, in my experience, it doesn't hurt to have a couple of AI assistants standing by.

Special Signals — A Museum of Listening

This guide describes the tools and methods used to build the website. Services, features, and pricing may change. Investigate the alternatives before deciding what works best for you.