Thursday, May 24, 2012

QST & digital QST


The new digital QST edition is now on the web, accessible to ARRL members.  It's a good effort -- at least if you like the new web magazine reading experience.   It is being provided to members as a no-extra-cost addition to the traditional print version.

I hope the pdf version won't go away completely.  That's the format that appears on the annual publications CDROM and on the QST web archives up through 2011. The new format is fine (well, if you like it!) for on-line reading and limited off-line reading, too, but it is a proprietary and DRM-restricted format that probably won't be convenient (if readable at all) 50 years from now.

I was interested in the new QST logos that are cropping up.  There are several variations. One is at the top of this post (I understand it is for the iOS app), and here is another:


But I like to look through the QST archives to how QST presented itself in the very earliest days.  The first "logo", from 1915, was this neoclassical marvel:


Then, in the late teens and into the twenties, you might have seen this one.  (Color added.)


This is the classical logo for me.  Its block lettering and at least some of the lightning bolts continue into the modern era.  The slogan now says "Amateur Radio" instead of "the Wireless Amateur".  I like this old graphic, but I'm pleased that there is so much continuity in today's version.

Finally, take a look at the first digital QST cover (June, 2012):


Bold and hyperactive design, and presented twice for good measure!

Monday, April 09, 2012

Adventures in Platform Independence

So I have this nice program developed that will allow us to transmit compressed communications audio over an Internet link.  It will be part of a remote Internet receiver that will support W1HQ, the club station at ARRL, Newington, CT.

The program came together fairly easily, using old-fashioned Linux / C programming, together with the Speex and Portaudio libraries.  The sending program runs on an ARM-based Beagleboard card, and the receiving side should run on any Linux box running Ubuntu or your favorite Linux distro.

Along with the audio software, there is an independent rig control function using Python, wxWidgets, and Hamlib.  That should run nicely on Linux, Windows, or what-have-you.

Since our W1HQ crew really needs to keep their Windows station computer, we do need to make the audio receive software run under Windows, along with rig control.  That's where today's lesson begins.

Porting to Windows!

The problem of porting Linux C code to Windows is the subject of a lot of Internet discussion.  It needs to be done frequently, but the process is not simple.  For one thing, the programming tools are rather different.  While the basic principles are the same, all the details are different.  In Windows you generally code within a complex IDE system (Interactive Development Environment).  Managing libraries, dealing with the graphic user interface, and even finding useful "help" files are all a challenge. But the killer, for me, is the unavoidable fact that the underlying operating system just does things differently from Linux.  This shows up in many ways, but my problem specifically was dealing with Internet communications (sockets).

I looked at 3 approaches, before finding a solution that might work for us:
  1. Visual C++ and Visual Studio.  This is Microsoft's preferred development system, using the big IDE model.  Fortunately, there is a free "express" version that might work for us.  I could get the Portaudio and Speex libraries to compile, but the socket programming model seems to require serious recoding work.  It would be possible, but it's almost like starting from scratch.  Furthermore, we'd end up with  Windows source code and Linux source code that would have to be maintained in parallel.
  2. CygwinCygwin is software that runs under Windows and provides a Linux command line interface.  Compiling with gcc works in Linux style, so that's good.  However, there is no support for Linux sockets model, so it's no help in the end.
  3. MinGWMinGW does not provide a full Linux run environment, but it has a number of features that help you compile Linux code to run under Windows.  Compiling the libraries is no problem, but still there is no sockets compatibility.
Not Porting to Windows!

