SteveShannon

From this page: https://www.miklor.com/UV82/UV82-MenuDef.php R-TONE Repeater Tone - Used to activate those repeaters requiring a specific audible tone to be transmitted for access. - Sending tone requires first pressing the PTT, then pressing the [F] key. This is not to be confused with a sub-audible CTCSS or DCS code.

It looks like they used the RT97 image.

Are there any lights that light up to indicate power? I assume you checked the fuses in the power cable and that the power cable is connected correctly polarity wise. Also, there is an internal fuse (page 19 of the service manual), password protection, and there’s an “ignition sense” option that turns on the radio when it senses that your car is started. Good luck. Here’s the operator manual: Here’s the service manual (you’ll have to do the whole Captcha thing):

Nice. Yes, you probably could run it once a day as a cron. If the pi is never restarted and if rc.updatenodelist just runs and sleeps then eventually you’ll have the same problem, but it may take nearly two years! The real question I have is if rc.updatenoelist runs to completion and breaks out of its loop or if it continues running. If it exits eventually then it shouldn’t be gobbling up memory and you could run it as a cron more frequently. It was only because you had like 544 instances running and sleeping that you had problems (that’s what I think anyway).

I don’t think anything is wrong. You shouldn’t expect a handheld radio not to have its receiver circuitry overwhelmed by a high power transmitter nearby.

That seems like the best or at least only thing to do to keep from chewing through memory. Do any instances of rc.updatenodelist run at all? Are there any sleeping? I think I read somewhere that a module called “dial” might call it once. Is it possible there’s a problem in the extnodefile itself?

Remove the antenna on your handheld. Does it still happen? Is the case correctly assembled to the repeater? What about the duplexer? Cables? I suspect your handheld is just not very good at rejecting interference from the repeater. Typically you’d never use a handheld in the same room as a repeater.

Is there a transmit LED or display on the repeater (or even a wattmeter on the output) that indicates when the transmitter is transmitting? Does it stop if you power down the repeater? (I know that probably sounds like a dumb question and maybe it is. )

Help me understand the proximities involved and the exact nature of your concern. When you’re in the same room as the repeater with one of your handhelds, no matter what channel you tune the handheld to you hear whatever the repeater transmits. Also, using an identical handheld, when you go farther away from the repeater the handheld only hears the repeater on the correct channel. Is that a correct description?

Thanks!

Also, DCS is what most companies call it. DPL is just what Motorola calls theirs.

Are you sure you haven’t changed anything in the code? In particular look at the post immediately above your first post where WRLJ719 talks about the call to rc.updatenodelist. Also, his post appears to have a misspelling “rc.updatenodeist” rather than “rc.updatenodelist”. Nothing makes a person more aware of spelling than programming. It looks like cron is spawning new instances of “rc.updatenodelist” which runs and then goes to sleep, over and over and over, each time eating up valuable resources until there are none left. I suspect either rc.updatenodelist needs to exit gracefully, rather than sleeping, or something needs to be fixed in crontab. I doubt it needs to run very frequently anyway, but it should exit each time. That link to the stackoverflow question that I pasted above has other suggestions for diagnosis. You probably do have the 3b+ but that shouldn’t matter. So, look at where you were when you followed this instruction: ”Change your crontab -e to run rc.updatenodelist” and make sure you did it correctly and that you included the asterisk as pointed out by WRLJ719.

My rule on metal roofs is to get on them as seldom as possible and to rope off if the pitch is uncomfortable. At that height, and running the cable the way you have to you’re possibly going to lose a lot of signal just in the coax. Be sure to use the best coax you can. Here’s a website that has several charts showing coax losses. Be sure to look at the 450 MHz values: https://www.w4rp.com/ref/coax.html Second, I’m not sure that either of those antennas will get you the performance you might hope. Try putting that mag mount with either Nagoya onto a metal pie plate on a painters pole out in your yard first, or even on the roof of your car. Does it work well enough? If so, then maybe get on the roof. If it doesn’t work then you’ve saved yourself a trip.

I was wrong to focus on problems like shorts or opens. KAF6045 is correct. With RG58 you lose half of your power every thirty feet. Sometimes you can up for that by placing a decent quality antenna up in the air, but with a bad antenna, a bad cable, or a weak signal lack of quality will really bite you. Borrowing a VNA from someone can tell you if you have the kind of problem I was overly fixated on before (opens and shorts), but won’t tell you if your antenna has lousy performance. If an HT with a Nagoya has good performance but an antenna up in the air doesn’t you have every right to be suspicious of both the antenna and the cable. I’ll include a link to a website with performance charts for various cables. Be sure to look at the frequency you’re using. The closest frequency will probably be 450 MHz. Because GMRS is slightly higher, the losses through cable at GMRS frequencies will be even worse, but not a lot. Every 3dB loss means half of the remaining power, so 10.6 dB loss costs about 90% of the power. That’s for 100 feet. At 35 feet you lose over 3.7 dB so you probably lose 55% of the signal each direction. That’s substantial and enough to make it difficult to know if the antenna works or not. Of course everything adds up. It helps to start with something you know works and then try one thing at a time to see where you can get some improvements. Coax losses site I mentioned: https://www.w4rp.com/ref/coax.html

Welcome!!

You really can rule out almost everything by swapping things out. It’s a quick and easy way to troubleshoot.

If there’s actually something wrong with it, such as a short between the center conductor and the shield, yes. Or if the center conductor is broken or disconnected from the radio or antenna. Those kinds of problems can be present in the antenna as well. Try a different cable.

Try different things to see what works. For instance, put it near the steel patio roof.

That’s great news! Thanks for the update. Steve

I have a friend who is on that system and who has good results.

Gps could also be used at each receiver to time tag signals as received, which could then be used to ensure the comparator is comparing synchronized portions.

Marc, I’m sure you have already seen this but maybe it will help provide background. This is from repeater-builder: “A good voting system is completely transparent when it's working properly - you can't tell it's there except by the superior coverage. Obviously the voter has to be voting identical simultaneous signals, which is why using VOIP (voice over IP, a.k.a. the Internet) as a link to bring in the audio from one or more outlying receive sites usually does not work - there is too much delay and jitter, causing the voter at one instant to be voting the noise between two words on channel one and voting the middle of the previous word on channel two. Manually adding a fixed delay to the one receiver in an IP network does not work either, as the per-path internet packet switching delay is not consistent, even within one transmission, and definitely not from one transmission to the next. Note that there is a lot of incentive to "fix" this characteristic, and a revision of this paragraph may be needed at some point as the technology advances.”

A memory leak like that will eventually cause a stack overflow no matter how much memory you have. The stackoverflow forum link I posted has some suggestions for how you can see what processes are being forked and never exit or killed. Then you (or a programmer if you’re not) will have to figure out why those calls aren’t exiting freeing up their memory. Things to look for are incursion (when a function calls itself), or calling cron from within a loop. Since cron seems to be at the heart of this issue that’s what I would start with. Cron is a scheduler. It only needs to be called once for each scheduled task or fork. It typically shouldn’t be called over and over with the same parameters unless you kill it before calling it. (Which would be sloppy coding!) So, check and see which processes are running. If you have a whole bunch of some dig into why. Good luck, Steve

Thanks! I appreciate the help.