Monday, July 21, 2014

Fun with WSJT-X

Since this weekend's ARRL 100th Convention, I've been trying out WSJT-X, the latest from Joe Taylor K1JT in his series of "Weak Signal" programs.  It supports the JT65 and JT9 digital modes, mainly for HF communications (1.8 - 30 MHz).  It's a more modern and user-friendly program than the original WSJT.

The JT65 mode, shown here as a waterfall spectrogram in the 17 M band, is Joe's classic mode.  It uses 64 tones plus a pilot to convey the digital message in a ~200 Hz band.  This selection is interesting, because the weak WSJT-X signal (JA1VGV) is hidden behind a strong RTTY station -- the two big vertical bars.  The JA station is -17 dB relative to the SSB noise level, while the RTTY signal is probably > 0 dB. 

A contact goes in 1 minute "chunks": sending for one minute (actually, 48 sec.) and receiving for one minute.  The divisions of transmit/receive are shown as red horizontal lines. (The waterfall is stopped for 48 sec during transmit.)

I use two power levels for JT65. Normal is 5 Watts.  When conditions are tough, I can ramp up to "QRO" -- 20 Watts.  To go higher than that is considered unsporting, I think!

JT65 is nice, but JT9 is better.  It uses the same message structure, but with only 9 tones that are spaced more closely.  JT9 is much more efficient in terms of spectrum utilization (by a factor of ~10), so it is clearly a better solution for crowded HF bands.  Unfortunately, most of the JT65 software now in use does not support JT9.  WSJT-X supports both.

Sunday, July 20, 2014

ARRL 100: Report from Hartford

The first 100 years of Amateur Radio (and the American Radio Relay League - ARRL) is now history. The National Centennial Convention closed that chapter yesterday in Hartford CT. The second chapter is slowly opening.

The League put on a great conference in the Connecticut Convention Center; a fine venue in an interesting city. If you hiked around the newly developed riverfront, you would come to the the Old State House and a lively street scene. Great food and music!

There is an occupational hazard in ham radio and the ARRL. We sometimes focus too much on how we got here – our 100 year history – and not so much on where we are going. A lot of us are old-timers with nostalgic thoughts about how we got into the hobby long ago, our first rigs, the controversies along the way, "Rotten QRM" and so on.

Conference presentations did try to look ahead. Craig Fugate KK4INZ, FEMA Administrator, gave a compelling view of Amateur Radio as a vital backup emergency service "when all else fails". The challenge is to go back to the future – to be sure you can communicate when the public telephone and data networks are completely off-line. High technology comm. systems have proven to be surprisingly brittle, just when you need them most. It was amazing to receive that kind of endorsement, personal and professional, from a high place in government.

Joe Taylor K1JT gave another keynote talk that was billed as future-oriented. Joe is a friend who is well-known as the driving force behind the WSJT weak signal communications software, a physicist and astronomer, a regular guy, and, yes, a Nobel Laureate. Even K1JT's "futures" talk was heavily biographical and historical, describing a moving personal journey that brought the audience to its feet.

Both Fugate and Taylor were given well-deserved ARRL Medals of Honor.

Futures? I found the forum talk by Frank Lloyd AA7BQ to be the most challenging. Frank is the guy behind, the well known callsign database and forum site. From humble beginnings redistributing the early FCC tape-based callsign data, QRZ has grown into a leading edge cloud-based Internet service, with a staff of 4 or 5 people. The site claims to be the number one Amateur Radio web site.'s basic service is free, but it has a number of subscription services at prices $20 per year and up. The latest is an on-line logbook service and accompanying award program. The front-end website for logging and log analysis looks quite appealing. I expect it will be a serious competitor with other on-line services like LoTW and eQSL.

What might that mean for ARRL's future? ARRL still needs to continue to reinvent itself for the Internet era. Increasingly, ARRL's identity will (and should) be as an Internet service provider – in addition to the traditional member service, technical, and regulatory roles. The League does have its big website (with lots of good content, but lots of problems, and only a weak forum system) and the LoTW program. LoTW is widely considered to be security-heavy and user-unfriendly, aimed at qualifying for ARRL awards, but having little "social media" orientation. All that said, it does serve an important role!
One of the problems for ARRL is finding a new revenue model to support an aggressive Internet program. The $39 dues are amazingly low, given all the services that are supported not to mention QST. Many hams are happy to pay another $39 or more to or similar services. That should be sending a message to the League.

