New Thing! Video!

I’ve been playing with antenna modeling, and decided to make a video series introducing this to other people who may be interested.

I’m new to this, but I think it came out pretty well. I only misspoke a couple of times, but it will probably only be noticed by the technical pedants (I count myself among these).

The first episode covers the basic user interface and some basic concepts. I already have plans to make more episodes, possibly with these topics:

• Basic data input file format for xnec2c
• Antenna tuning, resonance
• Single band beam antennas, more elements for more directivity
• The dB (Decibel) – as a unit AND a referenced quantity
• SWR – what it is, why it matters, and when it doesn’t
• How antenna height affects gain and impedance
• How to model traps in xnec2c
• Near field analysis – why do you need it and what does it mean?

I need to figure out where to place show notes for these, as there are a lot of good information sources about these topics on the internet already, and I need to reference those in each episode. I’ll get smoother at all that.

For the first episode, here’s how you can fetch the example files:

git clone git@github.com:sconklin/Antenna-Modeling.git

Here’s a link to my show page on blip.tv

And here’s the embedded episode:

While it’s only a single study (disclaimer, blah blah blah), Here is some interesting data to consider for everyone involved in open source projects which have a community, or would like to. Especially for corporations for whom a community is an important part of your model, and community leaders for whom a corporation is a major driver of your project.

The study isn’t directly related to community, but you should be able to make your own connections.

I will point out one result in particular, which is that “[the results] suggest that workers perform most accurately when the task design credibly links payoffs to a worker’s ability to think about the answers that their peers are likely to provide.” When I read this, my first thought was of the Linux kernel process, in which contributions generally undergo public review on mailing lists. New contributors quickly learn to think about what mailing list participants will think about their contributions. We use the same process within the Ubuntu kernel team, with public review by peers. Many other projects do as well. So is the kernel development process the same scheme, with a feedback loop wrapped around it? (i.e. you actually DO get the feedback, you don’t just think about it).

This reward scheme, called “Bayesian Truth Serum”, produced more accurate results than schemes which awarded a bonus for accuracy!

I can think of a few really simple redux statements that might be made about how this applies to community projects, but (as this blog is subtitled) I think it’s more complicated than that. I’d rather just throw this much to community leaders and let them think about it.

Note that this was rescheduled due to me being busy with disaster recovery. We can talk about that, too if anyone is interested.

–

Please join us on Friday, May 6th at 14:00 UTC for:

Ubuntu and Amateur (Ham) Radio for Ubuntu Open Week

Steve Conklin AI4QR, and Kamal Mostafa KA6MAL

Curious about what you can do with Amateur Radio and Ubuntu?
Curious about Amateur Radio in general?

Steve and Kamal will take questions and do their best to answer them.

—-

Amateur Radio is a hobby and a public service enjoyed by at least a million people around the world. Whether you are interested in transmitting and receiving radio signals around the world to meet new people, in being of service after disasters, or in the technical aspects, there is probably something for you.

Amateur Radio covers a huge number of interests, including local and long distance communications, emergency communications, satellite communications, digital networks, competitions, and electronics design.

Ubuntu offers many software applications related to Amateur Radio. We’ll discuss some of our favorite apps for use in the “ham shack”, and show how you can receive and decode digital conversations and telemetry with Ubuntu and any shortwave radio receiver (no Amateur Radio license required!).

We will be holding an open Question and Answer session:

When: Friday May 6th at 14:00 UTC

Where: In the #ubuntu-classroom and #ubuntu-classroom-chat channels on freenode IRC.

For more information about IRC:

Here’s a web client for IRC:

You don’t have to wait until the session to learn more about Ubuntu and Amateur Radio and meet other interested people. Check out our team information page or drop into #ubuntu-hams on freenode IRC.

73, DE AI4QR

This post is really well written and should probably be required reading for network geeks.

I think it might explain some of the problems I was seeing before I dropped my DSL provider and moved to Knology cable, which I’ve been mostly happy with (Their DNS servers are slow, so I use dyndns).

