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.

Saturday, October 08, 2011

The Beagle Has Landed!


The Beagleboard is an open-source hardware project developed around an ARM Cortex A8 processor (TI OMAP3 family). See Beagleboard.org for the general scoop. The Beagleboard-XM shown above sports the DM3730 1 GHz processor with 800 MHz DSP, 512 MB RAM, 4 GB micro SD "disk", 4 USB ports, 10/100 Ethernet, HDMI video, audio in and out. Oh, and an old-fashioned serial port. It is about 3" square and draws 2.5 W on a 5 V power supply.

That's all the hardware you need to run a slew of interesting applications. First, there is Angstrom Linux, which is a distribution tailored for embedded systems. There is also a version of Ubuntu being developed. And you can run other ARM environments, too. Android, anyone? Forth?

I'm interested in some ham applications along the lines of remote control, such as remote receiver systems for HF. The hardware is wonderful, but it's clear that 99% of such a project is software.

Google reveals a number of ham applications already out there:
I'd like to hear of others that are active. The net is littered with projects that have been announced in ambitious terms, but aren't heard from again.

Tuesday, August 30, 2011

Irenic Thoughts

So Hurricane (Tropical Storm) Irene came and went.  This is what it did to my little antenna stack.


2 meters is still pointing north, I think, but the HF SteppIR is off to the northwest, it seems.

Friday, July 15, 2011

Ham Radio Ecclesiastes

"Is there any thing whereof it may be said, See, this is new? it hath been already of old time, which was before us."  Eccl 1:10.

We often hear complaints about the decline of Amateur Radio in one way or another.  Often people say that we just don't build stuff the way we used to.  Well now, 'twas ever thus!

You can read it yourself in the pages of QST for March, 1916.  That's an article by Lloyd Manuel called "Thoughts of the Good Old Palmy Days".  He's talking about his old-time experiences -- probably ca 1905 -- when men were men and hams had to build their own stuff!

This article is a transcription from the QST archives.  You may be interested to browse through selected portions of early QST at history.aa6e.net.

Tuesday, June 14, 2011

The Sun may be headed for a little quiet time


"Is the solar cycle shutting down?
New results indicate it may very well be, at least temporarily. Even though the Sun is currently approaching the peak of its cycle in 2013, and we’re seeing an increase in activity (more sunspots, flares, and other violent events), there are strong signs that the next expected peak (in 2022 or later) may be weaker, or may not come at all! ..."
(Read more from Phil Plait's Bad Astronomy blog...)

Tuesday, May 03, 2011

Most Political / Historical QSL Ever?


Up with Bulgaria and savior Russia.  Sorry, Ottoman Turks.

Maybe this isn't the best way to QSL your contact with TA-land?

Wednesday, April 13, 2011

Bels and Nepers - BSTJ 1929

Today's ARRL Contest Update mentions the on-line availability of all the issues of the Bell System Technical Journal. That's a wonderful thing, because so much of the cutting edge electronic and technical developments of the era 1922-1983 were written up there.  It is a spectacular testament to the value of AT&T's Bell Laboratories.  It is so sad that Bell Labs (and other private research labs like IBM's) no longer have the prominence in fundamental research they once did.

So anyway, enough sentimentality.  I thought I would open up a BSTJ article at random.  Sure enough, it was very interesting.  The first article in the Jan., 1929, issue was Decibel--The Name for the Transmission Unit, by W.H. Martin, wherein the "db" was introduced to the technical public!

Why do we always use "db" instead of bels? AT&T had been using the "transmission unit" for some time, which indicated a ratio of 10**0.1 -- which was identical to the new decibel.  It's a handy unit, too, because it is just about the minimum loudness ratio a person can detect in favorable conditions.

Thursday, February 17, 2011

Quick Look at FUNcube Dongle SDR Radio

My candidate for the new radio with the most unlovely name is the FUNcube Dongle.  It is a part of the AMSAT-UK FUNcube satellite project, but it is attracting wide interest (not just for satellite work) as an example of what can be done by a volunteer group to build a very simple, but powerful Software Defined Radio to cover the 60 - 2000 MHz frequency range.  And it's pretty cheap.  The last lot went for £ 108.22 each to the US, about US $170.  They are only being made sporadically, but another batch is supposed to be coming at the end of February.

I have had a chance to borrow an FCD, and I've been trying to figure out what it does and does not do, and whether it's something I need to add to my stable.  Here are some of my lab notes:

My quick tests in my home shack without good signal generation & attenuation showed that the receiver (like any SDR) is sensitive to overload. The only signal source I could use easily was my 2M HT (¼ watt low power) transmitting into a dummy load a foot away from the receiver. I also noted that the dongle radiates at its LO frequency, breaking squelch on the HT. There seems to be little or no shielding on the dongle.  It has a plastic case, and there may or may not be shielding inside.


I used both the basic software combination (FCHid and SpectraVue) and the more user friendly (IMO) WRPlus with the G0MJW adapter DLL. The project's documentation for newbie users is fragmentary and frustrating, but that's understandable at this early stage.

At the ARRL Lab*, I found the FCD's crystal oscillator frequency in this unit is about 119 ppm high, but either software solution allows you to enter a frequency scale factor to correct for this. Warmup drift of nearly 1 ppm was observed from a room temperature start. (Lack of a high stability oscillator or an external sync capability might be a limit in some advanced applications.)

I was able to update the dongle firmware to version 18f, which is current. Surprisingly and unfortunately, I could find no indication in the PC software about what firmware version is actually installed.

I looked at the tweaks available for DC balancing (suppressing the zero frequency peak) and I/Q balance (maximizing image rejection). At 926 MHz, I was able to get 49 dB of image rejection, but the adjustment is critical. Switching to 2000 MHz, the image rejection is down to 30 dB. (Image rejection is typically about 24 dB if you don't do careful tweaking.)

Maximum input level before clipping occurs is about -55 dBm, varying somewhat with frequency.  You can easily reach this level depending on your RF environment.  A preselector filter may be needed.  (Strictly speaking, the -55 dBm limit applies to a simple sinewave input.  It's an instantaneous voltage limit, so a broadband input of greater power might be tolerated.)

A quick measurement of tangential sensitivity gave the following

60 MHz -122 dBm
144    -129
926    -130
1000   -129
2000   -133
Tangential sensitivity is a measure of the the minimum detectable signal. These values are by eye with a particular FFT and filtering setup. Don't hold me to them!

The frequency coverage was at least 60.1 – 2000 MHz.  I did not explore the outer limits of coverage.

The major limitations of the dongle are its limited sensitivity, lack of input filtering or attenuation or AGC, and limited instantaneous bandwidth (96 kHz). The USB dongle package is cheap and effective, but it's susceptible to mechanical damage if it's hanging off your laptop.

For about US $170, it's a steal. It is usable as a wide-coverage VHF/UHF receiver, especially with a low noise preamp, and it provides a good playground for learning about SDR.  I suppose it's even going to be a cheap and effective receiver for satellite work! I would want one as test equipment, but the bandwidth limitation becomes significant if you are searching for a signal with unknown frequency.

Update: The next sale of Dongles will begin Sunday 20 February 2011 22:00UTC.
----
*I volunteer in the ARRL Lab in Newington, CT.  The work here is my own and ARRL is not responsible for my mistakes!

ShareThis