delara news Delaware Amateur Radio Association, Delaware OH   VOL 36 NUMBER 8

Technical Coordinator

Jeff Kopcak, K8jtk Technical Coordinator Have you recently built something? Came up with a solution to a problem in the shack? Achieved a milestone? Now, ask your club newsletter editor if they are looking for content from club members. I’ll bet they say “yes!” Hams are interested in good articles written by club members sharing their experiences with projects and adventures. You’ll be surprised to find out how many other people are interested in the same thing or how it will motivate others to experiment with something similar. Believe me, it happens. One of the reasons you see me here in the OSJ is because of articles Ken - KG8DN asked me to write for the LEARA newsletter a few years ago. If you don’t write articles as part of a job or for fun, the last time many of us wrote anything was probably in school. Those writing technique brain cells were fried long ago. I will cover techniques, ideas, and some lessons learned to assist you in putting together a fantastic article for the club’s newsletter. First and most important, meet with the newsletter editor or shoot them an email letting them know the topic you want to write about and get an idea of their requirements. Requirements such as: how much space will I have, will there be room for pictures and diagrams, when is the deadline to have everything turned in. Page requirements will help you focus the article emphasizing certain topics and provide detail versus insignificant points that don’t fit with the rest of the story. The editor may have some general questions to help jump-start the process. This works too as stories wrote themselves with a question or three. Note these questions and refer back to them if you have writer's block. If the topic isn’t exactly ham related or different than the usual type of articles found in the newsletter (ie: more public service than technical), ask about that too or write it with a technical focus. With the editors’ requirements in mind, make an outline (bullet point list) of general topics to cover. What do you see as the major milestones of the project? Maybe something like: design considerations, building, and operating. Once the main points are established, include a few detail points. For a build project, this might look something like: Design o Power source (AC, DC, USB, car, battery) o Inputs (radio audio, computer audio) o Outputs (radio audio, computer audio, line monitor) o Connections (speakers, headphones, USB) o Indicators (LED: power, audio level, PTT) o … Build o Placement of components (circuit board, level adjustments mounted on the side) o Connectors (USB, serial, audio) o Sizes (hidden switch, large lighted switch, large LEDs) o … o Housing (Altoids tin, wooden box, oil pan, baking tray, hobby store find) o Mounting (wall, portable, back of radio) Operation o Testing (digital net, friend over the radio) o Tweaking (changed component values) o Adjustments (audio level knobs in front, manual pot inside) o … o Anticipated results (clean audio on PSK) o Actual results (splattered across the entire band – only kidding) After the general outline is assembled, it’s time to start thinking about the details. People have different writing styles. Some plan the entire article top to bottom and write as such. Others start with the detail points and form a story around it. Some just write their stream-of-consciousness then add or delete details in revisions. Whatever your style, introductory paragraph should have generalizations about the topic giving the reader something they can relate to: “have you ever heard…,” “did you ever wonder about…,” “I first learned about…,” “while I was doing X, I heard about Y,” “when I first got my license I was thinking what about doing Z.” The first paragraph or two should illustrate the topic in “broad brush strokes.” No specific details about the topic, yet. Quaky antidotes are always good. The last sentence should setup the specific topics covered in the article. This is referred to as the thesis. The thesis can outline specific topics:  “I’m going to talk about experiences designing, building, and operating my new widget.” Or general: “here’s how I got this project off-the-ground” with specific topics detailed in the article. Either way, the main bullet points created earlier should form the thesis and drive the main topics covered in the article. After topics are established for the reader, start by first talking about the problem you were trying to solve. Talk about things like: “I wanted to add JT65 capability to my QRP rig,” “I’ve used available interfaces before and wanted mine to do A and B because C,” “I wanted to learn Linux so I used a Raspberry Pi to make a portable NBEMS station,” “I wanted to learn Python and now the club’s station can be operated remotely.” Fill in the details about how you went from a problem to a working solution using the detail bullet points outlined earlier as a guide. Was the solution similar to another design found online or did you create one from scratch? Why did this solution work for you? What value did it add for you? What lessons did you learn about your chosen path? What problems did you incur and how did you solve them? Describe to the reader the functions of different pieces or purposes of the different stages. Example: “this stage takes the audio from the radio and amplifies the level for the computer,” “this takes the computer audio and drops the level for the radio.” When in doubt, answer the 5Ws: who, what, when, where, why.  It’s incredibly easy to get wrapped up or focused on the details. Remember your reader probably doesn’t have the same level of experience and is only mildly interested in your project.  Bombard them with minute details and their head will explode. Give them some table scraps, they’ll find something interesting and keep reading. Don’t rattle off specifications like: ‘I choose the ARM v5 blah blah processor because flux capacitor blahs blahs +1,000,000,000V than the equivalent direct-conversion Arduino ATmega2560 16 MHz blah blah PWM at 4097 bit encryption…’ No one cares. Concise descriptions in (mostly) plan English are always better: “I wanted an audio path between the radio and computer that keyed the transmitter from the software. It must be isolated to prevent buzzing and hum noises from potential ground loops.” Most hams know what those terms mean. If some technical detail is paramount to the story, relate it to something most non- technical hams would understand: “the Raspberry Pi hard drive is an SD card, which is the same type of storage used in nearly all cell phones and digital cameras.” If space allows, note any other solutions researched and discuss reasons those alternative methods where abandoned. Take a position then argue with yourself: here’s my idea, here were other possible solutions and why I didn’t accept them or why they didn’t work. An absence of supporting facts shows a lack of critical thinking and understanding of the subject. The closer the audience is to a subject, more convincing and disproving other theories will be required. Use of snarky comments shows arrogance, so leave them out. Finally, wrap it up. Include anecdotes, accomplishments, funny stores, or final comments about the project. Were you happy with the results? What do you use the device for? Did you find other or different uses for the project than you envisioned? Pheew! Now I’m done right? Well, far from it. The article is written, now revise, revise, and revise. Re-read your work to make spelling, grammar, and context corrections all while making sure it flows well together – does anything I wrote make sense? The free LibreOffice Writer is great but Microsoft Word has a phenomenally better grammar checker. For me, it works best to print the entire article, read it, make revisions on paper as I go along, enter them into the computer, print it out again, make more revisions, put it down for a few days – repeating this process about 5 or 6 times. Printing takes me away from the computer allowing me to focus on the article. I picked up this habit in grad school when I got a C on a paper. I knew if I spent more time revising, my grade could have been better. Whether I’m not in the right mindset, got a lot going on, stressed, or not committed, my revision regiment eventually produces something I’m proud of. If you’re not good with revising, ask a buddy or spouse to help you out. The newsletter editor is there to give you some direction. Don’t expect them to do all the work. They have enough to do. Unlike news or publishing organizations that have paid staff to scrutinize the article, the editor probably has little experience or standing with your topic. If they offer to proof read and make suggestions or comments, utilize it. Don’t expect them to validate every detail, statement, correct every spelling mistake or grammar error. Don’t take offense to their feedback either. They’re trying to help by providing constructive criticism while making the newsletter appealing to readers. Don’t send them a bunch of pictures without relating them to the work. It will be embarrassing when they put the wrong picture in the wrong section because ya’ didn’t make it clear! For images, designs, or facts found elsewhere, give credit to the source of that information. You wouldn’t like it if someone stole your design and claimed it as theirs. In school, they made this big deal about using specific style guides for a bibliography. I haven’t used any of that stuff. I’ll make a note, usually with a website or URL, in line with the text or put a section at the end giving credit for their hard work. Personally, I love to see pictures of the device in operation, installed, or the person working on it. Leave out anything more than basic diagrams and schematics. Details in those images will be lost when sized for the copy. Detailed images, documents, diagrams, and videos can be uploaded to a website, if available, or use a free online storage service like Google Drive or Dropbox. Both have provisions to create a shared directory that others can only view (that is important!). Link to that folder or specific file at the end of the article: “for more pictures, a more detailed writeup, or schematics, go to this URL.” Videos are good if they’re kept to about 2-4 minutes in length showing the person using their project and talking a little about it. These can be uploaded to YouTube for exposure or to the online storage folder. Longer detailed videos or build videos should be separate. If the viewer wants to learn more, they can check-out the longer versions. While the examples provided here were geared toward a build project, this outline can be used for sharing knowledge on a software defined radio dongle you picked up, a new digital mode you learned, operating adventure, or new toy many have yet to see. If you’re still looking for more methodology ideas, grab any issue of QST and follow the format of a similar article to yours. With a little work, you can become a published author and help your club out in the process! Thanks for reading and . . .
© DELARA News, the official monthly newsletter of the Delaware Amateur Radio Association, Delaware, OH