Repeater Controller FAQs

From Link Communications - Support

Jump to: navigation, search

Contents

[edit] Controller-Specific FAQs

[edit] Accessories FAQs

[edit] Firmware

The firmware in most of the controllers can be updated by replacing an EPROM. The controllers will usually need to be reprogrammed after such an update. Update kits typically include one or more EPROMs and a new manual and cost $75. It is also possible to update some controllers yourself at no cost, if you have an EPROM programmer. See the links below for details:

[edit] General FAQs

[edit] Q: Where can I find old versions of the firmware or manuals?

A: Many older versions can be found in the File Archive. If you need something else, please contact us.

[edit] Q: Are schematics available for your products?

A: Most of our products include the schematics in their manuals. Many others (and schematics for older hardware revisions) can be found at http://link-comm.com/ftp/schematics/.

[edit] Q: What is the latest version of the firmware for the RLC...?

A:

Controller Current Firmware Version
RLC-1 V1.01
RLC-1 Plus V2.09
RLC-2 V4.30
RLC-3 V2.15
RLC-4 V1.79
RLC-5 See RLC-5 FAQs
RLC-Club V2.15
RLC-DSP404 See RLC-DSP404 Firmware and Manuals

In general, if the firmware version you are using does what you need it to do, there is often no compelling reason to upgrade to the latest version; it may just add features that you wouldn't use. For details about what changed in each firmware version, see the readme.txt file for that version at <http://www.link-comm.com/ftp>.

[edit] Q: Is there a way to restore the repeater to factory defaults from the serial port? Or is it just the button inside of the controller cabinet?

A: We didn't make a way to do it remotely because it was a security concern, so the button is the only way (see Appendix D in the controller manual for instructions). You could try connecting one of the output lines (from the I/O connector) to the INIT button, so that you could turn on an output to simulate pressing the button, then remote reset the controller with command 035. I haven't tried that, but I am pretty sure that it would work. What I am not sure of is that it won't also cause it to reinitialize when you cycle the power, as I don't know what state the output lines come up in, or even whether they are consistent (once the software gets running, it sets them to the state you put them in last, but that happens after the check to see if it should reinitialize). If you try it, please make a note here to let the rest of us know how it worked out (and which controller you tried it with).

[edit] Q: What is think "ping pong" effect I hear about?

A: See Ping Pong Effect.

[edit] Q: How much current does each device draw?

A: The current draw of the repeater controllers can be found at the bottom of the comparison chart at <http://www.link-comm.com/controllers/compare.htm>. See the following for some other devices:

  • DVR-4 (the DVR-2 should be similar): 3.3mA when idle, 28.3mA when playing or recording.

[edit] Q: How can I program the repeater controller to control a cooling fan?

A: Maybe the first question you should ask is "SHOULD I program the repeater controller to control a cooling fan?" Consider that if lightning or something else damages the repeater controller, it could both turn on the transmitter and turn off the cooling fan. There are several other options:

  1. Leave the fans on all the time.
  2. Control the fans with a thermostat.
  3. Control the fans with the PTT line.
  4. Use a timer to make the fans continue to run for a while after the PTT drops.

Before deciding which of the options makes the most sense, consider the purpose of the fans. Obviously they should run to keep the transmitter from getting too hot, but any of the above options would accomplish that. Also, during a long continuous keydown, all of the options would run the fans continuously; if that isn't enough to keep the transmitter from overheating, you need more fans, a bigger heatsink, or less transmit power. The differences between the options determine whether the fans run as the transmitter warms up and as it cools down:

  • Options 1, 3 and 4 would cause the fans to run as the transmitter warms up (as it is transmitting), while option 2 would wait to turn the fans on until the transmitter is warm.
  • Between transmissions, options 1, 4 and sometimes 2 will cause the fans to run for at least a while, cooling the transmitter back down quickly.

Now back to the purpose of the fans. If their purpose is to keep the transmitter as cool as possible at all times, option 1 or 4 would be the best. On the other hand, if the fans can keep the transmitter from overheating while minimizing the temperature swings, it will reduce the wear on the solder joints, transistors and other components that may eventually crack from the expansion and contraction caused by many temperature cycles. To minimize the temperature swings, the fans should try to keep the temperature from climbing when the transmitter is first keyed up (anything but option 2) and let it say warm as long as possible when not transmitting. That may not seem intuitive, but consider this: if the transmitter is keyed long enough to get hot (to the point where the temperature stabilizes with the fans running), then is idle for a while, then gets keyed up again, there isn't any advantage to cooling it off in the meantime (assuming the fans can keep it from overheating during continuous transmit). It will cause the least temperature change if the fans turn off as soon as the transmitter does.

