MultiTx logic problem - switch ON TX but not OFF SVXLInk v1.8

[sp2ong]

We have used in our Fm Network SVXlink version 1.8 and and we are seeing a serious problem with the use of MultiTx

In many cases, after analyzing the logs, when in the same second there is "Talker start ..." and MultiTx Turning the transmitter ON and then in the same second we have "Talker stop ..." (see the sample log piece below) MutliTx will never turns off the transmitter, i.e. MultiTx does not appear ... OFF
While in the case of RepeaterLogic, when someone sends something and opens the repeater receiver, after this action MultiTx is OFF, but in the case of a Simplex Node, only the svxlink reset remains. On the other hand, no one monitors the duplex or simplex repeater 24 hours a day when hangs while transmitting, so this is a problem. This phenomenon occurs when activity comes from svxreflector.

I don't really know the code mechanism on what basis MultiTX decides to turn MutliTx off (OFF), but you can see from the logs that this phenomenon occurs when the time of the Talker start, MutliTx ON, Talker stop phenomena are in the same second (it probably differs in milliseconds, but in the log we have the same times for these 3 phenomena

If the problem could be solved, it would be very helpful for us when we use MultiTx mode

2024-05-20 21:30:10 ReflectorLogic: Talker start on TG #260: SR6AA
2024-05-20 21:30:10 MultiTx : Turning the transmitter ON
2024-05-20 21:30:10 ReflectorLogic: Talker stop on TG #260: SR6AA
2024-05-20 21:31:33 ReflectorLogic: Node left: SP2ABC
2024-05-20 21:31:52 ReflectorLogic: Node joined: SR3SN
2024-05-20 21:32:15 ReflectorLogic: Node joined: SR2SWR

In section [SimplexLogic] or [RepeaterLogic] we use

TX=MultiTx

below section MultiTx and TxUDP which is used send via UDP audio

[MultiTx]
TYPE=Multi
TRANSMITTERS=Tx1,TxUDP

[TxUDP]
TX_ID=TU
TYPE=Local
AUDIO_DEV=udp:127.0.0.1:4300
LIMITER_THRESH=-6
AUDIO_CHANNEL=0
PTT_TYPE=NONE
TIMEOUT=7200

When we switch in SimplexLogic or RepeaterLogic from TX=MultiTx to TX=Tx1, this phenomenon does not occur, so it is clear that MultiTx has a problem

Best regards Waldek

[f5vmr]

That is very odd. Of course I'm using MultiTx with Darkice streaming the repeater outputs but have no problem with it stopping when it should. I'll look more closely for clues. Chris

…

On Wed, 22 May 2024 at 18:52, Waldek ***@***.***> wrote: We have used in our Fm Network SVXlink version 1.8 and and we are seeing a serious problem with the use of MultiTx In many cases, after analyzing the logs, when in the same second there is "Talker start ..." and MultiTx Turning the transmitter ON and then in the same second we have "Talker stop ..." (see the sample log piece below) MutliTx will never turns off the transmitter, i.e. MultiTx does not appear ... OFF While in the case of RepeaterLogic, when someone sends something and opens the repeater receiver, after this action MultiTx is OFF, but in the case of a Simplex Node, only the svxlink reset remains. On the other hand, no one monitors the duplex or simplex repeater 24 hours a day when hangs while transmitting, so this is a problem. This phenomenon occurs when activity comes from svxreflector. I don't really know the code mechanism on what basis MultiTX decides to turn MutliTx off (OFF), but you can see from the logs that this phenomenon occurs when the time of the Talker start, MutliTx ON, Talker stop phenomena are in the same second (it probably differs in milliseconds, but in the log we have the same times for these 3 phenomena If the problem could be solved, it would be very helpful for us when we use MultiTx mode *2024-05-20 21:30:10 ReflectorLogic: Talker start on TG #260 <#260>: SR6AA 2024-05-20 21:30:10 MultiTx : Turning the transmitter ON 2024-05-20 21:30:10 ReflectorLogic: Talker stop on TG #260 <#260>: SR6AA 2024-05-20 21:31:33 ReflectorLogic: Node left: SP2ABC 2024-05-20 21:31:52 ReflectorLogic: Node joined: SR3SN 2024-05-20 21:32:15 ReflectorLogic: Node joined: SR2SWR* In section [SimplexLogic] or [RepeaterLogic] we use TX=MultiTx below section MultiTx and TxUDP which is used send via UDP audio [MultiTx] TYPE=Multi TRANSMITTERS=Tx1,TxUDP [TxUDP] TX_ID=TU TYPE=Local AUDIO_DEV=udp:127.0.0.1:4300 LIMITER_THRESH=-6 AUDIO_CHANNEL=0 PTT_TYPE=NONE TIMEOUT=7200 When we switch in SimplexLogic or RepeaterLogic from TX=MultiTx to TX=Tx1, this phenomenon does not occur, so it is clear that MultiTx has a problem Best regards Waldek — Reply to this email directly, view it on GitHub <#673>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAKA5DR5YL4MF45ZMYQ7I3ZDTLNJAVCNFSM6AAAAABIED5IJ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYTCMJUG43DANA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sp2ong]

