N1MM Logger appears to be the logging program of choice for amateur radio contests. A lot of hams use it as a contesting log because of it’s many contesting features but after the contest is completed will export the data to another general logger that they use to log all of their contacts.

N1MM allows you to automate a lot of the steps when contesting. For example, when using Morse code, you can load a configuration for a state QSO party, and just press function keys to perform the contesting exchange instead of using a Morse key and doing it manually. While this may seem like cheating to some, contesters like it because of the quick turnaround of contacts, beginners like it because they are prone to making sending mistakes and other like it because it’s just easier than sending code manually. For the automatic features to work, the program needs to be able to communicate with your radio. The rest of this article will tell you how to do that.

Note that I’m using a Yaesu FTDX101D radio during this procedure but any Yaesu radio should have a similar setup and other non-Yaesu radios will probably work pretty much the same with some minor tweaks to the process.

Here’s how to do it…

• Launch N1MM Logger and select ‘Config’ > ‘Config Ports, Mode Control, Winkey, etc…’ then select the ‘Hardware’ tab.

• At the top of the dialog you will see three radio boxes, these are used to select the type of hardware configuration you are using.
  • ‘SO1V’ is the simplest. It used when your radio has just one VFO that you will be using for both transmitting and receiving.
  • ‘SO2V’ is used when your radio has two VFOs. Selecting this will configure the program to work with both and will display two separate dialogs during normal operation with each one allowing you to control a separate VFO. For example, one dialog/VFO could be used to work the 20M band, while the second could be used to work the 40M band.
  • ‘S02R’ is similar to ‘SO2V’ except instead of controlling to VFOs on the same radio, you are controlling to separate radios.
• To keep things simple, even though the FTDX101D contains 2 VFOs, I’m only using one and thus will select ‘SO1V’.

• Next, we’ll set up CAT control for N1MM. This allows the software to control the radio and do things like change and read frequencies, modes and bands. It also enables the software to read and set many of the parameters used by the radio. On Yaesu radios, CAT control is accomplished using the Enhanced COM port and on my computer it is mapped to COM4, so on the first line we set ‘Port’ to ‘COM4’ and ‘Radio’ to ‘FTDX101D’. The ‘Radio’ field is used by the program so that it understands what messages to use during communications and what features are supported.

• Now press the ‘Set’ button and set the following values:
  • ‘Speed’ to ‘38400’
  • ‘Parity’ to ‘N’
  • ‘Databits’ to ‘8’
  • ‘Stop Bits’ to ‘2’
  • ‘DTR’ to ‘Always Off’
  • ‘RTS’ to ‘Always Off’
  • ‘Radio Nr’ to ‘1’
• Select ‘OK’ to save the changes. We use these values because they match the values we used when we configured the radio and the drivers in the previous article. They describe the speed and rules that the radio, computer an N1MM use to talk to each other. You can use different values if you like but just make sure they are consistent between all three devices.
• In this step, we set up keying for N1MM. This allows the software to key the radio instead of you having to push a button or press a Morse key. On Yaesu radios, this is done using the Standard COM port. On the second line of the dialog, select the port that’s mapped to your standard COM port, for me it’s ‘COM3’, leave the ‘Radio’ set to ‘None’, and check the ‘CW/Other’ check box.

• Press the ‘Set’ button and set the following:
  • ‘DTR’ to ‘CW’
  • ‘RTS’ to ‘PTT’
• Select ‘OK’ to save the changes and ‘OK’ a second time to close the ‘Configurer’ dialog. This setup is simpler than the one for the Advanced COM port because there’s no data transfer involved, Yaesu keys the radio based only on the state of the DTR pin or the RTS pin. So essentially, only a single line is used on this port.
• Finally, verify that CAT control works by tuning your receiver and seeing if the N1MM frequency display in the title bar of your dialog updates. As a second check, click on one of the bands in N1MM and see if it changes the band on your radio. If these tests fail something is wrong with your enhanced com port settings you will need to troubleshoot it. You can check to make sure that keying is taking place by connecting your radio to a dummy load, turning down the power and pressing one of the function keys used during an exchange. If everything is working your radio should start transmitting and you will hear keying taking place.

This document is an attempt to explain the connections that are needed to interface a computer with the Yaesu FTDX101D, what each of those connections does and what you need to do to get your computer talking to your rig. While it’s written for the FTDX101D, I suspect the same information will apply to any modern Yaesu transceiver and with some minor changes could also be used to set up non-Yaesu rigs.

