I have many hobby interests and ham radio was something I "planned" to get into, but never got around to until now. I'm sure that's true for a lot of folks. However, the funny thing is I do have somewhat of a background in radio both as a radio technician in the past, and as an software engineer. In my Army days (33S) I repaired receivers, instrumentation recorders, demodulators, you name it: all kinds of radio receiving, recording, and signals analysis equipment. We'd even make our own precision length coaxial cable assemblies by watching how many times a cable's phase wrapped completely around a VNA Smith chart (in total degrees) - very useful for direction finding systems requiring multiple precisely matched dipole/transmission line sets and/or other phased array antennas. Simply heating and moving the soldered center pin of a coax cable in or out a tiny fraction would cause a noticeable change in electrical length.

I've been a geek for a long, long time, but I consider myself to be of the joe sixpack variety.

I've always had an interest in computers, starting way back with the Tandy Radio Shack TRS-80 - and I've made a career out of realtime C/C++/Asm embedded programming. My last job was writing DSP firmware for 900MHz and 2.4Ghz RFID interrogators (usually in the ISM frequency bands) - these units were "licensed required" ones (higher powered) that you see placed on gantries over many of the US State Tollways here and around the world. This was exciting as in the late 1990's,  DSP and SDR/(MMIC) technology was finally getting affordable/useable/plentiful for commercial uses. Formerly, only military systems could afford these. Today they are  common, although coding signal processing routines can be really  tricky - every Smartphone has one. The systems I worked on are microwave backscatter systems (RFID) with simultaneous transmit and receive (homodyne) via a single patch antenna.

Newer RFID systems I worked on were more retail/warehousing oriented. Back in the early 2000's RFID technology was *exploding* and several competing standards were created. Someone requested a SQL-like way of addressing tags and I came up with a system I called BRI (Basic Reader Interface) using the Purdue Compiler Construction Toolkit. This project almost didn't make it. Luckily, my boss (and second set of eyes) found a few outrageous memory allocation macros in the PCCTS headers. Thank goodness too - we built that entire RFID interrogator around a TMS320C520x DSP - all the hairy signal processing plus the BRI in code all in about 64K or so bytes! It's been extended in functionality again and again (beyond recognition?) - but they are still using derivatives of it to this day. Still the only intelligent RFID interrogator interface out there that you can have up and running in a few minutes with nothing more than a dumb terminal.

I've somehow been "stuck" in transportation with my career - an even earlier job was working with firmware for CRIP (card reader in pump) systems. Basically, these are the automatic (credit card) fueling systems we take for granted today. These really took off at the start of the 1990's.

Still on "transportation", there was also a short stint writing contract graphical PC software for the FAA ARTCC center here in Albuquerque back when they were *still* using the ancient plan-view air traffic control system. That system ran on ancient (at the time) mainframes, so being able to graphically view and edit its aeronautical datasets on a modern (at the time) PC before loading it into a clunky old mainframe was quite awesome considering that all of that data was still formatted as if for old 80-column punch cards. IBM had produced a competing PC editing system but it required the use of a floating point co-processor and, if you remember, almost all early 16/32-bit PC's didn't include them as standard. They were quite expensive too. Floating point math is interminably slow without a floating-point math coprocessor, it has to be emulated. IBM's system would take over a minute to refresh its graphical display without one. Woe to him who merely decided to change his center of geographical reference merely to bring something into view.

We stole IBM's lunch back then because apparently no one at IBM thought to code mathematical geo routines using a precision fixed point integer system. This is something that would be rather obvious to a journeyman PC developer of the day - but maybe not so much in a more rarified atmosphere such as an IBM research lab equipped with PC's loaded with all the trimmings and Masters/Phd boffins doing the coding (coding not being their primary job).

Our application was somehow "magically" snappy - redrawing data was instant on plain old PC's w/o coprocessors as compared to IBM's. We also used the latest (at the time) RAD software development tools (Borland Delphi/Borland C++) which meant we got it done relatively quickly. I'm sure a big part of the success of it was due to the fact we were much younger and working for peanuts too...

I've had a lot of fun with digital signal processing in my later career. Since I'm retired, a lot of this stuff is getting stale for me memorywise - but I always know where to look to reaquaint myself. 

My hobbies and pastimes are riding and traveling with my motorcycles, photography, music production (digital audio workstations), graphics arts, and now - ham radio. I'm having a blast with my new IC-7300 on both voice and data.

The background on my QSL card (top right of page) is a photo I took of Sandhill Cranes flying at the Bosque Del Apache National Wildlife Refuge. These birds like to migrate and feed in New Mexico from October through January.