PRC-344 Module 6 repair

With module 6 removed from its shield, the next task was to track down the failed component(s). The large TO-5 can is the regulator IC, an LM100H. Very much obsolete and available only at extortionate prices!

Armed with the datasheet for the LM100H, so I knew which pins connected where, I first traced and drew out a rough circuit diagram. There are four connections to this module. Three make immediate sense - raw 24v, regulated 6v, and Ground. But the fourth im not sure of! But it does seem to rule out the plainly obvious repair of simply replacing the thing with a modern three-terminal device!

The first suspect, and the easiest to isolate and test, was the 22uF capacitor across the raw 24v input line. I lifted the +ve leg of this and metered it...

Bingo! Bloody thing was dead short! I lifted the other leg to take it totally out of circuit and confirmed this was the case.

Now, im not at all sure what type of capacitor this is! But its value, voltage rating, polarity, size and the fact it was across a supply rail leads me to suspect a tantalum. My next job was to physically remove it. Although these modules look normal, they are in fact washed over with a tropicalizing varnish, and the capacitor was stuck down solid. It required a careful application of a wood chisel to prize it off!

A modern standard electrolytic capacitor fits neatly in its place. I would have liked to have fitted an axial device, but the only 22uF 50v devices I have are radials, so I had to bend the legs around a little!

At this point, I havent yet put the module back in the radio and tested it. First, ive to check this beastie over -

This is mounted in fuse holder contacts in the supply line. My suspicion was that it was a varistor, but a bit of research online suggests it might actually be a Schottky diode!

This (soldering) guns for hire, even if were just faultfinding in the dark...

I have a certain amount of sympathy with the lyrics of the song from which I have paraphrased this post title - as a night shift worker the first few lines are very familiar! So apologies to Mr Springsteen.

Earlier today, I popped along for a nosy at Johnsons of Leeds, and came away with a Clansman PRC-344 UHF manpack and antenna. I always knew I was taking a big gamble on an untested set, so was only minimally disappointed to find it doesnt work. Physically it is complete, and no damaged parts other than the lamp/call switch, which does still work but the toggle is loose.

So, with nothing more than a basic block diagram and 25years of experience, I set about trying to find the problem...

Firstly, the fact that it is totally dead (not even the dial light works) is actually a good thing! A part working set is always more of a worry, but a totally dead unit immediately points to a power supply problem.

Opening it up, I discovered a few of the plug in modules to be loose, but seating them back in correctly didnt cure anything. It may be that someone had previously started fault finding? Who knows!

What I can say, is that the build quality of these is amazing!About half of the electronics are in the form of plug in modules, but the interconnecting wiring harness looks a nightmare!

The first job was to ensure that the battery supply was actually reaching the electronics. So with the set off, a check at the incoming battery terminal showed 19v. Hmm, ok so the power is there, but thats a recently charged 24V battery! So, battery off and trace the supply wire, expecting to find a fuse blown.

What I found, in a fuse holder, was not a fuse. I think its some form of Varistor, but either way, there was no voltage after it. Having removed it from the circuit, I tried metering out the supply wiring to other parts of the radio, and made an interesting discovery - there was a dead short!

Now, in a radio as complex as this, a dead short could be a real basket to locate! But, here we have the advantage of plug-in modules! So, after making a sketch of the module positions and numbers, I pulled all the modules I could. Checking again showed no continuity to ground, so it was reasonable to assume that the short was in one of the modules.

Putting them back in one by one, and checking the continuity after each, the short returned when I replaced module 6.

Module 6 is the 6V stabilised power supply. I suspect that much of the radios systems run on 6V, and so this being faulty would almost certainly account for a dead radio!

Converting the PRC-349 for amateur band use?

The Clansman PRC-349, a huge 'hand-held' 1/4W low-band FM transceiver, is the British forces version of the Racal BCC349. These are regarded as useless for amateur purposes as the 10MHz band they cover, from 37 to 46.975MHz, in 25kHz steps, doesnt cross any of the amateur bands.

But - Racals own advertising of the BCC349 clearly states that it can be supplied covering ANY 10MHz segment between 30MHz and 76MHz.  Since the frequency control element is the most expensive (other than the RF Power device), and Racal wished to sell to as many markets as possible, its very unlikely that a major amount of work was required to change the band. Racal would surely have used a standard set of modules, with minor component changes.

So, knowing the operation of these sets, there are a number of necessary steps to convert them to amateur use -

1. Change the Rx and Tx frequency references
2. Disable or otherwise overcome the 150Hz tone squelch control
3. Re-align the filtering/oscillators
4. Modify LOUD and WHISPER settings to have the same mic gain on Tx

