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).

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.

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.

Smartbooks have been delayed by Flash issues, says ARM:

This what you get when you have a product ecosystem dependent on a single proprietary piece.

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.

Calling all developers of amateur radio software …

Recently there has been discussion in several of the amateur radio development communities that I participate in about establishing standards for interoperability of amateur radio applications.

Discussion has been around protocols and data formats for amateur radio applications, to be used both on a local host and for interaction with web-based applications.

In the last week, the discussion gained enough momentum on the linux-ham mailing list that it was suggested that interested participants take the discussion to the arswd Yahoo group:

http://groups.yahoo.com/group/arswd/

The informally stated purpose is to create an open cross-platform specification that will allow interoperability of applications. This is not aimed at any particular operating system or distribution.

This is still in the stage of having people gather for further discussion, so it’s wide open for contribution.

it would be great to have participation by the principal developers of various amateur radio applications, no matter which O.S. your applications run on. No one knows better than you what would help you make your app work better. No matter what your area of knowledge - logging, sound card modems, satellite comms, contesting … there are probably unique aspects of those applications that should be accounted for in the spec.

I personally see this as a step toward some amazing amateur radio applications, suites, and web-based applications.

Steve AI4QR

Bobby Johnson writes a nice piece here about pressure for U.S. trade representatives to consider countries using open source technology as enemies of capitalism. Here’s a great quote:

“I know open source has a tendency to be linked to socialist ideals, but I also think it’s an example of the free market in action. When companies can’t compete with huge, crushing competitors, they route around it and find another way to reduce costs and compete. Most FOSS isn’t state-owned: it just takes price elasticity to its logical conclusion and uses free as a stick to beat its competitors with (would you ever accuse Google, which gives its main product away for free, of being anti-capitalist?).”

I agree. Open Source is free choice and open markets in action. The reason it’s getting this sort of policy level attention is that it breaks the game that the the big-dollar interests have been playing with the “free market” system.

Disclaimer: I earn a living working on free software, as do a lot of people I respect who work for companies that ostensibly compete with my employer (Canonical) and with each other. The majority of them work for companies who get paid by other companies to provide good and services, who then pay their employees to do the actual labor of producing those, and we in turn spend that money locally just the same as anyone working in any other field. That’s pretty traditional capitalism.

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.

I just noticed a couple of new Linux amateur radio projects. The first is a D-Star compatible repeater - More info Here and the project page is here . I see no mention of source code or a license for the repeater code, but it is apparently based on Centos. The second project is an APCO-25 decoder, and is clearly available under the GPL.