2024-04-12 — What's New at DLARC; Why TARPN?; Advantages of a Bit-Regen Rptr for LANs: Why It's So Hard to Get People Excited About Using Packet Systems, and We Need Better, More Flexible User IFs
Apr 13Liked by Steve Stroh N8GNJ, Kay Savetz K6KJN
I don't know why the mention of SSTV Today stood out. Maybe the idea of printing and mailing a newsletter on a regular cadence being so foreign these days. It would be fun to resurrect that format as a special one-off type event every once in a while.
I felt the same way as I scanned my copies of PSR... there was just something nice and different in handling and reading the paper. I'm considering creating a paper version for the 3rd anniversary of Zero Retries in July as a special Thank You to the paid subscribers.
Steve, I wish I had read this issue last night instead of waiting until this afternoon. :-) This morning I decided to see what was happening on the local packet radio network since I hadn't been on it for a few years. I use Rpis for all of my ham stuff, and discovered Linpac which took some time to get to work with Direwolf, but I was ultimately successful. Then I saw your mention of Paracon and gave that a try, and had it up and working in about 5 minutes. Very nice package! Thanks for all that you do, -Dj, N1JOV
DJ - Glad to hear that Zero Retries is so useful, and your recommendation of Paracon. But I'm just the "passthrough" - please let the Paragon author know about your experience as well as Chris Lance WW2BSA who mentioned it on a list that I monitor.
Apr 13Liked by Steve Stroh N8GNJ, Brian Webster N2KGC
One thought. What if we consider Packet AND AREDN-like technologies?
In the San Francisco Bay Area, there is a large AREDN network (the Bay Area Mesh) - but that network does not cover San Jose well (if at all). Why? San Jose is FLAT, with lots of buildings and trees. Line of sight to any microwave link, high or low, is barely possible - so AREDN is not progressing well here.
Perhaps the answer is to combine our technologies? The combination of a TARPN and AREDN links if integrated with modern UI's and applications would go a long way to getting hams who cannot participate in one technology to be able to connect and expand activity.
Why are we thinking about packet and AREDN in silos? If we start thinking about complementary uses and seamless ways to integrate our protocols, we could solve some major connectivity and participation issues.
Scott - The problem isn't that the various technologies can't be combined and interoperate... they absolutely CAN. But the use cases, and knowledge base of some folks preclude them from doing so. For example, AREDN network builders often use applications like live (and sometimes high-definition) cameras, VOIP phones, etc. that ARE incompatible with packet radio (or even conventional Amateur Radio like FM voice).
One of the cool things that I've observed about AREDN and other microwave networks is that such networks actually attract IT folks into Amateur Radio so they can play with AREDN and microwave networking because they understand it from their day job. But they have no comprehension of, nor appreciation for "slow speed" data communications like Packet Radio.
If your operations are heterogenous and YOU can do both Packet Radio and AREDN, it's fun and instructive TO make it work together. The creator of New Packet Radio (which, of course, only relates to conventional Packet Radio in name) was clear that his use case was that NPR was intended to be a complement to the (microwave) HAMNET.EU network, which was high speed and based on TCP/IP.
I think N2KCG is looking for the TARPN Home app, not aredn. Most of the country (including San Jose) is not blessed with the topography of the Northwest, so VHF and UHF are the preferred bands, not microwave.
Packet is most definitely not high-speed. AREDN is. TARPN eschews the Internet in favor of amateur radio bands. EastNet is, as far as I can tell, a 1980s packet network.
I wonder how well EastNet might perform using TARPN rules?
I have studied TARPN and I worked with TAD a long time ago when he was a big part of the old NEDA network. My biggest issue with going to TARPN rules is that we already have so many high sights that do not conform to TARPN standards our network would further fall apart if we had to eliminate them. The other issue is that we are no longer all RF as things were back in the NEDA days. We have bridged islands of RF networks with AXIP links over the internet. We strive to not have those but necessity has us using them to keep what we have left of the network active. Since we are already stretching the limits of the 220 and UHF backbone links as it is, the low ham density in locations where we could build a TARPN network is VERY challenging at best. As you have know it's a chicken and egg situation. I love the concept that everyone is a sysop, so that requires them to be more informed on the importance of not running your own station in a harmful way to the network. Ideally we just need new node software on user ports that are not CSMA, get rid of this HTS syndrome by having managed node operating systems that can manage all the user radios such that collisions just no longer happen. The commercial wireless internet companies and manufacturers learned this a long time ago, I know that because I have been working in that space for over 20 years. Steve knows it just as well. Unmanaged user devices in a CSMA environment just don't scale, the MeshTastic guys are starting to learn this as well. TARPN addressed it in the fact that there cannot be any HTS stations because anyone on the network is a backbone and there are no user only stations on the air. That works technically and works well. From a practical sense it's a real hard sell in building a network in low populated and terrain challenged environments.
Brian - Thanks again for your article in ZR 0147! I think there's some improvements to be made in a scenario that perhaps in a network like EastNet, there's some value in setting up "cells" of users and diversifying them by frequency. With the cheap and capable SD receivers we have, you have the ability to listen to ALL the stations within range, and they can hear your station. As I said to N2IRZ in the previous comment, there's SO much technology we can apply now.
I wish FlexNet and X-Net were open source software. The FlexNet protocol actually does something like this NOW, When you set up a station all you do is set the call sign, SSID and the TX delay for the parameters. FlexNet monitors that channel and tweaks settings like FRACK, PACLEN, ACK and such. If the channel is clear it sends acks faster, and it also sends bigger packet lengths to get the overall payload to the destination more efficiently. Some new open source version of that would be great. Also exploring the IL2P protocol with regards to this topic might offer up some promising solutions. If something can be done WITHIN the AX25 protocol backwards compatibility to existing hardware might be possible, but moving to software modem solutions U7ZHO and DireWolf are certainly not out of play either. Since we have not taught the Aloha networking concept and it's pitfalls, it's hard to understand the issues, that is unless you lived through the heyday of packet activity and you watched the networks slow down as more user came on the air.
Brian - I don't consider that FlexNet and X-Net aren't open source to be a showstopper. The main thing is that they proved out the concepts of better, automatic channel management and now that we know that CAN be done, and generally HOW it's done (over the air), we have more than good enough technology to recreate how FlexNet and X-Net work; perhaps not well enough for interoperability with those, but certainly apply those techniques to existing open source packet radio systems like Dire Wolf. As far as I'm concerned, Dire Wolf is a fantastic demonstration of what's possible with fast processors and (well-documented, well-maintained) open source. Dire Wolf not only added the FX.25 Forward Error Correction system that's backwards compatible with AX.25, but also IL2P to be compatible with NinoTNCs using IL2P. (In my opinion, IL2P is justification to "move over in frequency to establish LANs that use ONLY IL2P.
I frequently reference how much I admire VARA FM with its ability to make better use of a 20 kHz channel to achieve up to 25 kbps... but in the end, what VARA's author did was integrate a number of techniques - OFDM, channel sounding, handshaking to determine what capabilities the other station has (fast? slow?), FEC, etc. All of those techniques are available now as libraries / subsystems, and an open source equivalent of VARA FM is certainly possible.
For both VARA FM and FlexNet / X-Net, the trick is for someone talented in such work to create a specification from how those systems WORK over the air. Once a complete-enough specification is available, the software hackers can get to work IMPLEMENTING and iterating on that specification.
We (Amateur Radio, collectively) just haven't done so - yet. But I'm convinced that someone WILL. And if they want to work on it intensively, again, ARDC is willing to fund interesting projects.
Now that I think about this problem more, if we could just add some sensing smarts to the existing CSMA protocols and upgrade software/hardware on existing sites and hardware, this would breath a lot of life in to things. Heck even APRS could benefit from something like that. That has always been what is missing, adapting the settings in the existing protocols based on channel traffic conditions. Too often EVERYTHING has fixed set parameters and as such we don't get the most efficiency under varying conditions.
Brian - Fixed parameters in Amateur Radio Packet Radio is a legacy of the limited compute power we had access to in Z80 or 68xx microprocessors that could (then) only access 64 kB in a combination of RAM and ROM. We don't have that problem now, and we finally have the luxury of rethinking some of those decisions... much like John Langner WB2OSZ did as he was developing Dire Wolf. He was constrained only by the degree of compatibility he wanted to have with legacy packet radio. I applaud WB2OSZ's decision to add IL2P as an option for Dire Wolf, though it's not backwards compatible with legacy packet radio. What you're discussing can be done the same way - fork Dire Wolf (or other AX.25 codebase) and try adding some better over-the-air protocols... like FlexNet and X-Net did.
Yes I agree! Now if the software modems can start to listen to the channel activity, even even they might be a hidden transmitter, they are hearing at least half of the conversation and know when there are ack packets and responses to retries. Know just that information alone and the timing in between these packets, one could adjust timing and data packet lengths to achieve the best settings to a properly delivered packet. Artificial intelligence at it's best. The beauty of this idea, it doesn't require any new protocol. More beauty in the idea is that any ad-hoc networks could achieve good performance without needing specialized and compatible hardware/firmware systems.
FlexNet had variable link parametrization back in the 1990s. This is great if all you want is a black data pipe. But a visible and transparent network is in itself a valuable learning tool, and hiding the gearworks (as Ma Bell does) fails to excite users to explore how it works.
The (minor) trouble with non-radio wormholes is they remove all drive and incentives to use radio for the link. Yes, having only sysops does mean more dedication to keeping the network viable. And only point-to-point links means no HTS, and (almost unbelievably) the only difference between low load and maximum load is latency.
With the low cost of link-capable radios today, converting much of EastNet to TARPN would not be a struggle - or, not a technical struggle. Selling the idea might be, though.
Agreed! But there is also the phenomenon of if a site or link disappears eventually so do the users and in the end the reason for having the network. Hard to serve both especially when the motivators are initially a smaller group. I have been watching TARPN from the early days and have talk to Tad about it as well as our mutual old friend from the NEDA data Dana. I am very excited to see TARPN continue to grow. I took the concept of EastNet away from what was essentially a FlexNet only network, to inviting any and all who want to participate. This is evident on our Quarterly Zoom calls. Progress is slow and nowhere near as impactful on a large scale as I would have hoped, but there is still forward momentum and movement. So in that respect we have to take that as a win.
Tadd should've been a preacher. He has an infectious enthusiasm and persistent drive that draws in participants. Not easy to replicate, but it seems to be effective.
Agreed! "Reverend" Tadd was a persuasive evangelist for his vision of Amateur Radio data communications, including his time when he was picking up the pieces of the PSARTG when the primaries had burned out.
Donald - Thanks again for your article in ZR 0147! San Jose itself is flat (in Silicon VALLEY) but there is high profile terrain nearby and that's used to complete saturation by many, many radio relay systems. In my days of writing about Wireless Internet Access, every startup company trying to develop new radio technology had systems on the mountain whose name I can't recall. So it's ideal situation for repeaters, or sectored antennas on the hill.
We have so much better technology now that we can try things that didn't work well because we didn't have the (reasonably priced) technology back then. Instead of CSMA / CD we could be trying TDMA, or token passing, or having 10 inputs into a high speed "firehose" data repeater.
There's no "practical" or profit motive in any of this kind of experimentation (cellular / LTE / 5G won; moving on) - it's just FUN for someone like me that's always curious about various data communications technologies. I still have a sense of wonder that I literally walked into my first IT job mostly on the strength of understanding how to use and "sysadmin" TCP/IP on a LAN, back when that skillset was pretty rare... and everything I knew about TCP/IP - routing, troubleshooting, etc. was all from experimenting with it via Amateur Radio.
No disagreement, but with proper architecture those issues are solved. I think many of us choke on the idea of "no user ports", but once you can wrap your head around it, it works.
I read Brian's email on the Eastnet group, and although I agree with most of it, I think we in the Packet Radio world might be missing an opportunity.
In the early '90s, when most hams started with Packet, it was not with a Node, BBS, or 44net. Things were different. You bought a 2m/440 radio, a TNC, you put up an antenna, and you tuned it to 145.010, and there was all this crazy noise on the frequency, and the cool blinky lights started flashing, and text would appear on the screen. Then, you could read the 100+ page manual for the TNC to figure out what all the different commands/settings were and how to get your personal mailbox working. There is nothing better than getting a message in your TNC's mailbox.
I think this is where Packeteers may be missing an opportunity. We know the packet network could use more nodes to close some of the gap now occupied by AXIP and put radio back into Packet Radio, but before trying to get folks to put up these mostly Linux-based systems, we need more "end users." Otherwise, we stand up all these nodes with no one to use them.
Most hams today are doing Winlink with either VARA or maybe Packet RMS, but any ham that is doing Winlink, in most cases, already has everything they need to participate in Packet Radio, and they don't even know it. With a few pieces of FREE software, they can be up and running on Packet with very little effort.
The easiest way I have found to start is by installing UZ7HO's Easyterm and Soundmodem, which is like the hardware TNC of old. Easyterm even has a Personal mailbox in it; the only thing missing is the blinky lights. Link to Easyterm: http://uz7.ho.ua/apps/easyterm49.zip Link to Soundmodem: http://uz7.ho.ua/modem_beta/soundmodem114.zip.
Packet Radio has so much to offer these days, with its ability to use most of the new high-speed software modems, all the different flavors of BBS/Node systems, and even AREDN. At its core is AX.25, and this is the key. With the proper links, all of these modes and systems should, at the end of the day, have the same messages in the original AX.25 format.
I think that once you get a Ham using Packet Radio as an end user, it will not be long before the Ham starts tinkering and has their own node/System up in no time. If we are willing to step back in time and use Packet Radio, then let's go all the way back and work to get the end users back on the air. Not everyone needs to be or even should be a Sysop.
Glenn - The tools for connecting with your fellow, local Amateur Radio Operators have never been better... or more numerous or diverse. Trying to inventory those tools will be a major focus of my upcoming book. To your point, yes, I think there's enough activity to justify "getting back on packet radio", and part of the fun... or pain... (depending on your perspective) is checking out the various tools such as U77HO's applications. I think it would be fun for all of us to host our own BBS and learn how to automatically forward between them.
Apr 13Liked by Steve Stroh N8GNJ, Brian Webster N2KGC
I agree Steve, but some just don’t always understand so I think those folk should start out as a user. Then as then get comfortable with it then move up to a bbs/node.
Apr 14Liked by Steve Stroh N8GNJ, Brian Webster N2KGC
Seems like much of this stuff should just be in the radio itself. Modems aren't the high power DSP devices that they were in the 1990s. Logging programs are basic database applications that shouldn't be more than a few hundred MB in size, writing to an SD card in the radio. Radio GUI should be through a web browser.
Imagine if the SDR circuitry in your radio did just a little bit more? And imagine if all that computing power that went into making the relatively small touchscreen display on your hot new 7300 was repurposed into a web server? We have these RF in audio out devices that could do a little less demoding (or a little more) and spit out data streams to send off to a PC, or an SBC companion computer slotted into the radio, or just do it all internally and spit out HTML with multimedia, depending on what the user is comfortable with, or what activity is going on that day. So a quick POTA activation might only need a radio and tablet/cell phone -which BTW has a speaker and mic that I guarantee has more R&D behind it than any amateur company's products no matter how beloved- and a little butt in chair time to make a few Qs. Or a radio sitting at home on your network listening to the local net and pushing the IRC style conversation out to your favorite web browser in a window sitting in the lower corner of your screen.
I think we have to move away from the PC centric ham shack, and make radios much more networkable. The old tried and true "buy a rig blaster, set up your sound card and download N1MM/WSJT-X/TQSL/CHIRP" way of doing things is the problem. Imagine buying the latest kilobuck radio, cabling it up to your network and browsing to "coolnewradio.local" for setting it up? That's maybe not as much "fun" as constantly screwing around with sound card settings when Windows does whatever it does (one notch is too low, the other sets the ALC into "freakout" mode), but I don't know too many hams that are going to complain.
Of course the argument is what happens when some hot new mode comes out? Well, that is a problem for sure. The manufacturers are stuck in the old paradigm of selling complete boxes with carefully managed interfaces to the outside world. Interfaces that are frozen in 2004. The IC-9700 manual says it has a "USB (1.1/2.0) type B" connector. Which I'm guess is going to show up on my computer as a SILABS serial port and audio interface. An audio interface that won't do 9600 baud. What's going to get me to upgrade my IC-9100, especially in a neighborhood where the noise floor of the receiver is probably the last thing I need to be concerned with?
And the thing is, there are very good operating systems out there that can do all that and more. Android and Ubuntu are two that are very well documented, supported and have a healthy ecosystem around them. It's not like the old days. There's probably more people capable of writing software for Android than there are Windows programmers. Not to mention all the HTML-5 and python programmers. Yes the low-level stuff will still probably require engineers who know the RF DSP stuff. And if they continue to think like they do today, building complete stand-alone products (which to be fair is a requirement for most part-90 commercial radios and mobile phone networks) there's not going to be much movement.
Ready - A year or so I would agree with you that the radio belongs IN the modem. But I can offer several examples why it shouldn’t / couldn’t:
* FlexRadio, despite the indisputable capability to do so, has not deigned to incorporate new data modes IN the radio. My main gripe on this score is the lack of inclusion of FreeDV, which would help popularize that mode. The FreeDV team has developed an elegant hardware dongle so that FreeDV fans can run FreeDV on their expen$ive FlexRadios... but the promise of SDR was that new modes could be easily incorporated. For whatever reason (and I'm convinced it isn't technical), FlexRadio seems wedded to the old "just the basic modes" paradigm. Other than the sensitivity, a few cool tricks, and complete remoteability... FlexRadio units seem to be the Collins HF radios of this era.
* The Icom IC-9700 is a very nice radio for VHF / UHF operations, and in most aspects it's an ideal radio for satellite work. It includes an integral audio interface that's accessible via its USB port. But Icom's engineers apparently didn't see the use case of satellite managers using the IC-9700 as a telecommand radio, which requires bog-standard 9600 bps FSK, which apparently the integral audio interface cannot do. Nor does the IC-9700 have an integral way to bypass the audio interface... thus satellite managers are precluded from using the IC-9700.
* The Kenwood TM-D710, (and some earlier radios in that line) have an integral TNC, including 9600 bps FSK, but I'm told that TNC isn't really capable of general data use because it has too small a buffer memory. It was intended for APRS use, and it excels at that mode. Fortunately the TM-D710 also offers an "audio interface port" (mis-named the "data" port - the 6-pin MiniDIN) to bypass the integral TNC.
* Icom also has a claim to shame that it created the fastest data mode of a production Amateur Radio unit in the Icom ID-1 - the 128 kbps Digital Data (DD) mode. When Icom shipped the IC-9700, it continued the "ID-1" implementation of DD, despite numerous advances in Amateur Radio data communications such as inclusion of Forward Error Correction, Orthogonal Frequency Division Multiplexing, etc. Icom could have improved their own data communications standard and incorporated backwards compatibility for ID-1s... but... just... didn't. Ditto the very forward-thinking IC-905 - no change in the DD mode. Despite the quality of Icom radios (I'm a fan, generally... and they're the home team here in the Pacific Northwest) their understanding of data modes is abysmally poor.
* Yaesu System Fusion... sigh... They came SO close to an ideal data mode with the System Fusion radios. But, inexplicably, Yaesu just refused to allow "data" to flow through the SF radios. The SF radios have a native 9600 bps capability, but the only usage of that is to send images reasonably fast. But arbitrary data - emails, files, etc? Nope.
Thus I conclude that (the current) big Amateur Radio RADIO manufacturers just don't seem to be able to wrap their heads around data communications. If FlexRadio can't get it... then I conclude that there just isn't any hope. It will take some new vendor to come into Amateur Radio and disrupt the status quo. It's possible that will be a radio vendor from China, but other than some clever tricks like shipping black boxes that put all the externals such as microphone, speaker, controls, etc. entirely over Bluetooth, I haven't seen any innovation in data communications from a Chinese radio manufacturer.
I should have added in my previous descriptions that in the end, I don't fault the Amateur Radio radio manufacturers too much. Higher speed data is a niche (of very nichey Amateur Radio), and it's already very hard to make Amateur Radio units at a profit. I frequently cite the old maxim:
Want to make a small fortune (in Amateur Radio)? Best to start with a large fortune.
So... for the immediate future, we're stuck with external modems and the few radios that allow reasonable fidelity audio I/O such as the new Yaesu FTM-6000R. Fortunately, the MODEM manufacturers seem to get higher speed data, and my favorite example of that is Kevin Custer W3KKC of Masters Communications creating the Digital Radio Adapter series - https://www.masterscommunications.com/products/radio-adapter/dra/dra-index.html. (No compensation - just a fan.)
Amateur Radio can be doing the coolest things in data communications via radio, with our ability to do so on VHF / UHF...
Thanks for clarifying my thought. I was looking at what SHOULD be happening but probably won't ever happen. When RTL-SDR dongles are the size of postage stamps and cost less than $20 retail (with connector, circuit board and case), there's really no excuse for not including an open standard wideband output data stream on the USB connector. After posting that I took a few minutes to read the IC-7300 manual and noticed they do have an IF out feed available on the USB connector, but of course it's a secret that can only be used with Icom's Windows only software.
I guess my definition of a modern radio is probably more inline with your concept too. Something like the promised Lime SDR LimeNET 2.0, housed in something the size of a Yaesu FT-817, with a primarily web GUI. Only ports being antenna jacks for TX/RX, GPS, WiFi, Ethernet and power. No displays other than possible status indicator. No speaker or mic jack. But how to get it past the FCC and the legal department and still make it flexible enough for new modes? How can one be sure that someone isn't going to introduce some new modulation that screws up the 3rd harmonic and splatters into someone else's territory? Of course the answer is to remove type certification as a requirement for mass produced amateur equipment, but that would probably require an act of congress. Heck, we can't even have COTS 10 meter amplifiers because someone might make it work on 11 meters.
I think we'll eventually get there, but it will take a lot of thinking outside the box. And a "stone soup" development model. Take a core system that's open then add to it in a modular fashion. Or build a basic reference standard that can be used to build on, much like TAPR TNC II, but with direct mod/demod instead of in the audio domain. And APIs for the user side. As the article pointed out, the old arcane CLI was part of the TNC II spec, and people built on that to make decent terminal programs. Heck, the AT command spec is still in use for many serial devices, just do something like that.
Hey Steve, when you get around to running that fiber, check out https://fs.com. I've used hundreds of miles of their pre-terminated cables over the years and their support has been great. I can also recommend their SFPs.
I've never used any of their switches or other network equipment so I can't comment there. Their passive media converters look very inexpensive and I'd be willing to try them if I needed one.
Ben - Thanks for that pointer for some study. This will be my only foray into fiber (I'm hardly pushing the limits of Cat6 in my networks), so I'm imagining a 100m pre-terminated cable (or pulling two, one as a backup) and a Fiber / Ethernet converter on each end. But if it's economical, maybe I should activate both fibers, and the second one will extend the isolated Amateur Radio network (currently only accessible from N8GNJ Labs) into the house.
Apr 16Liked by Steve Stroh N8GNJ, Brian Webster N2KGC
Wow, I'm glad I checked back for comments. Looks like there are lots of opinions on improving packet networks which I think is great.
Personally I think the TARPN approach is way too rigid. I understand why it is what it is, but it's too inflexible. It can't handle terrain, or low population density, at all. In the driftless region of the upper Mississippi River valley where I am we are lucky enough to have club equipment on county-owned towers at 300 and 350ft on top of a bluff. We are running two VHF ports on the BPQ node there and it, for better or worse, is the glue holding the local packet community together. Before it was in service, members of my local club couldn't make any packet connections that weren't extremely local. Hams in the next town down the river were in the same boat (haha,) and the communities to the west couldn't connect due to hundreds of feet of limestone between them. Having two ports, one for the Wisconsin side of the river and one for the Minnesota side help to keep congestion down, but I could see how this design would fall flat if there were a few dozen more users.
TARPN would never work here. Height is might on VHF and UHF. to do this within TARPN rules someone would have to buy land on a bluff, build a shack or house, and then put up a several hundred foot tower, then put up half a dozen yagis with half a dozen radios, etc... Sure it would handle heavy use better but nobody has the money for that.
We use BPQ's chat system for weekly nets as well as public service events. The lack of user ports on TARPN would either preclude the service events, or make the amount of required equipment much greater. Rather than a laptop and HT with a built-in TNC, a rest stop now needs an RPi as well as a dedicated antenna/frequency on the station it will connect to.
I'm a fan of limiting cell sizes and using dedicated P2P links (AX.25, AREDN, NPR, or whatever) to connect the cells together. This also (hopefully) reduces the number of required hops to access shared resources.
I haven't tried the bit-regenerative repeater method yet. It seems like it would be great for peer-to-peer type connectivity. Hopefully I will have the opportunity to test this in the future.
These thoughts have always been my issue with adopting a TARPN network here in the Northeast. Building any type of packet network teaching people how data networks actually work with many users is where we are failing. Because we haven't seemed to create a teaching aid that shows how collisions happen on a single store and forward single frequency network, the understanding of how detrimental that is and how a network capacity and throughput falls to it's knees. Today because packet has low user counts, it's hasn't become very obvious. Before the days of the internet, when we had a lot more packet users, we learned this. That is why the old NEDA group really did a good job of teaching the concept and as such they built a real backbone network to minimize the effect. People are learning the lesson all over again, I see the issues with ARDEN networks where they try to do too much on a single node on one frequency (REALLY evident when you do more than one video UDP streams on the same node) and the Meshtastic guys are learning this same lesson as the participant count increases. Their busy networks are seeing their coverage ranges decrease, mostly due to packet collisions and subsequently not decoding properly.
High tower sites are usually restricted access for good reason, they are located with other non-ham users and you don't want people in those sites in there that might do things that would cause problems for other users on the tower. You do mention the reason why they are still very much needed and I agree. Not having users ports are also a hindrance to using packet networks for portable emergency data networks for the exact reason you mention. I am not saying TARPN is wrong, its just not the right solution for all situations. That's ok as long as your group understands the pro's and con's of both methods.
Brian - I think the "loss of tribal knowledge" about building Amateur Radio data networks is a big factor in our current situation of fragmented Amateur Radio data networks with varying technologies and systems. We all used to work from a common "knowledge base" with TAPR PSR, ARRL Gateway, books that we all bought and read, etc. Not so much now - we're pretty fragmented and I think us that have visions of better Amateur Radio data network might need a "level up reset" where we all educate ourselves about what the options ARE to build new networks / rebuild or update existing networks. That's one of the reasons I'm so excited about the potential of the new MMDVM-TNC and fitting that technology into existing FM repeaters. We could rapidly create communities of Amateur Radio data around the repeaters, link the data function on the repeaters via "bridge / routers" that can access multiple repeaters, and then go on from there to build dedicated links ala TARPN.
Apr 18Liked by Steve Stroh N8GNJ, Brian Webster N2KGC
Yeah, there would be some political and financial things to work out if we ever went that way. Site access is easy (as long as you own a pair of snowshoes for when the weather gets bad) but being a county-owned site any climbing requires someone licensed and insured. We used to have someone in the club but he retired and doesn't like going up that high anymore. I can't say I blame him. That makes climbing pretty expensive, as well as opens the can of worms of who pays for the climber, feedline, and additional antennas. Rough back-of-the-napkin figuring would indicate that we would need to add 3-4 additional ports.
I'm genuinely curious how other groups handle this, even on private home installations. Let's say Bob moves in to a new town and wants to join the TARPN network there. Alice lives a few miles away and is an easy contact for Bob. She lives on a hill and has a connection to Charlie in the next town. Does Alice buy the extra equipment for her shack to connect to Bob, or is Bob expected to help? You see how this could get sticky with club politics too where maybe 10% of club members are interested in the activity.
The other political situation would involve the County. Our club has free, exclusive use of the tower because of the public service aspect. Emcomm too a little since there is a 440MHz repeater there that covers dead spots in the counties radio system--spots that are prone to flooding of course. Taking the user port away would mean taking down the Winlink gateway which the emergency manager likes having, as well as making the public service events difficult. I'm guessing in the next couple of years Starlink will take over for the Winlink side of things and hopefully the club doesn't find itself looking for a new tower.
The one aspect of TARPN that I don't see stressed is ARES/RACES, I get the impression the networks are built more for fun and experimenting. Groups that see and use packet more for backups/ARES/RACES/ do things differently as you state Ben. Here in NY the state RACES organization pushed to keep the packet networks running and the state department of homeland security does their best with their technicians and climbers to to support the efforts. That process is slow even with their help because they have no many other priority projects that keep them busy. Locally we are fortunate that our County actively supports RACES and we have limited but good tower access. We usually get a small budget to do small projects as well, which has allowed us to also start including AREDN equipment.
Brian - I'm... pessimistic, or perhaps realistic, that the capabilities of Starlink are rapidly going to displace Amateur Radio in EMCOM situations. I can easily foresee a small, trailerable package (think something the size of a "light tower") that combines solar panel, battery, Starlink, Wi-Fi, and perhaps a local repeater for tactical comms that can be remoted via Starlink. There's also Iridium "portable radios" that are the same functionality as conventional radio, but work with no infrastructure other than being able to see the sky. And there's also FirstNET that's doing the same thing, only with cellular service that's finally, genuinely prioritized, hardened, and availability monitored by the US Government's NTIA. It's also now possible to have a localized, private cell phone service using CBRS spectrum. Not many EMCOM organizations are there yet, but I think it's inevitable. I think that Amateur Radio ARES / RACES / ACES groups (and their support organizations) should recognize that this transition IS coming and work to get ahead of it, and embrace newer technologies as ITDRC (https://www.itdrc.org) does.
Oh I wholeheartedly agree and I own a trailer like that. Our county RACES group has 3 other trailers like that as well and we make use of IP Cameras and AREDN links extensively. These routinely get deployed as portable traffic cameras sites to support events such as Triathlons, motocross races, and other large public events (For us a big one is the National Baseball Hall of Fame Inductions Ceremony) where we actually staff command posts and our EOC managing video streams to monitor crowds and traffic in and around the events. Here is a post about the Hall of Fame event last summer with pictures of the trailers and improvements made inside the EOC https://www.facebook.com/groups/1309131859113362/posts/7200641083295714/
Ben - I'm in agreement with you. Like you, I understand why NCNet (and others) developed and chose the TARPN methodology. It certainly does have many positive attributes... and provably it works to develop and grow an Amateur Radio data network. Also like you, I appreciate the challenges of terrain in the Midwest (my experience was in Central and Northern Ohio) and yeah, height pretty much trumps most other aspects on VHF / UHF. I don't think there is a "best" Amateur Radio data network methodology - mostly it's what the local Amateur Radio community can agree upon, build up, maintain, and support and MOST importantly, what it's prepared to EVANGELIZE to new and prospective Amateur Radio Operators. If it's operated as "let's just keep it limping along - I don't want to see it die..." then you can hardly expect to see newcomers getting excited. That factor alone is why there is so much enthusiasm about Meshtastic - it's certainly not "better" than Amateur Radio data networks... but it's new, it's being presented with enthusiasm, and it's gaining a lot of newcomers into the idea of low speed data networks independent of cellular, Internet, satellite, or any other infrastucture. I think the biggest factor about Meshtastic is that techie experimenters are beginning to understand that radio can be used for more than Wi-Fi, Bluetooth, cellular, satellite, or broadcasting.
Apr 17·edited Apr 17Liked by Steve Stroh N8GNJ, Brian Webster N2KGC
The bit-regenerating repeater has a lot of other possibilities that are not possible when just passing audio. For instance, the receiver side could collect data from multiple frequencies and/or bands, and queue them out the single transmitter as a continuous 9600 bit stream. An SDR receiver would make this highly flexible. You could have data coming in on 1200bps 2m packet to support people with old fm radios, and maybe 9600 on 70cm, all APRS traffic from 144.39, or even multiple input channels for different kinds or priorities of traffic (Eg., send your long transmissions on low-priority channel A, and use your real time chat program on channel B, the latter will get re-transmitted right away).
You could even think of ways to make further use of that transmitter time. Perhaps send it some data to beacon every hour for a day, ultra-low priority bits on the transmitter. I'm thinking radar maps someone is pulling from wx satellites or the club newsletter or something like that.
All users would basically pick an uplink frequency based on capability and traffic type, and everyone would listen to the same data stream on the repeater out. That 9600bps transmitter can conceivably transmit 100mb per day if it's capable of 100% transmission time. A bit-regenerating repeater could actually do it and provide for a LOT of activity.
Jason - Reimagining the roles / uses / functions of repeaters in Amateur Radio is, and will be a recurring theme here in Zero Retries. I think that, like HF, repeaters are an Amateur Radio superpower that can't easily be matched by other radio services. GMRS also has repeaters, but limited in power and functionality - FM voice only (no data... currently), Meshtastic / LoRa data rate is low (LoRaWAN is a paid [I think] system), etc. Amateur Radio can do so many things. I can imagine what you're proposing, as well as being able to link repeaters together on RF (with the simple expedient of a repeater being upgraded with a Software Defined Receiver to monitor other repeaters), and the potential to do flood data transmissions for files, bulletins etc. (see http://www.w1hkj.com/files/manuals/US_English/FLAmp_2.2_Users_Manual.pdf#section.1.1) and even using the concepts of a PACSAT, which is being revived for a future AMSAT satellite payload.
I don't know why the mention of SSTV Today stood out. Maybe the idea of printing and mailing a newsletter on a regular cadence being so foreign these days. It would be fun to resurrect that format as a special one-off type event every once in a while.
I felt the same way as I scanned my copies of PSR... there was just something nice and different in handling and reading the paper. I'm considering creating a paper version for the 3rd anniversary of Zero Retries in July as a special Thank You to the paid subscribers.
Steve, I wish I had read this issue last night instead of waiting until this afternoon. :-) This morning I decided to see what was happening on the local packet radio network since I hadn't been on it for a few years. I use Rpis for all of my ham stuff, and discovered Linpac which took some time to get to work with Direwolf, but I was ultimately successful. Then I saw your mention of Paracon and gave that a try, and had it up and working in about 5 minutes. Very nice package! Thanks for all that you do, -Dj, N1JOV
DJ - Glad to hear that Zero Retries is so useful, and your recommendation of Paracon. But I'm just the "passthrough" - please let the Paragon author know about your experience as well as Chris Lance WW2BSA who mentioned it on a list that I monitor.
One thought. What if we consider Packet AND AREDN-like technologies?
In the San Francisco Bay Area, there is a large AREDN network (the Bay Area Mesh) - but that network does not cover San Jose well (if at all). Why? San Jose is FLAT, with lots of buildings and trees. Line of sight to any microwave link, high or low, is barely possible - so AREDN is not progressing well here.
Perhaps the answer is to combine our technologies? The combination of a TARPN and AREDN links if integrated with modern UI's and applications would go a long way to getting hams who cannot participate in one technology to be able to connect and expand activity.
Why are we thinking about packet and AREDN in silos? If we start thinking about complementary uses and seamless ways to integrate our protocols, we could solve some major connectivity and participation issues.
Thoughts?
Scott - The problem isn't that the various technologies can't be combined and interoperate... they absolutely CAN. But the use cases, and knowledge base of some folks preclude them from doing so. For example, AREDN network builders often use applications like live (and sometimes high-definition) cameras, VOIP phones, etc. that ARE incompatible with packet radio (or even conventional Amateur Radio like FM voice).
One of the cool things that I've observed about AREDN and other microwave networks is that such networks actually attract IT folks into Amateur Radio so they can play with AREDN and microwave networking because they understand it from their day job. But they have no comprehension of, nor appreciation for "slow speed" data communications like Packet Radio.
If your operations are heterogenous and YOU can do both Packet Radio and AREDN, it's fun and instructive TO make it work together. The creator of New Packet Radio (which, of course, only relates to conventional Packet Radio in name) was clear that his use case was that NPR was intended to be a complement to the (microwave) HAMNET.EU network, which was high speed and based on TCP/IP.
I think N2KCG is looking for the TARPN Home app, not aredn. Most of the country (including San Jose) is not blessed with the topography of the Northwest, so VHF and UHF are the preferred bands, not microwave.
Packet is most definitely not high-speed. AREDN is. TARPN eschews the Internet in favor of amateur radio bands. EastNet is, as far as I can tell, a 1980s packet network.
I wonder how well EastNet might perform using TARPN rules?
I have studied TARPN and I worked with TAD a long time ago when he was a big part of the old NEDA network. My biggest issue with going to TARPN rules is that we already have so many high sights that do not conform to TARPN standards our network would further fall apart if we had to eliminate them. The other issue is that we are no longer all RF as things were back in the NEDA days. We have bridged islands of RF networks with AXIP links over the internet. We strive to not have those but necessity has us using them to keep what we have left of the network active. Since we are already stretching the limits of the 220 and UHF backbone links as it is, the low ham density in locations where we could build a TARPN network is VERY challenging at best. As you have know it's a chicken and egg situation. I love the concept that everyone is a sysop, so that requires them to be more informed on the importance of not running your own station in a harmful way to the network. Ideally we just need new node software on user ports that are not CSMA, get rid of this HTS syndrome by having managed node operating systems that can manage all the user radios such that collisions just no longer happen. The commercial wireless internet companies and manufacturers learned this a long time ago, I know that because I have been working in that space for over 20 years. Steve knows it just as well. Unmanaged user devices in a CSMA environment just don't scale, the MeshTastic guys are starting to learn this as well. TARPN addressed it in the fact that there cannot be any HTS stations because anyone on the network is a backbone and there are no user only stations on the air. That works technically and works well. From a practical sense it's a real hard sell in building a network in low populated and terrain challenged environments.
Brian - Thanks again for your article in ZR 0147! I think there's some improvements to be made in a scenario that perhaps in a network like EastNet, there's some value in setting up "cells" of users and diversifying them by frequency. With the cheap and capable SD receivers we have, you have the ability to listen to ALL the stations within range, and they can hear your station. As I said to N2IRZ in the previous comment, there's SO much technology we can apply now.
I wish FlexNet and X-Net were open source software. The FlexNet protocol actually does something like this NOW, When you set up a station all you do is set the call sign, SSID and the TX delay for the parameters. FlexNet monitors that channel and tweaks settings like FRACK, PACLEN, ACK and such. If the channel is clear it sends acks faster, and it also sends bigger packet lengths to get the overall payload to the destination more efficiently. Some new open source version of that would be great. Also exploring the IL2P protocol with regards to this topic might offer up some promising solutions. If something can be done WITHIN the AX25 protocol backwards compatibility to existing hardware might be possible, but moving to software modem solutions U7ZHO and DireWolf are certainly not out of play either. Since we have not taught the Aloha networking concept and it's pitfalls, it's hard to understand the issues, that is unless you lived through the heyday of packet activity and you watched the networks slow down as more user came on the air.
Brian - I don't consider that FlexNet and X-Net aren't open source to be a showstopper. The main thing is that they proved out the concepts of better, automatic channel management and now that we know that CAN be done, and generally HOW it's done (over the air), we have more than good enough technology to recreate how FlexNet and X-Net work; perhaps not well enough for interoperability with those, but certainly apply those techniques to existing open source packet radio systems like Dire Wolf. As far as I'm concerned, Dire Wolf is a fantastic demonstration of what's possible with fast processors and (well-documented, well-maintained) open source. Dire Wolf not only added the FX.25 Forward Error Correction system that's backwards compatible with AX.25, but also IL2P to be compatible with NinoTNCs using IL2P. (In my opinion, IL2P is justification to "move over in frequency to establish LANs that use ONLY IL2P.
I frequently reference how much I admire VARA FM with its ability to make better use of a 20 kHz channel to achieve up to 25 kbps... but in the end, what VARA's author did was integrate a number of techniques - OFDM, channel sounding, handshaking to determine what capabilities the other station has (fast? slow?), FEC, etc. All of those techniques are available now as libraries / subsystems, and an open source equivalent of VARA FM is certainly possible.
For both VARA FM and FlexNet / X-Net, the trick is for someone talented in such work to create a specification from how those systems WORK over the air. Once a complete-enough specification is available, the software hackers can get to work IMPLEMENTING and iterating on that specification.
We (Amateur Radio, collectively) just haven't done so - yet. But I'm convinced that someone WILL. And if they want to work on it intensively, again, ARDC is willing to fund interesting projects.
Now that I think about this problem more, if we could just add some sensing smarts to the existing CSMA protocols and upgrade software/hardware on existing sites and hardware, this would breath a lot of life in to things. Heck even APRS could benefit from something like that. That has always been what is missing, adapting the settings in the existing protocols based on channel traffic conditions. Too often EVERYTHING has fixed set parameters and as such we don't get the most efficiency under varying conditions.
Brian - Fixed parameters in Amateur Radio Packet Radio is a legacy of the limited compute power we had access to in Z80 or 68xx microprocessors that could (then) only access 64 kB in a combination of RAM and ROM. We don't have that problem now, and we finally have the luxury of rethinking some of those decisions... much like John Langner WB2OSZ did as he was developing Dire Wolf. He was constrained only by the degree of compatibility he wanted to have with legacy packet radio. I applaud WB2OSZ's decision to add IL2P as an option for Dire Wolf, though it's not backwards compatible with legacy packet radio. What you're discussing can be done the same way - fork Dire Wolf (or other AX.25 codebase) and try adding some better over-the-air protocols... like FlexNet and X-Net did.
Yes I agree! Now if the software modems can start to listen to the channel activity, even even they might be a hidden transmitter, they are hearing at least half of the conversation and know when there are ack packets and responses to retries. Know just that information alone and the timing in between these packets, one could adjust timing and data packet lengths to achieve the best settings to a properly delivered packet. Artificial intelligence at it's best. The beauty of this idea, it doesn't require any new protocol. More beauty in the idea is that any ad-hoc networks could achieve good performance without needing specialized and compatible hardware/firmware systems.
FlexNet had variable link parametrization back in the 1990s. This is great if all you want is a black data pipe. But a visible and transparent network is in itself a valuable learning tool, and hiding the gearworks (as Ma Bell does) fails to excite users to explore how it works.
The (minor) trouble with non-radio wormholes is they remove all drive and incentives to use radio for the link. Yes, having only sysops does mean more dedication to keeping the network viable. And only point-to-point links means no HTS, and (almost unbelievably) the only difference between low load and maximum load is latency.
With the low cost of link-capable radios today, converting much of EastNet to TARPN would not be a struggle - or, not a technical struggle. Selling the idea might be, though.
Agreed! But there is also the phenomenon of if a site or link disappears eventually so do the users and in the end the reason for having the network. Hard to serve both especially when the motivators are initially a smaller group. I have been watching TARPN from the early days and have talk to Tad about it as well as our mutual old friend from the NEDA data Dana. I am very excited to see TARPN continue to grow. I took the concept of EastNet away from what was essentially a FlexNet only network, to inviting any and all who want to participate. This is evident on our Quarterly Zoom calls. Progress is slow and nowhere near as impactful on a large scale as I would have hoped, but there is still forward momentum and movement. So in that respect we have to take that as a win.
And a win is a win!
Tadd should've been a preacher. He has an infectious enthusiasm and persistent drive that draws in participants. Not easy to replicate, but it seems to be effective.
He has always been fun to work with!
Agreed! "Reverend" Tadd was a persuasive evangelist for his vision of Amateur Radio data communications, including his time when he was picking up the pieces of the PSARTG when the primaries had burned out.
Donald - Thanks again for your article in ZR 0147! San Jose itself is flat (in Silicon VALLEY) but there is high profile terrain nearby and that's used to complete saturation by many, many radio relay systems. In my days of writing about Wireless Internet Access, every startup company trying to develop new radio technology had systems on the mountain whose name I can't recall. So it's ideal situation for repeaters, or sectored antennas on the hill.
We have so much better technology now that we can try things that didn't work well because we didn't have the (reasonably priced) technology back then. Instead of CSMA / CD we could be trying TDMA, or token passing, or having 10 inputs into a high speed "firehose" data repeater.
There's no "practical" or profit motive in any of this kind of experimentation (cellular / LTE / 5G won; moving on) - it's just FUN for someone like me that's always curious about various data communications technologies. I still have a sense of wonder that I literally walked into my first IT job mostly on the strength of understanding how to use and "sysadmin" TCP/IP on a LAN, back when that skillset was pretty rare... and everything I knew about TCP/IP - routing, troubleshooting, etc. was all from experimenting with it via Amateur Radio.
No disagreement, but with proper architecture those issues are solved. I think many of us choke on the idea of "no user ports", but once you can wrap your head around it, it works.
Posting this comment on behalf of Glenn N3MEL:
I read Brian's email on the Eastnet group, and although I agree with most of it, I think we in the Packet Radio world might be missing an opportunity.
In the early '90s, when most hams started with Packet, it was not with a Node, BBS, or 44net. Things were different. You bought a 2m/440 radio, a TNC, you put up an antenna, and you tuned it to 145.010, and there was all this crazy noise on the frequency, and the cool blinky lights started flashing, and text would appear on the screen. Then, you could read the 100+ page manual for the TNC to figure out what all the different commands/settings were and how to get your personal mailbox working. There is nothing better than getting a message in your TNC's mailbox.
I think this is where Packeteers may be missing an opportunity. We know the packet network could use more nodes to close some of the gap now occupied by AXIP and put radio back into Packet Radio, but before trying to get folks to put up these mostly Linux-based systems, we need more "end users." Otherwise, we stand up all these nodes with no one to use them.
Most hams today are doing Winlink with either VARA or maybe Packet RMS, but any ham that is doing Winlink, in most cases, already has everything they need to participate in Packet Radio, and they don't even know it. With a few pieces of FREE software, they can be up and running on Packet with very little effort.
The easiest way I have found to start is by installing UZ7HO's Easyterm and Soundmodem, which is like the hardware TNC of old. Easyterm even has a Personal mailbox in it; the only thing missing is the blinky lights. Link to Easyterm: http://uz7.ho.ua/apps/easyterm49.zip Link to Soundmodem: http://uz7.ho.ua/modem_beta/soundmodem114.zip.
Packet Radio has so much to offer these days, with its ability to use most of the new high-speed software modems, all the different flavors of BBS/Node systems, and even AREDN. At its core is AX.25, and this is the key. With the proper links, all of these modes and systems should, at the end of the day, have the same messages in the original AX.25 format.
I think that once you get a Ham using Packet Radio as an end user, it will not be long before the Ham starts tinkering and has their own node/System up in no time. If we are willing to step back in time and use Packet Radio, then let's go all the way back and work to get the end users back on the air. Not everyone needs to be or even should be a Sysop.
Glenn - The tools for connecting with your fellow, local Amateur Radio Operators have never been better... or more numerous or diverse. Trying to inventory those tools will be a major focus of my upcoming book. To your point, yes, I think there's enough activity to justify "getting back on packet radio", and part of the fun... or pain... (depending on your perspective) is checking out the various tools such as U77HO's applications. I think it would be fun for all of us to host our own BBS and learn how to automatically forward between them.
I agree Steve, but some just don’t always understand so I think those folk should start out as a user. Then as then get comfortable with it then move up to a bbs/node.
Thank you for getting my post up for me Steve!
Seems like much of this stuff should just be in the radio itself. Modems aren't the high power DSP devices that they were in the 1990s. Logging programs are basic database applications that shouldn't be more than a few hundred MB in size, writing to an SD card in the radio. Radio GUI should be through a web browser.
Imagine if the SDR circuitry in your radio did just a little bit more? And imagine if all that computing power that went into making the relatively small touchscreen display on your hot new 7300 was repurposed into a web server? We have these RF in audio out devices that could do a little less demoding (or a little more) and spit out data streams to send off to a PC, or an SBC companion computer slotted into the radio, or just do it all internally and spit out HTML with multimedia, depending on what the user is comfortable with, or what activity is going on that day. So a quick POTA activation might only need a radio and tablet/cell phone -which BTW has a speaker and mic that I guarantee has more R&D behind it than any amateur company's products no matter how beloved- and a little butt in chair time to make a few Qs. Or a radio sitting at home on your network listening to the local net and pushing the IRC style conversation out to your favorite web browser in a window sitting in the lower corner of your screen.
I think we have to move away from the PC centric ham shack, and make radios much more networkable. The old tried and true "buy a rig blaster, set up your sound card and download N1MM/WSJT-X/TQSL/CHIRP" way of doing things is the problem. Imagine buying the latest kilobuck radio, cabling it up to your network and browsing to "coolnewradio.local" for setting it up? That's maybe not as much "fun" as constantly screwing around with sound card settings when Windows does whatever it does (one notch is too low, the other sets the ALC into "freakout" mode), but I don't know too many hams that are going to complain.
Of course the argument is what happens when some hot new mode comes out? Well, that is a problem for sure. The manufacturers are stuck in the old paradigm of selling complete boxes with carefully managed interfaces to the outside world. Interfaces that are frozen in 2004. The IC-9700 manual says it has a "USB (1.1/2.0) type B" connector. Which I'm guess is going to show up on my computer as a SILABS serial port and audio interface. An audio interface that won't do 9600 baud. What's going to get me to upgrade my IC-9100, especially in a neighborhood where the noise floor of the receiver is probably the last thing I need to be concerned with?
And the thing is, there are very good operating systems out there that can do all that and more. Android and Ubuntu are two that are very well documented, supported and have a healthy ecosystem around them. It's not like the old days. There's probably more people capable of writing software for Android than there are Windows programmers. Not to mention all the HTML-5 and python programmers. Yes the low-level stuff will still probably require engineers who know the RF DSP stuff. And if they continue to think like they do today, building complete stand-alone products (which to be fair is a requirement for most part-90 commercial radios and mobile phone networks) there's not going to be much movement.
1/3
Ready - A year or so I would agree with you that the radio belongs IN the modem. But I can offer several examples why it shouldn’t / couldn’t:
* FlexRadio, despite the indisputable capability to do so, has not deigned to incorporate new data modes IN the radio. My main gripe on this score is the lack of inclusion of FreeDV, which would help popularize that mode. The FreeDV team has developed an elegant hardware dongle so that FreeDV fans can run FreeDV on their expen$ive FlexRadios... but the promise of SDR was that new modes could be easily incorporated. For whatever reason (and I'm convinced it isn't technical), FlexRadio seems wedded to the old "just the basic modes" paradigm. Other than the sensitivity, a few cool tricks, and complete remoteability... FlexRadio units seem to be the Collins HF radios of this era.
* The Icom IC-9700 is a very nice radio for VHF / UHF operations, and in most aspects it's an ideal radio for satellite work. It includes an integral audio interface that's accessible via its USB port. But Icom's engineers apparently didn't see the use case of satellite managers using the IC-9700 as a telecommand radio, which requires bog-standard 9600 bps FSK, which apparently the integral audio interface cannot do. Nor does the IC-9700 have an integral way to bypass the audio interface... thus satellite managers are precluded from using the IC-9700.
* The Kenwood TM-D710, (and some earlier radios in that line) have an integral TNC, including 9600 bps FSK, but I'm told that TNC isn't really capable of general data use because it has too small a buffer memory. It was intended for APRS use, and it excels at that mode. Fortunately the TM-D710 also offers an "audio interface port" (mis-named the "data" port - the 6-pin MiniDIN) to bypass the integral TNC.
2/3
* Icom also has a claim to shame that it created the fastest data mode of a production Amateur Radio unit in the Icom ID-1 - the 128 kbps Digital Data (DD) mode. When Icom shipped the IC-9700, it continued the "ID-1" implementation of DD, despite numerous advances in Amateur Radio data communications such as inclusion of Forward Error Correction, Orthogonal Frequency Division Multiplexing, etc. Icom could have improved their own data communications standard and incorporated backwards compatibility for ID-1s... but... just... didn't. Ditto the very forward-thinking IC-905 - no change in the DD mode. Despite the quality of Icom radios (I'm a fan, generally... and they're the home team here in the Pacific Northwest) their understanding of data modes is abysmally poor.
* Yaesu System Fusion... sigh... They came SO close to an ideal data mode with the System Fusion radios. But, inexplicably, Yaesu just refused to allow "data" to flow through the SF radios. The SF radios have a native 9600 bps capability, but the only usage of that is to send images reasonably fast. But arbitrary data - emails, files, etc? Nope.
Thus I conclude that (the current) big Amateur Radio RADIO manufacturers just don't seem to be able to wrap their heads around data communications. If FlexRadio can't get it... then I conclude that there just isn't any hope. It will take some new vendor to come into Amateur Radio and disrupt the status quo. It's possible that will be a radio vendor from China, but other than some clever tricks like shipping black boxes that put all the externals such as microphone, speaker, controls, etc. entirely over Bluetooth, I haven't seen any innovation in data communications from a Chinese radio manufacturer.
3/3
I should have added in my previous descriptions that in the end, I don't fault the Amateur Radio radio manufacturers too much. Higher speed data is a niche (of very nichey Amateur Radio), and it's already very hard to make Amateur Radio units at a profit. I frequently cite the old maxim:
Want to make a small fortune (in Amateur Radio)? Best to start with a large fortune.
So... for the immediate future, we're stuck with external modems and the few radios that allow reasonable fidelity audio I/O such as the new Yaesu FTM-6000R. Fortunately, the MODEM manufacturers seem to get higher speed data, and my favorite example of that is Kevin Custer W3KKC of Masters Communications creating the Digital Radio Adapter series - https://www.masterscommunications.com/products/radio-adapter/dra/dra-index.html. (No compensation - just a fan.)
Amateur Radio can be doing the coolest things in data communications via radio, with our ability to do so on VHF / UHF...
Thanks for clarifying my thought. I was looking at what SHOULD be happening but probably won't ever happen. When RTL-SDR dongles are the size of postage stamps and cost less than $20 retail (with connector, circuit board and case), there's really no excuse for not including an open standard wideband output data stream on the USB connector. After posting that I took a few minutes to read the IC-7300 manual and noticed they do have an IF out feed available on the USB connector, but of course it's a secret that can only be used with Icom's Windows only software.
I guess my definition of a modern radio is probably more inline with your concept too. Something like the promised Lime SDR LimeNET 2.0, housed in something the size of a Yaesu FT-817, with a primarily web GUI. Only ports being antenna jacks for TX/RX, GPS, WiFi, Ethernet and power. No displays other than possible status indicator. No speaker or mic jack. But how to get it past the FCC and the legal department and still make it flexible enough for new modes? How can one be sure that someone isn't going to introduce some new modulation that screws up the 3rd harmonic and splatters into someone else's territory? Of course the answer is to remove type certification as a requirement for mass produced amateur equipment, but that would probably require an act of congress. Heck, we can't even have COTS 10 meter amplifiers because someone might make it work on 11 meters.
I think we'll eventually get there, but it will take a lot of thinking outside the box. And a "stone soup" development model. Take a core system that's open then add to it in a modular fashion. Or build a basic reference standard that can be used to build on, much like TAPR TNC II, but with direct mod/demod instead of in the audio domain. And APIs for the user side. As the article pointed out, the old arcane CLI was part of the TNC II spec, and people built on that to make decent terminal programs. Heck, the AT command spec is still in use for many serial devices, just do something like that.
Hey Steve, when you get around to running that fiber, check out https://fs.com. I've used hundreds of miles of their pre-terminated cables over the years and their support has been great. I can also recommend their SFPs.
I've never used any of their switches or other network equipment so I can't comment there. Their passive media converters look very inexpensive and I'd be willing to try them if I needed one.
Ben - Thanks for that pointer for some study. This will be my only foray into fiber (I'm hardly pushing the limits of Cat6 in my networks), so I'm imagining a 100m pre-terminated cable (or pulling two, one as a backup) and a Fiber / Ethernet converter on each end. But if it's economical, maybe I should activate both fibers, and the second one will extend the isolated Amateur Radio network (currently only accessible from N8GNJ Labs) into the house.
Wow, I'm glad I checked back for comments. Looks like there are lots of opinions on improving packet networks which I think is great.
Personally I think the TARPN approach is way too rigid. I understand why it is what it is, but it's too inflexible. It can't handle terrain, or low population density, at all. In the driftless region of the upper Mississippi River valley where I am we are lucky enough to have club equipment on county-owned towers at 300 and 350ft on top of a bluff. We are running two VHF ports on the BPQ node there and it, for better or worse, is the glue holding the local packet community together. Before it was in service, members of my local club couldn't make any packet connections that weren't extremely local. Hams in the next town down the river were in the same boat (haha,) and the communities to the west couldn't connect due to hundreds of feet of limestone between them. Having two ports, one for the Wisconsin side of the river and one for the Minnesota side help to keep congestion down, but I could see how this design would fall flat if there were a few dozen more users.
TARPN would never work here. Height is might on VHF and UHF. to do this within TARPN rules someone would have to buy land on a bluff, build a shack or house, and then put up a several hundred foot tower, then put up half a dozen yagis with half a dozen radios, etc... Sure it would handle heavy use better but nobody has the money for that.
We use BPQ's chat system for weekly nets as well as public service events. The lack of user ports on TARPN would either preclude the service events, or make the amount of required equipment much greater. Rather than a laptop and HT with a built-in TNC, a rest stop now needs an RPi as well as a dedicated antenna/frequency on the station it will connect to.
I'm a fan of limiting cell sizes and using dedicated P2P links (AX.25, AREDN, NPR, or whatever) to connect the cells together. This also (hopefully) reduces the number of required hops to access shared resources.
I haven't tried the bit-regenerative repeater method yet. It seems like it would be great for peer-to-peer type connectivity. Hopefully I will have the opportunity to test this in the future.
These thoughts have always been my issue with adopting a TARPN network here in the Northeast. Building any type of packet network teaching people how data networks actually work with many users is where we are failing. Because we haven't seemed to create a teaching aid that shows how collisions happen on a single store and forward single frequency network, the understanding of how detrimental that is and how a network capacity and throughput falls to it's knees. Today because packet has low user counts, it's hasn't become very obvious. Before the days of the internet, when we had a lot more packet users, we learned this. That is why the old NEDA group really did a good job of teaching the concept and as such they built a real backbone network to minimize the effect. People are learning the lesson all over again, I see the issues with ARDEN networks where they try to do too much on a single node on one frequency (REALLY evident when you do more than one video UDP streams on the same node) and the Meshtastic guys are learning this same lesson as the participant count increases. Their busy networks are seeing their coverage ranges decrease, mostly due to packet collisions and subsequently not decoding properly.
High tower sites are usually restricted access for good reason, they are located with other non-ham users and you don't want people in those sites in there that might do things that would cause problems for other users on the tower. You do mention the reason why they are still very much needed and I agree. Not having users ports are also a hindrance to using packet networks for portable emergency data networks for the exact reason you mention. I am not saying TARPN is wrong, its just not the right solution for all situations. That's ok as long as your group understands the pro's and con's of both methods.
Brian - I think the "loss of tribal knowledge" about building Amateur Radio data networks is a big factor in our current situation of fragmented Amateur Radio data networks with varying technologies and systems. We all used to work from a common "knowledge base" with TAPR PSR, ARRL Gateway, books that we all bought and read, etc. Not so much now - we're pretty fragmented and I think us that have visions of better Amateur Radio data network might need a "level up reset" where we all educate ourselves about what the options ARE to build new networks / rebuild or update existing networks. That's one of the reasons I'm so excited about the potential of the new MMDVM-TNC and fitting that technology into existing FM repeaters. We could rapidly create communities of Amateur Radio data around the repeaters, link the data function on the repeaters via "bridge / routers" that can access multiple repeaters, and then go on from there to build dedicated links ala TARPN.
TARPN would work fine there. As long as someone has reasonable access to the site, it's fine. But that ridge node still wouldn't be a user port.
Yeah, there would be some political and financial things to work out if we ever went that way. Site access is easy (as long as you own a pair of snowshoes for when the weather gets bad) but being a county-owned site any climbing requires someone licensed and insured. We used to have someone in the club but he retired and doesn't like going up that high anymore. I can't say I blame him. That makes climbing pretty expensive, as well as opens the can of worms of who pays for the climber, feedline, and additional antennas. Rough back-of-the-napkin figuring would indicate that we would need to add 3-4 additional ports.
I'm genuinely curious how other groups handle this, even on private home installations. Let's say Bob moves in to a new town and wants to join the TARPN network there. Alice lives a few miles away and is an easy contact for Bob. She lives on a hill and has a connection to Charlie in the next town. Does Alice buy the extra equipment for her shack to connect to Bob, or is Bob expected to help? You see how this could get sticky with club politics too where maybe 10% of club members are interested in the activity.
The other political situation would involve the County. Our club has free, exclusive use of the tower because of the public service aspect. Emcomm too a little since there is a 440MHz repeater there that covers dead spots in the counties radio system--spots that are prone to flooding of course. Taking the user port away would mean taking down the Winlink gateway which the emergency manager likes having, as well as making the public service events difficult. I'm guessing in the next couple of years Starlink will take over for the Winlink side of things and hopefully the club doesn't find itself looking for a new tower.
The one aspect of TARPN that I don't see stressed is ARES/RACES, I get the impression the networks are built more for fun and experimenting. Groups that see and use packet more for backups/ARES/RACES/ do things differently as you state Ben. Here in NY the state RACES organization pushed to keep the packet networks running and the state department of homeland security does their best with their technicians and climbers to to support the efforts. That process is slow even with their help because they have no many other priority projects that keep them busy. Locally we are fortunate that our County actively supports RACES and we have limited but good tower access. We usually get a small budget to do small projects as well, which has allowed us to also start including AREDN equipment.
Brian - I'm... pessimistic, or perhaps realistic, that the capabilities of Starlink are rapidly going to displace Amateur Radio in EMCOM situations. I can easily foresee a small, trailerable package (think something the size of a "light tower") that combines solar panel, battery, Starlink, Wi-Fi, and perhaps a local repeater for tactical comms that can be remoted via Starlink. There's also Iridium "portable radios" that are the same functionality as conventional radio, but work with no infrastructure other than being able to see the sky. And there's also FirstNET that's doing the same thing, only with cellular service that's finally, genuinely prioritized, hardened, and availability monitored by the US Government's NTIA. It's also now possible to have a localized, private cell phone service using CBRS spectrum. Not many EMCOM organizations are there yet, but I think it's inevitable. I think that Amateur Radio ARES / RACES / ACES groups (and their support organizations) should recognize that this transition IS coming and work to get ahead of it, and embrace newer technologies as ITDRC (https://www.itdrc.org) does.
Oh I wholeheartedly agree and I own a trailer like that. Our county RACES group has 3 other trailers like that as well and we make use of IP Cameras and AREDN links extensively. These routinely get deployed as portable traffic cameras sites to support events such as Triathlons, motocross races, and other large public events (For us a big one is the National Baseball Hall of Fame Inductions Ceremony) where we actually staff command posts and our EOC managing video streams to monitor crowds and traffic in and around the events. Here is a post about the Hall of Fame event last summer with pictures of the trailers and improvements made inside the EOC https://www.facebook.com/groups/1309131859113362/posts/7200641083295714/
Ben - I'm in agreement with you. Like you, I understand why NCNet (and others) developed and chose the TARPN methodology. It certainly does have many positive attributes... and provably it works to develop and grow an Amateur Radio data network. Also like you, I appreciate the challenges of terrain in the Midwest (my experience was in Central and Northern Ohio) and yeah, height pretty much trumps most other aspects on VHF / UHF. I don't think there is a "best" Amateur Radio data network methodology - mostly it's what the local Amateur Radio community can agree upon, build up, maintain, and support and MOST importantly, what it's prepared to EVANGELIZE to new and prospective Amateur Radio Operators. If it's operated as "let's just keep it limping along - I don't want to see it die..." then you can hardly expect to see newcomers getting excited. That factor alone is why there is so much enthusiasm about Meshtastic - it's certainly not "better" than Amateur Radio data networks... but it's new, it's being presented with enthusiasm, and it's gaining a lot of newcomers into the idea of low speed data networks independent of cellular, Internet, satellite, or any other infrastucture. I think the biggest factor about Meshtastic is that techie experimenters are beginning to understand that radio can be used for more than Wi-Fi, Bluetooth, cellular, satellite, or broadcasting.
The bit-regenerating repeater has a lot of other possibilities that are not possible when just passing audio. For instance, the receiver side could collect data from multiple frequencies and/or bands, and queue them out the single transmitter as a continuous 9600 bit stream. An SDR receiver would make this highly flexible. You could have data coming in on 1200bps 2m packet to support people with old fm radios, and maybe 9600 on 70cm, all APRS traffic from 144.39, or even multiple input channels for different kinds or priorities of traffic (Eg., send your long transmissions on low-priority channel A, and use your real time chat program on channel B, the latter will get re-transmitted right away).
You could even think of ways to make further use of that transmitter time. Perhaps send it some data to beacon every hour for a day, ultra-low priority bits on the transmitter. I'm thinking radar maps someone is pulling from wx satellites or the club newsletter or something like that.
All users would basically pick an uplink frequency based on capability and traffic type, and everyone would listen to the same data stream on the repeater out. That 9600bps transmitter can conceivably transmit 100mb per day if it's capable of 100% transmission time. A bit-regenerating repeater could actually do it and provide for a LOT of activity.
Jason - Reimagining the roles / uses / functions of repeaters in Amateur Radio is, and will be a recurring theme here in Zero Retries. I think that, like HF, repeaters are an Amateur Radio superpower that can't easily be matched by other radio services. GMRS also has repeaters, but limited in power and functionality - FM voice only (no data... currently), Meshtastic / LoRa data rate is low (LoRaWAN is a paid [I think] system), etc. Amateur Radio can do so many things. I can imagine what you're proposing, as well as being able to link repeaters together on RF (with the simple expedient of a repeater being upgraded with a Software Defined Receiver to monitor other repeaters), and the potential to do flood data transmissions for files, bulletins etc. (see http://www.w1hkj.com/files/manuals/US_English/FLAmp_2.2_Users_Manual.pdf#section.1.1) and even using the concepts of a PACSAT, which is being revived for a future AMSAT satellite payload.