Saturday, August 4, 2018

Aligning a TS-430S, or "wait, how am I supposed to check FM again?"

I'm fixing another (I know I know) TS-430S for a friend. Yes, this means I'm returning it back to them. After all of the repairs I had to do to get the thing up and going reliably I did an RX carrier calibration. It was a little bit off - a combination of using WWV at 10MHz and the scope to calibrate CW, USB and SSB.

However, the AM and FM carriers didn't at all meet the expectations of the service manual. Notably, the AM carrier is seemingly the same as the USB carrier on transmit and there isn't one on receive. The FM carrier just didn't appear during receive or transmit. But .. it's transmitting FM.

Now, I need to go get the TS-430Ses I've fixed and compare the carrier behaviour to the other rigs, but .. well, they work on AM/FM receive and transmit. So ok, let's figure it out.

The AM carrier matches the USB carrier. It's weird because the circuit has an AM/FM carrier crystal however.. yeah, AM carrier here is linked to the USB carrier. I need to figure that out. And the FM transmit has no power control - it's 100W carrier only. So the only way to do it without dumping 100W out into the finals whilst adjusting it is to remove the RF drive output on the RF board (which feeds the finals with RF), attach a 50 ohm resistor across it and check the final RF carrier signal on the scope. This worked mostly OK but since there's no ALC feedback, the output is .. very distorted. Now, I don't know if these rigs were supposed to output a clean sine wave at all carrier output settings but .. well, they're very loud signals on lower bands, sometimes more than 8V peak-to-peak, which is almost triple what you need to feed the finals to get 100W out. So I got it in the ballpark - because well, the thing is not outputting a true sine wave here because the carrier output is way too high - and then had to resort to checking using a directional coupler and the scope.

Now, this isn't too bad - I was in the rough right spot for the FM carrier frequency anyway, and I can key down for a few seconds at a time without making things sad. But, this step was delayed until I verified the finals were working and that took a lot of work to get right. It turns out it was on the nose anyway after all of that and FM modulation now works great.

So - if you're aligning a TS-430S, the AM/FM carrier bit in the service manual may not be entirely correct.

Sunday, July 15, 2018

Restoring a TS-430S, or "dry joints and stray RF: a tutorial"

I recently acquired a TS-430S HF transceiver. The seller claimed the FM board and full complement of filters worked, but no display, buttons/LEDs or sound. He said it worked until he sent it in to have filters added. I figured it was going to be something simple. Boy was I both right and wrong.

These rigs have a habit of dry joints everywhere. So, I powered it up to see - yes, no display. Ok - step 1 - check power rails. I discovered there was no 5v line. The IF board has the 7805 regulator, so it is time to check for dry joints.

Oh look! Some very dry joints. I bet these were marginal until the tech installing the filters jostled it about. I fixed these any anything else I could find on the IF board.

I then powered it up. One digit showed up - the optional 10Hz digit - but all the lights and buttons worked.

Now, this rig has a separate PLL board for the main VFO which exports a signal that blanks the VFO output and the display. Amusingly it doesn't blank the final digit though. Ok, so it's likely PLL unlock. The PLL board was getting power, but ... no stable 36MHz base oscillator. That's on the control board. I pulled that out to find more dry joints around that circuit and its connector - so, fixed that.

I fired it up again. The PLL board was still unlocked even though the 36MHz oscillator was now working. I spun the dial and measured the other VFO feeding the PLL board - this is the fine grain frequency selection that gets mixed in to the PLL boards four VFOs to output the final VFO signal. It was moving OK - so the control board and the other PLLs were OK. Next - check the four VCO selection lines - nothing.

The PLL board has four varicap diode based VCOs and a PLL loop. The control board outputs the band select data to the RF board which decodes it and drives the PLL VCO, the relay based LPFs and the receiver HPFs. There were multiple issues - the control board bandpass lines were wrong and the VCO select lines were wrong.

Next - the RF board. Dry joints everywhere. Here is one of many that linked ground planes together.

And this one was on the VCO output connector.

I removed the TTL IC that did the BCD to output line demuxing because it was dead and fixed the dry joints. But the control board was still outputting the wrong band info. It turns out the IO expander IC that drives those four lines had two dead IO lines. So, that needed replacing too.

At this stage the control board was OK, the band select lines and VCO select lines are OK, but no PLL lock. Time to diagnose the PLL board.

First up - the varicap VCO was working. Wrong frequency but working. The circuit takes the output of that, buffers it though a transistor amplifier, shapes it into a square wave and divides it down via a pair of TTL chips and feeds it into the PLL control IC.

Next - the 5v line on the PLL board was ... suspiciously low. 5v was coming in OK, but something was dragging it down to 3.8v in places. That is too low for TTL. I checked each chip and... the 75S112N flip flop chip was running hot. Ok, so that needed replacing. Note it is S and not 74LS - the PLL loop runs from 45 to 75MHz, so it needs speed. With that chip replaced the 5v rail was again at 5v. But, no PLL lock.

So I then traced the PLL loop. VCO was OK. VCO though the buffer amp wasn't. I pulled out the transistor there and it was open circuit. I didn't have an equivalent so I found a close enough one for now and ordered a replacement. But then it was sill not working right - the signal level into the TTL NAND chip was super low. I figured either the transistor I replaced it with wasn't biased right or the TTL chip was pulling its input low. Indeed it was the latter - the input side was shorted to ground. I replaced that chip and the rig sprung to life!

I recalibrated the four VCOs now that I had replaced some parts. It was locking OK on all bands.

But - the receive signal was low. I checked the attenuator switch - no go. I disconnected the attenuator control cable to the RF board - RX sprung to life! A little solder reflow on the switch board and that fixed that.

After that I just did the obligatory filter and finals board check and reflow.

One LPF relay clean procedure and finals alignment later and it's all ready to go. The SWR foldback protection needs fixing and I need a 150 ohm dry load to do that, so that's my next week project.

As to how those parts all failed, likely at once? My guess is stray RF fried a path somehow. I'm glad this was the extent of the part damage!

Monday, March 12, 2018

Not merging stuff from FreeBSD-HEAD into production branches, or "hey FreeBSD-HEAD should just be production"

I get asked all the time why I don't backport my patches into stable FreeBSD release branches. It's a good question, so let me explain it here.

I don't get paid to do it.

Ok, so now you ask "but wait, surely the users matter?" Yes, of course they do! But, I also have other things going on in my life, and the stuff I do for fun is .. well, it's the stuff I do for fun. I'm not paid to do FreeBSD work, let alone open source wireless stuff in general.

So then I see posts like this:

I understand his point of view, I really do. I'm also that user when it comes to a variety of other open source software and I ask why features aren't implemented that seem easy, or why they're not in a stable release. But then I remember that I'm also doing this for fun and it's totally up to me to spend my time however I want.

Now, why am I like this?

Well, the short-hand version is - I used to bend over backwards to try and get stuff in to stable releases of the open source software I once worked on. And that was taken advantage of by a lot of people and companies who turned around to incorporate that work into successful commercial software releases without any useful financial contribution to either myself or the project as a whole. After enough time of this, you realise that hey, maybe my spare time should just be my spare time.

My hope is that if people wish to backport my FreeBSD work to a stable release then they'll either pay me to do it, pay someone else to do it, or see if a company will sponsor that work for their own benefit. I don't want to get into the game of trying to backport things to one and potentially two stable releases and deal with all the ABI changes and support fallout that happens when you are porting things into a mostly ABI stable release. And yes, my spare time is my own.