Icom F5061/62 - what are internal pads K and L used for?

[g8tzl2004]

I have a VHF IC-F5061/62 which is RXing but not TXing when you press the PTT. But the radio does TX when the D25 connector pins 19 (EPTT) and 14 (GND) are shorted.

When I initially tested the radio it was RXing OK...but I'm not sure if I checked the TX prior to reprogramming...but I think I did and it was OK.

For some reason the radio locked on TX when I uploaded an .icf file from an identical radio. Powering down and up again did not help and the radio defaulted to TX at power up until a 30 sec TX timeout. The radio was running v1.0 firmware. When I updated the firmware to v5.5, the radio RX'ed again but is not TXing when you press the PTT...but the radio will TX when you short pins 19 and 14 on the DB25 external accessory connector.

I think the radio was originally set up with an" OPC-617 type" external serial connector as there is a gap (filled with black sponge) where the external connector was originally fitted.

I guess the F5061 was originally set up as some kind of repeater...the SQL setting was high and the front end was detuned maybe to avoid desense??

I checked out the pads on the PCB. Pad K link has been cut (not that cleanly) and Pad L has been soldered.

Does anybody know what Pad K and Pad L are used for. This may explain why the F5061/62 is not TXing when the PTT is pressed??

I've searched the internet but can only find mention of cutting pads A and B when fitting a scrambler unit. I can't find anything in connection with the functions of the other Pads. There is no mention in the service manual.

Thanks

 

[jeepsandradios]

I start by digging into the SM

ICOM IC-F5061 SERVICE MANUAL Pdf Download

View and Download Icom IC-F5061 service manual online. IC-F5061 transceiver pdf manual download. Also for: Ic-f5062, Ic-f5063.

www.manualslib.com

If I recall L was detect and K was discriminator audio... both would be rx stuff.

 

[ramal121]

Yes, K & L are disc audio.

 

[g8tzl2004]

Thanks very much for the "coffee bean" pad info...you would think that it would have been in the service manual!!

I guess "cutting K and soldering L" (Detected audio) is not the reason the F5061 is not TXing when the mic PTT is pressed...but the radio does TX when I link pins 19 (EPTT) and 14 (GND) on the rear DB25 socket. Maybe the TX/RX switching circuit is faulty?

What is the reason for cutting K and soldering L - what application is it done for??

 

[jeepsandradios]

Did you not read the document ?

Coffee beans “K” Close When cut, this isolates the audio processor’s demodulator output (pin 18 of IC2) from discriminator signals (DISC) on the J1 option connector. Coffee beans “L” Open When connected, this routes detector output signals (DET) to discriminator signals (DISC) on the J1 option connector.

Cant have both using same pin. Its one or the either.

 

[g8tzl2004]

But what reason would I do the above? Why would I want to isolate the audio processor’s demodulator output from discriminator signals and route detector output signals to discriminator signals??

Is it done to decode something?

 

[jeepsandradios]

Its two different use cases. One is discriminator audio. One is a Detector circuit. If you look at the diagram in the manual you will see it. There are hundreds of uses for these option cables. All depends on what the user was setting it up for.

 

[g8tzl2004]

The DB25 pin assignments says that pin 9 is "Detected Audio" if you cut K and solder L.

It appears that cutting K and soldering L at the same time creates a single use "Detected Audio" option??

Any idea of a typical use for "Detected Audio"? The 5061 was an ex-ambulance radio I think.

Does cutting K and soldering L affect normal operation if I am not using any external devices?

 

[fontanei]

Thanks very much for the "coffee bean" pad info...you would think that it would have been in the service manual!!

I guess "cutting K and soldering L" (Detected audio) is not the reason the F5061 is not TXing when the mic PTT is pressed...but the radio does TX when I link pins 19 (EPTT) and 14 (GND) on the rear DB25 socket. Maybe the TX/RX switching circuit is faulty?

What is the reason for cutting K and soldering L - what application is it done for??

If I recall correctly, there is an option to enable/disable eptt. I can't recall if there was an option to disable local ptt as well. I believe it was the last tab on the left....I can't even recall the tab name. :/

Can you post the 'codeplug'/ .icf file somewhere?

***ALSO: If the radio was an ambulance radio, it might've been used exclusively to RX/TX data....I'm assuming it was used as a modem for 'an onboard laptop' where they can see a call's details.

 

[g8tzl2004]

I think the radio was originally TXing using the RJ45 PTT when I did a brief test using the original .icf frequencies. The radio was running very early v1.0 firmware.

I saved the original .icf but uploaded a "similar" .icf from an identical v1.2 firmware radio to save having to input all the frequencies again. The .icf uploaded OK but the radio immediately started TXing (red LED) but there was a 30sec TX timeout so the radio defaulted to RX after 30 seconds. I assumed that I had corrupted the eeprom? I was unable to write back the original .icf file as there was no comms. I then installed v5.5 firmware...but it took 3 attempts...there was an error after about 1% and 72% but was successful on the third attempt...or at least it was reported as successful.

Maybe there is still some corruption in the eeprom?? Maybe I should try installing v5.5 firmware again??

I have tried writing the original .icf and then a new default .icf...so I'm sure the RJ45 PTT has not been disabled in software. There is also no other "coffee bean" pad soldered or cut except K and L.

I also experimented with the "Maker Reserve" option and was able to recover the original alignment and hidden data from the original .icf when I uploaded a new default .icf...but still no TX...although it was useful to learn about the Maker Reserve option and having to always read the radio BEFORE enabling Maker Reserve otherwise all the alignment and hidden data is lost.

I'm still wondering whether the eeprom is corrupted (or faulty) even though a successful write was reported on the third attempt.

As the radio was originally running v1.0 firmware, maybe some hardware mod is required to run later firmware?? (unlikely)..or maybe the RJ45 PTT TX/RX switching circuit has failed?? Maybe I should try installing the original v1.0 firmware...but I don't have a copy.

I installed v5.5 firmware...but I think there is a v5.8...so maybe I should try installing that?

Maybe jumping from v1.0 to v5.5 firmware can cause issues...with my Moto stuff its often recommended to update big firmware jumps in stages??