A few weeks ago at a wedding reception I was making small talk, and was introduced as someone who “works for Canonical”. One of the people in the circle immediately said “OH!, you do Agile development! We’re training for that now!”.

I used to work at the company they now work for, although we never overlapped. I put in as many years there as I have anywhere else, and I can say with confidence that You’ve already lost. 

Continuing my exploration of SDR and the Softrock RX/TX Ensemble …

You can catch the beginning of those posts here.

The programmable oscillator on the softrock runs (in my case) at four times the desired mixer frequency. My unit is set to start up at 14.080 MHz, in the 20m band.

But - it would start up with the master oscillator running off frequency, which led to calibration being shifted by about 20 KHz on the band.

I’ve been using an application called usbsoftrock to access the firmware interface on the radio. Usbsoftrock is available packaged for Ubuntu as described here. I think that usbsoftrock is supposed to allow me to calibrate my radio so it will start on frequency every time. I grabbed the source for usbsoftrock, and read the README, and it looks like the proper steps are to run the calibrate command:

$ ./usbsoftrock -a calibrate
Version     : 15.12 fXTALL = 114.440115

Then as  I understand it, I can just set the crystal frequency in the radio eeprom like this:

$ ./usbsoftrock -a set xtall 114.440115
Version     : 15.12

This just resulted in the exact same behavior. Actually, when I ran the calibrate command, the frequency would change to being much closer to where it should be, but it was still a bit off. As soon as I would cycle power, it would return to the original value.

I decided to experiment with writing different crystal frequencies to the eeprom, and had the following results, measuring after cycling power:

Set xtall    |   Output
——————-|——————
 114.265     | 56.3253
 114.2745    | 56.3207
 114.275     | 56.3204
 114.2758    | 56.3200  <——-
 114.285     | 56.3155
 114.440     | 56.2390

Since I want it to start at 14.080 MHz, the correct value is four times that or 56.3200 MHz. Incidentally, I’ve been measuring at top hairpin lead of R13 using a frequency counter.

Having written the correct value, the radio starts up on frequency every time. It’s very close to being dead on, I can tell by listening to WWV on 10 MHz.

I’m not sure why the procedure I thought I should use with usbsoftrock didn’t work. I may investigate that more later. I’ve asked on the yahoo softrock group, and there’s a lot of expertise there. If I get an answer I’ll post an update here. Otherwise, at least here’s a trial and error method for you.

Once I got the radio into a case and out of the rats-nest of cabling that I was using for testing, and disconnected the counter, the signal quality improved drastically. Here’s a screenshot covering the 20m band from about 14.050 to 14.095 MHz. You can see some CW at the left, a bunch of psk31 traffic around 14.070, and rtty around 14.085. It was amazing to see the phone portion of the band, there’s some sort of contest going on this weekend.

The Ubuntu kernel team has prepared a new proposed kernel for Lucid (2.6.32-25.43), containing a large number of fixes. This is a larger number of updates than we would usually push at one time, but processing of the upstream stable updates was delayed by a couple of security updates.

This kernel should fix a lot of issues, including this one that people have been asking about a lot.

You will get this automatically if you have updates from lucid-proposed enabled. Note that if it breaks you get to keep all the pieces,  so don’t try this on production machines.

Please test against your favorite bugs in the changelog and provide feedback.

My previous two posts are about the Softrock RXTX Ensemble board, and getting it built. After I got mine built, I had trouble finding software applications to use it. Applications are out there, it’s just that I couldn’t find them. I’d be really happy to have something like Flexradio’s PowerSDR available for Linux. That application is great and it’s open source, but it’s Windows only.

(I’m definitely open to advice here, from the Linux SDR people who find this)

I’ve ended up being able to use an application called “quisk” as a receiver, but it required some customizations. My work was all done on Ubuntu Lucid 10.04.

This is not a solution you can just install and run, so be warned. You’ll have to twiddle with it, especially with respect to how your sound devices are configured.

