开云体育

Responses embedded into your reply....?? I will prefix my new comments with the word "Comment:", because I'm not sure how my reply here to you will appear at your end.

?

Hello Stan,

?

I think it is correct that what I want to use is called "connected" mode, using standard packet, but I have only a fuzzy fundamental mental picture of what all that entails.

Ok.

To reword my objective, now that I have a wee bit more understanding, I think what I want to work toward getting set up is a small network of nodes, which would only be active when deployed during an ARES event.? This network of nodes would be like what was apparently very common back in the 90's, in that an originating station would connect to a node, then tell that node to connect to yet another node, etc, and finally telling the last node to connect to a specific end station.

Ok.. so during your activation, you'd like to have station-A use a CONNECTED session back to net control.? That will work fine and even have lots of other stations such as station-b, station-c, station-d, etc all connected back to net control simultaneously assuming they have strong signals and they aren't sending too much traffic all at the same time.? The best thing about connected mode is that you are ensured either the traffic will get to net control or the session will be torn down due to too many retries.? They are also near real time communications.

So, to get started on all this, we might use an old laptop computer, with a USB sound card, and an old 2M mobile.? This arrangement would be set up with whatever software is needed to make it into a "node".? Then that whole thing be duplicated with yet another laptop, sound card, and 2M mobile as a second "node".?

With these nodes now set up, yet another laptop, sound card, and 2M mobile would then be set up as just an operator's station.? And this is the arrangement that the more technical fellows would assist the rank-and-file members in setting up and using whatever they already have, while the more technical fellows would set up and maintain the "nodes".

Ok.. that will work perfectly fine and Direwolf can do this.? At it's minimum design, you would need TWO computers:? One for net control and one for a leaf-node - Station-A.

After some time has passed using this arrangement, whereby several rank-and-file members are comfortable using such network, we might move up another small step and set up those nodes to be PBBS stations (or PBBS nodes, if that is more correct terminology).

Yup.. this would be an easy addition depending on what hardware/software you want to use.? Many nodes in my area are Kantronics KPC3 TNCs that can be a digi, a node, a netrom router, and a PBBS all at the same time.? I believe the newest Timewave PK96 TNCs can do the same.

So, if I am now making more clear statements describing the objective (and hopefully stating them more correctly), it now appears that I need to be looking for the following kind of software:

??? 1)??? Software that makes a loptop into a node, and that will interface with DireWolf.

??? ??? ?? ??? And here, hopefully, one software that runs on Linux, and another that runs on Windows.

Are the "nodes" that you'd like to use already operational or would you be deploying them in an adhoc fashion?? If these nodes are to be adhoct I know this can be done well using Linux but I'm not aware of any node software for Windows.? Some might exist but I fully expect it will be old, un-maintained from the Windows95 era and probably will NOT run on modern versionsof Windows

Before we get into the details of this specific design, I wanted to explain that there are a *few ways* to connect Station-A to Net-Control.? It all depends on how far apart your nodes are and their reachability:

?? - Simplex : the two stations can clearly hear each other and can pass traffic w/o using any other hops in between.? This is by far the fastest and most efficient way but usually requires the stations to have line of sight to each other

?? - Digipeaters: two stations *cannot* hear each other but they can hear a digipeater in between.? In this scenario, packets are duplicated at the digi and it works well but any retries that are required have to be created from the end-points.? Packet connections using digipeaters start to experience high retry counts, failures, et.c after about three digipeater hops due to the retry issue

?? - Nodes : two stations *cannot* hear each other but they can hear a node in between.? In this scenario, Station-A manually logs into a node and manually initiates a connection to net control.? Though manual to setup the connection, all retries are isolated to the two links (station-a to node, and node to net control).? At that point, the node be be responsible for doing part of the retries when required.? This is a more reliable connection for long distance, multi-hop connections (100s of miles).? On a Kantronics KPC3, they call this a KaNet node.? On Linux, I would recommend to use the URONode program.

?? - Netrom / ROSE / Xnet network :? two stations *cannot* hear each other but they can hear a routing node in between.? In this scenario, Station-A either manually logs into local node or initiates a NETROM, ROSE, or Xnet network connection directly to the final destination *regardless* of how many hops away it might be.? At this point, the nearest node knows how to get to the final destination via the most reliable path.? All retries are isolated to the various network links and even if an intermediate link is torn down (say due to retries), the broken link will be automatically re-established and continue forwarding the traffic transparently to the two endpoints!? This is a more reliable connection for long distance, multi-hop connections (100s of miles) but adds additional protocol overhead to "tunnel" your traffic over the connection.? This also requires the various nodes have to periodically send network "routes" to the other nodes so they know about each other.? On a Kantronics KPC3, they call this a Knet node.? On Linux, you run a daemon to create the? Netrom, or Rose, or Xnet routing packets.? You don't necessarily need a node program like UroNode if the leaf nodes natively support the routing protocol.

