> OK, good. I'm running that code on my link now. It does not seem to be fully
> functional though. I have one link defined between two logics.
> Immediately on startup the link activates even though CONNECTMODE=ON_STARTUP
> has not been specified. I guess some initialization is missing. If I try to
> deactivate it, I'm told that the link is not active.
OK, maybe there are still some problems...as expected ;-)
> Also it's not possible to have different commands to activate the same link. If
> you for example have one 70cm repeater and one 2m repeater it would make sense
> to use the command 971 to activate the link from 2m to 70cm but using the
> command 921 if activating the link from the 70cm side. Also, if we add another
> repeater, let's say 10m, I want to use the same command activating the link to
> the 70cm repeater (971) both from the 2m and the 70cm repeater. So, I think
> the command should be associated with the logic and not with the link.
OK, for me it was not interesting from which logic the connect request
was initiated, but you're right, there should be different commands for
different linksets, e.g.:
So the command is only accepted from the "MASTERLOGIC" and ignored from
all others. An advantage is, that there could be setup a "small"
SimplexLogic from which you can control the state of all links/logics of
> The same thing is also true for the link name, really. If I have a config with
> a RepeaterLogic and then a SimplexLogic that is used to link to another
> repeater via RF, the two sides may have different names. When activating the
> link from one side we would like to announce the callsign of the other
> repeater ("Activating link to SK3GK/R" if we are on SK3GW/R).
> I think it should be possible to specify if the link should be default active
> or default inactive. This is of most use together with a timeout. If the link
> is default inactive, it should automatically deactivate after the timeout. If
> the link is default active, it should automatically activate after the
I think it could be done with the CONNECT_MODE and TIMEOUT params, e.g.:
-> the link is established when SvxLink is starting up for 100 seconds
or as long as communication take place, then the connections between the
logics are being diconnected
-> after startup the logics are disconnected, if somebody sends the
connect command, the logics are being connected for TIMEOUT, then (if no
communication) they are being disconnected automatically
-> the logics are being connected when SvxLink starts up an remain
connected, no disconnect possible
-> the logics are disconnected after SvxLink startup, if somebody sends
the connect command, the logics are being connected and remain connected
until SvxLink stops
-> the logics will being connected during SvxLink startup and remain
connected. If somebody sends the disconnect command, the links are being
disconnected for TIMEOUT and then being reconnected automatically
-> no idea, like TIMEOUT=100 ??
I hope I didn't forget anything...it's a bit confusing ;-)
> On top of that we need to handle stuff like automatically activating
> connections between logics where the links partly overlap. Let's say we have
> 10m, 2m and 70cm repeater logics configured. We then have three different links
> defined 10m<->2m, 10m<->70cm, 2m<->70cm. Now, if we first activate the 2m<->70cm
> link and then someone activates the 10m<->2m link, we must also make sure
> sound is flowing between the 10m and the 70cm repeater. We should not activate
> the 10m<->70cm link but rather just connect the two logics in the audio switch
> matrix, if you see the difference. If then the 10m<->2m link is deactivated we
> must remember to also disconnect the audio between the 10m and the 70cm
> We may also have link definitions that overlap. We may have the link definitions
> mentioned above and then a link definition that connect all logics at once. If
> for example the 2m<->70cm link is active and then the "connect all links" link
> is activated and then deactivated, we must remember to keep the 2m and 70cm
> logics connected.
> The easiest way to solve the two problems above is probably to go through all
> links every time something changes (a link is activated or deactivated) and
> decide which connections that should be active.
I think we can store all active connections in a map of <int,struct>,
and the struct contains a set of further information like
"id=1" -> ["Logic_1","Rx1","Tx2"]
"id=2" -> ["Logic_1","Rx2","Tx1"]
"id=3" -> ["Logic_2","Rx1","Tx2"]
"id=4" -> ["Logic_2","Rx1","Tx3"]
"id=5" -> ["Logic_2","Rx2","Tx2"]
"id=6" -> ["Logic_2","Rx2","Tx3"]
"id=7" -> ["Logic_2","Rx2","Tx4"]
"id=8" -> ["system1","Rx1","Tx2"]
"id=9" -> ["system1","Rx2","Tx3"]
If a disconnect command was received on "Logic_1", we scan the entries
and if it finds an entry where the logicname is different from the
origin ("Logic_1") and the audio_paths are identical then the disconnect
action isn't conducted.
For the previous example it means that only the connection with id=2
between Rx2 and Tx1 will being disassociated because there is an
existing connection from "system" (id=8) and "Logic_2" (id=3). The entry
with id=2 will being removed from the set when disconnected. The
"system1" means system triggered connections, e.g. by external commands,
aprs, cron-actions and so on, it's a bit looking ahead.
What are you thinking about this?
> We can talk a bit more about the implementation later. It's more important to
> get the concepts straight first.
> Good ideas but I think we should first concentrate on the core switching
> system. It's hard enough to get that right even without the extra features.
Ooooh yeah ;-)
73's de Adi, DL1HRC