I’ve moved to a new website….

Just wanted to let you all know that I’ve moved to a new website that allows me to do things like post videos and share files. You can find it here: https://alaskalinuxuser3.ddns.net/ Once there you can subscribe via E-mail, RSS, or Telegram.

This website’s contents can all be found there as well, and you are welcome to continue browsing here, too. All new posts will be on the new website, though. See you there!

Linux – keep it simple.

Building Nile SODP Kernels

Recently I decided to do some personal kernel work on my discovery, aka Sony Xperia XA2 Ultra, which is part of the “nile” family of devices. I use the Sony Open Device Project trees and kernel, because regardless of what they think of me, I think they do exceptionally great work.

Unfortunately, the SODP build instructions for kernel building are just a little out of date, as Google has depreciated using GCC in favor of Clang. If you built your kernel for a nile device with clang, it will actually have issues with the camera, as you can read about in the issue tracker for SODP.

So, since I walked through it, I decided I would write down what I did in case anyone else needs a little help with this. I’m writing it in the same order the SODP instructions use, so it will be very clear when reviewing with the written instructions on their website.

Step 1: Unlock the boot loader per the SODP instructions.

Step 2: Download a cross compiler.

This is the part where things go awry. If you follow the instructions, you get the version of GCC tool-chain that Google removed half of it’s contents, causing it not to work, since they are depreciating it. You need to download this version: https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/+archive/606f80986096476912e04e5c2913685a8f2c3b65.tar.gz because it is the last version to have all of the tools in it.

Also, while you are only compiling a 64 bit kernel, if you don’t have the 32 bit tool-chain, you will have to trick the compiler when compiling stand alone (e.g., outside of Android source code). So, I recommend you also download this 32 bit tool-chain to keep GCC and the scripts from trying to use your system one: https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/+/refs/tags/android-cts-10.0_r6

Both of these should be extracted into their respective folder. In my case I made the 64 bit one called android, and the 32 bit one called android32. You can name the folder anything you want.

Step 3: Export the cross compiler.

Again, this would work, except that as stated, the scripts will call for a 32 bit tool-chain version, so if you follow the steps exactly, you will be left unable to build until you either edit the arch/arm64/Makefile on line 83, or declare one from the get-go. I recommend the latter.

$ export CROSS_COMPILE_ARM32=/mnt/719a5453-f8d5-4282-b4d9-f73a127316da/SonyXA2ultraKernel/android32/bin/arm-linux-androideabi-
$ export CROSS_COMPILE=/mnt/719a5453-f8d5-4282-b4d9-f73a127316da/SonyXA2ultraKernel/android/bin/aarch64-linux-android-

Make sure you use your folder names and locations.

Steps 4 through 10 can be done per the SODP instructions.

Overall, it’s only 2 small steps that need a little tweaking, but it’s very difficult to get through it if you don’t know what to do. Hopefully this will help the next guy, and I hope the SODP will keep up their great work!

Linux – keep it simple.

Fixing a TS-520 Band Select Switch

One of the major problems with the TS-520 I have was that the band select switch did not actually select a different band. This was problematic, of course, and turned out to be a rather interesting fix. As it turned out, there were two rods inside connected by brass inserts housed in a plastic shell. That plastic shell had broken, but, to God be the glory, I managed to fix it.

To do that, I fired up FreeCad and, after taking a few measurements of the real deal, I put a plastic sleeve together. It took me three tries to print it “just right”, for a really tight fit for the brass inserts. The first time was too short, the second time was too tight, and the third try was right on the money.

I exported it to an STL file and ran it through Slic3r for my Colido3D printer. This gave me the G-Code file, which I input into Cura, and out popped the cylinder. You can check out all three files in my MediaFire account, if you’d like. I thought I’d share since some one else may need that part also.

The final result was pretty tight, which is what I wanted. The brass inserts are knurled and I wanted the knurling to cut into the plastic on it’s way in. I had to lightly tap it in with a hammer at the end.

Now that it’s fixed, I look forward to spending a little more time with the 520 to see how well it works on other bands.

Linux – keep it simple.

Building an External VFO Cable


The gentleman who sold me the TS-820S was actually quite generous. For what little I paid for the transceiver compared to it’s online costs, I not only got the unit, but several microphones, and a matching external speaker and VFO, as well as all sorts of parts to build several cables.




I was a little confused on how the nine pin cable went together at first, but I managed to figure out that I was originally putting it together backwards! Once I turned it around the right way it was fairly straight forward to build.
Unfortunately, I left my fine tip soldering iron at work, so I had to use this big brute of a soldering iron to get the job done. That certainly made it a bit trickier, but I managed.