So consider option 3, controlling the fans with the PTT line. Besides minimizing wear on the transmitter caused by thermal cycles, it is simple to do (doesn't require any extra I/O lines, thermostats, timers or controller programming) and if something did damage the controller and cause the PTT line to stick on, the fan would automatically stay on too.

Other thoughts:

[edit] Why does the first word or two get cut off?

A: When talking through a repeater, you may notice that some users' first word or two gets cut off. Obviously they can avoid the problem by waiting a bit after keying their radio before talking, but it is hard to train people to do that. There are at least three places where the first word or two can be lost:

  1. In the user's own radio (they start talking before their radio starts transmitting).
  2. In the repeater (receiver, controller, transmitter).
  3. In the listener's radio.

If the problem is #1 above, there is nothing that can be done except training that user to wait a bit after keying up. You can determine if this is the problem by monitoring that user on a simplex frequency or on the repeater's input frequency with your radio set for carrier (not tone) squelch. If you can't hear their first word that way, this is the problem. Also, problems #2 and #3 should affect all repeater users equally, so if the problem is worse for some users than others, those users are probably the source of the problem :)

If the repeater uses PL (CTCSS), the time it takes for PL decoders to work is by far the most likely cause of the delays that cause the first word to be lost. Often, repeaters use PL only on their input (they decode PL but don't transmit it). If that is the case, the problem is almost certainly #2. Even if the repeater does encode PL, you can negate its effect by setting your radio for carrier (not tone) squelch; if the problem persists, it is probably #2.

If you have determined that the problem is #2, there are several ways to minimize how much is chopped off of the beginning of each transmission:

  • Switch to a higher PL frequency. PL decoders are relatively slow compared to the other sources of delay in a repeater. The lower the PL tone frequency, the longer it takes them to detect the tone. Tone frequencies below 100Hz are especially problematic.
  • Use a faster PL decoder. It may be possible to find a faster PL decoder, or to modify the one you have to decode the same PL tone faster. The typical tradeoff is that the faster it decodes, the more likely it is to false (think there is PL when there is not).
  • Use audio delay. If the repeater receiver sends audio to the repeater controller even when PL is not being decoded, an audio delay module installed in the repeater controller can record that audio before the PL is detected, then play it back afterward. It may not be practical to delay the audio enough to completely compensate for the PL decoder's delay (100mS to 200mS is a typical range for delay times). See Audio Delay Modules for more information about audio delay.

[edit] Why do the PTT or output lines turn on when the controller is powered off?

Some of the controllers use an output driver chip for the PTT and/or user I/O output lines (RLC-4, RLC-3 I/O boards) while others use a 2n7000 MOSFET. The ones that use a UDN2596 or UDN2597 output driver may pull the PTT or output lines to ground when the controller is powered off. That is because those chips include a diode clamp to the 12V power supply that is used to protect them against voltage spikes.

If none of the outputs of that chip are driving relays, you can safely disable the diode clamp. To do that, pull the chip out of its socket, bend pin 10 slightly out to the side, and plug the chip back in so pin 10 goes beside the socket and doesn't make contact.

If one or more of the outputs from that chip are driving a relay, make sure that you have a diode clamp across the coil of the relay, or the inductive kickback may destroy the output driver (a diode clamp is a good idea even if pin 10 is installed normally).

[edit] Why does everything slow down if I have a serial cable connected to the controller but nothing on the other end?

One person described the symptoms on a RLC-Club like this: "When I cycle power to the CLUB controller with a serial cable connected to it (and no computer at the other end of the cable) the controller seems to go into slow motion (CW ID speed goes to about 1 WPM and the hang time extends out to a few minutes) it also ignores commands from the radio and will not answer the phone line. If I unplug the serial cable (the cable runs to another room where the computer is located) and cycle power to the controller it will boot up and work normally."

The root cause of the problem is crosstalk in the serial cable between pins 2 and 3. When a computer is connected to the other end of the cable, it drives pin 3 low when no data is being sent (or pulses it high to send data to the controller). When a computer is not connected, that line just floats, leaving it susceptible to picking up noise. The capacitive coupling between the wires in the serial cable can then weakly connect the wires together, in some cases enough that when the controller sends serial data (such as a reset or error message) that it sees at least some of that that data coming back. Since the controller can't tell that the data it receives is not from a computer, it tries to process it as commands. Sometimes those (invalid) commands cause it to print error messages which cause it to receive and process more invalid commands, which cause more error messages, causing a loop. The controller can get so busy dealing with those serial commands and sending error messages that everything else slows way down.

The easiest solution is to unplug the serial cable from the controller whenever the other end is not plugged into a computer. Alternately, something else could be plugged into the other end to keep pin 3 from floating, maybe a DB-9 connector with pins 3 and 5 (ground) connected to each other. If you don't want to have to remember to plug something in, try putting a 1K resistor between pins 3 and 5 all of the time (if that keeps serial from the computer to the controller from working, using a larger value of resistor).

Retrieved from "http://linkcomm.com/wiki/index.php?title=Repeater_Controller_FAQs"
Personal tools