Sounds easy? Well, possibly, or possibly not. Studying the frequency synthesis system in use however throws up an interesting aspect - the VCOs do not feed directly to the divider chains! Instead, each (Tx and Rx VCO) is down converted with a fixed reference crystal oscillator, and the resulting roughly 2.5 to 12.5MHz band is fed to the dividers. It makes for a reasonable assumption then, that so long as the reference crystal frequencies are selected to mix the required VCO frequencies down to this range, and the VCOs are modified to cover the desired frequencies, that it should be possible to make the synthesiser work in a segment that covers an amateur band.

However, this wouldnt be all. The VCOs would need modifying certainly to oscillate as required, but also the Tx PA tuning, Band Pass filtering, and Rx front end filtering/tuning will all require modification to the desired frequencies.

It just so happens though that I have a copy of the Racal BCC349 technical manual, and all the necessary circuit diagrams! If we aim for moving up in frequency, to perhaps the 6m band (at least to start with, 4m would be better but lets go easy at first!), then I can see from the diagrams there isnt really too much to modify, and since we are going up, modifications to tuning coils is by removing turns, which is far easier than adding them to resonate lower! It might be that some parts will even align to 6m as is, or perhaps with some simple changes to fixed capacitors.

The likely difficult, or perhaps easy but expensive, part will be replacing the reference oscillator crystals. Custom crystals are in the order of £35 a pair! But, it might be possible to find stock channel pairs from older PMR equipment that will work - at least for testing.

In fact, probably the hardest part of a conversion will be dealing with the tone squelch! This might be defeated the way it is in the PRC-351, with an internal 160Hz oscillator, the difficulty here is that there is almost NO free space inside the PRC-349 AT ALL! So where such an oscillator would be fitted ive no idea!

What I can do though, if find out of my stock of spares a full set of working modules, and arrange a bread-board set-up, so that the various sections can be experimented  on to see if the adjustments are in fact possible - I just need to get hold of a suitable pair of 3rd overtone crystals for the reference oscillators now!

Clansman Handset cable repair

Well, I ended up cracking on with it.

One good thing about these cables is the messenger cord. By tying this the two halves of the cable were secured, and it was just the tricky job of stripping, joining, soldering, and sleeving the individual wires, then enclosing the whole repair in heat-shrink.

Of course, making extra sure that the heat-shrink tubing was on the cable before making the connections!

Clansman Cable Chomped!

Since ive got the 320s in bits, I thought i'd also try and find out why my spare handset wont key the transmitter.

After much metering, cable flexing at both ends, and scratching of bonce, all of which got me nowhere, since the metering showed good and the flexing didnt cause anything.. I happened to move the middle of the cable!...

...and it keyed up!

Examining the cable I discovered a cut in the outer sheath, moving this exposed the damaged interior! It looks like at some point the cable has been trapped and cut. Really annoyingly, the cut is about six inches from the plug end! These are not easy plugs to repair! Had it been the same distance from the handset I could have just cut it back and soldered it back on.

So, thats another job for another day! Ive a cable on a pair of DT100 cans to repair first!

PRC320 slow tx/rx recovery - fixed?

Having spent a long time investigating the slave relay 6RLA (the relay on the unit 6 motherboard that switches the tx/rx 6v line and the IF signal), using tacked on LEDs to observe the DC rails, and 'dry' testing of the IF contacts using continuity testing and an external supply to activate the relay, I started to come to the conclusion that whatever was causing the fault was not associated with the physical switching. I couldnt positively rule it out, but my suspicion began to fall elsewhere.

In particular, it fell on module 6b - the Receive Audio module. This contains the demodulator/detector, audio stages, and AGC circuitry. I noted in particular the presence of one of the suspect tantalum capacitors in its supply rail, isolated from the rest of the radio by a 100 ohm resistance.

So, today I embarked on the task of swapping this module for the one from the test-bed radio. Not a simple task!

18 soldered connections and 3 bolts!

 There are 18 connections, plus 3 bolts, to module 6b. Each is made via a link wire, looped around the module pin. Each had to be desoldered and lifted, the pin cleaned, the bolts unfastened, and the module withdrawn, first on the spare module from the test-bed radio, then the one from the faulty radio.

Since I had the test-bed open and was removing 6b, I decided to also remove module 6a - the Receive IF stage. This is located beside module 6b, and would be the next suspect in the investigation!

module 6b (left) and 6a (right)

After removing these from the test-bed, they were carefully put aside. The same was then done to the faulty radio, only this time removing just module 6b. With that put safely away from either the radios or the previously removed modules, to ensure they didnt get mixed up I immediately installed the spare 6b module into the faulty radio.

With the module replaced and reconnected, and a couple of the chassis screws replaced to ensure ground continuity - I made a brew and a sandwich!

