Repository navigation
Conversation
|
Commented-out parts marked with CFIXME. |
introduced add_cluster_text() and add_other_text() for the specific use cases. also changed argument of bm_add() and send_lan_message() to 'const char *'
|
The logic for forwarding cluster messages to LAN nodes is as follows:
Note1: upon receiving a CLUSTERMSG, a node stops transmitting further Note2: manually generated cluster spots follow the standard cluster data path: The previous implementation relied on the global |
|
Now TLF starts up with the new cluster thread, spots are shown on the band map. |
also always init cluster queues, even if cluster is not explicitly configured, as there could be traffic coming via LAN
reason: now all cluster messages are passed via rx_queue, the direct injection using addtext() has been removed. so rx_queue has to be checked, even if (local) cluster is not configured.
was clearing one record too much
use symbolic FILTER_x constants in getclusterinfo() streamline cluster display code
|
Reworking the interface is really an appreciated and needed step. Some comments as a start:
It would be good besides :info to get a quick information during startup if the cluster gets connected.
Strongly supported.
|
|
Please check if the logging in into your cluster (I assume via telnet) works now. |
|
Checked with 4 different clusters. I does not work for any of it - neither with the added \n nor without. It seems that all 4 clusters give me a 'login:' text without a following '\n' or '\r' and waits for the callsign. After some time without getting a response the connection gets closed and TLF starts tries it again. So maybe we have to wait for the 'login:' before sending out call. |
|
Interesting. Could you please try this cluster, just to rule out any local issue: It works for me, even with just \r line ending. The code now doesn't wait for login. It sends user name right in the first iteration. Normally this means after a read of up to READ_SIZE (1k) bytes. I could add a bit of logic to ensure that this read was actually done and some time (~half sec) has elapsed since then. |
That works without problems.
Seems the different cluster versions out there behave differently. My failing test are with the following clusters: dxc.pi4cc.nl All on port 8000. Maybe we should have a look into the old code how they handled the login process. |
|
ok, was sending just CR out of CR+LF, fixed. I was able to see the issue with some .de clusters and it is now resolved. |
|
That was the problem, nice :-). Works fine now with all clusters tested. |
|
Glad to hear it worked. Startup is now instantaneous, and the connection is established in the cluster thread. There’s no explicit notification of whether the connection succeeded or what the error was; that was also the case before, but now at least :INFo gives some indication of the connection state. We could add a basic connection-error notification by checking the cluster state in the background process, similarly to the “Fldigi: lost connection!” warning. I’m not sure it would add much value, though. No new spots is a fairly clear indirect indication that something has gone wrong. I just realized that atomics have been used in audio.c since #317, when the VK thread was introduced. GCC has supported C11 for about ten years, so we could add a check, but it probably isn’t worth it. In fact, we could also check other uses of atomics, since other variables are also shared between the threads. I’m still working on the cluster-terminal concept. We’ll see how it goes. |
probably this check guards against line noise; not what one sees on a tcp connection...
In case of no radio control frequencies show actually bands. This works for other nodes, but own frequency was not converted to Hz units and thus when scaling to kHz the result was 0.
before it was: clearing all node lines and then writing freq now: for each node clearing and writing freq
|
The new cluster terminal is available the same way as the old one: type :PACket or simply : (colon). To return to the log, press Esc or type any command beginning with :. |
…splay mode Setting the filter to "ALL" before enabling cluster display mode defeats the purpose of the filter.
The motivations for reworking the cluster interface are:
I decided it was easier to just rewrite the code than to try and untangle the mess of UI and backend logic, especially since most of the current code is just dead and isn't even being used.
particularly when accidentally entered it by typing a colon in the call input field.
The new design moves cluster handling to its own dedicated thread.
To ensure no UI actions occur within this thread, communication with the rest of the TLF (main and background threads) is performed via thread-safe queues. The main RX queue is fed with lines read from the network, serial, or FIFO device, while a similar TX queue is used for sending messages into the cluster.
The tasks of the cluster thread are to:
Cluster-related features like band map or spotting are not affected.
Current cluster information is shown on :INFo screen.
I've been using the code locally for several months, but there may still be some rough edges.
These will be addressed along the way.
Starting with a quick cleanup of an unused define. After this, I'll remove
splitscreen.candsockserv.cand begin incrementally rebuilding the functionality.