Connecting your computer to your transceiver allows you to do all sorts of interesting things. You can control your rig from your computer, automate the logging process, run software that allows you to communicate with others using the various digital modes and many other things.

While researching the connection process, I came across a lot of good information, some bad information and found that although many people were able to connect the two devices, a lot of them didn’t really understand what was going on when they did it. I hope to clear that up here.

There are four different connections that need to take place when you connect to your radio with each one serving a particular purpose.

The first is for CAT (Computer Aided Transceiver) control. This allows the computer to send commands to the radio and receive back responses enabling you to do things like change your rigs frequency and mode and read back parameters like SWR and power, etc.

The second connection is for keying the rig. You want your computer to be able to tell your transceiver when to transmit and when to stop transmitting so it can automatically send and receive data.

The next connection is for sending audio to your rig. This is required to modulate the carrier for digital modes or for sending prerecorded audio.

The final connection is used to receive audio from your rig. Doing this allows software on your computer to ‘listen’ to the rig, giving it the ability to do things like decode Morse code or interpret digital mode messages.

In the old days, interfacing with a radio was complex and required two different cables. CAT control took place through an RS-232 cable while RTTY/Data, audio input and output and transmitter keying were done using a special 6-pin Mini-DIN data/packet connector cable. In modern setups, both of these cables have been replaced with a single USB cable which greatly simplifies the connection process. Unfortunately, the connection process is a bit confusing because the industry has implemented the USB interface in a way that emulates the old two cable method making it more complex than it really needs to be.

On Yaesu radios, you install a set of drivers that connect to the computer hardware and present an interface through which your programs (WSJT-X, JS8Call, fldigi, Ham Radio Deluxe, etc) can talk to the radio. The driver installation creates two virtual COM ports (Enhanced COM Port, Standard COM Port) and two audio devices (Line USB Audio CODEC), (Speakers USB Audio CODEC).

Enhanced COM Port is used for CAT control. It sends commands to the rig and receives back responses allowing the computer control the radio and read the various settings and parameters. This acts as the equivalent of the RS-232 cable.

Standard COM Port is used strictly for keying the transmitter. This takes the place of the 6-pin Mini-DIN connector cable. One of the things that’s interesting with this connection is that only the DTR or RTS line is used for keying the rig, so it really doesn’t matter what setting you use for baud rate, parity, etc. (Even though it doesn’t matter, later in the procedure I use the same settings that I use for the enhanced port, just to make them consistent).

Line USB Audio CODEC sends audio information from your computer to your radio allowing it to modulate the carrier and transmit information. This connection used to be part of the 6-pin Mini-DIN connector cable.

Speakers USB Audio CODEC receives audio from your radio allowing it to decode the audio and present it as Morse code or digital mode data.

Installing and Configuring the Drivers

• Go to the Yaesu website and navigate to the FTDX101D page. Select ‘Files’ and click on the ‘FTDX101MP/D USB Driver Virtual COM Port Driver (Windows 11/10)’ link towards the bottom of the page. This should download the file ‘CP210x_Universal_Windows_Driver.zip’ to you computer.
• Right-click on the file, select ‘Extract All…’ and press the ‘Extract’ button.
• After the files have been extracted, right-click on the ‘silabser.inf’ file, select ‘Install’ and then press the ‘Open’ button and follow the prompts to install the driver.
• Open Windows Device Manager, click on ‘Ports (COM & LPT)’ and verify that you have two ‘Silicon Labs Dual CP2105 USB entries’. While doing this, take note of the COM port numbers used for each device since you will need this information later in the process. On my system ‘COM4’ was used for ‘Enhanced’ and ‘COM3’ for ‘Standard’ but your values may be different.

• Double-click on the ‘Enhanced’ port entry, navigate to ‘Port Settings’ and verify the settings are as follows, changing the values if needed. If you look around the Internet you may see many different values set for these parameters. This is because the values you use aren’t critical as long as both the radio and computer use the same values. It’s like talking to someone in French, if both of you are using speaking French, everything is fine but if one of you is speaking French while the other is speaking German, nothing good will come of it.
  • ‘Bits per second:’ ‘38400’
  • ‘Data bits:’ ‘8’
  • ‘Parity:’ ‘None’
  • ‘Stop bits:’ ‘2’
  • ‘Flow control:’ ‘None’

• Double-click on the ‘Standard’ port entry, navigate to ‘Port Settings’ and enter the same values you used for the ‘Enhanced’ port.
• You can now delete the CP210x zip file and folder since they’re no longer needed.

