Showing posts with label hamr. Show all posts
Showing posts with label hamr. Show all posts
Thursday, August 15, 2019
Casing the Environment
We have completed our move to Evergreen Woods, at least to the point of unpacking many of our boxes of "stuff". Time to check out the Electromagnetic Environment.
It's not all good or all bad. The fact is that we're inside a fairly large complex of 249 apartments and commons buildings. We are in a rural/suburban setting, but the buildings have complex systems for HVAC, data networks, and power distribution. So we expect a somewhat challenging RFI situation for HF. You see one example above. All the peaks (separation ~106 kHz) seem to come from one source that probably gets here via the AC power line.
I am using a Flex 6500 SDR as an RFI receiver with an EMCO 6502 active loop antenna. The antenna sits at my new second-floor operating position, not far from some metal objects that probably affect the measurements. The proposed antenna site is on the roof above the third floor, which is probably (hopefully) a somewhat better location!
Zooming in to get some finer detail, we see three of these peaks in the 40 M band:
A working hypothesis is that these may come from the building elevator system, with the glitches occurring during elevator motion.
This 106 kHz frequency comb is not quite fatal for ham radio, because in most cases you can choose an operating frequency away from the RFI.
There seem to be several sorts of RFI that become visible at various operating frequencies and various times of day. Some of them are quite broad (no narrow spectral peaks), and some are impulsive, like ignition interference or PLC-type digital signaling. The Flex 6500 has several noise blanking options that are at least partially effective.
The antenna is probably going to be placed above the flat roof shown below:
A diagonal run of about 100 ft looks possible, using 20 ft masts.
Stay tuned for further developments!
Wednesday, July 03, 2019
Migrating from Branford to North Branford CT
AA6E moving on, see my web site: https://aa6e.net/nw/index.php/13-senior/25-aa6e-in-transition. The big shack picture is fading into history.
We are thinking about quality instead of quantity here, as far as the ham activity goes.
We are thinking about quality instead of quantity here, as far as the ham activity goes.
Monday, April 09, 2018
Frequency Measurement Test
![]() |
The old way: BC-221 meter |
This time, we've upped the ante, using the FlexRadio Systems 6500 transceiver (an SDR radio) with its GPS Disciplined Oscillator as a master frequency reference. The reference is said to be accurate to some parts in 1012, though we have no way to verify that number at this time. If the receiver is tuned to a known frequency just below the test signal in upper sideband mode, so that the received signal shows up as an "audio" tone. (In this SDR receiver, there is no "audio", since everything is digital. That bypasses various audio measurement problems that might otherwise have cropped up.) The fldigi software package is used in its "spectral analysis" mode to accurately measure the offset, combined with the known local oscillator tuning, to yield a good measurement of the unknown RF frequency. The software outputs an Excel CSV file that records time and best-fit frequency each second.
Here in Branford, CT the antenna for 20 M is a 3-element SteppIR at 40 ft pointed west. For 40 M and 80 M the antennas were dipoles oriented NW-SE, more or less.
This exercise involved transmissions on the 20, 40, and 80 Meter amateur bands from K5CM in eastern Oklahoma.
RESULTS
The actual numbers as transmitted are reported on the FMT results page for 2018.
Band | F Measured (Hz) | F Actual (Hz) | Error (Hz) |
20M | 14,121,963.42 +/- .08* | 14,121,963.34 | +0.08 |
40M | 7,064,257.09 +/- .20* | 7,064,257.06 | +0.03 |
80M | 3,598,169.5** | 3,598,169.73 | -0.23 |
* Error bar quoted is 1/2 the total peak-to-peak frequency excursion in the 2 minute test transmission.
** 80M results were compromised by a data handling problem. Precision is reduced, and an error bar could not be estimated.
WWV reported geomagnetic conditions Kp=2 and Ap=9 during the test.