Also, in order for this to work, you will have to have previously installed usbsoftrock as described in my last post, and it will have to be on your default path. This is because quisk starts usbsoftrock in the background to control the SDR board.

When I went looking at quisk, I found an older version on the yahoo softrock group which had been modded to work with the softrock, but it didn’t work for me. I ended up grabbing the latest version of quisk (3.4.8) and copying and modifying some files from the one that was on the yahoo group files area.

Grab quisk from the link above, then also grab this tarball containing two files.

Put the file named quisk_hardware_vk6jbl.py in the directory with the rest of the quisk source. Copy the file named ai4qrdot.quisk_conf.py to $HOME/.quisk_conf.py

At a minimum, you will probably need to edit .quisk_conf.py to set your audio input and output devices. Quisk will receive audio on both stereo channels of the input (actually higher in range than you can hear, up to half the sampling rate). On my system, this is set like this:

name_of_sound_capt = “hw:0”

There’s a script in the quisk directory named portaudio.py, which will print information about sound devices - this may help you find the one you want. You’ll also need the correct input selected in the Ubuntu sound mixer, have it set to mic level, and adjust the volume there. Once you get this right, you’ll be able to see some noise (and hopefully signals) on the quisk display.

In order to hear the selected (tuned) output, you’ll have to have the output device set also. Now for me I was unable to listen on the speakers, which are the same device number as the input I’m using. I would get a split second of sound and then silence. I changed the output to be a pair of USB headphones I use, and that worked. For me, the USB headset device was selected like this:

name_of_sound_play = “hw:2”

A few other things to be aware of - If everything appears sort of ‘mirrored’ around the center of the display, i.e. you tune up in frequency and the signals you see shift up (right) instead of down, then you have the I and Q channels reversed, and need to swap them in these lines in the config file:

channel_i = 0

channel_q = 1

I hope that’s enough information to help. As I was doing it I didn’t really have in mind to document it, only to get something working.

It looks like quisk is capable of transmitting, using AM, SSB, or CW, but as far as I can tell it won’t handle PSK-31 and doesn’t make the audio available for other applications like fldigi. I could be wrong, I haven’t gotten into it very deeply. This may be possible using “jack” but I don’t know.

I’ve also only just discovered sdr-shell, and that looks like it does exactly what I want, with DttSP. In fact, I see that Bob McGwier was one of the starters of DttSP, which invokes full recursion.

In my last post, I described how I ended up finally starting with SDR. I’m experimenting with the Softrock RXTX Ensemble. This kit is a transceiver with 1 Watt output, definitely QRP. It features a USB interface which allows setting the frequency and keying the radio for SSB and PSK31 transmissions. It also has a key jack for CW, and connectors for everything, so you don’t have to hang wires from the board for connections.

Here are some links related to the board:

• WB5RVZ’s Build notes and information
• Ordering page (Tony Parks KB9YIG)
• Yahoo Group for Softrocks

A word of warning - These kits sell out very fast, and apparently Tony is having trouble getting components. One of the effects of the global recession we’re in is that there are shortages of electronic components, so I’m not sure what the availability will be.

The kit has surface mount components, and requires winding transformers and inductors on small toroids. If you’re not comfortable with this then try to find someone to help you with these parts. Mounting Surface Mount Devices (SMDs) without any special tools other than a very fine-pointed soldering iron and a good head magnifier is not that hard, but it really helps to get some pointers and watch someone else do it. If your vision and motor skills are average or better, then you can do it, and it will be a rewarding project.

The kit can be built for a number of “super bands” as described here. The kit comes with all components for all options, which means that 1) you have to pay attention to the instructions while you build it, and 2) you will have parts left over.

I built mine for the 20m/30m/40m option. This is because I’ll be traveling with it, and having both 20m and 40m gives me bands which are open during day and night, respectively (at least as it stands now in the current solar cycle). I also like 30m, so this is a good set of bands for me.