Chris,

This phenomenon occurs when the activity from svxreflector is in the logs within the same second, when the Talker start, MutluTx ON and Talker stop process is spread over time, everything works correctly, but when these 3 elements are present in the same second in the log (they probably differ between are in milliseconds) MultiTx does not turn off the transmitters, the radio transmitter is especially important for us
This phenomenon does not occur on one node, but is observed on various nodes that have MltiTx on svxlink v1.8

[f5vmr]

Hi. I am using the latest core from sm0svx. This is my output and config. Is there something on the udp stream holding the tx open? I am seen nothing unusual occurring. The only thing I have is a 5-10 second buffer of the audio on darkice, but that is perfectly normal, even if annoying. I might try to configure the udp settings somehow. Chris tail -f /var/log/svxlink.log Thu May 23 08:30:00 2024: MultiTx: Turning the transmitter ON Thu May 23 08:30:04 2024: MultiTx: Turning the transmitter OFF Thu May 23 08:40:00 2024: RepeaterLogic: Sending short identification... Thu May 23 08:40:00 2024: Playing short CW ID Thu May 23 08:40:00 2024: MultiTx: Turning the transmitter ON Thu May 23 08:40:04 2024: MultiTx: Turning the transmitter OFF Thu May 23 08:50:00 2024: RepeaterLogic: Sending short identification... Thu May 23 08:50:00 2024: Playing short CW ID Thu May 23 08:50:00 2024: MultiTx: Turning the transmitter ON Thu May 23 08:50:04 2024: MultiTx: Turning the transmitter OFF [MultiTx] TYPE=Multi TRANSMITTERS=Tx1,TxStream [TxStream] TYPE=Local AUDIO_DEV=alsa:plughw:Loopback,0,2 AUDIO_CHANNEL=0 PTT_TYPE=NONE TIMEOUT=7200 TX_DELAY=0 PREEMPHASIS=0 [Tx1] TYPE=Local AUDIO_DEV=alsa:plughw:0 AUDIO_CHANNEL=0 HID_DEVICE=/dev/hidraw0 PTT_TYPE=Hidraw HID_PTT_PIN=GPIO3 PTT_HANGTIME=10 TIMEOUT=0 TX_DELAY=0 PREEMPHASIS=0

…

On 22 May 2024, at 18:52, Waldek ***@***.***> wrote: We have used in our Fm Network SVXlink version 1.8 and and we are seeing a serious problem with the use of MultiTx In many cases, after analyzing the logs, when in the same second there is "Talker start ..." and MultiTx Turning the transmitter ON and then in the same second we have "Talker stop ..." (see the sample log piece below) MutliTx will never turns off the transmitter, i.e. MultiTx does not appear ... OFF While in the case of RepeaterLogic, when someone sends something and opens the repeater receiver, after this action MultiTx is OFF, but in the case of a Simplex Node, only the svxlink reset remains. On the other hand, no one monitors the duplex or simplex repeater 24 hours a day when hangs while transmitting, so this is a problem. This phenomenon occurs when activity comes from svxreflector. I don't really know the code mechanism on what basis MultiTX decides to turn MutliTx off (OFF), but you can see from the logs that this phenomenon occurs when the time of the Talker start, MutliTx ON, Talker stop phenomena are in the same second (it probably differs in milliseconds, but in the log we have the same times for these 3 phenomena If the problem could be solved, it would be very helpful for us when we use MultiTx mode 2024-05-20 21:30:10 ReflectorLogic: Talker start on TG #260 <#260>: SR6AA 2024-05-20 21:30:10 MultiTx : Turning the transmitter ON 2024-05-20 21:30:10 ReflectorLogic: Talker stop on TG #260 <#260>: SR6AA 2024-05-20 21:31:33 ReflectorLogic: Node left: SP2ABC 2024-05-20 21:31:52 ReflectorLogic: Node joined: SR3SN 2024-05-20 21:32:15 ReflectorLogic: Node joined: SR2SWR In section [SimplexLogic] or [RepeaterLogic] we use TX=MultiTx below section MultiTx and TxUDP which is used send via UDP audio [MultiTx] TYPE=Multi TRANSMITTERS=Tx1,TxUDP [TxUDP] TX_ID=TU TYPE=Local AUDIO_DEV=udp:127.0.0.1:4300 LIMITER_THRESH=-6 AUDIO_CHANNEL=0 PTT_TYPE=NONE TIMEOUT=7200 When we switch in SimplexLogic or RepeaterLogic from TX=MultiTx to TX=Tx1, this phenomenon does not occur, so it is clear that MultiTx has a problem Best regards Waldek — Reply to this email directly, view it on GitHub <#673>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAKA5DR5YL4MF45ZMYQ7I3ZDTLNJAVCNFSM6AAAAABIED5IJ2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYTCMJUG43DANA>. You are receiving this because you are subscribed to this thread.

