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
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.
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 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.
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.
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.
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.
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.
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
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?
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?
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.
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.
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.
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.
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.