I built it in exactly the order recommended in the build notes, but didn’t actually test it until it was finished. This isn’t recommended, as the various tests in the build notes are helpful in isolating problems before they get compounded. So this is a case of “do as I say, not as I do”, unless you are confident that you can troubleshoot your way out of problems of your own making. I did have one short caused by sloppy lead clipping, which didn’t cause any damage.

The thing that caused me the most troubleshooting time is that the audio signal coming out of the board is labeled “Line In”, and the signal into the board is labeled “Line Out”. Presumably this labeling is for what they should connect to on your computer sound card but I missed that, despite the fact that it is correctly marked on the schematic and block diagrams. 

An aside: The kit includes parts and instructions for a low-pass filter which must be used on the TX output “if transmitting on 30m”. Does anyone know why this would only apply to 30m? Are there stricter requirements for harmonic emissions on 30m? I’ve been meaning to look this up but while I’m writing this maybe I can crowd-source the answer.

One reason I skipped the build tests is that I hadn’t found a good application for Linux that would allow me to control the oscillator on the board using the USB port. There is a ton of information on the softrock yahoo group, in files and in the message archive, but the majority of what’s there relates to using windows applications. I did actually try to use a windows 7 machine to connect to the board, but after losing about 4 hours to erratic behavior caused by conflicts in USB drivers and the application, I gave up. It was a reminder of all the things that I don’t like about windows.

I’m an Ubuntu Linux user (and developer), so I decided to just figure out how to make this all work there, and document it. Everything documented here is for the Ubuntu Lucid 10.04 release.

The one thing you need early in the build is a way to control the oscillator on the board via the USB port. This lets to make sure that it works, and check the quadrature signals to the mixers. On the softrock yahoo group, I found an application named usbsoftrock, which does this. In writing this post, I’ve discovered that usbsoftrock has been packaged for Ubuntu and is available in a PPA by Jonathan, AF6YF (now N6JU). He has some notes here. I’ve not tried this, but hopefully it will work for you and save you the trouble of building it.

Usbsoftrock expects the softrock (USB) device to appear as /dev/softrock. In order to make this happen, you are going to have to add a udev rule. I found a rules file by G3VBV somewhere in my searching of the web. I’m sorry I can’t link to the original because I can’t find it, but I’ve put a copy here. copy that file to /etc/udev/rules.d/88-softrock.rules. You’ll have to be super-user. Make sure it’s owned by root and has permissions 644:

$ sudo chown root:root /etc/udev/rules.d/88-softrock.rules

$ sudo chmod 644 /etc/udev/rules.d/88-softrock.rules

Now restart udev to pick up the new rule:

$ sudo service udev restart

Now, read the 88-softrock.rules file and follow the instructions for adding a softrock group and adding your username to it. Now when you plug in the softrock board, the device /dev/softrock should be automatically created, and you should be able to access it.

Usbsoftrock has an interactive mode that lets you change the frequency through a curses text interface, which is helpful for testing. To invoke it use “usbsoftrock -a interactive”.

That should be enough software to get you through the build. 

Next, how I was able to actually receive signals using the softrock and Linux software.

I’m pretty easily distracted by shiny things. That’s one reason that things get stalled in my project queue. If an opportunity or project of interest comes along, I’ll indulge that and devote some time to it.

I’ve been interested in SDR (Software Defined Radio) for a while. I studied signal processing at university, and I once wrote a prototype FSK modem as a work project. I’ve been following developments, hanging around in the FlexRadio booth at hamfests, and thinking about getting involved “some day”, when I could get in at a reasonable cost (meaning under $100).

I’ve also been wishing for a small QRP (low power) tranceiver that I could use for CW and PSK-31 while traveling. I travel light, so it needs to be small. I have a KX-1 that works for CW, and that size is about right.