Configuring the Yaesu FTDX101D

• On the FTDX101D, press the ‘FUNC’ button, then select ‘Operation Setting’>’General’.
• Set the following parameters:
  • ‘CAT RATE’: ‘38400bps’
  • ‘CAT TIME OUT TIMER’: ‘100msec’
  • CAT RTS’: ‘OFF’

• Press the ‘BACK’ button to back out of the current screen and the select ‘CW SETTING’ > ‘MODE CW’. Find ‘PC KEYING’ and set it to ‘DTR’.

• And you’re done. These settings should allow your radio to work with any program you install as long as the program configuration matches the values you’ve used here. I’ll soon be posting setup information for other programs like WSJT-X, N1MM Logger and N3FJP Logger which will show you how it’s done.

One of the examples that they use to show how designs can evolve and be improved upon over time is an application that is used to track musical instruments inventory. The initial design of the app is poor in that it lacks maintainability and requires modification of existing classes (one of the no-no’s of SOLID design principles) and the addition of many new classes any time you want to add a new instrument type to the application. In chapter 5 of the book, they improve the design considerably by replacing unique classes for each instrument with a single class, InstrumentSpec that maintains a list of properties for the instrument that it represents. Not only does this eliminate the need for the creation of a new instrument class, it also allows you to dynamically add new properties to each class instead of having them hardwired into the class.

While I agree with them about the software being greatly improved, I still feel there’s one glaring problem with it. When a new property is added to the InstrumentSpec class it uses a key/value pair to store the property. For the key, they’ve chosen to use the string type. While this gives you a lot of flexibility, I feel it’s pretty much a disaster waiting to happen. Not only does the user of InstrumentSpec has to be relied upon to make sure the string is a valid value and is spelled correctly, if a mistake is made it won’t be found at compile time but instead will manifest itself at runtime. The last thing you want happening is your software to fail in the field instead of failing when you’re designing it. Granted a lot of this can be avoided by the use of appropriate test cases but that still takes a leap of faith that the error will be caught.

A better way to handle this is to replace the string key with an enumeration key. This prevents the user from ever using an invalid key and also prevents the code from compiling if an incorrect key is used. The only downside to this approach is that you have to modify the PropertyKey enumeration any time you add a new property to the software. To me this seems a minor tradeoff that goes a long way towards creating more robust software.

The following example shows the use of property keys instead of strings.

InstrumentSpec.cs

using System;
using System.Collections.Generic;

namespace CH3_Guitar_Application
{
    internal class InstrumentSpec
    {
        private Dictionary<PropertyKeys, object> _properties;

        public InstrumentSpec(Dictionary<PropertyKeys, object> properties)
        {
            if (properties == null)
                _properties = new Dictionary<PropertyKeys, object>();
            else
                _properties = new Dictionary<PropertyKeys, object>(properties);
        }

        public object GetProperty(PropertyKeys propertyName)
        {
            return _properties[propertyName];
        }

        public Dictionary<PropertyKeys, object> GetProperties()
        {
            return _properties;
        }

        public Boolean Matches(InstrumentSpec otherSpec)
        {
            foreach (var property in otherSpec.GetProperties())
            {
                if (!_properties.TryGetValue(property.Key, out var value))
                    return false;

                if (property.Value != value)
                    return false;
            }

            return true;
        }
    }
}

PropertyKeys.cs

namespace CH3_Guitar_Application
{
    internal enum PropertyKeys
    {
        INSTRUMENT_TYPE,
        BUILDER,
        MODEL,
        INSTRUMENT_STYLE,
        NUM_STRINGS,
        TOP_WOOD,
        BACK_WOOD
    }
}

A second problem that I ran into was because of my choice of rewriting the examples in C# instead of doing them in Java like the book does.

The original application prints out a human readable string based on the value of an enumeration. This string is different than the actual name of the enumeration and is not a problem in Java. Unfortunately, in C# the enum type is limited and if you attempt to use the ToString() method to print out the enum, it will display the actual enum text instead of something that is tailored for readability.

To fix this problem, I replaced the enum type with the Enumeration class written by Jimmy Bogard. https://lostechies.com/jimmybogard/2008/08/12/enumeration-classes/ Not only does this class allow you to associate a human readable string with an enumeration, it also allows you to add methods to the enumeration if you need to perform other operations when using the enum. Most of the time you won’t need all this extra functionality and regular enums will do just fine but if you ever do, it’s nice to know this class is available.