Once it was all hooked up, it seemed to work pretty well. I think I need to take apart and clean the VFO up, because as you turn the knob, it seems to have a few “dead spots”, but if you wiggle it a bit, it comes back. Maybe I just need to exercise it a bit, as it may not have been used for over 10 years for all I know.
But, to God be the glory, it is great to have the cable built and the unit working!

Linux – keep it simple.

Fixing An Old Microphone


When I bought the TS-820S, one of the extra things that he gave me was this microphone. It doesn’t have any label on it and any decals or writing have long since worn off. However, with a little web searching, it looks a lot like a Shure 522, but maybe a knock off, or a different Shure model number, since the microphone cover is different.


Either way, I had the simple task of replacing the plug, and doing some general cleaning. Looks like the previous owner was a heavy smoker.


In any event, replacing the plug went fairly quickly and a quick radio check showed it keyed well. The only problem was that I didn’t find anyone to talk to on the 10 meter band, so I don’t know how well it sounds. But, it looks like it is functional from an electrical standpoint. I’ll try using it on the next net meeting and see what feedback I can get from the others on the net.

Linux – keep it simple.

A new layout for more space.

Having a household of several children, it can at times be hard to find some space for my projects and equipment. As it was, I had a perfect spot in the laundry room with a whole desk to myself. However, the desk was a bit crowded with my TS-820S radio, my 3D printer, and my home server computer. With this equipment on the bench, I didn’t really have a space to work on anything new.

So, I decided to try to rearrange the laundry room a bit and build a shelf to help organize my stuff.

As you can see in the pictures, the before shot shows the laundry room as it was, with my desk. The after picture shows my new shelf and the shortened desk.

This has worked out incredibly well in the short time I’ve been using it since the switch. The entire contents of the desk are now on four shelves, and the shortened desk is completely empty and ready for me to work on equipment and projects! It’s not the most aesthetically pleasing shelf, but it is very sturdy and quite functional, and since it is hidden away in the laundry room, it is not in view of anyone who comes over. It also makes great use of what was once wasted and empty space.

Linux – keep it simple.

Piping audio into RSCW

In my spare time, I’m still playing around with RSCW, the Morse code decoder program. One of the hurdles that I’ve finally overcome (Praise God!) was how to send sound to the decoder. It turns out to be pretty simple, it just took me a few tries to get it right.

You see, by default, RSCW has several examples and options for sound input. Since it is an older program, it was written back when Linux kernel still used /dev/dsp and /dev/audio, back when everyone was using OSS and only a few had switched to ALSA sound. I don’t think PulseAudio was even a thing, yet…. It could also use input from programs such as sox, converting wave files to raw sound data, or use it’s own noise and CW generator.

Obviously, it would not be practical to record audio and then use sox to convert it and send it over to RSCW, nor would it be helpful to generate my own Morse code with the noise program, since I want to get live feeds from my HAM radio. I don’t want to downgrade my Linux kernel or OS to go back to the old method of sound card control, and to be honest, I’m not sure I really could without wiping my current setup.

Fortunately, there was a much simpler answer: arecord. Arecord is a “command-line sound recorder and player for ALSA soundcard driver”. In essence, it allows you to create recordings of anything being played or input into your sound system from the command line. The great thing is, as it has command line support, I can actually pipe it directly into RSCW rather than record the audio.

So, as a test, I jumped onto Morsecode.world’s translator page, which can generate Morse code from your input, and pasted information from the PulseAudio Wikipedia into the text field. This started playing Morse code over my speakers, to which I then used arecord to pipe to RSCW! Here was the output:

alaskalinuxuser@alaskalinuxuser-OptiPlex-790:/etc$ arecord | rscw -w 20 --track
RSCW 20 wpm mode track 1 - 3999 Hz ( rscw -h for help)
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono

The command is pretty basic:

arecord | rscw -w 20 --track

Of course there are more options that you could use, for both arecord or RSCW. Of interest is that you can use arecord to send just one specific input/output rather than everything or the default. You can list the available options with arecord -L:

alaskalinuxuser@alaskalinuxuser-OptiPlex-790:/etc$ arecord -L
Playback/recording through the PulseAudio sound server
Discard all samples (playback) or generate zero samples (capture)
PulseAudio Sound Server
HDA Intel PCH, ALC269VB Analog
Default Audio Device
HDA Intel PCH, ALC269VB Analog
Front speakers
HDA Intel PCH, ALC269VB Analog
Direct sample mixing device
HDA Intel PCH, ALC269VB Analog
Direct sample snooping device
HDA Intel PCH, ALC269VB Analog
Direct hardware device without any conversions
HDA Intel PCH, ALC269VB Analog
Hardware device with all software conversions

