HSMM-MESH networks are different than WiFi and delivers important benefits in certain situations.

Welcome to the Field Day results section. Here we will give some real-world examples of how HSMM-MESH was used in Field Day networking. The note below and my reply to it were originally sent out on the HSMM Developers mail list.

This section is reprinted with permission from Jim Duram, K8COP. In giving his permission, Jim mentioned that he needs to include another user that he had forgotten at the time of his original post.  "Another Ham who is active in HSMM-MESH is Damon, KC7NEC.  He assisted Jim, KD8DLQ with getting the MESH up and running on FD.  He also had his MESH node with him, and deployed it within the network.  I didn't know about his help until after I sent out the message on the list."

It is very important to note that basic ham radio can-do problem solving pulled a couple of rabbits out of the hat in real time on Field Day. These guys didn't know their stuff would be needed but set it up in minutes once the need appeared.

Jim's original note is below, followed by my reply.

HSMM-MESH came through again! The guys were setting up the FD Network for the logging program on Saturday. They had tested the non-MESH network a few weeks ago and everything worked fine. They got out to the FD Site and had issues using the normal 2.4 gig system as the laptops would not stay linked to our County's Mobile Command Vehicle where the file server was located. One of our members, Jim, KD8DLQ, had two HSMM-MESH routers, AP's, and batteries with him. He set one MESH router, AP, and battery on top of our Mobile Command Post, and the other set on top of a trailer at the other end of the FD site. Within minutes the new network was configured and the laptops were talking to the file server. This quick fix generated a lot of SMILES within the group, and proved the value of HSMM-MESH!

The HSMM-MESH network has operated flawlessly the entire weekend! 

This has generated more interest in HSMM-MESH with in our county.

73's

Jim Duram, K8COP
Muskegon County EC/RO
Muskegon, MI.
www.mcecs.net

The difference represented here is actually pretty important. It goes like this: The first link to a network can either be wired (you connecting to your mesh node or switch/router with cat5 cable) or you connecting directly via WiFi. In the first case, a delay in propagation or server responce on the other end would be ok as TCP/IP behavior. We all know that hitting a web page doesn't always build a full web page. The network stack calls this a propagation delay or high server loading and life continues. If you lose the WiFi connection, you might be ok on a web browser, but will show a fault with client/server applications.

If the first link is by WiFi, the link to the remote machine is lost as the WiFi disconnects/reconnects. Even in a totally empty RF world where you have only one WiFi client and one WiFi access point and one frequency in use, you can have a periodic disconnects.  If you are using a network logging program, you are usually pointed to a network resource to post/check your logging data. This is usually set up as a mapped drive or UNC connection. If the connection to your computer is wired, there can easily be delays in propagation without having a loss of network connection. If your connection to the logging computer is WiFi, Windows will unlink the share or UNC and call it unavailable. This happens even if the WiFi reconnects itself. If data flows in a few seconds, some programs will reattach to the network resource, others won't.

The fact that a slight delay occurs as data is fetched is usually tolerated on a wired network because the application always "sees" a network resource connected on the other end.  This has siginificant importance for Emcom applications since they are generally attaching you as a client to some network resource on the other end. Your served agencies will have the same risks and the same benefits.  We saw this very clearly with N3FJP Field Day network logger. With that program and some others I have seen, you get a message on the screen that the network is unavailable. You must then define the remote logging server again to continue use. WiFi networks were an issue for the Austin Field Day the first time they were used. Hard wired stations never saw the disconnect. In later years, we turned all links into "wired" by making the first network connection a cat5 cable into the mesh node. An RF hop can easily exist in sections of the network (your mesh node)  as long as the data flows in a few seconds.

Bottom line is that wired networks (your laptop/desktop into a mesh node) are more stable with network based applications than straight WiFi connects for many types of applications. The example given below solved a Windows weakness by using HSMM-MESH networks.

73,
NG5V
Rick