13 Pin Accessory Connector CAT for IC-706 Rig

I am an amateur radio operator (extra class, call sign: N7DSP) and I made a rig control interface cable for my Icom 706 many years ago. I've been working from home during this COVID-19 quarantine and have had a little time to get it back up and running with the hope of getting email via Winlink 2000 up and running.

To my surprise, I couldn't remember how to get the dang thing working with fldigi (http://www.w1hkj.com/) so I'm trying to capture that information here.

The interface cable I made apparently used the USB to RS232's RTS line to signal the radio to transmit (or virtually to push the PTT or push-to-talk button) so that was the first mystery. The second mystery was that I needed to use a "separate serial port" under the "hardware ptt" tab even though both USB devices turned out to be the same.

Cables

The green 8mm stereo jack line is my transmit audio cable and should be hooked up to the headphones or line out jack, a second separate 8mm stereo cable (not connected to the USB, green audio, or 13-pin accessory cable) needs to attach to the phones line on my front panel and it should hook up to the line in or microphone jack on my computer.

The black cable attached to the 13-pin accessory jack connector with an 8mm stereo connector is for the CV-I interface (multi-drop serial port that Icom uses to control radios) and hooks up in the back of the 706. It connects to the 8mm jack that is closest to the 8p8c (colloquially known as the RJ45 jack) used for the HM-103 mic.

The remaining black cable is the USB cable which is an RS232 serial emulator chip and cable and needs to be plugged into a free USB port, I'm assuming above that it's the only USB serial port you've plugged in otherwise the "device" might be /dev/ttyUSB1 or /dev/ttyUSB2 or something.

With the below fldigi settings, if you run fldigi and the radio isn't powered and the USB control cable isn't plugged into your computer, fldigi will not start! Once you plug in the USB cable and power the radio it will run.

Settings

Here is a summary of the settings I need for my interface cable:
Rig Control:
Use Hamlib: checked
Rig: Icom IC-706
Device: /dev/ttyUSB0 (add yourself to the dialout group on Ubuntu to get permissions correct, else chmod 777 /dev/ttyUSB0 everytime you want to use it)
Baud rate: 19200
Stopbits: 1
All other settings at defaults which are:
Retries: 3
Retry interval: 1000
Write delay: 0
Post write delay: 0
PTT via hamlib command: unchecked
Audio on Auxiliary port: unchecked
DTR +12: unchecked
RTS +12: unchecked
RTS/CTS flow control: unchecked
XON/XOFF flow control: unchecked
CW is LSB mode: unchecked
RTTY is USB mode: unchecked
Sideband: Rig mode
Mode delay: 200
Polling Interval: 250
Advanced configuration:



Hardware PTT:
PTT tone on right audio channel: unchecked
h/w ptt device-pin
Use separate serial port PTT: checked
Use RTS: checked
RTS = +V: unchecked
Use DTR: unchecked
DTR = +V: unchecked
Device: /dev/ttyUSB0
Use parallel port PTT: unchecked
PTT delays valid for all CAT/PTT types
Start of trasmit PTT delay: 0
PTT end of transmit delay: 0



While debugging all of this, occasionally the PTT button would get stuck "on" so I wrote this python script to force it back off:

#!/usr/bin/python3
import serial

ser = serial.Serial()
ser.baud = 19200
ser.port = '/dev/ttyUSB0'
ser.setRTS(0)
ser.setDTR(0)
ser.open()
ser.close()

Fake BSOD Ransomware

Background

Tonight a loved one's computer was hit by ransomware. I rarely have to deal with viruses and malware because I run only Linux and OS X at home. That's not to say that neither of those platforms are without security issues--they're not. It comes down to numbers. OS X has maybe 10% of the desktop market share and Linux has may 1%. In a ransomware scheme it's all about getting it in front of as many people as you can.

The problem

A very unconvincing "blue screen of death" was displayed with a customer support number to call. Surely if I called a friendly customer support rep. would have fixed my problem for a small fortune. The going rate seems to be around $150 if my googling is accurate.

The Solution (sort of)