The 40 M signal was about S8, i.e. up to 16 dB weaker than on 20 M. This probably produced much of the short-period noise on the graph. However, we might also expect the ionosphere to produce more variability on the lower frequency.
For 20 and 40, we calculate a simple average frequency, after eliminating the initial points on 20 M. Note that we might have done better of we could weight the samples according to instantaneous signal strength. There are two sharp dips in the 40 M data that may well have arisen from deep signal fades. If they were eliminated, we would have a slightly higher frequency estimate, which would have increased our final error value.
Because of the problems with the 80 M data, there is no meaningful graph to plot for that band.
DISCUSSION
The final error (Measured - Actual) is under 0.1 Hz for the two fully analyzed bands, while the 80 M error is -0.23 Hz based on fewer data points. These are surprisingly good, leaving relatively little room for improvement given the "noisiness" of ionospheric propagation conditions. Presumably, we might get a somewhat better measurement if we had a longer test run, perhaps 5 or 10 minutes or more, or if we got lucky and had a period of super-stability in the ionosphere.
Friday, February 23, 2018
GPS is Looking Up
![]() |
GPSDO unit in Flex 6500, cover removed |
![]() |
Flex 6500 GPSDO attachment area |
As you can see from the photo, the GPSDO appears to be based on custom version of a Jackson Labs GPSOCXO (Oven Stabilized Crystal Oscillator) module. It's the green board that attaches to a blue Flex-produced interface board. The GPSOCXO specifications are available as a PDF, while general information is here.
I am now on my third GPS unit. The first was a "reconditioned" unit, because new units were then in short supply. It never worked for me -- it would not detect satellites. Flex then supplied another unit, which worked well. It detected satellites, locked up, and appeared to deliver good frequency stability. But, over time, it grew hard of hearing. It dropped out of lock more and more and finally would not lock at all, though it continued to supply 10 MHz in "holdover" mode.
![]() |
GPS Status, SSDR software |
Currently, I use the Flex-supplied simple "patch" active antenna attached to a nearby west-facing window. Typically, I track 7-8 satellites out of 10-11 "visible". We might be able to squeeze out more performance by installing a larger outdoor antenna.
Why use GPS?
The standard Flex TCXO is fine for nearly any application in the HF/6 bands. So why go for GPS? Because it's there. Because, as an erstwhile VLBI radio astronomer, I am interested in time and frequency standards. (See time-nuts.)
There's a good case to use GPS stabilization for VHF/UHF/microwave work, where oscillators are typically locked to a high harmonic of a 10 MHz standard. A portable GPS time standard is also useful for operating modes like JT65 or FT8 that require it. (Although, with care, WWV's HF time signals are also good enough.) Unfortunately, Flex does not yet offer time synchronization services for the radio shack. Maybe in the future.
Note added: So after 24 hours of operation, we lose lock. Of course there's a light cold rain and heavy overcast. Hoping it's the weather. (But my cell phone GPS is working fine...)
More: It's looking like this was a connector problem. (Electronics troubles often are.) If you look at the attachment area photo (here enlarged), you will notice the 10 golden spring terminals. These touch gold-plated tabs on the GPSDO PC board. They provide all the power and computer signalling. It's not apparent in this photo, but if you look edge-on with a magnifier, you might notice that the tiny springs are not all in perfect alignment vertically. It seems that one or more of them were not making good contact. (The PC board screws down on the alignment posts, and the contact pressure has to be "sufficient" -- whatever that may be.) After a little fiddling with a tiny screwdriver, along with an alcohol cleaning, the GPSDO seems to be back in operation. For good measure, I also replaced the RF input cable.
We will see if things are now stable. It has been OK for 12 hours! I have to say that the GPSDO-to-mainboard connection system is not the most robust. It looks like we had a marginally OK connection at first, which degraded after some temperature cycling or minor vibration. A traditional connector (with pins and sockets) would have been much more reliable, though a bit more expensive and less elegant.
It's possible that all this last year's GPS travails came down to that connector, but I can't be sure.
Yet more: After the connector fix, the GPSDO seems to be much healthier, but we were still experiencing occasional drop-outs (loss of sync). Moving the antenna outdoors seems to make a big improvement. The view is much less obstructed. I've made a stab at a weather-tight case for the little biscuit antenna using a large size prescription container and taped the whole thing to a nearby mast at about 5 ft elevation. We seem to be getting good sync about 10 minutes after a warm start, which is a lot better than before.
Sadly, the Flex module does not give any direct indication of GPS signal strength. There is also no way to log loss of sync events. Maybe this is a good time to start writing Python code to access GPS status from the radio via TCP/IP. I would like to log performance for a few days as a final system check.
Monday, October 02, 2017
A little NUC on my desk
When my 8 year old computer, home built with a Core i7-920 processor, began freezing up randomly, a new generation computer was in order. The only application I normally use that takes significant computing power is FlexRadio's Smart SDR for Windows that needs to control the Flex 6500 SDR transceiver.
Recent SSDR versions are much less demanding than they used to be, so maybe I could make do with a "downgrade" to a Core i5 system. Intel processors divide broadly between "i3" (dual core), "i5 (dual core, with hypterthreading yielding 4 threads), and "i7" (quad core, 8 threads). Of course, the later chips ("generations") in each category will be a lot more powerful than the earlier ones.
After some debate, I selected a Intel NUC (next unit of computing) tiny computer configuration in "kit" form. You need to supply your own SSD (solid state disk) or hard drive and your own DDR4 RAM. The NUC is available in quite a few versions, but I ended up with the Intel BOXNUC7I5BNH kit, which is a "7th generation" i5 box with room to add a 2.5 in. SSD or HD.
I installed a Samsung 960 EVO Series - 250GB PCIe NVMe internal SSD, which uses the (relatively) new M.2 interface and leaves the 2.5 in. bay free for the future. Two 4GB DDR4 RAM chips complete the kit. Assembly is trivial, if you're at all familiar with computer innards. Installing Windows 10 Home from a USB memory stick was quick. Transferring data and software from the old system was simplified by staging files onto an external USB hard drive.
After all that, we have a very fast little computer. The Passmark benchmark comes out at 3,644, which is roughly 60% of the score of the old i7-920 with GT640 graphics -- but with half the cores and only on-chip graphics. The NUC is happy to drive my two HDMI displays, although the second display requires a Thunderbolt/USB-C to HDMI adapter cable. SSD I/O performance is blazing!
But what about Flex SSDR? That's the primary app for this computer -- when I'm not using the Flex Maestro controller. Here are some results:
Panadaptors |
|
window size |
|
CPU utilization |
|
Network Mb/s
|
1
|
1/4
|
15%
|
2.4
|
1
|
full
|
20%
|
2.7
|
4
|
full
|
33%
|
6.0
|
4*
|
full
|
44%
|
9.4
|
4*
|
1/4
|
36%
|
7.2
|
(* maximize spectrum frames per second and waterfall rate)
The worst case CPU load (44% across the 4 i5 threads) seems to be a comfortable number. The Flex 6700, on the other hand, with its maximum 8 panadapters might have trouble, if that's your operating style.
The NUC handles the required load with capacity to spare. It uses much less power to run and has only about 1/60 the volume of the old system, fitting easily on the desk.
Saturday, February 25, 2017
Whatever became of Eimac?
![]() |
(Wikimedia) |
With the help of DuckDuckGo, I was able to trace a long corporate history, starting with the original Eitel-McCullough company (1934), which became Eimac. Then, a merger with Varian Associates, ending up as a part of Communications and Power Industries (CPI).
The good news is that, within CPI, the Eimac name still exists, and they still market power transmitting tubes. Alas, the classic glass envelope / internal anode tubes (as shown above), including the 3-500Z, are no longer offered by Eimac. (Some are still widely available as imports and marketed by firms such as RF Parts.)
Eimac is found in high-end markets for commercial, industrial, and military transmitters. Glass has given way to ceramic for insulating seals, while external directly cooled anodes are the choice for efficiency and performance. "Low end" Eimac tubes (triodes and tetrodes that are effective for our 1.5 kW power levels) may still be produced in low volumes, but they will be very expensive compared with glass envelope imports for our ICAS operations.
Over recent years, the old vacuum tube technology has been replaced by solid state designs, especially for commercial service. So there is little demand for the kW size tubes. Still, it's much cheaper to keep an SB-220 going with new imported tubes if needed, than to upgrade to the latest transistor amps.
Your reward for reading this far!
CPI provides a library of some of the older Eimac applications support documents. I found "Care and Feeding of Power Grid Tubes" especially interesting. So here are some links to the PDF files. The basics will be interesting to ham operators, especially those of a certain age. The advanced sections cover some fascinating large and exotic transmitting tubes that most of us will never see.Sunday, January 15, 2017
First Meteor Scatter Contact
![]() |
Meteor in a Perseids shower, Wikipedia |
Meteors strike the Earth's atmosphere frequently, even in the absence of a big meteor "shower". They generate a trail of ionization that lasts up to a minute or so (at 50 MHz), which is sufficient to exchange a bit of information between ground stations that have mutual visibility -- up to about 1,300 miles.
![]() |
Strong meteor burst from N0TB in Minnesota displayed on FlexRadio FLEX-6500 SDR transceiver |
Thursday, November 24, 2016
Prefixes I have known (WPX)
Recently received some more wallpaper, attesting to the number of "prefixes" I have contacted on the Amateur bands over 50+ years -- 550 Digital and 600 total. (There are a lot of prefixes out there. AA6 is different from AA7, etc.) Digital contacts include RTTY (radio teletype), PSK31 (phase shift keying), and (mostly) JT65/JT9.
Sunday, April 10, 2016
Modest Ham Radio Milestone (LoTW)
Personal Best Dept:
My Logbook of the World (LoTW) account just turned 2,000. That's the number of confirmed "electronic QSLs". My digital log stretches back to the 1980's at least. (I wish I still had my earliest logs, starting in 1958 or so!)
This will not set the world of amateur radio on fire. Many folks are a lot more active than I am. With a little grit, you can get 2,000 contacts in a single weekend contest! But it's meaningful to me, in a Sunday-driver kind of way.
Another interesting statistic is that my percentage confirmed on LoTW is just about 50% now, a big improvement over the last few years. Largely, that is due to a lot of JT65 / JT9 contacts, where LoTW confirmations are very common. (The folks who are able to set up for digital modes are also likely to be able to handle the still-somewhat-arcane LoTW procedures.)
I still like to send and receive the traditional paper QSL cards, but I confess I have not solved the problem of how to store and/or display them.
My Logbook of the World (LoTW) account just turned 2,000. That's the number of confirmed "electronic QSLs". My digital log stretches back to the 1980's at least. (I wish I still had my earliest logs, starting in 1958 or so!)
This will not set the world of amateur radio on fire. Many folks are a lot more active than I am. With a little grit, you can get 2,000 contacts in a single weekend contest! But it's meaningful to me, in a Sunday-driver kind of way.
Another interesting statistic is that my percentage confirmed on LoTW is just about 50% now, a big improvement over the last few years. Largely, that is due to a lot of JT65 / JT9 contacts, where LoTW confirmations are very common. (The folks who are able to set up for digital modes are also likely to be able to handle the still-somewhat-arcane LoTW procedures.)
I still like to send and receive the traditional paper QSL cards, but I confess I have not solved the problem of how to store and/or display them.
Saturday, January 16, 2016
ARRL President's Award
Lots of comings and goings at the ARRL. Dave Sumner is retiring this year as CEO, and has just received the ARRL President's Award for his many years of service to the League, presented by outgoing President Kay Craigie.
Monday, June 29, 2015
Morse Motivation!
I've been amiss not contributing to the blogosphere for some time -- busy with some writing assignments.
But this article from 7 years ago came into my inbox today. It reminds me that there's a lot of room for improvement when it comes to Morse communications. It needs old-fashioned wetware effort. (No computer CW for me!)
We won't all achieve 140 wpm or anything like it, but I, for one, have been stuck on a plateau around 20 wpm for many years.
A while back I was inspired by a FISTS article IIRC about the guy who made the simple resolution to have at least one Morse QSO every day. It seems like such an easy thing -- but he had been doing it for many many years.
I don't know what goal I should set, but I do need one.
But this article from 7 years ago came into my inbox today. It reminds me that there's a lot of room for improvement when it comes to Morse communications. It needs old-fashioned wetware effort. (No computer CW for me!)
We won't all achieve 140 wpm or anything like it, but I, for one, have been stuck on a plateau around 20 wpm for many years.
A while back I was inspired by a FISTS article IIRC about the guy who made the simple resolution to have at least one Morse QSO every day. It seems like such an easy thing -- but he had been doing it for many many years.
I don't know what goal I should set, but I do need one.
Friday, August 15, 2014
Radio Warmup Issues
The WSJT-X software has various uses. One neat one is to measure frequencies and drifts accurately.
This is the warmup curve for the TenTec Orion 575AT. Ambient temperature is 75F, and we're starting from that temperature and watching the drift in the apparent frequency of the 15 MHz WWV signal. The receiver is tuned to 14.999700 USB, so the "correct" response would be a WWV carrier appearing at 300 Hz on the spectrogram. The WWV carrier (strong red trace) had a starting point (ambient) at about 280 Hz, but this plot begins a little after warmup has started. (The other, blue/yellow traces are modulation sidebands that can be ignored.)
You can see that the initial warmup (fast drift) is over after about 6-8 minutes. A slow drift continues for another 10-15 minutes, with the apparent frequency stabilizing around 302 Hz. But after 30-50 minutes, an even slower downward drift comes in that brings the reading down to ~298 Hz. (This is getting into the weeds of ambient temperature stability, etc. For real statistics, you'd have to repeat all this under various conditions.)
Is this result good or bad? The initial 20 Hz offset is about 1.3 ppm, while 2 Hz is 0.13 ppm, relative to the 15 MHz signal. The TenTec specification for this radio is +/- 3 ppm over the operating temperature range. The Orion uses a temperature compensated crystal oscillator - TCXO. The oscillator has a screwdriver adjustment for frequency, which I carefully tweaked in 2005.
Clearly, we are in spec at this particular operating temperature, but in fact the specification does not really tell us what to expect in terms of accuracy or stability at any particular ambient temperature.
I may be in the minority, but I like to be able to use my gear for precise frequency measurement. (And not as an expensive thermometer!) Some newer rigs are better. For example, the Flex 6300 and 6500 offer a "0.5ppm TCXO", while the 6700 has a "0.02ppm OCXO" (oven stabilized crystal oscillator.) Flex offers an expensive add-in GPSTCXO option (GPS stabilized TCXO) that claims 5 x 10**-12 stability over 24 hours.
These numbers are helpful, but if you really want to compare time and frequency standards, you need to consider the Allan Variance, which is a measurement of stability on different timescales. (See informative PowerPoint by H. Fruehauf, or comprehensive Wikipedia article.) What we usually need for precise amateur communications (say using advanced WSJT-style modulation at microwave frequencies) is stability over tens of minutes. The vendors' specs really don't tell you that.
This is the warmup curve for the TenTec Orion 575AT. Ambient temperature is 75F, and we're starting from that temperature and watching the drift in the apparent frequency of the 15 MHz WWV signal. The receiver is tuned to 14.999700 USB, so the "correct" response would be a WWV carrier appearing at 300 Hz on the spectrogram. The WWV carrier (strong red trace) had a starting point (ambient) at about 280 Hz, but this plot begins a little after warmup has started. (The other, blue/yellow traces are modulation sidebands that can be ignored.)
You can see that the initial warmup (fast drift) is over after about 6-8 minutes. A slow drift continues for another 10-15 minutes, with the apparent frequency stabilizing around 302 Hz. But after 30-50 minutes, an even slower downward drift comes in that brings the reading down to ~298 Hz. (This is getting into the weeds of ambient temperature stability, etc. For real statistics, you'd have to repeat all this under various conditions.)
Is this result good or bad? The initial 20 Hz offset is about 1.3 ppm, while 2 Hz is 0.13 ppm, relative to the 15 MHz signal. The TenTec specification for this radio is +/- 3 ppm over the operating temperature range. The Orion uses a temperature compensated crystal oscillator - TCXO. The oscillator has a screwdriver adjustment for frequency, which I carefully tweaked in 2005.
Clearly, we are in spec at this particular operating temperature, but in fact the specification does not really tell us what to expect in terms of accuracy or stability at any particular ambient temperature.
I may be in the minority, but I like to be able to use my gear for precise frequency measurement. (And not as an expensive thermometer!) Some newer rigs are better. For example, the Flex 6300 and 6500 offer a "0.5ppm TCXO", while the 6700 has a "0.02ppm OCXO" (oven stabilized crystal oscillator.) Flex offers an expensive add-in GPSTCXO option (GPS stabilized TCXO) that claims 5 x 10**-12 stability over 24 hours.
These numbers are helpful, but if you really want to compare time and frequency standards, you need to consider the Allan Variance, which is a measurement of stability on different timescales. (See informative PowerPoint by H. Fruehauf, or comprehensive Wikipedia article.) What we usually need for precise amateur communications (say using advanced WSJT-style modulation at microwave frequencies) is stability over tens of minutes. The vendors' specs really don't tell you that.
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.

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 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 QRZ.com, 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.
QRZ.com'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 QRZ.com 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. :-)
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 SourceForge.net.]
Message from Gary KM5TY:
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.
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.
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 http://speedtest.comcast.net (MA server):
but Boston is not 5300 miles away!
Comcast (NJ Server):
Broadband Reports offers a more sober report http://www.dslreports.com/ (NJ):
The list price for this service is pretty steep IMO ($60/mo), but a slower service is not much cheaper.
Test with http://speedtest.comcast.net (MA server):
but Boston is not 5300 miles away!
Comcast (NJ Server):
Broadband Reports offers a more sober report http://www.dslreports.com/ (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:
Still, there are possibilities.
Can I embed in a blog post? Let's give it a try:
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 https://help.ubuntu.com/community/PostfixAmavisNew. (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 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 https://help.ubuntu.com/community/PostfixAmavisNew. (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 Pobox.com, a commercial outfit that specializes in email - and doesn't sell my info to the highest bidder, hopefully.
Wednesday, October 23, 2013
ARRL Handbook: Cool, but Heavy Reading

Yesterday, I got my engraved hardbound copy of the 2014 (Centennial) Handbook. It's the Ham Bible, they say, but it's big!
In fact, it weighs in over 6 lbs (2.7 kg). This makes it rather difficult for reading in bed, especially for us geezer types. (Note for reflection: the actual Bible, as usually printed, is much more user-friendly!)
My solution: upload the CD right away to Google Drive. (privately) That makes it available wherever I'm likely to be. And with the Nexus 7, it's quite manageable while reclining!
So apart from the cool-factor of having this tome on my bookshelf, it would be just as well to get my Handbook via Google Drive directly -- or some other network based solution.
(We might ask what it would be like if each chapter of the Handbook had an accompanying online wiki where readers could add their material. Mixing curated and non-curated content would be a challenge, but a worthy one!)
At right is the classic ARRL graphic (ca 1975) that I seem to carry around in my head. A very nice portrayal of the then-modern ham!
And strangely enough, it must be one reason while I frequently go up to HQ, and why I'm thinking about the Second Century Campaign.
Sunday, October 20, 2013
Station Computer Upgrade
I had enough! My creaky Intel Atom-based computer had enough oomph with Ubuntu to run fldigi, but just barely. It couldn't handle a browser and logging program running alongside very well. So the D945GCLF motherboard supporting an Atom 230 processor and 1 GB of RAM is now surplus. (See right.) Note that it has on-board serial and parallel I/O ports - a rarity now! (I originally chose the Atom board as an experiment to see how small a processor was really necessary. I answered that question.)
Upgrading was straightforward. I could keep the power supply, case, DVD drive, etc. The board is an MSI B75MA-P45, which will run many current Intel chips. (Left) I selected the "Celeron" G1610 (2.6 GHz, 2 cores) to run with a "mere" 2 GB of RAM. Choosing the configuration was helped quite a bit by Ars Technica's "Bargain Box" System Guide. My logic was that any new system, even a "bargain" system, would be way better than what I had been using. And that has proven correct.
The hardware change went smoothly enough. The real work (no surprise) was building the new Ubuntu environment with needed development tools and Amateur Radio applications. It will be some weeks before we get all the way back to equilibrium.
Added: I ran the BOINC Whetstone and Dhrystone benchmarks on the G1610 and then on my "big" i7-920 machine. For 2 cores, the G1610 gives 2768 floating point and 16928 integer MIPS per core. For 2 cores (of 4), the i7-920 delivers 2869 floating and 16577 integer per core. So core for core, today's "budget" CPU is comparable to a premium chip of a few years ago. Such is Moore's Law. The '920 will run 8 independent execution threads across 4 cores, giving it 2-4 times more potential in terms of throughput. In practice, that throughput is only realized when I'm cranking 8 threads of BOINC apps, which is a nice thing to do, if your tastes run to extraterrestrial intelligence, pulsars, or gravity waves.
Purists will note that Whetstone and Dhrystone aren't great benchmarks, and I'd have to agree. All I will say is, they came easily to hand, and they're better than BogoMIPS.
Upgrading was straightforward. I could keep the power supply, case, DVD drive, etc. The board is an MSI B75MA-P45, which will run many current Intel chips. (Left) I selected the "Celeron" G1610 (2.6 GHz, 2 cores) to run with a "mere" 2 GB of RAM. Choosing the configuration was helped quite a bit by Ars Technica's "Bargain Box" System Guide. My logic was that any new system, even a "bargain" system, would be way better than what I had been using. And that has proven correct.
The hardware change went smoothly enough. The real work (no surprise) was building the new Ubuntu environment with needed development tools and Amateur Radio applications. It will be some weeks before we get all the way back to equilibrium.
Added: I ran the BOINC Whetstone and Dhrystone benchmarks on the G1610 and then on my "big" i7-920 machine. For 2 cores, the G1610 gives 2768 floating point and 16928 integer MIPS per core. For 2 cores (of 4), the i7-920 delivers 2869 floating and 16577 integer per core. So core for core, today's "budget" CPU is comparable to a premium chip of a few years ago. Such is Moore's Law. The '920 will run 8 independent execution threads across 4 cores, giving it 2-4 times more potential in terms of throughput. In practice, that throughput is only realized when I'm cranking 8 threads of BOINC apps, which is a nice thing to do, if your tastes run to extraterrestrial intelligence, pulsars, or gravity waves.
Purists will note that Whetstone and Dhrystone aren't great benchmarks, and I'd have to agree. All I will say is, they came easily to hand, and they're better than BogoMIPS.
Subscribe to:
Posts (Atom)