??? 2)??? Software that is just a "dumb terminal" that will interface with DireWolf for the end users.

??? ??? ??? ??? And again, hopefully, one that runs on Linux and another that runs on Windows.

There isn't much "dumb terminal" software that can interface with Direwolf directly.? I think based on your use case, you should consider using better software than a dumb terminal.? If you DO want to start with a dumb terminal approach, you could try the new Direwolf 1.4 dev release (not deemed stable) that natively supports CONNECTED mode with an AGW terminal program such as Outpost's ipagwpe.exe Windows program.? It would be very basic and potentially unreliable (Direwolf 1.4 is still in development) but this would be simplest setup on the clients.?? It's also worth noting that these clients WON'T be able to do native Netrom/Rose/Xnet connections directly.? Ideas for more featureful software could include Linux's native axcall, Linpac for Linux, XPware for Windows, etc.? Other programs like the old KaGold, PackRatt, etc. won't work with Direwolf.

??? 3)??? And for maybe later on, software that makes a laptop node into a PBBS.

Using a tree analogy, you won't want the "leaf nodes" to be the center of communications as they might not be as available for others to connect to it.? This creates more traffic funnel to a specific branches and to a specific leaf station (creates network bottlenecks, single point of failure if the station becomes unavailable, etc)

And finally, on down the road, as time and resources become available, convert the nodes/PBBS's over to Raspberry Pi's

Running packet software on a laptop running Linux is 99% the same as running packet on a Raspberry Pi.? I think the Rpi units would be good for the core digi/nodes but for the leaf nodes (say Station-A, Station-B, etc), keeping them a laptop might be best as those devices have a built-in screen, keyboard, mouse etc.? You can connect a screen, keyboard, mouse, etc to a Rpi, but all that is external components which potentially makes the setups overly complicated.

For now, however, the hardware that we have to work with is some old laptops, some USB sound cards, and some older 2M rigs that we would like to assemble together to form our first packet radio network.

Please note that Direwolf (on a Raspberry Pi running Linux) isn't always compatible with all USB sound cards.? It does seem that Direwolf running on regular PCs/Laptops are more compatible.? You'll have to try it out to see if your specific soundcards work OK with Direwolf but if they aren't reliable, replacement USB sound cards are not expensive.? Roughly $7 will get you a good one - see the tested HW in the Direwolf User Guide).? Also, Windows running on old computer hardware might provide to be troublesome as there isn't as much software, it's less flexible for your currently planned use case, etc.? I would also add that you shouldn't don't run old Windows versions like Windows 2000, Windows XP.? Please only run versions of windows that get security fixes, OS patches, etc even if they aren't connected to the Internet.

There are also some old TNC's availble, but I am not familiar with what they are. However, if they could be pressed into service in a similar manner, then all the better!!

Using some of those TNCs might get you started but they also might limit your options too.? Just a few thoughts:

? - Classic TNCs only do AFSK1200 or FSK9600 modes - while more compatible, your network sounds like it will be adhoc setups.? Direwolf 1.4-DEV now offers a 2400bps QPSK mode that is 2x faster with existing radios and it initially looks to be more robust than 1200AFSK too.? That's great news but that mode won't work with your old physical TNCs.? It's all going to depend if you want speed vs legacy compatibility.? Also consider the old TNC2 TNCs from say MFJ, PacCOMM, AEA/Timewave, Kenwood, Kantronics, TNC2 + X1J firmware, etc can have differing features (PBBS, Netrom routing, chat room (talk), etc.?


Btw.. one more us-case you might want consider in a future version of your system design there:

My local ARES/RACES group used to have their weekly net checkins sent into a PBBS but it was both a single point of failure and also had scaling issues.? They moved a centralized packet BBS (several of them actually) and clients would use the Outpost for Windows message program and send messages to the net control mailbox.? The benefits of using Outpost (Windows program but can run under Wine for Linux) is it has a user friendly GUI, customizable message templates (drives consistency), archive support, etc.?? This isn't a real-time messaging system like using a CONNECTED-mode chat but it can be quite quick depending on how often the leaf-nodes poll for new messages.? The flip side of this specific design is that it's complex but it also offers a high level of redundancy once deployed properly.

I'm sure there are several other designs out there that can be considered as you come up to speed with all the basics, etc.? I would still recommend to start with your original design to become familiar with the technology, how it performs (good and bad), and see how well your larger team adopts it.

--David
KI6ZHD