Thank Rein - good to know it's not a bug. I may not like this feature, but that's hardly important in the big scheme of things! I think I can live with it ;-)
Thanks again for the quick reply. Steve. On 01/31/2010 01:54 PM, Rein Couperus wrote:
This is a feature. The normal case should be NO rxID, NO txID, so your client will not be mode switched when somebody sends a txID, and will not mode switch other clients which are standby on the channel. Normal case means the client uses the default mode of the servers, so it can receive APRS messages and beacons. That is also why the client is regularly (once per minute) returned to the default mode (the mode set in the Mode menu) used on the channel. The client uses txID ON when sending a link request, a connect request or a manual beacon. As soon as the link request or beacon is acknowledged by the server, the txID is reset to OFF. As soon as a connect request is acknowledged by the server txID on the client goes OFF, and rxID goes ON so the server can control mode switching of the client. Reason for all this is that we don't want wild mode switching on the channel, creating massive chaos. Mode switching should be ON during a connected session, in this case the channel is busy for everybody else. Here in EU we have at least 3 servers on the same channel, so this is the behaviour creating the least havoc.... On the server, rxID should be ON in stand-by, txID should be OFF. The servers listen for txID, so a client can start a connection in a slower mode. As soon as the session is open, rxID on the server must go OFF and txID on the server must only go ON to request a mode change. All this is still in alpha status, being tested. On the PI4TUE all this works fine most of the time, but it is very well possible there are still quirks... Hope this brings some light to the matter... 73, Rein PA0RMaybe I'm getting bugs mixed up with design features, but I notice that if I have the client FLDigi set to TxID and then do a manual beacon, it will clear the client TxID and not restore it. Surely that can't be good, can it? Steve (VK2ZSZ)