A few weeks ago I met Bob McGwier, N4HY on Facebook, because he noticed that we had some interesting mutual friends. Bob has done some really cool things, and is an expert on SDR, so I asked him whether he could recommend a small, cheap introductory SDR rig that was a transceiver. He was very helpful and recommended the Softrock RX/TX Ensemble, designed by Tony Parks, KB9YIG. Tony has brought low-cost SDR kits to a lot of people, enabling a lot of amateurs to get into SDR experimentation. There is a really excellent set of builder information for the kit by WB5RVZ, which helps make the kit accessible to more experimenters.

I dropped an email to Tony, and got an immediate response. So I was already having an amazing week, having connected with two rock stars of the SDR world. Tony told me he had an order in prep, and if I sent him payment via paypal, he’d have a kit for me. I did, and a few days later, the kit arrived.

Now, as of today, I already have the rig running as a receiver, but I’m stopping to document some of how I got here, especially since a lot of the documentation and software applications available are for Windows, and I used Linux.

I’m going to break this up into a few posts for readability. Next, some information about the Softrock RXTX Ensemble.

“At this point, since Ubuntu is beginning to look like a really viable alternative OS, the next big issue is whether it will support the ham radio applications that we want to run. Fortunately, the answer to this question is — yes it will.”

- - Ubuntu Linux for Hams

My Ubuntu Hams badge. Some nerd bling just in time for hamfest.

It’s been a great week for the Ubuntu-Hams team. We’ve had a lot of activity on IRC for weeks, but we finally set up some scheduled nets, and had the first of those this week.

Of the four nets on the schedule, we managed to have two - the 80m net ended up moving to 20m because it just wasn’t working for us on 80, and we had a nice round-robin net until the band closed on us. Today we had our first echolink net. There were only two of us, and it was a chance for me to hear the voice of 9W2PJU in Malaysia. Due to his location, power and band limitations, it’s not likely that he and I will be able to make an actual rf contact for a long time.

If you’re an amateur radio operator or want to be, and you are interested in Linux in the ham shack, check out the team page and join us on IRC.

The Ubuntu Hams team was started a year ago, and has seen a lot of membership growth since then. We just finished the first BOF session we’ve ever had at an Ubuntu Developer’s Summit, and it was a lot of fun. As soon as I can I’ll email a summary to the team mailing list. The discussion was wide-ranging, from enabling translation of amateur radio packages, to increasing the number of upstream maintainers that we engage with.

We decided to begin having monthly meetings on IRC for Ubuntu-hams, as well as starting to have some HF nets. If you’re interested in following this, join the team and subscribe to the mailing list. We’ll be having followup discussions there.

If you’re attending the Ubuntu Developer Summit in Brussels May 10-14, you’re welcome to participate in the openPGP keysigning party on Wednesday evening.

I love discovering new tools.

Lately my work on Ubuntu Linux kernels has had me paying closer attention to the Intel open source graphics drivers.

I’ve come across a few tools that are handy to developers and people with more advanced troubleshooting skills. One of those is intel_reg_dumper, which (not surprisingly) dumps the values of a whole bunch of internal registers from the graphics card. This comes as part of the xserver-xorg-video-intel-dbg package.

On Ubuntu you can install that with this rune:

sudo apt-get install xserver-xorg-video-intel-dbg

[UPDATE] this tool will be moving to the intel-gpu-tools package. Thanks to tormod on IRC for that info!

Note to self: See what other goodies are in that package

Why is this tool useful? I discovered the tool because I was following an email thread on a development list about high power consumption during suspend. By comparing register contents before and after the problem appeared, the troubleshooter was attempting to see whether there were associated register changes.

I can also see this being useful if you’re trying to debug problems with monitor capabilities - by examining the output you can tell a lot about the video timing that’s been selected - here’s an excerpt:

(II):             HTOTAL_B: 0x05a704ff (1280 active, 1448 total)
(II):             HBLANK_B: 0x05a704ff (1280 start, 1448 end)
(II):              HSYNC_B: 0x054f052f (1328 start, 1360 end)
(II):             VTOTAL_B: 0x0336031f (800 active, 823 total)
(II):             VBLANK_B: 0x0336031f (800 start, 823 end)
(II):              VSYNC_B: 0x03280322 (803 start, 809 end)

