Month: March 2016

A Very Simple CW Key and Keyer

russell Leave a comment

So I finally got around to building a very simple CW practice setup. Initially, after a little window shopping for keys and keyers, and being frustrated with the prices I saw, I thought there had to be something cheaper. I became determined to wade through the sometimes confusion terminology, figure out what exactly I needed and make it. What I found was that making a paddle or key is so simple it’s almost disappointing, but it turned out to be super exciting nonetheless. I found “plans” for what the maker was calling The Hackey, which is a simple 3-wire iambic key that uses an old hacksaw blade for the dit and dah switches. Pretty brilliant, simple and cheap. So I started collecting parts as I’d find them. I finally got the parts for the paddle together… now what? For a paddle or iambic key to work, you have to have a keyer. This is a point that I had some trouble with initially.

The key and keyer are separate devices. A key can refer to a straight key, paddle or iambic key. With a straight key, the user controls the dit and dah length, letter spacing, word spacing, everything. This can be very difficult for a beginner to learn to send clear code especially at a reasonable speed. For a paddle or iambic key to work, you need an electronic keyer and generates the dit and dah tones automatically for you. This is not to say that it will generate code for you. It just generates the dits and dahs at the correct length and spacing. A keyer for a paddle will just generate a dit or dah repeatedly, with the correct spacing, while you hold that the paddle to that side. A paddle key is such that the paddle is ground and the two contacts are dit or dah. A paddles and greatly increase the speed and accuracy of your code. An iambic keyer has two “paddles” with a center contact, such that the center is ground and the each paddles is dit or dah. The iambic key will generate a dit with one side or dah or alternating dits and dahs of the paddles are squeezed to the center contact. This method can be used to send fast code with minimal physical input.

Much of this is probably over-simplified. I’ll expand on this post as I learn more about keys and keyers.

Starting CW

russell Leave a comment

As the stated purpose of my blog is low-cost/homebrew, I’ve found that a lot of simple and cheap projects are expressly for CW. Voice is a lot more complex for homebrew. So, I’ve had growing interest in learning morse code, but I haven’t found a good training program for Linux. Aldo seg faults. GtkMMorse seems like it may be good, but I didn’t feel like it was as clear as it could be. I was reading the article A Dialogue with a Reader from KB6NU’s Ham Radio Blog and his reader mentioned LCWO.net as his resource for learning CW. This was the aha! moment that I needed.

LCWO.net a very configurable web app that allows you to adjust not only the keying speed, but also the spacing. This is very helpful for a beginner. It can be difficult to here the separation between characters at first, and, at least with me, there is a delay in my recall of the letter. This pause compensates for that delay so I don’t miss letters and start to freak out and miss more letters.

On my Android devices, I use an app call Morse Mentor. It is free and a lot of the same features as LCWO, but I can use it on the go with or without Internet access.

 

Progress on Several Projects

russell Leave a comment

As with everything in my life so far, I have trouble focusing on a single project. Radio should be no different. I’m currently trying to get my 2m mobile Yaesu back on the air, build a practice CW setup and figure out SDR on my DVB-T dongle.

The Yaesu just needs an antenna outside. I recently moved into a metal building that acts as an excellent RF shield. That means I have to get and antenna outside to get on the air really at all. As usual, I don’t have much money, so I turn to the Internet and making stuff out of found or cheap materials. I mostly completed my 5/8 wave 2m whip antenna tonight, but I haven’t had the chance to test it. And I haven’t really solved how I’m going to mount it on the roof. Hopefully I can test it soon and it will just work. The “coathanger” antenna I built before worked perfectly, so I’m hoping for the same luck with this one.

The paddles for the CW practice rig are almost built. I’ve finally gathered the parts I need, now I just need to assemble it. Then I get to build the practice keyer. I’m not sure how I really want to do this one. There are several plans for IC based oscillators/keyers that I’ve seen, but I’m leaning toward Arduino for several reasons. I think there are probably already some plans out there for Arduino, so that’s a good place to start. If not, it would be a good exercise for me to better understand the Arduino. It also seems like the Arduino keyer would be pretty easy to modify and improve. Plus I’m dying to make something useful out of the Adruino kit that I recently got. I know I’m pretty late to the party on that one, but at least I’m finally getting started. Better late than never, right?

And finally the SDR. I’m still in the very early screwing around stage. I know less about SDR than I do radio, and that’s really saying something. I did however pick up a faint transmission/conversation somewhere in the 2m band. Pretty amazing for using the crappy little 4″ antenna that came with the dongle and being inside of a big metal box. That seems like it will be a fun little thing to mess with on my little Acer laptop. The app GQRX-SDR was the ticket here. The latest version just detected my dongle and started working. I was tuning around in minutes. It’s built on the GnuRadio framework, but you don’t have to know much about SDR programming to start using it. I was even able to pick up several of the local FM radio stations. Pretty cool.

Anyway, time for bed. I’ve got Easter with the family tomorrow.

trial and error

russell Leave a comment

It’s not trial and error, it’s trial and observation. Error implies a failure, but the only failure is when truly nothing is gained. An error, in this way, is when the unexpected happens as a result of the trial, but nothing is learned. If nothing was learned, the trial would never change. Or if it did, the change would be random, directionless. Observation, however, of an unexpected result, is learning. It affords educated change. It provides the direction necessary for further learning, discovery and development. Observation precedes evolution.

I guess I’m learning Python

russell Leave a comment

I just wrote the first script I’ve written in years and it works beautifully. It’s very dirty, and I’m sure I’ll rewrite it to be more robust, but for now it gets the job done. The job, so to speak, is relatively simple. Take a large single audiobook file and break it up into smaller, regular tracks. Using python, ffprobe, ffmpeg and very liberal use of google, I got it done in just few hours total time. But this is starting pretty much from scratch. I couldn’t remember how to start a python script. It’s amazing what one is able to remember when the need arises. I seemingly intuitively knew to use str() and float() to correct a concat error? That one surprised me. Anyway, here it is in all it’s glory.


#!/usr/bin/python

## this is a very quick and dirty file splitter
## i think this only works for non-chapter .m4b
## quicksplit.py author title filename

import sys
import subprocess
import os

author = sys.argv[1]
title = sys.argv[2]
filename = sys.argv[3]

start = 0
end = 0
track = 1
segment = 1800 # time in seconds

probe_command = "ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 '" + filename + "'"

print("Audiobook " + title + " written by " + author)

## get the total duration of the file and convert to float
duration = float(subprocess.check_output(probe_command, shell=True))

while start < duration : end = start + segment ## get a new endpoint by adding the segment length if end > duration : ## check of we've iterated past the actual duration
end = duration
print("Break from " + str(start) + " to " + str(end) + " until " + str(duration))
split_command = "ffmpeg -i '" + filename + "' -ss " + str(start) + " -to " + str(end) + " -acodec copy '" + author + " - " + title + " - " + str(track) + ".mp4' #print(split_command)
subprocess.call(split_command, shell=True)
start = end ## iterate start to where we left off
track = track + 1