Transitioning to digital publications is hard for any print publisher, but it is necessary. Digital QST is a first step, but it still has too many limitations that come from the print world. Where is Digital QEX – and other kinds of digital newsletters or forums on special topics?

That's the big challenge. The League has to stay relevant on the Internet! Oh, and on the bands, too. :-)

Friday, June 13, 2014

IPV6 ready

Comcast has blessed me with a working IPv6 connection, viz

What does it mean?  It means that we're all set when some of the Internet service providers are forced to use the new IPv6 addresses when there are really no IPv4 addresses left. (That's likely to begin soon.) It also means I'm behind the curve technically.  I understand IPv4, more or less, but v6 seems very different and a lot more complicated.

Comcast also upgraded us to 100 Mb/s download (from 50) without fanfare.  That's nice, but I'd rather have had a 50% price cut.

Wednesday, May 14, 2014

Tiny Python Panadapter (QST 4/2014)

[This posting refers to my QST magazine article, "A Tiny Python Panadapter", April, 2014, pp 33-38.  For latest information, see my website. The code repository and a support mailing list are available at]

Message from Gary KM5TY:

I'm interesting in putting together my own panadapter, however am not gelling with the idea of the low bandwidth around a signal / amount of spectrum visible with just a sound card. I am thinking that a dedicated sampling board taking in 500kHz to 1.5MHz possibly more would be much more interesting. What do you think of adding such a piece of hardware to a Raspi or Beaglebone? Would the python code be a bottle neck for the data?
Of course, more bandwidth would be very nice.  Unfortunately, to go beyond the simple soundcards for the Tiny Python Panadapter would require considerable new work or expense.  You'd have to consider the following
  • Limited CPU power of the tiny cards.  The RPi is already marginal with a 48 kHz sample rate (equivalent to 192 kBytes/sec). [Note added: We've recently made a big improvement for the Pi by downgrading to USB1.1.  The default USB 2.0 can't handle our continuous stream.] You could get to higher rates by starting over with hand-tailored C/C++ code, but there would still be a limit.
  • Cost.  The USB soundcards and the RPi/BBB are commodity items that let us do interesting things in the sub-$100 range.  Fast ADC boards are going to be more expensive, if they are available for small platforms -- or you can design & build your own out of chips.
  • Proportionality.  The systems you're suggesting are on the market already - like the QS1R and the Flex 6000 line.  These are great products, but expensive.  They are built with high performance FPGA and/or PC-level computing power.  It would be interesting to develop and open-source a free alternative project.  (Some are already out there, like openHPSDR.) But that's well beyond TPP's scope.
