CNRLS - Operation
Crossband Node Repeater Linking System - Operation
Here is part two of my 'White Paper' describing a repeater linking system. I have decided to break the 'Details' section into several parts. This is the description of operation. Hardware, software, locations and financing will be discussed in subsequent articles.
Upon startup each node will determine if it has a direct internet connection. If it does, it will initiate communication with the 147120.net servers, which will assign a node designation to the station. It will then tune to a frequency determined by the servers and send a 'cq' via packet radio with an announcement that it is a 'root node' with an internet connection.
If the node lacks its own internet connection, it will tune to a predetermined frequency and listen for a cq from a root node. If none is heard in a reasonable time, it will initiate its own cq via packet radio with an announcement that it needs a connection to a root node.
If a root node hears a cq, or its cq is answered from a non-root node it will accept a connection and ask for credentials. The root node will pass the credentials to the servers, which will assign a node designation for the non root node and pass it through the root node.
If a connected non root node hears an unconnected non root node call cq, it will answer the cq and announce that it is a connected non root node. If the unconnected non root node does not make a connection to a root node, it will call the connected non root node and the negotiation with the server will complete through this link.
Once the connection is established the servers will assign tasks to the nodes according to settings, schedules, conditions, activity, or many other considerations. This can be rather complex, and can provide a mountain of information if hardware is added to the nodes and telemetered data from those sensors is stored on the servers.
In any case, if a node receives multiple connection offers it will choose the strongest one at the highest level.
A server has to initialize at least once, and any time it needs to reboot. It will read a configuration file and proceed from there. On its first boot the configuration file will have been written by hand. Subsequent intentional reboots will have written a config file according to criteria determined at reboot time.
Once started the server will determine if there are any other servers running and if so, compare the configuration and determine if it is a primary or secondary server. If the server determines it is a primary server it will query existing nodes and call for any nodes not yet listed. If the server determines it is a secondary it will query the primary for the current list of nodes and verify it can communicate with them.
If a server determines it is secondary but cannot communicate with the primary, it will attempt to communicate with the nodes. It will query their current configuration and compare it with the last configuration sent to it from the primary. If the nodes' configurations are different from the previous config from the primary, the secondary will instruct the nodes to configure according to the primary's last config and take over as primary.
When the original primary comes back online it will query the existing primary, accept its current config and request to take over as primary. If there are no pending operations the existing primary will transfer any current data streams and relinquish primary control. If there are pending operations, the existing primary will instruct the original primary to standby until it has completed the operation, and relinquish control once the operation is complete. If the secondary determines that the primary has lost internet connection a predetermined number of times within a predetermined period, it will request to remain primary when the malfunctioning primary comes back online and alert the administrator.
It is acceptable to have only a primary server in a small to medium CNRLS system.
Once registered with a server the nodes will report operational status and telemetered data as well as any on the air user requests. Idle mode operations will begin immediately or when programmed.
The server will be listening for connections from root nodes but it will also be running a web server through which users and administrators can interact with the system. A series of Status panels will present current configuration and measurement data as well as historical information including recent usage modes. A series of menus will allow administrators and to a limited extent users to control the configuration of the system. Telemetered data can be queried from the database using an API. Certain data milestones can be sent to social media such as 'tweeting' details about a connection change.
On The Air
Nodes will listen for command signals via DTMF and digital control codes on predetermined frequencies. These signals will trigger the node to request operational status settings from the server. The predetermined frequencies can be looked up on the web server pages and will be announced on node frequencies depending on the current mode of operation. IE a node configured to give a simplex crossband link into the 147.120 repeater operating on 222.5 mhz might announce "147.120 crossband link listening on 222.5 mhz PL 103.5" on 147.120 mhz. The node will only initiate these announcements on an idle channel.
Data accepted by the server by any means will then be processed and signaled to the nodes for operation.
We're going to start getting into functional details soon regarding signal code formats and data packet construction. Still, it will be sudocode and not specifically tied to any given programming language although Python appears to be the direction we're going to go.