Remotetx tone heard at wrong time

Hi All -

I’m setting up a couple of nodes that are linked full-time via private Ethernet network. The full-time link is accomplished through a startup_macro in rpt.conf.

From the documentation I understand that the remotetx courtesy tone is heard when you complete a Tx and your node is connected to another node in “Transceive” mode. This scenario is working fine in my tests.

When my nodes aren’t connected at all to a remote node (I remove the startup_macro), the remotetx courtesy tone is not heard, which again is expected.

What I’m confused by is if my nodes were previously connected, but the Ethernet connection is interrupted (cable unplugged, remote node powered off, etc), the status on my local node changes from “Transceive” to “Connecting”, and even though my local node isn’t actually connected to a remote node anymore, I still hear the remotetx courtesy tone.

I was hoping the remotetx courtesy tone would be an easy indicator for my users to know if the system is “working”, or if instead there’s a problem.

Is this a bug? Am I implementing it wrong? Or is this working as intended?

Thanks!

  • Trevor, N6TJL

I’m not an app_rpt coder but I think it’s working as intended. Think about being connected to two nodes and one of the connections failed. What should the tone be then? Should there me a third tone to indicate a failed connection? There are already other tones for connection the type of connection. It’s already a bit confusing.

You can use Allmon, Supermon, the lstat dtmf or the cmd line to monitor your system status.

Yes, I agree it’s already a bit confusing. I guess I was hoping that if the remotetx tone simply didn’t occur when there wasn’t a connection, it would actually be a little less confusing (and it would be more consistent with the documented function of remotetx).

I’m using Allmon to be aware of system status, but in my scenario that isn’t something that the general user can access.

I agree that it seems odd that attempting a connection is treated as connected for CTs. Someone with C programing skills and some time could modify app_rpt.c to your liking. Here’s the code.

Forgive me a bit as I poke around at the unexplained.
I do not know what is in your ‘startup macro’ and I dont know how exactly you are removing what so if you explain a little there it may be usefull to cut to the skinny.

If you have not changed the CT’s from the default, and you are not switching ‘control states’

There will always be a CT. It changes depending on if the node is stand alone without connections or not.

So I would say study them and ID them in your rpt.conf file so you better understand them.
Make a backup file before you start making changes.

Also notice that other functions rely on telemetry
from rpt.conf
[telemetry29285]
ct1=|t(350,0,100,2048)(500,0,100,2048)(660,0,100,2048)
ct2=|t(660,880,150,2048)
ct3=|t(440,0,150,4096)
ct4=|t(550,0,150,2048)
ct5=|t(660,0,150,2048)
ct6=|t(880,0,150,2048)
ct7=|t(660,440,150,2048)
ct8=|t(700,1100,150,2048)

;As far as what the numbers mean,
;(0.0.10.0)
; | | | |-------amplitude
; | | |-----------duration
; | |--------------Tone 2
; |----------------Tone 1

;remotetx=|t(1800,100,120,3000)(1300,100,120,3000)(1750,100,120,3000)(1000,100,120,3000); Star Trek
;remotetx=|t(1173,100,120,3000)(1316,100,120,3000)(1045,100,120,3000)(523,100,120,3000)(783,100,120,3000); Close Encounters

remotetx=|t(1633,0,50,3000)(0,0,80,0)(1209,0,50,3000);
remotemon=|t(1209,0,50,2048)
cmdmode=|t(900,903,200,2048)
functcomplete=|t(1000,0,100,2048)(0,0,100,0)(1000,0,100,2048)
patchup=rpt/callproceeding
patchdown=rpt/callterminated

And these can be changed as groups with control states (see wiki)

try using *3node instead of *73node in your startup_macro then it will not keep trying to reconnect if you lose the network all nodes will have been disconnected and remotetx= won’t be played. Hearing the unlinkedct= will alert users to issue the reconnect command, there are a few choices for the reconnect.