Anyway, most online resources instruct you to do the following to remove this ransomeware:
(quoting from http://sdpcfix.com/computer-security/ransomlock-fake-blue-screen-tech-support-scam/)

1. Press Ctrl+Alt+Del
2. Open Task Manager
3. Look for the ransomware entry on the Processes tab, which should be ‘diagnostics.exe’, and end the process.
4. Go to the registry editor by clicking on Start -> Run -> Typing ‘regedit’ and pressing enter.
5. Delete the following registry entry: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\”Diagnostics” = “[PATH TO MALWARE]”
6. Delete the file folder from the directory.

Ok, sounds reasonable. Unfortunately for me, this particular version had a few tricks up its sleave. First, I couldn't move the mouse away from the top lefthand corner of the screen. Second, the BSOD drew itself on top of all other windows so starting task manager or cmd.exe or anything else useful was, well, kind of useless.

The Solution (for real)

Over time I realized that at least the keyboard focus was still going to the current window, so using Alt-tab I could navigate from the BSOD to cmd.exe and task manager and anything else I needed. I also found that when I held Alt-tab down I could see the selected window briefly, but the Alt-tab menu itself often occluded important information. After letting go, however, the BSOD would draw over it again. Ugh. The last discovery that I needed to lick this one was that hitting Ctrl+Alt+Del then selecting task manager let me use the mouse for a second and then if I hovered the mouse over the task manager icon or the cmd.exe icon on the start menu bar then I could see selected window in its entirety!

Being a Linux guy I'm still appalled at how crappy Microsoft's command line utilities are. I finally googled enough to find:

dir /b /s

That lets you list files recursively.

tasklist /v

Shows running tasks and their run times.

taskkill /f /im <glob>.exe

Kills a task matching the glob expression.

Using those commands and with the Ctrl+Alt+Del and Alt-Tab tricks above I was finally able to find the offending process. Final trick up this ransomware's sleave: the process was called "windows.exe", not "diagnostics.exe" like above. It was pretty satisfying to kill that nasty with taskkill. A quick search then yielded its location: c:\Users\Public\windows.exe (or close to that, I didn't write it down).

So kids if you're hit with a nasty fake BSOD that doesn't let you use your mouse, don't give up just be on the lookout for "windows.exe".

