Making the Exchange Script

After a conversation less than two days ago I've taken an idea and turned it into a script with output I rather like. Now seems a good time to reflect on decisions made along the way. github

See also First Look at Exchanges

Spots stream in as a batch of decodes from multiple bands every 15 seconds. What to keep?

I store broadcast messages, CQ, meaning calling anyone, separate from exchanges meant from one station to another. The first was indexed by a call sign, the latter, a pair in alphabetical order. I can imagine scenarios where this will be insufficient but these failures can be noticed if not resolved from the data I keep.

I save the spots in the payload format they arrive with one exception. I remove fields that are always blank when receiving and others that seemed redundant. This meant the remaining fields showed with useful precision with console.table().

My first look showed that exchanges could be usefully examined when downloaded as json first by patching the download logic into a running script and later by making this part of the program. Press download.

Data collected at a few megabytes an hour. I was unconcerned about this while programming because useful runs were only minutes.

I started purging whole exchanges based on the time of last entry discarding those that weren't heard recently. This kept some too long and others not long enough. I switched to selecting based on the first entry, when the exchange was first recorded. This was easier to understand and cut off stations that called another incessantly rather than bloating my output.

My first output was just the exchange keys plus a few characteristic values easily extracted from the spots. I added click logic to these and showed contents in the console log. I had to poke at quite a few to find exchanges that looked interesting. They are rare.

I wanted tabular output with a rows somehow tied to time and cells big enough for a whole exchange. I was thinking minutes but learned quickly that a row of just one 15 second slot was going to have to wrap around if it is to fit.

It was hard to tell what was going on when some rows wrapped and others not. My solution was to add interstitial rows showing the clock when time advanced.

I had visions of incrementally updating cells when new data arrived and may still do that. For the moment I just regenerate the whole display with every payload and accept that it can be slightly jumpy.

I highlight cells with complete exchanges which I define as having a 73 as their last transmission. I add the CQ from the broadcast data if there appears to be one appropriate. We can never be sure why one station calls another but this is a good guess.

I like the way cells at the top and bottom of the table are incomplete in different ways. It is easy to scan for interesting recordings which are often in the middle rows. They are bold and start with CQ. That means we're likely hearing both participants.

I found long exchanges hard to follow. I now offset odd slots by two spaces which helps.

I add the bands present in the row to the time label. There are often only a few bands because it is only listing the signals that don't got with some other row.

I added a parameter search=word which highlights were that word is used. Multiple words work separated by spaces. Built-in default searches for a few respected callsigns.

My first implementation handled clicks on a cell and searched for both operators involved. This was always confusing. Now click on individual work to find and highlight just this. Works great for maidenhead coordinates too.

We can see, for example, station K5PI working DX stations at a good clip. expand

K5PI reports operating from EM00 outside of his FCC declared residence. We can guess he is operating from the exotic W5KFT station at Buchanan Lake where there is lots of "metal in the air". google

I'm ready to set this program aside as it already represents the idea well and I have more distinctly different things I'd like to explore. I do have a few things I know I could do better and will mention them here for the record.

I'd like to show signal strength of each transmission using the color code I've used in the Signals script. These could be little squares in front of each transmission.

I could compare timestamps between adjacent entries and notice where some transmissions are missing. How missing is missing?

It might be interesting to know which bands host which exchanges. This could be a faint background color using the yet to be implemented band color code standard I wish I had in the Bands script.

I've preserved the single column exchange summary output which would be a good fit on a federated wiki page. Click could open new pages with the transcript, possibly annotated, and other metadata like maps, google links or even operating history should we keep that somewhere.

See Digital Exchanges Explained