[sp2ong]

As I wrote, this situation with MutliTx not being turned off occurs when activity comes from svxreflector, i.e. when someone via the network makes a short Talker start and Talker stop event and they are in the log in the same second as MutliTx ON and this phenomenon with PTT blocking occurs only when such situations happen via svxreflector often.
Blocking TX for UDP is not a problem, the problem for us is that the radio transmitter is turned on and it can be so long until there is no activity after this event, i.e. MultiTx On but no Mutlitx OFF
I wouldn't write about this problem if it was an isolated incident, but we have this problem on many nodes with SVXLink v1.8
I would like to know on what basis MultiTx makes the decision to turn it off, i.e. MultiTx OFF, is it based on the lack of a network audio stream or another mechanism because something causes it to not be able to close MultiTx OFF when such a phenomenon is Talker start and talker stop (i.e. network activity from the svxrefrlector ) takes place in a short time, practically in the same second

[f5vmr]

You have probably looked already but MultiTx:state is called from ReflectorLogic.cpp only once at line 711, referring to MultiTx.cpp line 323. So if the state change is not notified then it will stay open. From my observation, MultiTx is referenced in three .cpp files only, the two above and Tx.cpp. I am only looking at the code in VScode, I do not pretend to understand it. LOL. Perhaps you can see a bug? There has been little activity on my network, so seeing any anomaly is not possible without constant observation, but I’ll look through the last 24 hours of logs. Chris

…

On 23 May 2024, at 09:12, Waldek ***@***.***> wrote: As I wrote, this situation with MutliTx not being turned off occurs when activity comes from svxreflector, i.e. when someone via the network makes a short Talker start and Talker stop event and they are in the log in the same second as MutliTx ON and this phenomenon with PTT blocking occurs only when such situations happen via svxreflector often. Blocking TX for UDP is not a problem, the problem for us is that the radio transmitter is turned on and it can be so long until there is no activity after this event, i.e. MultiTx On but no Mutlitx OFF I wouldn't write about this problem if it was an isolated incident, but we have this problem on many nodes with SVXLink v1.8 I would like to know on what basis MultiTx makes the decision to turn it off, i.e. MultiTx OFF, is it based on the lack of a network audio stream or another mechanism because something causes it to not be able to close MultiTx OFF when such a phenomenon is Talker start and talker stop (i.e. network activity from the svxrefrlector ) takes place in a short time, practically in the same second — Reply to this email directly, view it on GitHub <#673 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAKA5EECFHWSMAVEOYDZEDZDWQIJAVCNFSM6AAAAABIED5IJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRWGQ4TQMZQG4>. You are receiving this because you commented.

[sp2ong]

Yes, and I think that Tobias knows the intricacies of the code and information transfer paths so that MultiTx turns OFF if Talker sends the OFF status
You can see that this information is lost if the phenomenon is correct and at the same time the differences are in milliseconds and using MultiTx becomes a problem for us because it blocks radio transmitters and may be blocked for different time periods.

[f5vmr]

I went back through the logs over the past week and found no incorrect issues of the phenomenon. I have a couple of Swedish stations that connect on a regular basis, and their activity has not caused a failure in the MultiTx Stop. Chris

…

On 23 May 2024, at 09:41, Waldek ***@***.***> wrote: Yes, and I think that Tobias knows the intricacies of the code and information transfer paths so that MultiTx turns OFF if Talker sends the OFF status You can see that this information is lost if the phenomenon is correct and at the same time the differences are in milliseconds and using MultiTx becomes a problem for us because it blocks radio transmitters and may be blocked for different time periods. — Reply to this email directly, view it on GitHub <#673 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAKA5BX6FVDOHQGVF2CZQ3ZDWTSBAVCNFSM6AAAAABIED5IJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRWGU2TGMRSHE>. You are receiving this because you commented.