On the one hand, it's fun to try to squeeze all the performance you can from a $35 or $45 computer board.  On the other hand, be realistic!  It's so much easier to work with a modern full-size PC.  They are incredibly fast, even the budget models.  How many hours of programming time is it worth to cram the functionality into a tiny board, while saving only a few hundred dollars?  (My time is worth something, isn't yours? :)  In the end, cheap hardware and miniaturization are good, but they're not everything.

It's economic thinking like this that led me to see what could be done with Python on the tiny boards.  At least for me, Python is much "cheaper" to develop with than the C/C++ alternatives.  The added benefit was that it should be easier for "newbies" to pick up and modify.

Sunday, April 27, 2014

Internet Speed Tests

At AA6E, we are using the Comcast "Xfinity" "blast" service, which originally provided 50 Mb/s download, but now seems to have been quietly upgraded to ~100 Mb/s. Oh, we seem to have IPv6 service now, too.  Effectively using that in my home network will be a challenge. (One that I don't need at this time!)

Test with (MA server):

but Boston is not 5300 miles away!

Comcast (NJ Server):

Broadband Reports offers a more sober report (NJ):

The list price for this service is pretty steep IMO ($60/mo), but a slower service is not much cheaper.

Thursday, March 06, 2014

Nice things from Getty Images

Getty Images has a new program that lets you use some of their large supply of professional images for free for nonprofit purposes.  It's called their "Embed Images" service.  It's less flexible than you might want.  You can scale the image, but apparently can't crop it. You have to use their embedded viewer. (They give you an "iframe" to insert in your HTML.)

Still, there are possibilities.

Can I embed in a blog post? Let's give it a try:

Wednesday, December 18, 2013

What's Wrong with CT? (telephone edition)

This article in the Hartford Courant lays it out:

The independent phone company known as 
Southern New England Telephone (SNET)
was bought out by
Southwestern Bell Company (SBC)
was then bought out by
American Telephone & Telegraph (AT&T)
which is now being bought out by
Frontier Communications
doing business as (possibly) 
South New England Telephone (SNET)

SNET was independent for a long time and never fully part of the original AT&T.  In the new deal, AT&T will retain only its wireless phone service in CT.

All in all, the wired telecom business is sinking pretty fast as a fraction of the telecom market.  I suppose a smaller and more agile company should be managing it;  maybe that's Frontier.  On the other hand, if it is locked out of the wireless business and it doesn't have lots of capital available, will it ever be at the forefront of technology?  Will CT residents resume their status as a telecom backwater? Will there be more or less competition in this market?

State approval is needed, but I'm not feeling optimistic.  On the bright side, we dumped AT&T U-verse service in favor of Comcast for phone, data, and video a year ago.

Saturday, October 26, 2013

Data Footprint Control -- Your own email server!

Lately I've been talking up the idea of "data footprint".  It's a fact that we're spreading all kinds of personal data around the Internet in the course of our modern electronic and financial lives.   Our bank, Facebook, Google, Yahoo, Comcast and essentially everyone we do business with is collecting data about us. The data get bought and sold and snooped no matter what our wishes may be.

One concrete thing I could do, while having a bit of fun, was to move my Google email back to a server computer under my own control.  That's (a) a rather old-fashioned thing to do, (b) rather complicated to set up correctly, and (c) a losing game in terms of functionality.  No doubt Google Mail sets the standard for usability, especially for power users.  It also has the best anti-spam technology I've come across.  So if we step back to a local server, we will be losing some useful features.

It happens I have an older Raspberry Pi (256 MB Model B) which hasn't had a particular mission.  So now it is the household IMAP server, with my 1.6 GB email stash on a 16 GB SD card.  It would have been easier to use a big PC for this function, but I wanted a platform that I could leave on 24/7 without eco-guilt.  It uses just a couple of watts of power.

I am temporarily (until I forget all the details) an expert on Postfix, Dovecot, and SSH, allowing me to access the e-mail from any machine on the home network and (securely) from external machines. Fortunately, I have an external SMTP relay that is part of my web hosting service, so outgoing e-mail should be treated with proper respect by the big services.  (A user PC directly sending out SMTP mail is often shunned as a likely source of spam.)

It's a just a symbolic step. We have a long way to go before we get control of all our data.

UPDATE 1: The dirty little secret they don't tell you at e-mail school is that most e-mail is spam, and an e-mail server without spam filtering is ... not worth a lot.  On the client side, Thunderbird and some others make a valiant attempt, but it wasn't going to work for me.  Especially since I want to use an Android client like Kaitin (no spam filtering) for mobile e-mailing.  So I consulted (Ubuntu is close enough to Raspian.) Everything installed OK until it became clear that my 256 MB Pi might not support a big freshclam update.  OK, we don't need antivirus for Linux/Android, do we?  Anyway, the server has started bouncing spam pretty well now.  And the Pi can feel virtuous as it crunches on each message for a second or two.

UPDATE 2:  ClamAV is hopeless, taking way too much RAM and CPU.  Fortunately Amavis doesn't need antivirus, so it's OK just to remove it from the system.  Even so, Amavis & co. take a lot of RAM and just fit in the 256 MB machine along with Linux.  If I start doing package updates, for example, there is a lot of "disk" thrashing -- swap utilization climbs, and things go very slow for a while.  (But no crashes!) A 512 MB machine would be much better.  Spam scanning and message handling seem to take 5 to 15 seconds per message.  This is not a high volume solution, but it handles my load OK.

UPDATE 3: This project was a success technically, but Comcast woke up to it (maybe they read my blog?) and they blocked port 25 on my service. Maybe I could have argued my case, but I didn't pursue it. Instead, I moved my email action to, a commercial outfit that specializes in email - and doesn't sell my info to the highest bidder, hopefully.