Now that I can accept input, now I just need to play around some more and see what I can do for speed settings for RSCW. It currently requires that you choose a speed, as it is not programmed to detect the speed of the signal. A Telegram user told me I should try “Fldigi”, so I’m going to take a look at that as well.

Linux – keep it simple.

Updating RSCW to work with GTK 2.0

As I get further and further down the rabbit hole of HAM radio, I started looking at Morse Code (CW) decoders. As it turns out, being just a licensed technician, I can only do limited voice communications on certain bands, all of which are above 10 meters (28 MHz). Below that, however, I can only use CW. Of course, I don’t happen to know Morse Code by heart.

While learning Morse Code is ultimately the goal, in the interim, I was hoping to find a way to “listen” to others and have a decoder to help me translate. There are a lot of great programs out there for this. However, there is a very limited number of Linux programs available. In fact, I could only find one: RSCW.

RSCW looks like a very nifty tool. But it was written a long time ago, back when GTK 1.2 was the normal method of building GUI’s on Linux. Now GTK is up to version 3.0. Unfortunately, the source code for RSCW just doesn’t build on any modern machine.

So, since it was licensed under the GPL 2.0, and all the source code was available, I took the liberty of editing it to work with GTK 2.0. Granted, we are up to GTK 3.0 now days, but that was too big of a leap in the programming. To modernize it to GTK 3.0 would just about require a complete re-write, and my programming skills are somewhat weak. But, it only took a few edits to update it to GTK 2.0, and 2.0 is still available in the Ubuntu repositories, so it worked out great on my home computer.

I did email the original author to let him know, but I haven’t heard back from him yet. However, if you want the GTK 2.0 version, you can get it on my Gitlab, and you can check the edits I made there as well.

Linux – keep it simple.

AboCom Systems Inc [WN2001 Prolink Wireless-N Nano Adapter]

I needed another WiFi adapter for a computer at work. I had several old USB WiFi adapters laying around, and I thought I should try to make use of them, rather than buying something else. This lead me to try out an “AboCom Systems Inc [WN2001 Prolink Wireless-N Nano Adapter]” that I had on my desk.

When I plugged it in, the Ubuntu 18.04 computer recognized what it was and tried to load it, but gave some nasty dmesg errors in the process. It also couldn’t see any networks in the office. Here’s the output of lsusb:

alaskalinuxuser@alaskalinuxuser-OptiPlex-7010:~$ lsusb
Bus 001 Device 006: ID 07b8:8188 AboCom Systems Inc AboCom Systems Inc [WN2001 Prolink Wireless-N Nano Adapter]

And here are the dmesg errors:

[1730947.161636] rtl8192cu: Failed to polling REG_APS_FSMCO[APFM_ONMAC] done! 
[1730947.161640] rtl8192cu: Failed to init power on! [1730947.161642] rtl8192cu: init mac failed!

After digging around for a while, someone suggested this online:

alaskalinuxuser@alaskalinuxuser-OptiPlex-7010:~$ echo options rtl8xxxu ht40_2g=1 dma_aggregation=1 | sudo tee /etc/modprobe.d/rtl8xxxu.conf

However, that didn’t help either. Finally, after searching around, I ended up finding that they got this information at pvaret’s Github, which also said to do this:

Make sure to blacklist the older rtl8192cu driver, which some distros seem to load by default otherwise.

So, I edited /etc/modprobe.d/blacklist.conf with nano and added these lines:

# Bad wifi driver
blacklist rtl8192cu

All that remained was to run:

root@alaskalinuxuser-OptiPlex-7010:/home/alaskalinuxuser# update-initramfs -u

And a quick reboot gave me a working USB WiFi! It was great of folks like pvaret to share their knowledge online so I could get this thing working!

Linux – keep it simple.

Building a Balun

After watching TRX Bench on Youtube, I learned how to make a balun. I am still a bit fuzzy on all the technical terms, but it is to convert an unbalanced load to a balanced one, hence BAL-anced to UN-balenced.

It is really neat to see all the different types, and to figure out what you would use them all for. To be honest, I haven’t got it all figured out yet. For now, I’m building baluns for specific antenna projects, where some other HAM has already charted the waters. In theory, then the antenna setup should work, it is only a matter of testing my home made balun.

For this project, I’m making a 1:1 balun, and two 4:1 baluns. The 1:1 is wound on a FT130 and the 4:1’s are wound over a FT140 toroid. Thus the slightly different sizes. I followed the Youtube video pretty closely, although I did use different wire, so I hope that they work well.

I also learned that I can double them, such as these two 4:1 baluns can be put together in series to make a 16:1 balun, or backwards to make a 1:1 balun. Either way, it’s fun to experiment and learn!

Linux – keep it simple.