开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. Winfldigi
  2. Topics

Multiple instance question

 

开云体育

Hi Dave,

A group of us are testing various ways to use multiple instances of fldigi (current alpha version) that include some automatic modes.

I have "discovered" that if I run 2 fldigi instances in the following manner there is potential for a "key up collision" that leaves the connections confused:

IC-7300 - dial freq 7.1025MHz
fldigi (instance 1) THOR22 @ 2000Hz
fldigi (instance 2) FSQ @1500Hz Beacon enabled
flrig 1 instance controlling transceiver - both fldigi instances using it

THOR22 is being used as data channel for FSQ network works well and is stable. PSM is engaged.

I added in an APRS client (PinPoint) by? TCP/IP connection to fldigi instance 1. THOR22 is used as the transport layer for the APRS packet.

If FSQ sounds and the APRS client beacons concurrently the transmit attempts to overlap. While sound is generated concurrently, the extra overlapping commands confuse the transceiver and flrig. Unpredictable things begin to happen during the transmission. This is not surprising. I have tried force the "collision" without PSM engaged and I get the same result.

Now, I had innocently hoped that the fldigi PSM function included a way to sense and inform flrig of the second concurrent transmit request and tell the other fldigi instance to wait until after the first sound or beacon had completed. The PSM settings would determine the wait time before the second transmission request is made. Rather obviously that is not the case.

Is such a "arbiter function" possible? How difficult would that function be to code? My C coding skills are to rudimentary and too rusty for me to even contemplate doing that with the flrig and fldigi code.

To simplify the use case: Looking for a way for a single instance of flrig to signal multiple instances of fldigi using it that the transceiver is in TX mode already and to wait until after the transmission is done before sending the next TX request.

The response would be similar to the squelch function and PSM. Thanks in advance for thinking through my inquiry with me and hope it made sens.

Jack Spitznagel
KD4IZ FM19oo
Parkton, MD
 

Hi Jack,

Your request does make sense, and you are the first one to request this type of function.? I'll look at code changes (probably all in fldigi).

David


On Wed, Jan 22, 2025 at 12:30?PM Jack Spitznagel (KD4IZ) via <kd4iz=[email protected]> wrote:
Hi Dave,

A group of us are testing various ways to use multiple instances of fldigi (current alpha version) that include some automatic modes.

I have "discovered" that if I run 2 fldigi instances in the following manner there is potential for a "key up collision" that leaves the connections confused:

IC-7300 - dial freq 7.1025MHz
fldigi (instance 1) THOR22 @ 2000Hz
fldigi (instance 2) FSQ @1500Hz Beacon enabled
flrig 1 instance controlling transceiver - both fldigi instances using it

THOR22 is being used as data channel for FSQ network works well and is stable. PSM is engaged.

I added in an APRS client (PinPoint) by? TCP/IP connection to fldigi instance 1. THOR22 is used as the transport layer for the APRS packet.

If FSQ sounds and the APRS client beacons concurrently the transmit attempts to overlap. While sound is generated concurrently, the extra overlapping commands confuse the transceiver and flrig. Unpredictable things begin to happen during the transmission. This is not surprising. I have tried force the "collision" without PSM engaged and I get the same result.

Now, I had innocently hoped that the fldigi PSM function included a way to sense and inform flrig of the second concurrent transmit request and tell the other fldigi instance to wait until after the first sound or beacon had completed. The PSM settings would determine the wait time before the second transmission request is made. Rather obviously that is not the case.

Is such a "arbiter function" possible? How difficult would that function be to code? My C coding skills are to rudimentary and too rusty for me to even contemplate doing that with the flrig and fldigi code.

To simplify the use case: Looking for a way for a single instance of flrig to signal multiple instances of fldigi using it that the transceiver is in TX mode already and to wait until after the transmission is done before sending the next TX request.

The response would be similar to the squelch function and PSM. Thanks in advance for thinking through my inquiry with me and hope it made sens.

Jack Spitznagel
KD4IZ FM19oo
Parkton, MD
 

Dave,

Seems to me the arbitrator would be FLRIG. FLRIG would need away to determine if there is more then one instance of FLDIGI running and at that point ignore any additional transmit requests if one is already active. Audio mixing hopefully is handled by all operation systems that FLDIGI supports.

Might want to consider having a transmit/disable transmit counter that way if you receive 2 transmit requests you will wait for 2 end transmit before calling the transmit ended.

Just a few thoughts that popped in my head after reading the issue/request.

Robert
 

开云体育

Robert,
Thanks for adding in your thoughts. I would not want to see a blanket "ignore" but rather a way to say in effect "instance fldigi_2, wait and queue the transmission for sending as the current transmission is cleared by CAT command from instance fldigi_1. There might be an important "ACK" or answer lost .
73
Jack Spitznagel
KD4IZ FM19oo
Parkton, MD


On 1/23/2025 2:58 PM, Robert, KK5VD via groups.io wrote:

Dave, 

Seems to me the arbitrator would be FLRIG. FLRIG would need away to determine if there is more then one instance of FLDIGI running and at that point ignore any additional transmit requests if one is already active. Audio mixing hopefully is handled by all operation systems that FLDIGI supports.

Might want to consider having a transmit/disable transmit counter that way if you receive 2 transmit requests you will wait for 2 end transmit before calling the transmit ended.

Just a few thoughts that popped in my head after reading the issue/request.

Robert

Mike Black
 

This is known in the programming world as a mutex and could be done in fldigi using the pthread mutexes.

Mike W9MDB
 

True,

But having looked at the mode and frequency that was selected gave me the impression of concurrent transmitting. Thou that is a good idea that one might be able to enable a mutex lock/unlock using XLMRPC interface.

Robert
 

Jack,

The thing is if the transmitter is transmitting then receiving anything and missing an ACK is still going to be possible, as the other station transmitting the ACK may not be monitoring the beacon signal to know that reception isn't possible.

Robert

1 - 7 of 7