Here’s an example of using the Enumeration class. Just subclass the Enumeration class, add your enumeration values with a human readable string and you’re good to go.

InstrumentType.cs

namespace CH3_Guitar_Application
{
    public class InstrumentType : Enumeration
    {
        public static readonly InstrumentType GUITAR = new InstrumentType(0, "Guitar");
        public static readonly InstrumentType BANJO = new InstrumentType(1, "Banjo");
        public static readonly InstrumentType DOBRO = new InstrumentType(2, "Dobro");
        public static readonly InstrumentType FIDDLE = new InstrumentType(3, "Fiddle");
        public static readonly InstrumentType BASS = new InstrumentType(4, "Bass");
        public static readonly InstrumentType MANDOLIN = new InstrumentType(5, "Mandolin");
        public static readonly InstrumentType ANY = new InstrumentType(6, "Unspecified");

        private InstrumentType()
        {
        }

        private InstrumentType(int value, string displayName) : base(value, displayName)
        {
        }
    }
}

The Horsehead Nebula and Flame Nebula (lower left). Narrowband hydrogen-alpha, sulfur II and oxygen III data was acquired over two nights, processed using Pixinsight and the channels were mapped to the Hubble Palette. Not my favorite color combination but it does bring out a lot of detail in the image.

Astrophotography is tough. Before you can produce anything of interest, you first need to learn how to use your equipment to acquire images and then you need to learn how to use the software tools to process those images.

On the acquisition side, you’re having to master the use of a lot of different hardware. You need to understand and be able to set up a telescope, a mount, an auto-focuser and a color wheel and connect all of these to a computer so you can guide the mount and acquire your images. If you make a mistake with any of these, you have probably wasted a nights worth of work. You can look for help online but everyones setup is slightly different so you’ll probably have to do a lot of experimentation to make your own equipment work properly.

On the processing side, the tools are daunting. My processing tool of choice is called Pixinsight which consists of a suite of processes that you run your images through to achieve your final image. Almost all the processes have multiple parameters that you can tweek to control the mathematics behind the processing of the images. I suspect few actually understand what all of the parameters do and mostly rely on experimentation to determine the best values for their images.

Understanding what processes to use and the order in which to apply them is another challange. For me, as I suspect it is for most people, the path to learning was to watch lots of YouTube videos, try out the various techniques, and over time, build up a repertoire of things that work while tossing out the things that dont. This takes many hours and often ends with sub-optimal results that you end up just throwing away. It can be frustrating.

Unless you have lots of time and patience, you should probably consider another hobby. On the other hand, if you like challenges and are willing to put in the time, it can be really fun.

First the setup process:

1. Download EasyLogging++ from the repository on GitHub at https://github.com/zuhd-org/easyloggingpp#configuration
2. Unzip the file and copy the easylogging++.cc and easylogging++.hh into your projects source directory.
3. Right-click on your project’s header file directory and select ‘Add > Add Existing Item’ and select easylogging++.hh.
4. Right-click on your project’s source file directory and select ‘Add > Add Existing Item’ and select easylogging++.cc.
5. Right-click on your project and select ‘Properties’ then select ‘C/C++’ > ‘Preprocessor’. Add ‘ELPP_THREAD_SAFE’ to the ‘Preprocessor Definitions’ section. Make sure you do this for both the Debug and Release sections.
6. At the top of your main source file add the text ‘INITIALIZE_EASYLOGGINGPP’ to initialize the logger.

That’s it for the setup. The developer did a really nice job with this. It couldn’t be easier to setup.

To actually use the logger in your code, you will need to configure the logger. That can be accomplished by loading a config file and calling reconfigureAllLoggers as follows:

   const el::Configurations conf(R"(logger.conf)");

   el::Loggers::addFlag(el::LoggingFlag::StrictLogFileSizeCheck);

   el::Loggers::reconfigureAllLoggers(conf);

The config file that I used is as follows:

• GLOBAL:
  FORMAT = “%datetime %thread %level %msg”
  FILENAME = “D:\Win10_Workspaces\LogTest\LogTest\Logs\Logs.log”
  ENABLED = true
  TO_FILE = true
  TO_STANDARD_OUTPUT = false
  SUBSECOND_PRECISION = 6
  PERFORMANCE_TRACKING = false
  MAX_LOG_FILE_SIZE = 2097152 ## 2MB