(I wish I'd written down the tech. support phone number.)

As recommended above, delete "windows.exe" and remove the corresponding "Run" key from the registery.

(BTW, I was able to run regedit in safe mode, but for some reason I missed the c:\Users\Public\windows.exe "Run" key when I looked for it. Finding it there would have been a much faster way to resolve this.)
(Also BTW, this was Windows 8 if that matters.)

GNU Global in vim (and emacs!)

I know, I know, this blog is for emacs, but Wade's post on getting GNU global to work with vim was too good to pass up.  (Thanks for the shout out, Wade.) I've been meaning to write a similar post for emacs for years.  Enjoy...

http://wadeberrier.blogspot.com/2012/04/source-code-navigation-with-vim.html

Binding or Setting Function Keys in GNU Emacs

After learning the basics of emacs, you'll want to start customising your keys.  Function keys are a great place to start since few have default bindings in the stock emacs.

For instance.  If you're a C, C++, or Java developer you'll likely want to compile from within emacs so that you can easily jump to compiler errors.

Last I checked, there is no default key binding for doing this besides

M-x compile

(to set the compile command) and

M-x recompile

(to instantly compile after the compile command has been set.)

I like to compile with F9 (force of habit from an old tool), debug with F10, and set my compile string with F11.

For the above key bindings, add this to the end of your .emacs file:

(global-set-key [f9] 'recompile)
(global-set-key [f10] 'gdb)
(global-set-key [f11] 'compile)

How to return a function pointer without a typedef in C/C++

The intertubes are full of examples on how to use function pointers in C/C++. Most try to simplify things by typedef'ing the function signature. What if you're a glutton for punishment like me and want to do it the "hard" way?

Ok, here's the background. Let's say you want to be able to find the cosine of an array of doubles, but you also want to be able to find the sine, tangent, etc.

You could do this:

#include <math.h>

void apply_sin(double *dat, int length, int type)
{
    int k;
    for (k=0;k<length;k++)
    {
        dat[k] = sin(dat[k]);
    }
}

void apply_cos(double *dat, int length, int type)
{
    int k;
    for (k=0;k<length;k++)
    {
        dat[k] = cos(dat[k]);
    }
}

void apply_tan(double *dat, int length, int type)
{
    int k;
    for (k=0;k<length;k++)
    {
        dat[k] = tan(dat[k]);
    }
}

void apply_square(double *dat, int length, int type)
{
    int k;
    for (k=0;k<length;k++)
    {
        dat[k] *= dat[k];
    }
}

But this leaves a lot to be desired. Each operation requires a new function that is nearly identical to all the rest. Can't we factor out the commonality?

Ok, how about this:

#include <math.h>
#include <stdio.h>

double square(double val)
{
    return val * val;
}

void apply_operation(double *dat, int length, double (*oper)(double))
{
    int k;
    for (k=0;k<length;k++)
    {
        dat[k] = oper(dat[k]);
    }
}

void print_vector(double *dat, int length)
{
    int k;
    for (k=0;k<length;k++)
    {
        printf("%g ", dat[k]);
    }
    printf("\n");
}

void call_it(void)
{
    double vals[] = {1,2,3};
    apply_operation(vals, sizeof(vals)/sizeof(vals[0]), sin);

    print_vector(vals, sizeof(vals)/sizeof(vals[0]));
    apply_operation(vals, sizeof(vals)/sizeof(vals[0]), cos);
    print_vector(vals, sizeof(vals)/sizeof(vals[0]));
    apply_operation(vals, sizeof(vals)/sizeof(vals[0]), tan);

    print_vector(vals, sizeof(vals)/sizeof(vals[0]));
    apply_operation(vals, sizeof(vals)/sizeof(vals[0]), square);
    print_vector(vals, sizeof(vals)/sizeof(vals[0]));
}

int main(int argc, char *argv[])
{
    call_it();
}

So that's a bit better. Only one implementation of the loop code, simple implementations for each operation, only the overhead of an additional pointer dereference per element. How did we pull this off?

void apply_operation(double *dat, int length, double (*oper)(double))

apply_operation() takes a function pointer as a parameter (the last argument). This makes it so that apply_operation() can take any function that takes a single double as input and returns a single double as output. Slick.

Now, the next step: returning a function pointer (without typedefing the signature). Let's say we have a table of operations and we associate each operation type with a function pointer so that we can do a simple lookup to get a pointer to the desired operation function. So, in other words, we're returning a function pointer. Here's how to do it without a typedefed function signature.

#include <math.h>
#include <stdio.h>

enum
{
    OPER_SIN,
    OPER_COS,
    OPER_TAN,
    OPER_SQUARE
};

struct oper
{
    int type;
    double (*func)(double);
};

double square(double val)
{
    return val * val;
}

struct oper oper_lut[] =
{
    {OPER_SIN, sin},
    {OPER_COS, cos},
    {OPER_TAN, tan},
    {OPER_SQUARE, square},

};

double (*get_oper(int oper_type))(double)
{
    int n;
    for (n=0;n<(sizeof(oper_lut)/sizeof(oper_lut[0]));n++)
    {
        if (oper_type == oper_lut[n].type)
        {
            return oper_lut[n].func;
        }
    }
}

void apply_operation(double *dat, int length, double (*oper)(double))
{
    int k;
    for (k=0;k<length;k++)
    {
        dat[k] = oper(dat[k]);
    }
}

void print_vector(double *dat, int length)
{
    int k;
    for (k=0;k<length;k++)
    {
        printf("%g ", dat[k]);
    }
    printf("\n");
}

void call_it(void)
{
    double vals[] = {1,2,3};
    double (*func)(double);
    func = get_oper(OPER_SIN);
    apply_operation(vals, sizeof(vals)/sizeof(vals[0]), func);
    print_vector(vals, sizeof(vals)/sizeof(vals[0]));
    func = get_oper(OPER_COS);
    apply_operation(vals, sizeof(vals)/sizeof(vals[0]), func);
    print_vector(vals, sizeof(vals)/sizeof(vals[0]));
    func = get_oper(OPER_TAN);
    apply_operation(vals, sizeof(vals)/sizeof(vals[0]), func);
    print_vector(vals, sizeof(vals)/sizeof(vals[0]));
    func = get_oper(OPER_SQUARE);
    apply_operation(vals, sizeof(vals)/sizeof(vals[0]), func);
    print_vector(vals, sizeof(vals)/sizeof(vals[0]));
}

int main(int argc, char *argv[])
{
    call_it();
}

The magic is in get_oper(). Did you catch it?

double (*get_oper(int oper_type))(double)

This means that get_oper() is a function that takes a single int as a parameter and returns a function pointer to a function that returns a double and takes a single double as its only argument. Simple, right? There it is--returning a function pointer from a function without typedefing the signature (the "hard" way).

This is the best reference I've seen so far on function pointers http://www.newty.de/fpt/fpt.html.

Surviving Visual Studio

I love emacs. I can't describe how much I miss it when I have to do development in Windows. Yes, I know there's a version of emacs for Windows, but it seems like if you're developing for Windows it's easier to give into the borg than to fight them.
My tip for the day:
C-k C-f indents a region similar to C-M-\ in emacs.

Now the Economic Crisis is Personal ... Mother's Cookie Company Goes Out of Business

The economic crisis hasn't really made a big difference in my life until today. I just heard that Mother's Cookie Company is going under. I bought one last bag of pink and white "Circus Animals". Apparently it will have to last me for ETERNITY. Where's the 700 billion dollar bailout for cookie companies? Forget the whales, SAVE THE COOKIES! Check out the AP story.