(there are over 200 registers dumped for my graphics card)

On November 6th I’ll be helping Dave Freese, W1HKJ make a presentation about fldigi to the Huntsville Amateur Radio Club. Fldigi is an amazing open-source cross platform application for communicating using sound card digital modes on amateur radio.

Dave is really knowledgeable about the encoding and error correction used for the various modes, and I learned a lot by helping him with a similar presentation at the Huntsville Hamfest this year. Our demo was cross-platform between Windows and Ubuntu Linux.

There are some really interesting uses being made of fldigi and some companion applications - sending digital files error-free by amateur radio. This is useful for emergency communications in post-disaster situations, when information must be accurately transmitted. Some of these applications do not use point-to-point connections, and therefore allow a file to be received by multiple stations at once. That way, if any station fails to receive the file correctly, they can get a “fill” from any other station who did get it.

It’s possible to perform these file transfers simply by holding the microphone on an FM radio near the computer speaker, and to receive them with a computer microphone near the receiver!

This should be a worthwhile presentation for people with any level of interest or experience in digital sound card modes. For more information see Dave’s excellent web site. Don’t miss his sights and sounds of digital modes page, especially if you’ve been listening to the sounds on the ham bands and wondering what modes they are.

The presentation will be November 6th at 7:30 at the American Red Cross chapter house, 1101 Washington street, Huntsville, AL. This is the regular weekly meeting place and time of the Huntsville Amateur Radio Club.

PPAs on Launchpad are an amazing way to get the latest crack builds, which is useful if you track or contribute to an upstream project, or test new code to see if it resolves a problem. That’s what I’ve been doing this week - I  installed the latest Xorg crack on top of a karmic beta install.

If you visit that last link, you’ll find a description of how to install and use a package called ppa-purge, which will revert the PPA settings and restore the packages to the distro versions. This makes it much easier to restore the system, or even to bounce between the distro and bleeding edge versions and see what changed.

Dave Freese, W1HKJ will be presenting a forum at the Huntsville Hamfest titled “Emergency Communications using HF Digital Modes”. Dave and a core group of contributors have been working for the last few years on a suite of open source applications for amateur radio. The fldigi application is the flagship of these.

Fldigi is a digital modem application which generates and decodes a number of digital modes using the sound hardware in your computer. Amateur radio using digital modes has been growing in popularity, and with good reason. These modes offer a variety of tradeoffs between rf bandwidth, data bitrate, error correction, and noise immunity.

These modes are all sent and received using audio frequencies that fall in the normal voice range used in amateur radio, about 300-3000 Hz. Some modes use very little bandwith, as low as 31Hz, allowing many contacts to take place within a frequency range that would be occupied by one voice contact. These modes are most commonly used with a text interface that resembles internet chat, but are also suitable for inclusion in a higher layer of protocol which allows further error correction, block sending, and retries. When used with a ‘stack’ like this, it is possible to send binary files over amateur radio error-free. This is useful for emergency communications. An example is to be able to send a spreadsheet listing items needed at a shelter, instead of reading and copying every line in the document by voice. The low speeds of these modes limit the usefulness to relatively small files, but a lot of information can be passed in small text files.

Fldigi runs on Linux, Free BSD, Windows XP, W2K, Vista, and OS X. At the hamfest, Dave will be demonstrating using windows and a Linux platform, and I will be helping him demo with my Ubuntu system.

The forum is at the Huntsville Hamfest from 14:00-16:00 on Saturday August 15th, in Salon 10. For more information about these apps, see Dave’s site

I’ll be presenting a session at Atlanta Linux Fest titled “Debugging the Kernel”. This presentation originated with Colin King, another member of the Ubuntu kernel team. Colin’s blog has a wealth of debugging information.

The presentation is an overview of various methods used, as applied to increasing difficulty. What can you do when you have no video, no console, no serial ports, and no network? Come find out.