I won’t describe it here because the Easylogging++ site does a pretty good job explaining it. For the purpose of this tutorial though the important line is the MAX_LOG_FILE_SIZE. When your log file exceeds this value a new log file will be generated and the old one will be archived.

To setup the software up for rotating logs you will need to install a callback function to do the job. That’s accomplished using the call:

el::Helpers::installPreRollOutCallback(PreRollOutCallback);

This function will be called any time your file size hits the MAX_LOG_FILE_SIZE limit that you’ve set in the config file.

The callback function that I put together is as follows:

void PreRollOutCallback(const char* fullPath, std::size_t s)
{
   char newPath[256];

   ver++;

   std::string str(fullPath);

   std::string pathNoExtension = str.substr(0, str.find_last_of('.'));

   sprintf_s(newPath, sizeof(newPath), "%s_%s_%d.log", pathNoExtension.c_str(), GetDateTime().c_str(), ver);

   rename(fullPath, newPath);
}

All it really does is rename the existing log file with the date and a version number. When the call returns Easylogging++ will generate a new log file with the default name.

And that’s it. I’m including a download for a sample project that does all the above and creates three thread to demonstrate Easylogging++ multi-threading capabilities.

I’d like to give credit to the developers, Zuhd Web Services. They’ve done an excellent job with this and it’s great of them to share their work with others.

Source Files:

Code is signed by Al Carnali

I use InMotion Hosting for my domain provider but since the majority of the install process uses CPanel, I suspect that what I’ve done will apply to other providers as well.

To perform the install of the certificate you will need SSH access to your site using Putty and also FTP access using the FTP program of your choice.

First open PuTTY and enter in the host name and port for your site. In my case the host name was carnali.com and the port was 2222.

On the left side of the PuTTy dialog select Connection > SSH > Auth. Use the browse button to load your private key file (generated while you were setting up your site for SSH access) and then press the ‘Open’ button.

A console window will open and you will need to enter the user name and SSH password for your site.

The process is as follows:

Download the getssl script from github using the following command:

curl –silent https://raw.githubusercontent.com/srvrco/getssl/master/getssl > getssl ; chmod 700 getssl

Add a user agent to the getssl script using the following:

sed -i ‘s/curl -k/curl -Aagent -k/’ ./getssl

Create a directory for the configuration files using the following command. (Make sure you replace www.carnali.com with your own domain name)

domain=www.carnali.com; ./getssl -c $domain

Enter the following commands to generate the needed configuration files:

configFile=.getssl/$domain/getssl.cfg; sed -i ‘s/SANS/#SANS/’ $configFile

echo ‘CA=”https://acme-v01.api.letsencrypt.org”‘; >> $configFile

echo “ACL=(‘public_html/.well-known/acme-challenge’)” >> $configFile

./getssl $domain

Next, launch your FTP program, navigate to the .getssl/www.carnali.com folder (again substitute your own domain wherever carnali.com occurs) and download:

www.carnali.com.crt
www.carnali.com.key
chain.crt

Log in to your websites CPanel interface and navigate to ‘SSL/TLS > Manage SSL Sites’

Go to the ‘Install an SSL Website’ section and do the following:

Select a Domain: carnali.com

Copy and paste the contents of www.carnali.com.crt to the Certificate section.
Copy and paste the contents of www.carnali.com.key to the Private Key section.
Copy and past the contents of chain.crt to the Certificate Authority Bundle section.

Press the ‘Install Certificate’ button.

That should be it. Open a web browser and enter https://www.carnali.com to see if you can connect without errors.

If you do have a problem DIgiCert has a nice page where you can enter your domain and perform a check on the newly installed certificate.

When I did my own certificate installation I initially could not get it to work. When I attempted to go to my site I would see invalid certificate errors even though the certificate appeared to match the domain name. I ended up figuring out that I needed to use www.carnali.com during the certificate generation process instead of carnali.com. This is required because Lets Encrypt does not yet support wildcard certificates and requires an exact match for the domain name. This also prevents you from using the certificate for subdomains on your server. The good news is that Let’s Encrypt will start to support wildcard certificates in January of 2018 so this problem should go away.

Even worse, clicking on the icon would just open a folder on the desktop instead of launching the desired program.

With a bit of research I found that if you want to create a desktop icon for a Windows Store application you need to do things a little differently. First, press the Windows key and the ‘R’ key simultaneously. This will bring up the Run dialog. In the Run dialog enter the following: shell:AppsFolder then press OK.

This will open the Applications folder on your desktop and from here you can just find the appropriate application icon and drag it on to the desktop. Problem solved.