The only solution I've found that won't require investing time in Windows C programming, is to virtualize the problem.  That is, set up a virtual Linux PC inside our Windows box using the free Oracle VirtualBox.  A good modern PC should have enough horsepower for this.  (We'll see about the W1HQ machine!)  Once this is set up, you can run all the code the way it was meant to be run.  The price to be paid is 4-8 GB of disk space and 300-500 MB of RAM.  Since our needs on the Linux side are very modest, we may be able to pare down the memory requirements substantially.

VirtualBox runs the audio software fine under Windows 7 on my home machine.

Update 9/8/2012:  VirtualBox works nicely, but it has a large footprint on any average size computer, so it's probably too much to run at W1HQ without an upgrade.  RAM upgrades are cheap, but it's probably worth another look at Windows coding.  I've simplified the audio transport to use UDP, so there's probably less OS dependency.  We'll see.

Friday, February 17, 2012

ABCs of SDR

The new book is out.  It's a concise low-math (almost zero math) description of what SDR (software defined radio) is all about, for the general ham radio audience.

The short message:  It's the main technology at the core of about every HF radio you can buy these days.  If a radio has "IF DSP" it normally has an SDR back end.  Front ends vary, from minimal ("pure" SDR) to conventional, but the digitization and digital signal processing is mostly the same.

Order from ARRL or your favorite bookseller.

Wednesday, January 18, 2012

Thursday, December 08, 2011

The Beagle Barks!

Our Beagleboard-based remote rig control project passed a little milestone today. (See previous posting.)

The BB was set up here in Branford CT on my LAN and connected to a Ten-Tec Orion transceiver.  We accessed it from the ARRL Lab in Newington.

The new audio transport software uses PortAudio and the Speex codec, along with grig and hamlib for rig control, we were able to demonstrate remote receiver operation.

There are many other existing remote control schemes, but our project has a number of features:
  • Low-cost ($150 for the BB at Digikey)
  • Low power (~5 W)
  • Full-fledged Ubuntu Linux software environment
  • Lots of I/O and CPU options for future expansion
  • All open source (even the Beagleboard itself)
The demonstration was fine, but more integration and packaging are needed before we can share the details.

The fan would not be necessary, except that our board is overheating.  It is going back to the Beagle Hospital for some TLC soon.

Update: It turned out the BB hardware was fine.  I was running an Ubuntu kernel that was somehow configuring the board improperly.  With a new kernel, the board runs very cool, with no fan needed.

Wednesday, November 16, 2011

We Need a Few Good Codecs

audio waveform image by Jesse-lee Lang
from Fotolia.com via eHow.com
Software audio codecs for ham radio? What's the best? Lots is known about telephone voice codecs, but we have noisy voice with QRM, and we also have CW and various digimodes that we want to transmit from a remote RX via digital links. Each scenario might need a separate codec for optimum results. Give up and send linear/uncompressed? Inquiring minds...

This question comes up as I'm trying to work out a strategy for a remote receiving station using the BeagleBoard XM card running Ubuntu.  Lots of fun, but there are many details to work out, including the audio transmission problem.

Update: Beagles on the mind.  I'm using the BeagleBoard XM, not the BeagleBone, which was just announced.

Tuesday, November 15, 2011

Teaching Schematics

Great explanation of electronics schematics for new hams and other students:


Check out "Collins Lab" at Make Magazine for many others.

Friday, November 04, 2011

Hackers I have known

I've just finished "Hackers: Heroes of the Computer Revolution" by Steven Levy.  Originally published in 1984, the book chronicles the early days of computing, when giants strode the earth... It is out in a 25th anniversary edition.

Naturally, and without too much shame, I read it on the Kindle. (If you haven't read the book, see below to appreciate the situation.)

I suppose, by Levy's account, I was on the fringe of the second generation of hackers.  (or maybe generation 1.5)  I crossed paths with a couple of the figures mentioned in the book.  Unknowingly, there may have been more who I never met by name, but who inhabited the same spaces I did.

Bldg 26 -- It never looked this good!
I was a graduate student at MIT from 1966 to 1971, working in Building 26, the Compton Lab. (Levy has unkind words for grad students who were always trying to get things done with the computers, as opposed to the hackers who were building a little utopia around neat code and the "hacker's ethic".  But I will let that pass.)

I began my career at MIT with a couple of computing projects. (I was a physics student working in radio astronomy, but computers have always been central in my world.)  First, a re-reduction of Prof. Bernard Burke's 234 MHz Sky Survey data, which I inherited from other hands.  That project never really finished, and for all I know, someone is still working on it!  It was a great chance to learn the ropes of "glass house" computing, using the IBM 7094 system on the first floor.  It was a true glass house, having magnificent viewing windows from the first floor corridor.  This was a batch system, using punched cards and magnetic tape for input.  You waited hours for a print-out to come back.  A second 7094 system in the same room hosted the CTSS timesharing system, but that was too expensive and not quite powerful enough for my project.  This was all using the new Fortran IV language.

My more respectable work (in hackers' terms) was in connection with a later project, where we had to analyze radiometer data collected on punched paper tape.  We were setting up to measure the "3 degree" cosmic background radiation.  This analysis really needed an interactive analysis, where we could edit and calibrate the data with successive refinements.

So I was introduced to the DEC PDP-1 computer on the second floor.  It was the late 60's, and I was largely unaware of the glorious history of that system and its earlier sister machine, the TX-0 in the next room.  Levy's book fills in a lot of details for me.

MIT PDP-1
The PDP-1 had been expanded to a small timesharing system, supporting 4 terminals.  There was an early graphics display that you addressed in a very simple way: set X, set Y, beam on, beam off -- as I recall.  No driver software! We used a software system called "Stargazer" developed by Eric Jensen. I presume he was the same person mentioned by Levy as "Jensen".  I remember him as an affable but maybe quirky fellow, who had another passion as a comic diver at the MIT pool.

The PDP-1 was a wonderful system, everything was assembler code (of course!) with some exotic peripherals for the time.  A Calcomp plotter (which we used one year to make individualized snowflake Christmas cards) and a nice sound system that played a respectable "Eine Kleine Nachtsmusik" in 4 part harmony, IIRC.  I remember one day when the engineers wheeled in a new electronics crate.  They took the system down for a time, and then lo we had a new "index register" in our instruction set.  Magic.

Several years later, probably about 1969, I needed to make photographs of pulsar data -- time vs frequency for pulses dispersed by the interstellar medium. It turned out that the ancient (by that time) TX-0 computer had a magnetic tape drive and a suitable display and camera.  It was easy to get time there, since most of the action revolved around the PDP-1.

MIT TX-0
The TX-0 was truly amazing.  It had the power (maybe) of an Apple II, but it was built on a large collection of relay racks spread around a good sized room.  It was said to be the first computer to have used transistor-driven magnetic core memory.  (Levy goes into the history of this machine, but does not dwell on its technology.)  One feature stood out in particular.  It was a wonderful thing to turn the system "on".  It was not simple.  You turned on power, but then you had to start the processor clock.  The clock consisted of a sequence of variable delay lines connected in series and then wrapped around to make a loop.  (Several clock phases were needed to sequence the logic correctly.)  You had to wait until the electronic delays were stabilized (they were probably vacuum tube devices).  Then you pressed the "start" button that injected exactly one short pulse into the loop that started everything going.  It's safe to say I've had a higher interest in power-on sequencing since those days.

We got advice and help from John McKenzie, who was the support engineer for the TX-0 mentioned in Hackers.  I remember him as gracious, supportive and tolerant with us newbie students.  I would put him alongside D. Cosmo Papa, Jack Barrett, and a number of other engineers and technicians who really kept MIT and MIT students running right in those days.

Today's open-source software movement is a direct descendant of the original hacker generation.  Many of the early struggles still resonate.  "Information wants to be free."  Aggressive efforts to impose overbearing intellectual property rules and DRM (digital rights management) really need to be opposed.  Maybe we aren't seeking a free information utopia, but we do need to understand that creative expression (and programming) are always built on the foundation of earlier works.  Mickey Mouse can't be "owned" forever.

It may be that a true hacker would never be caught dead with the DRM-heavy Kindle, but some of us have mellowed at least a little.