Technology and geeky stuff Archives

Packet and SFWEM interconnects

28 May, 2021 by sky 1 Comment

Over the last year (most of 2020), the majority of my radio work has been focused on making my connections between packet radio and SFWEM even more resilient.

SFWEM.NET is the San Francisco Wireless Emergency Net, which is a mesh network that’s being built out by amateur radio operators with the intention of being a communications backup in time of emergency — when phone and data networks may be locally overwhelmed or not functional. Beside that, however, it’s an interesting experiment for amateur radio operators seeking to understand the benefits and limitations of “wi-fi” as a long-distance tool. [Read more…]

Got the Logitech C920/C922 blues?

18 September, 2020 by sky 6 Comments

photo of blueish tint in logitech C920 camera — This is the C920 camera’s “automatic” color balance before I corrected it. (In zoom.us setup on Mac OS)

We (the team here) have been struggling with the color on Logitech C920 and C922 webcams recently. We’re preparing for a big international conference in November when the cameras will be in around-the-clock use. Initially each camera had a nice color balance, but after a couple of weeks each of them acquired an “underwater” blueish cast, and things that should have appeared white in the picture turned a spooky underwater blue!

Some of the blueness is due to where we have located our webcams — they’re in rooms with good outdoor light, but no direct sunlight, so the ambient lighting is saturated with blue skylight. But, beyond that, the cameras over-emphasized the blue. They were trying to auto-correct, but slewed way too far blue. Instead of compensating for our blue light, they were over-emphasizing it. Today we solved the problem!

Visualizing packet traffic

26 April, 2020 by sky Leave a Comment

Very techie here… For a few months I’ve been operating a packet radio station on a 2-meter radio frequency here in the San Francisco Bay Area. I explored what it would take to make this a full “BBS” (like an online “forum”), and then backed off and let it just hang around n this frequency listening to the other (mostly BBS) stations. A few days ago, I got interested in graphing the data to better understand what stations were using the frequency and when.

Packet radio was very popular 20 to 30 years ago, and has mostly been displaced by other amateur radio digital technology and by the Internet. Yet, it’s still quite reliable and is a good way to pass messages from one place to another when Internet or voice communications are unavailable (i.e. in an emergency). I’ve always been interested in the presentation of data, and it was an interesting challenge to figure out how to chart the data in ways that support inquiry.The result of my experimentation is visible in a chart.

The chart is made by this process:

JNOS (the software that runs the packet radio station) logs all data it hears on the radio;
A Python script analyzes this log file, keeping track of what stations were heard in each hour;
The Python creates javascript data in a form acceptable to Google Charts;
The javascript is transferred to a web server;
PHP code reads the javascript and inserts it in an HTML page;
Google Charts javascript fashions the data into the interactive chart.

A “cron” job carries out this process once each hour to keep the chart data current. Because each data bucket spans a whole hour, there’s no need to update more than once an hour.

Packet Radio Notes

25 February, 2020 by sky Leave a Comment

In amateur radio circles there’s much use of digital modes to exchange information. (In olden days it was almost exclusively limited to “chatting” on the air.) At least in the circles I’m running in these days this is true. “Packet radio” involves putting a computer on the front end, which then controls the radio, connecting to other packet radio stations and transferring messages digitally. At the lowest level the software has a command-line interface (accessed via radio), and at its highest level, it is basically supporting programs that exchange email (again, by radio, not thru the Internet).

Later articles:
° Packet and SFWEM Interconnects
° Visualizing Packet Traffic

My packet radio station operates on 145.07 or 145.09 mHz (also known as “2 meters” and mail is exchanged by “connecting to” AA6AX-1 via that radio. If you need to email me about this, please use the email address packet@aa6ax.us.

The station uses a Raspberry Pi 4 as the computer, and I use VNC to view the virtual “screen” of the RasPi and interact with the system. The radio is a cheap 2-meter transceiver, and a circuit board in a box called a “TNC” attaches to the computer and controls the radio. The photo shows the RasPi (about 4 inches wide) on top of the slightly-larger TNC. Plug it all into electrical power, add a radio with an antenna, and it’s on the air.

(More aa6ax info.)

This diagram shows the components of the packet station. Most notable are the Raspberry Pi computer (the “RasPi”), with the reddish TNC-Pi on the top, connecting it to the radio. The radio has an antenna, and is connected to a power source.

The computer itself is on the local network, and the VNC software lets me view its “screen” on my own computer, and use my mouse and keyboard as if they were directly connected to the RasPi computer. It’s kind of a virtual computer.

Inspiration is for Amateurs

27 February, 2019 by sky Leave a Comment

I just wanted to document this quote, which I heard for the first time today, but it’s a thought that has crossed my mind in many guises over my entire career.

“Inspiration is for amateurs. The rest of us just show up and get to work.” — Chuck Close

I refer to (music) composition as “design and engineering” which reflects my experience that ideas are the easy part, but the hard part is then designing and building the product. I say “product” here quite intentionally. As an engineer, I spent many years building software products. In software, the idea may be subtle and tricky, but it’s still the easy part compared to the design and then the hard work of building — which is where the real time is spent.

And to a great extent, if you’ve studied and trained and understand how to use the tools available to you, and if you just show up and start working on your product, you usually (already) have what you need to accomplish your goal.

So for years I did this in software. And then in 2015 I started doing it in music.

Yeah, yeah, sometimes I get inspired and I write and write furiously late into the night. The endorphins tell me it was a great work. And frequently I then put aside my product, take a rest, then pick it up later on and yeegads(!) it sounds terrible to me. (Inspiration can be delusional.) And then there’s just lots more work to do. But that work is required to achieve the payoff. And if I do the work, the piece becomes so much better!

In my days in software I’d have people pitch me software ideas many times a year. My reaction was frequently, “Well, that’s a nice idea, but have you written the program?” I guess I was a bit brash, but many times I’d continue “Your idea is nice, but it probably represents less than 10% of a product, which requires hundreds if not thousands of hours of engineering.”

Another thing I’m fond of saying is “When you have a novel idea, you can bet that 8,000 people got up this morning and had that same idea; then 80 of them did something about it, like pulling together a team; then 8 of them will bring your product to market within the same two weeks.” That’s kind of hard for an inspired ideas person to hear, but it represents the harsh truth of the world of commercial software. Ideas come from lots of experience, and from creative responses, but they’re seldom completely unique.

Chuck Close is quoted in Inside the Painter’s Studio, a book by Joe Fig. A review of this book goes on to say “Inside an art gallery, it is easy to forget that the paintings there are the end products of a process involving not only creative inspiration, but also plenty of physical and logistical details.”

Those of us who do this kind of design and engineering, understand and appreciate the fundamental truth of this statement.