Refreshed, I reconnected unit 2 (the rear section), the handset and the battery, and began testing...

At present, I am testing with a dummy load connected of course. Carrying out several key up/down tests, with various times in Tx mode, on various modes, and with some modulation, it does seem that there is no longer a delay in returning to receive, at least no longer than the momentary pause as the relays drop out.

Next, I need to completely reassemble the radio, and ensure it continues to operate like this. Then, I will need to replace the dummy load with an antenna connection and test the receiver with live signal. Only then will I really know if the set is fixed. But im moderately hopeful!

If it does indeed turn out to be working now, then the fault is with the 6b module, which I will need to repair before putting it back into service in the test-bed. The photo below shows the inside of module 6b... im not looking forward to fault finding this thing!

Inside No. 9, sorry, 6b...

Inside the PRC320

With the initial tests inconclusive, im having to delve into the guts of this set.

The first photo here shows the faulty set. The relay ive been testing is located in the bottom right corner of the PCB, which is unit 6. In this state, with unit 2 (the rear section) attached, the radio operates, and I can check at least a few voltages.

Above is the test-bed radio with unit 6 in the 'service' position. How your meant to service the radio like this when the back doesnt attach the manuals dont say. The relay can just be seen behind the pink wires at the bottom. There are three components associated with this relay, a 100 ohm resistor, a 68nF capacitor, and a 180uF 6.8v tantalum capacitor. All are suspect! The tantalum isnt part of the relay switching like the other two, but is a smoothing capacitor on the 6v Rx rail. If I have a suitable part then this might get replaced anyway! The various audio module cans are shown here, of particular suspicion is the top one, 6b, as this has another big tantalum in its 6v Rx rail!

From the other side. The other slave relay is part of the turret tuning mechanism, which is the big metal block in the middle! You can just about see the relay in the middle of the side plate, part hidden by the tuner unit.

And the view from the other side, which shows just how difficult it will be to work on the relay in the turret tuner!

So, my plan is thus - tack solder an LED to the 6v Rx rail and see if I can discern any link between the delay in return to Rx and the switching of this rail. If so, or if inconclusive, I will replace the associated components, and if the fault remains, will exchange the relay.

The Hunt Commences - Tx/Rx switching fault PRC320

For some time ive been meaning to fault find an issue with my Clansman PRC320 HF manpack radio. This set has a slow return back to receive after transmitting, a delay that seems to increase the longer the pressel is held (i.e. longer in Tx mode), up to a maximum of about 2 seconds. This doesnt seem much, and indeed under proper R/T procedure in a military net would not be noticeable, as proper R/T procedure includes time between key up and speech to allow for stabilization of the equipment. But for amateur use, this delay is a nightmare! It means I miss the start of callsigns, and in contests or fast paced contacts such as SOTA - its possible to miss the entire transmission!

So, how to tackle fault finding such a problem? What can cause a transceiver to be slow returning to receive?

Several possibilities come to mind -

A. Sticking relays
B. Failing capacitors
C. Failing power supply
D. AGC faults
E. Semiconductor breakdown

Anyone who has ever been inside a PRC320 will know just what a maze they are! (if youve never seen inside one - piccies to follow!). They are a modular system, which on the face of it sounds easy to work with, but the modules are soldered in and bolted down - they are not plug-in units like on other Clansman equipments. Essentially, the radio breaks down into six sections, each consisting essentially of sealed or otherwise very awkward modules.

Part of unit 2, the rear section, is the reflectometer module 2b. As well as sensing the RF levels at the antenna, this also provides a master relay, which switches the antenna between Tx and Rx paths, and also 24V out to a pair of slave relays on other modules. 
The whole rear section can be removed, this comprises the audio inputs, bandpass filtering, PA, and reflectometer sections. Because of this, it was the best place to start, as I could simply swap unit 2 with the same from my 'test-bed' radio, thus proving or eliminating the master relay...

So, I swapped the rear sections between the radios - and the fault stayed put. So not the master relay then!

The next, and in fact last, part that could easily be checked was module 5, the PSU. In the test-bed radio, this is an original unit that has had its horrid 1970s tantalum capacitors replaced with modern electrolytic units. In the faulty radio, it is a complete modern rebuild using DC-DC converter modules. But, this module at least connects with a plug and socket!

So, I swapped module 5... and the fault stayed put.

This leaves me with two relays, the slaves, that might be at faults. One of these is in a module hidden away within the tuning turret, so I decided to start with the other, which is located on unit 6, the motherboard - the only directly accessible circuit board in the whole radio!

Unit 6 consists of a PCB with various discrete components, upon which is mounted and soldered about five screened modules - each soldered in and bolted on. It can be raised into a 'service' position, to access the modules, but in this position the radio cannot be operated as unit 2 cannot be connected! It is also awkward to do this as the LSB mod gets in the way!