[sp2ong]

Chirs will write again

This phenomenon occurs when (look at time and seconds) it is in the same second

2024-05-20 21:30:10 ReflectorLogic: Talker start on TG #260: SR6AA
2024-05-20 21:30:10 MultiTx : Turning the transmitter ON
2024-05-20 21:30:10 ReflectorLogic: Talker stop on TG #260: SR6AA

if after this you have some activity, there is no problem, but when after this phenomenon there is no activity from the svxreflector, there is no MultiTX OFF, if there is no activity for 20 minutes, then there will be PTT ON on the transmitter for 20 minutes

73 Waldek

[sp2ong]

If it was a single phenomenon and on one node, I wouldn't write about it, but since we have this problem on many nodes, it is a repeatable phenomenon when we have Talker start, MultiTx ON, Talker stop from the svxreflector in the same second

[f5vmr]

I’m not sure whether or not this may be relevant, but VSCode detects an error in ReflectorMsg.h in both the sm0svx and the dl1hrc/svxlink_usrp models.  This suggests that prior to compilation the path of these two files may not have been correctly incorporated. The location of these two files in the relevant fields is absent but should include src/async/core but doesn’t. Then again, VSCode may be showing a non-existent anomaly. What do I know? Chris

…

On 23 May 2024, at 10:23, Waldek ***@***.***> wrote: If it was a single phenomenon and on one node, I wouldn't write about it, but since we have this problem on many nodes, it is a repeatable phenomenon when we have Talker start, MultiTx ON, Talker stop from the svxreflector in the same second — Reply to this email directly, view it on GitHub <#673 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAKA5EYDBUUVU4MJBQZISLZDWYPVAVCNFSM6AAAAABIED5IJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRWGYZTQNZWG4>. You are receiving this because you commented.

[sp2ong]

Hm
Reading this file

/**
@brief	 Talker stop TCP network message V1
@author  Tobias Blomberg / SM0SVX
@date    2017-02-12

This message is sent by the server to the clients to inform about that the
specified node has stopped talking. Note that audio packets may be received
even after this message has been received. It should be used for informational
purposes only.

It turns out that the "Talker stop" message is not an element used to disable PTT, so there is something else in the code that causes the transmitter to turn on and off sequence to fail to properly close in this situation.

[f5vmr]

Hi again Interesting to note the ReflectorMsg.h contains everything relevant to the issue, including Tx:state and MultiTx:state both emanating from Class MsgTxStatus in this file including asyncMsg….. I’m not sure if VSCode is giving a false flag As the more I click on .h and .cpp files, the more VSCode reports # include errors in the recompilation files, so I am inclined to ignore them, as Tobias must have first class knowledge in this regard. However further observation of the code indicates that MultiTx on its own does not call the function ‘do_transmit' which is a boolean variable ‘ON’ and ‘OFF', but LocalTx and NetTx do. I cannot see a cross correlation between these variables in ReflectorMsg.h that derives the messages for the log. If there is a problem, I am far from qualified to see it. Best of luck. Chris

…

On 23 May 2024, at 11:26, Waldek ***@***.***> wrote: Hm Reading this file /** @brief Talker stop TCP network message V1 @author Tobias Blomberg / SM0SVX @Date 2017-02-12 This message is sent by the server to the clients to inform about that the specified node has stopped talking. Note that audio packets may be received even after this message has been received. It should be used for informational purposes only. It turns out that the "Talker stop" message is not an element used to disable PTT, so there is something else in the code that causes the transmitter to turn on and off sequence to fail to properly close in this situation. — Reply to this email directly, view it on GitHub <#673 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAKA5HH56DRMKIPZJPMO7TZDW75DAVCNFSM6AAAAABIED5IJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRWG42TQMBTGM>. You are receiving this because you commented.

[sp2ong]

It seems that this is something related to the use of MultiTx logic, because when SimplexLogic or RepeaterLogic turns instead of MutliTx, we will only use Tx1, which is the PTT for the radio transmitter, these problems do not occur in the situations described in the previous posts

[sm3sgp]

This issue might be resolved now. Eric AE0JE reported a similar issue on the groups.io mailing list, and found a connection to low voltage warnings on his node. The soundcard disconnected/connected but SvxLink did not reopen the device after this.
Please test the latest master if the problem is gone. On my node, I am able to remove the USB soundcard and reattach, and SvxLink works as normal again.