Friday, September 21, 2018

What's Next for DXCC?

At the end of summer every year, I start thinking about DXCC. For several years, it was getting more confirmations for 80m DXCC, so I could complete 5BDXCC. Last year, I accomplished that, including the 30m endorsement.

At the time of this writing, I have 109 confirmations for 17m. That band will be next - I'll submit that this year. This will also push me over the 1000 confirmations threshold for DXCC Challenge - I'll do that one at the same time.

The downside of earning DXCC awards on each band is there are fewer bands left.  On 12m, I need just 17 more confirmation. Given the low level of sunspot activity, that might take some doing. However, I did manage to add 10 confirmations since last year, so it is possible.

160m would be the next one. With 46/45 confirmations, it's further off. I'm not even half way to the necessary 100. I will definitely put some work into 160m this winter. But, honestly, DXCC on 160m may take a few years.

Speaking of years, on 6m I have a whopping seven confirmations. In the spring, I figured out how to use FT8 on this band, and while I heard a ton of DX, I only managed to work a handful. Definitely looking forward to the winter sporadic-E season. I think the most excitement I'll get for a while is finishing off 10-band confirmations. I have USA, Canada, Mexico, and Suriname on all 10 bands -- but there's several countries where I just need a 6m contact.

I've inched closer to Honor Roll, with 279/276 confirmed Mixed. have worked about nine of the remaining 64, but I need confirmations. Perhaps it is time to learn more about QSLing effectively.

And, if nothing else, it's fun building endorsements for the bands I already have. That's the fun of DXing -- it's long-term fun.



Thursday, September 20, 2018

Resolving the KAT100 Wake-Up Problem

KAT100 antenna tuner below the K2/100.
My KAT100 has been a little troublesome for a couple of years now. Sometimes, when turning the K2 on, the KAT100 would take a second or more to turn on, and the K2 would act like the KAT100 wasn't present, giving NOT INST when any of the KAT100-related buttons were pressed.

I noticed it sometimes at the Walton County QTH. When it did happen, cycling the power a few times usually got rid of it. Sometimes I had to leave the rig on for a while. Later, when I moved the radio back to Gwinnett, it didn't happen any more.

Then I moved the radio to the new Fulton County QTH. This problem appeared with more frequency. Indeed, it happened nearly always, and warming up the rig for an hour or so the only way to get around it. This sometime problem had become annoying, and I wanted to get to the bottom of it.

At first, I thought it was some kind of power delivery problem in the KAT100. Normally, the KAT100 is supplied continuous12v power on the coaxial jack J1. The K2 supplies a signal 12CTRL on the J3 Control jack that goes to 12v when the K2 is powered on. This signal turns on Q1, and Q2, which supplies 12v power to U8, the regulator chip, which supplies 5v power to the unit and everything comes on.

That theory was shot down quickly. As soon as the K2 was switched on, the 12CTRL voltage would come up immediately, and U8 would deliver 5 volts immediately. That part of the circuit was working perfectly. Power was available to the KAT100 the moment the K2 powered up.

Even so, the KAT100 LEDs would not light up right away. Sometimes, it would be a second or two, sometimes ten or more seconds. When this happened, I'd get the NOT INST behavior. If the KAT100 LEDs lit as soon as I powered on the K2, everything was fine.

My next theory was that must have been something wrong with the AUXBUS connection -- the internal bus that the K2 uses to talk to the micro controller in the KAT100 (as well as the several micro controllers in the K2!). That one was busted as well, as a scope probe revealed very healthy transitions on the AUXBUS right on U1 pin 40.

I tried other remedies. Thinking there might have been something weird about the control cable connecting the K2 and KAT100, I swapped it out for another straight through cable. No change. Maybe U1 was not properly seated in it's socket. I removed it and reseated it. No change.

This problem appeared to the temperature and humidity related. This is why it happened sometimes in Walton county, never in Gwinnett county, and nearly always in Fulton county.

Since power was present, what was delaying the lighting of the LEDs? Looking at the circuit diagram, the LEDs have to be turned on programmatically by U1, the PIC micro controller. Maybe it wasn't resetting properly?

But, power-on reset logic is part of the chip itself. Something else had to be delaying the reset.

I decided the problem might have to do with the U1 clock. If the clock oscillator didn't start up right away, that would delay the reset. Putting scope probe on pins 13 and 14 or U1 deepened the mystery. When the KAT100 would fail to power up, these pins would float up to about 1 volt. When it worked, the pins would be locked at 0 volts. Why 0 volts? Because the chip goes to sleep after initialization! This uses much less power. U1 awakens on transitions on the AUXBUS.

So, it seemed very likely this was the problem. But the clock circuit is dead simple. U1 connects to Z1, a ceramic resonator.

I tried hitting Z1 with a heat gun, but I didn't see any immediate effect. Then I nudged Z1 with a screwdriver, and the KAT100 came up immediately. Maybe I had a bad device, or maybe a bad connection. I reflowed the solder on U1 pins 12-14, plus the three pins on Z1.

This worked right away, and even the next day when I let everything cool down.

Solved! It appears it was a problem with the U1 clock circuit, likely because of a poor connection to Z1. If it fails on me again, I'll likely end up replacing Z1 entirely.


Wednesday, September 19, 2018

OK, I'm an Idiot....

Sometimes, it helps to just admit it to yourself. Let me explain.

Back in December 1st 2017, I started using FT8. I set up the WSJT-X Mac software and made my first contact. Mostly operating on 17m, 30m, 12m. I later discovered 6m. Indeed, this last summer was a huge opportunity to work much of the country on sporadic-E (Es) on 6m. I was amazed to work 40 states in just one summer. On all bands, I've worked all fifty states, and quite a few countries with this mode.

So, I've been using FT8 for months. However, one thing bothered me - everything seemed off frequency. You see, there are standard frequencies that are published for FT8, 12m is 24.915 MHz. But if I dialed in 24.915 MHz, everyone was too high -- like no one was using frequencies less than 2 kHz, and some were visible at 3.5 kHz and higher.

My solution to the problem was simple -- I just tuned higher. I decided that 24.916 was more accurate, and operated that way for months. I even reprogrammed WSJT-X so the 1 kHz higher frequencies were the right ones.

But, it bothered me. It seemed wrong.

I managed to work Baker Island using FT8, but it was a bit of trouble, and I had one fellow email me saying I was calling too low for the fox/hound DXpedition mode. I used a higher frequency and almost immediately had an exchange. This made me think about this issue more.

Originally, I had my K3 set up for RTTY using AFSK. This means I was using the AFSK A data mode on each band. For FT8, I would select DATA REV, so it would use USB instead of LSB.

What I didn't realize is that AFSK A means the display frequency is adjusted to reflect the Mark frequency of (in my case) 1445 Hz. This accounts for my frequency being too low -- I was off by 1.4 kHz.

With that figured out, I switched to DATA A, which has the display frequency of the suppressed carrier, as it would for LSB or USB. The frequency jumped, and I tuned again to the standard frequencies (the real ones, not my artificial higher ones).

But, it didn't work. I couldn't hear any signals. Back to AFSK A, and they are there, but switch to DATA A, and they are gone. What?

Turns out, AFSK uses LSB by default, while DATA A uses USB. Since I was using DATA REV, this means DATA A was LSB. Oops. Back to straight DATA mode, using the DATA A sub-mode, and everything works just as it should. Gosh, that's too easy.

I'm an idiot....

I'll just have to remember to change the DATA MD back to AFSK when I'm doing RTTY.