So I decided to meter out the relay and see if the change in voltages from the contacts matches the delay, indicating a sticking relay. I had already found just from the sound of the relays clicking that this relay seemed ok, but on metering the Rx 6v contact, discovered that the response times of my meters isnt fast enough to outrun the delay, and so the test proved inconclusive.

Im at a bit of a loss now. Unless I can locate a fault with the relay on unit 6, then im into the realm of module swapping! A rather daunting task! A last ditch method I can try is to tack-solder an LED and series resistor to the 6v Rx line from the relay. The LEDs response time should be near instantaneous, and so if the relay is at fault it should show.

If that doesnt work, then since I will have to start wielding the soldering iron, I may as well just swap the relay, and its associated components, out anyway, in exchange with those of the test-bed radio.

DMX512 Line Tester

Its been over 28 years since I last had any real involvement with stage lighting control, but an occasion has arisen whereby I need to do some basic tests on a DMX512 'universe' - as a DMX controller/slave network is known.

Testing DMX protocol properly, that is, by decoding the data packets, requires an expensive DMX analyser. But, as with most electronics handled by 'amateurs' (as opposed to professional engineers and technicians - but certainly not ruling those out!) the commonest faults are likely to be due to wear and tear and bad handling of cables and connectors. So, a simple device that can prove the flow of data, and diagnose simple connection issues, is all I require.

Now, proper, compliant systems use XLR-5 connectors, and I will be making up a tester for this once the plug arrives. But, many cheaper or older DMX lighting controllers use the XLR-3 connector. The build shown here is for a 3-pin XLR-3 line tester.

Im not going to include a circuit diagram here, as these can be found on the net easily. In the XLR-3 the DMX512 signal is on pins 2 and 3, and ground pin 1. DMX uses the RS-485 hardware protocol, and is a differential pair signal. All that is needed for basic testing is an inverse-parallel pair of LEDs across the differential line, i.e. between pins 2 and 3, along with a suitable series resistor to prevent the tester taking much current from the line (which is rated 250mA max, but any current draw from the line can induce noise, so this tester should not be left connected when the system is in use). As the DMX512/RS-485 standard requires a line termination, a second resistor should also be used across the pair to match the cable impedance. This is about 120 ohm.

Rather than a separate pair of LEDs, a single bi-colour device is preferred. These have two pins but contain back to back chips, usually one red and one green. I didnt have any of these, but instead had tri-colour LEDs, which are the same chips but a common cathode, and hence three legs. So, I had to use a connection to ground on pin 1. A pair of 270 ohm 1/4w resistors act as Rseries and Rload. Im not actually sure this is the right approach, as these were specified for the 2-leg bi-colour LED, and I think Rload should be a 120 ohm unit, and Rseries whatever gives best compromise between current draw and brightness. I'll modify them for the XLR-5 build once I get the plug, and have chance to test the XLR-3 on a live system. It shouldnt matter much though as the hardware protocol is rather robust.

The photo below shows the tester wired up. Care was taken to ensure that the distance from the pins to the LED matched that as from the pins to the top of the cable strain relief when the plug is made up

With the pins, circuit and cable securing gland inserted into the barrel, and the cable relief screwed on to complete the device, the LED protudes nicely out of the end of the rubber!

A quick calculation shows that for this type of LED, with Vled of 2-2.2v, and an expected line voltage of 6v, this tester should draw about 14mA. Thats not too bad for a line with 250mA max, but personally I would prefer 10mA, which would be a 380 ohm series resistor.

For the XLR-5, I will use Rseries 380 ohm, and Rload 120ohm. 120ohm is a standard value in the E24 series, but 380 ohm is not. I will have to decide whether to use 390 ohm (dimmer) or 360 ohm (a touch more current)

FT-857D Squelch Fault

Some weeks ago, I noted a distinct lack of apparent activity on 2m FM. Now, this wasnt too unusual, as the band is sparsely populated around here anyway save for CB type tools with no respect for any form of operating standards using it as their own private free-band.

But eventually I noticed that although I couldnt hear anything, I could see high signal strength readings! This led me to discover that the squelch had failed!

Thanks to the information from VK4SN near Brisbane, as shown here http://vk4sn.com/ft857.aspx and my trusty old Marconi 2955, ive been able to correct this fault, or at least, relieve the symptoms!

Following the instructions given, I also found like VK4SN that my new firmware values were around 170, far higher than they were before!

For the time being, I will see how it goes in this state. At some point though I suppose I will have to lift the main board (didnt fancy doing that today!) and check Q1063 as indicated. I might wait until I have located a source of this transistor first!