AX.25 Packet Digipeaters and Scripts

Aloha and welcome, I'm WH6AZ here to bring you high signal insights about radio mail, the win-link iPhone application I created. We're going to explore packet connections with a special focus on using digipiters and scripted nodes to extend your communication range . Let's start with a basic packet connection. But what exactly do we mean by packet? In telecommunications, a packet is a blend of user data and control information. By this definition, most modern communication protocols are based on packets. In amateur radio, when we say "packet", we are actually referring to communication via the AX25 protocol. So what is AX25? It's a protocol adapted from X25, which was widely used in data network from the 70s to the 90s, especially by telecom companies. And now while TCP/IP has largely taken over, X25 is still in use in a matter radio. So let's make a connection, and its core connection involves two parties. Here we have my station WH6AZ, which will establish a packet connection to a win-link RMS station known as WH6AZ-11. Win-link operates with connected sessions, so this means that both stations first establish a link, then they swap information back and forth, and finally they disconnect. Let's watch the traffic as it goes over the airwaves. I'm about to start a session here in radio mail. And here we can monitor the traffic broadcasted over the air. We're seeing frames being exchanged, and each station call sign is visible. The exchange kicks off with SABM, command, and UR response to set up the connection. Then we see some information frame that carry the application level data, what 's often called the payload. And in this connection oriented system, each frame is acknowledged , and we can see that here with the R response. Then at the end, the session terminates with a disk command, and the UI response to indicate this connection. Okay, this covers the basics, and for the most part it's all you need to send and receive emails via packet. But sometimes they're starting enough VHF and UHF frequencies need a clear line of sight, and due to distance or tricky terrain, sometimes you're going to have an issue to reach the other station. Fortunately, we have a few options. First, let's talk about using a digipeter. A digipeter works like a voice repeater, but for packet data. It's essentially a stall on forward system that picks up the packet and retransmit them on the same frequency. This helps us because digipeter are typically placed in high location to cover a wide area, and they will catch and relay your signal. It's worth noting that digipeter is a generic term for a digital repeater, and as there are many digital protocol, a digipeter needs to really support the your specific protocol in okay, that means AX25. In AX25, digip itting is actually embedded right into layer two in the OSI model. The OSI model breaks down the various layers for communication protocol, and since X25 predates that model, sometimes the layer don't match really well, but it's still useful nevertheless. So in okay, the physical layer is where the radio connection between peers exists. It handles the raw binary transmission over the air using AFSK modulation, and then moving up the stack to the data link layer, which is where the connection between the two peers are made. It breaks up the packet into frame and send them from the source to the destination. Now let's take a look at what one of those frames look like . A frame is a basic unit of transmission and contains the data, as well as all the necessary control information. In AX25, every frame contains the source, as well as the destination call sign. There are also two optional address fields for repeaters. The address field allows up to six character for call sign, as well as an SSID, which acts as a secondary station identifier. In the SSID field, the most significant bit identified here as H in VISTable serves a special purpose. When that bit is set, it indicates that the packet has been repeated. Why is this needed? With radio, every participant can professionally hear each other, so it's important for each peer to be able to filter out frames that are either not for them, or in this case, not yet repeated. Locating the DGP reader can be a bit of a challenge, and there is no central directory, so your local matter radio club is a good place to start, or you could try searching for WinLink DGPeters. However, there are a few things to keep in mind. Usually, a packet DGPeter will transmit on the same frequency it listens to, so this needs to match the frequency of your intended destination station, your WinLink gateway. Also, don't mix up a PRS D GPeter with packet DGPeters. Even though a PRS operates on the AX25 protocol, it uses unacknow ledged frames, and it follows a broadcast approach rather than a connect and exchange method. The repeater addresses in the PRS have specific function and only relay a PRS traffic. Also, the PRS DGPeter will be set to the standard APRS frequency, which won't be useful because it's unlikely that a WinLink gateway will be set to that frequency. Often, the GPDERS utilize aliases for easy recall, so for this demonstration, I've set up a DGPeter called NSDG. It's important to note that with a DGPeter, even though the retrans mission occurs through the airwaves, from the protocol perspective, the connection remains directly between the two peers. The DGPeter acts as a relay that simply passes the data along. Let's put this into practice. Here, I've entered the DGPeter details into radio mail, and I'm going to activate it here, my call sign, NSDG. Now, let's connect. If you notice here in the traffic that the DGPeter is appearing as well as the call sign. So, we'll see here AutoStation, and then each frame is actually repeated, and the little asterisks they're not when the frame is actually fully repeated. So, everything is repeated twice, only in each direction. So, remember, the DGPeter doubles the transmission time as each packet has to be transmitted twice and increase the potential for retransmission due to error. So, for these reasons, there's a limit of a maximum of two DGPeter. Radio mail is supported DGPeter for a while now, but what happens when you want more control or you want to cross-band from VHF to UHF? This is where using nodes come into play. Nodes are like servers on the packet network. They offer very services, and you interact with them via a text interface, requiring you to send keyboard commands. Nodes can have more than one radio, and that means they can make connection on different frequencies and send and receive at the same time. I've set up such a node, and let's take a look here. At the protocol level, you 're connecting to the node directly. Once connected, you have to tell the node what to do. This differs from the DGPeter, with nodes each path segment is an actively managed connection. Since node expects specific commands and the syntax may vary as script is needed to establish a connection. And radio mail now supports scripting for this purpose. Here's how it works. First, you add a station in the station directory. I've already done that, so I'm going to edit the one I have here, and I want to reach w8-6 az-4, and here's the frequency. So let's edit. Then you can turn on now scripting for this connection. The script essentially mimics the user input command and wait for reply. So first, we instruct the script to wait for welcome new user string. Then we should command to connect the radio to the b6 az-11, which is our win-link station. And then finally, we wait for confirmation with the connected string. You can also name your script so that you can distinguish them based on what it does. In this case, it's all going to connect to the node dash 4. I want to be able to distinguish what they do. So let's disable the dg-p-ding and see what it does. Oops, I need to connect to my script. So let's pick the script here. Okay, so now you see it's connecting to the node. You're getting some different type of traffic. And what you'll notice is the exchange window on radio mail has been enhanced so that we can see a little bit more better what's going on. So the blue text is internal command in radio mail, and then in light gray, this is the information that's being received from the other station, and darker text is what we send. So if you notice here on the traffic, maybe we 'll wait until it disconnects a little bit clearer. But essentially, if we go back, we can go back. Okay, essentially, you can see here on the disconnect sequence, the blue text is making a connection or a disconnection to dash 4, which is the node dash 4 responding with a UA to disconnect. And then similarly, on dash 15, which is the other side of the node that's connecting to dash 11, which is the willing gateway, it's also maintaining its own connection and now disconnecting and waiting for a response. So both end of the segment maintain their own connection, and this is the big difference between using a node and using a digital computer. Now let's see if we can integrate these concepts. First, we'll use a digital computer to access our node, and the same principle applies. I'm going to go here, turn on the digital support and make a connection. So now we're going to go from radio mail through a digital computer to the node , and the node will connect to the wing link gateway. So we'll see here at the beginning, the exchange connection doubles the connection frame. [Music] So obviously, the connection takes longer because all the traffic has to be repeated twice to get to the node. There we go, I think the exchange is finished and now it's going to disconnect the connection. There we go. First, we send disconnect should be repeated and everybody's connected. Here we go. So now let's see if we can extend or reach further, because the node itself can utilize the computer. So let's see how we can do that. We'll just go into a script and modify the connection here, and we can just say via NSDG. Okay, so now what we've done is we're going to go from radio mail through the digital computer to the node, and then the node is going to use the digital computer to establish connection to then the wing link gateway. Let's see if that works. So now we hang a lot of traffic. Everything has to be repeated twice on the way to the node, and from the node to the wing link gateway, and the same thing for any traffic coming back. Okay, well, this is actually a demonstration that sometimes it doesn't work. We 've actually get time out of this connection because we didn't get the response from the node in time. This can happen. Okay, let's see if we can try that again. I think this shows that sometimes the more hops you add into your connection, the more chances you're going to have some issue and and retransmission and delays, and therefore your connection is more likely to time out, but it's still possible to establish nevertheless. So here we're connecting to the node first via the digital computer, waiting for the response from the node to be able to proceed with all scripts. This hasn't gotten too redeem yet as it's being repeated here. Let's see when it appears in the screen. There we go. Now we're making instructing the node to connect to -11 via the digital computer, and that connection is in progress, should be in progress very shortly. There you go, we see it here. -15 connecting to -11 via the digital computer, sending its SRBM connection. Now we're waiting for the confirmation from the node to say we're connected here, just came here, connected to -11. So now the connection is established end-to-end, and it's up to the win-link exchange protocol to take over, and does its first handshake, and then basically ask if there is an email to be sent or an email to be received, and if nothing will just terminate the session. So now RadioMeal has told Gateway that it has nothing to send, and we're waiting for the final answer from the Gateway itself. There you go, FQ. It's finished, and now the disconnect is going to occur first to the node itself, and then the node will relay the disconnect to the Gateway. There we go, incredible it works. We've managed a connection four hops away from our initial location. I hope you too will enjoy crafting scripts and navigate through nodes connection. Feel free to share your experience in the comments until we meet again 73 and Aloha.