Topics

Packet

Vincent
 

Hi everyone, my first post here.

I have been toying with the idea of setting up a Raspberry pi based BBS system for a very small number of users ( 2 to 5) at slow speeds (1200 and less). I have been away from Ham radio especially packet for years and I can now see that there is a move away from hardware TNC's to software modems. After a little bit of searching I found TNC board from W2FS, the TNC Pi.

I wonder if I may ask a newbee question: is there anything to be gained or lost choosing a box TNC over a software solution maybe like Direwolf ?

 

Mark Griffith
 


Vincent,

The TNC-Pi from W2FS is no longer available since he has retired and closed his business. MFJ is supposed to be soon selling a new TNC board John designed, but they are slowed in getting this done due to the virus situation.

The WVARC is selling the TNC-Pi9k6 which is a drop-in replacement for the TNC-Pi and also has 9600 baud capability. Their project is at https://www.wvcarc.com/p/tnc-96k-resources.html. You can get to their online store at https://www.etsy.com/shop/WVCARC where you can buy the TNC as a kit or assembled. The assembled price of $87 is pretty good and I doubt the TNC-Pi from MFJ will be much less.

Direwolf on the Raspberry Pi works, but it has a problem with locking up if left running for several days, which requires a reboot to fix. If this doesn't bother you, Direwolf works just fine.

I prefer hardware solutions when they are available, but that is just me. One less thing to worry about.

Check out John Wiseman's linbpq on the Raspberry Pi for a great BBS solution. http://www.cantab.net/users/john.wiseman/Documents/index.html

Mark
KD0QYN


On Thursday, May 28, 2020, 02:57:29 AM CDT, Vincent <panserv@...> wrote:


Hi everyone, my first post here.

I have been toying with the idea of setting up a Raspberry pi based BBS system for a very small number of users ( 2 to 5) at slow speeds (1200 and less). I have been away from Ham radio especially packet for years and I can now see that there is a move away from hardware TNC's to software modems. After a little bit of searching I found TNC board from W2FS, the TNC Pi.

I wonder if I may ask a newbee question: is there anything to be gained or lost choosing a box TNC over a software solution maybe like Direwolf ?

Noel Petit
 

Dire wolf doesn’t freeze up with a Pi 3+ running DW 1.4 with the latest Raspbian. WB0VGI-1 has run for months without stopping. Audio in and out with the USB interface and PTT via PIO pin.

Noel Petit

Allen
 

Mark,
   When you mentioned about the lockup after days of being on that got me thinking about the OS my past company had that did the same thing. As long as it rebooted every few days all was good. It had to do with when it was always looking for other AP's to mesh with the memory would not dump correctly. Within the firmware (OS) it had a reboot setup . We set it for every night at a late hour and everything ran for years. Something about memory not dumping within the OS. Can this be applied here? We spent  $$$$ for the OS and support. They raked the company over the coals. We tried another coder and platform both here in the U.S.A. and we ran into the same memory stacking issue. So go figure. The rebooting worked on both platforms. I just thought if someone wanted to do an experiment on this Direwolf software it might be a work around. Just my 2 cents.
Allen Higgins
KE8KZO

 

Direwolf can pull out weaker signals and does some bit error correction.  Also you have the option of additional data rates.  You may want to look at DRAWS™ to interface to your radio(s) and run Direwolf, plus applications.

On Thu, May 28, 2020 at 12:57 AM Vincent <panserv@...> wrote:

Hi everyone, my first post here.

I have been toying with the idea of setting up a Raspberry pi based BBS system for a very small number of users ( 2 to 5) at slow speeds (1200 and less). I have been away from Ham radio especially packet for years and I can now see that there is a move away from hardware TNC's to software modems. After a little bit of searching I found TNC board from W2FS, the TNC Pi.

I wonder if I may ask a newbee question: is there anything to be gained or lost choosing a box TNC over a software solution maybe like Direwolf ?

 



--
John D. Hays
Kingston, WA
K7VE

 

 

Direwolf is pretty solid, I run it for months without "lock ups" 

On Thu, May 28, 2020 at 8:38 AM Allen <alhiggins@...> wrote:
Mark,
   When you mentioned about the lockup after days of being on that got me thinking about the OS my past company had that did the same thing. As long as it rebooted every few days all was good. It had to do with when it was always looking for other AP's to mesh with the memory would not dump correctly. Within the firmware (OS) it had a reboot setup . We set it for every night at a late hour and everything ran for years. Something about memory not dumping within the OS. Can this be applied here? We spent  $$$$ for the OS and support. They raked the company over the coals. We tried another coder and platform both here in the U.S.A. and we ran into the same memory stacking issue. So go figure. The rebooting worked on both platforms. I just thought if someone wanted to do an experiment on this Direwolf software it might be a work around. Just my 2 cents.
Allen Higgins
KE8KZO



--
John D. Hays
Kingston, WA
K7VE

 

Bill WA4OPQ
 

If you are looking for a hardware solution I should also mention a new product: TARPN's NinoTNC. I just assembled mine yesterday and am still testing.

The cost is unbeatable: The board and CPU is $7 and the parts are $25 from Digikey.

NinoTNC

David Ranch
 


I'll admit I'm biased towards DIrewolf but it's for good reason as it's decode rates are better than ANY hardware TNC out there.  See the appendix of the Direwolf User-Guide to see measurements.  The other benefit here is that it's also free, doesn't require any hardware, and is being constantly improved (now has AX.25 v2.2, FX.25, etc).

--David
KI6ZHD


On 05/28/2020 12:25 AM, Vincent wrote:

Hi everyone, my first post here.

I have been toying with the idea of setting up a Raspberry pi based BBS system for a very small number of users ( 2 to 5) at slow speeds (1200 and less). I have been away from Ham radio especially packet for years and I can now see that there is a move away from hardware TNC's to software modems. After a little bit of searching I found TNC board from W2FS, the TNC Pi.

I wonder if I may ask a newbee question: is there anything to be gained or lost choosing a box TNC over a software solution maybe like Direwolf ?


Mark Griffith
 

Allen,

First let me say I have NOTHING against Direwolf and I fully support those hams that are giving up their time to add to the hobby. I developed the PiGate and PiGate RMS devices, so I'm in that group. I also fully support those hams that are building hardware solutions and there are a few.

The author of Direwolf advises to reboot it on a regular basis. My testing showed that that was true. You could setup a periodic reboot pretty easily on the Raspberry Pi and that would correct any issues that may be there. My point of view is using it with the PiGate and PiGate RMS devices. Since they are designed for emergency use, I would initially say periodic reboots would be unnecessary since these devices would only be in use for a day or two and then shut down until the next emergency.

However, there are lots of folks that use them all the time as 24/7 Winlink email clients or Winlink RMS stations. I have three that are running all the time. The problem then, is when to do a reboot? It would be unfortunate to do an automatic reboot when it is processing an email, or some other necessary function was running. I suppose you could programmatically look to see if something was going on and delay the reboot, but that just adds another layer of complexity.

Others here have said Direwolf does not lock up on them. Perhaps I need to retest, although my tests were done about 6 months ago and Direwolf has not been updated since Oct 2018. I would hate to be advising people on something that is not true.

I spent a lot of time a few years ago looking for a reliable and fairly easy packet communications system to send emergency email through Winlink. I tested all the software solutions that were available at the time and decided to build the PiGate and PiGate RMS devices because I could not find what I was looking for. In my opinion, and anyone is free to think otherwise, the PiGate and PiGate RMS are the most reliable and easy to use setup. This is based upon years of testing and development, and the excellent work of others like Basil Gunn with paclink-unix and John Wiseman with linbpq. My standards are if you can boot a device and do nothing else, and it continues to work month after month without any maintenance, then it is reliable. You get that with the PiGate systems.

And that is my two cents.

Mark
KD0QYN


On Thursday, May 28, 2020, 10:38:20 AM CDT, Allen <alhiggins@...> wrote:

Mark,

When you mentioned about the lockup after days of being on that got me thinking about the OS my past company had that did the same thing. As long as it rebooted every few days all was good. It had to do with when it was always looking for other AP's to mesh with the memory would not dump correctly. Within the firmware (OS) it had a reboot setup . We set it for every night at a late hour and everything ran for years. Something about memory not dumping within the OS. Can this be applied here? We spent $$$$ for the OS and support. They raked the company over the coals. We tried another coder and platform both here in the U.S.A. and we ran into the same memory stacking issue. So go figure. The rebooting worked on both platforms. I just thought if someone wanted to do an experiment on this Direwolf software it might be a work around. Just my 2 cents.
Allen Higgins
KE8KZO

Jim Erickson
 

The author of Direwolf advises to reboot it on a regular basis?  Where have you read that?  I’m clearly in the other group in that my Direwolf runs flawlessly, 24/7 with no need to reboot or restart.  Doesn’t matter whether I’m running it on my Linux desktop or my Raspberry Pi, whether I’m using it for APRS, Winlink or packet, I’ve never had it lock up.

My 2 cents.
------
73,
Jim
VA7SHG - Phone
VE7TGZ/VA7TGZ - Other

On May 28, 2020, at 09:44, Mark Griffith via groups.io <mdgriffith2003@...> wrote:

Allen,

First let me say I have NOTHING against Direwolf and I fully support those hams that are giving up their time to add to the hobby. I developed the PiGate and PiGate RMS devices, so I'm in that group. I also fully support those hams that are building hardware solutions and there are a few.

The author of Direwolf advises to reboot it on a regular basis. My testing showed that that was true. You could setup a periodic reboot pretty easily on the Raspberry Pi and that would correct any issues that may be there. My point of view is using it with the PiGate and PiGate RMS devices. Since they are designed for emergency use, I would initially say periodic reboots would be unnecessary since these devices would only be in use for a day or two and then shut down until the next emergency.

However, there are lots of folks that use them all the time as 24/7 Winlink email clients or Winlink RMS stations. I have three that are running all the time. The problem then, is when to do a reboot? It would be unfortunate to do an automatic reboot when it is processing an email, or some other necessary function was running. I suppose you could programmatically look to see if something was going on and delay the reboot, but that just adds another layer of complexity.

Others here have said Direwolf does not lock up on them. Perhaps I need to retest, although my tests were done about 6 months ago and Direwolf has not been updated since Oct 2018. I would hate to be advising people on something that is not true.

I spent a lot of time a few years ago looking for a reliable and fairly easy packet communications system to send emergency email through Winlink. I tested all the software solutions that were available at the time and decided to build the PiGate and PiGate RMS devices because I could not find what I was looking for. In my opinion, and anyone is free to think otherwise, the PiGate and PiGate RMS are the most reliable and easy to use setup. This is based upon years of testing and development, and the excellent work of others like Basil Gunn with paclink-unix and John Wiseman with linbpq. My standards are if you can boot a device and do nothing else, and it continues to work month after month without any maintenance, then it is reliable. You get that with the PiGate systems.

And that is my two cents.

Mark
KD0QYN


On Thursday, May 28, 2020, 10:38:20 AM CDT, Allen <alhiggins@...> wrote:

Mark,

When you mentioned about the lockup after days of being on that got me thinking about the OS my past company had that did the same thing. As long as it rebooted every few days all was good. It had to do with when it was always looking for other AP's to mesh with the memory would not dump correctly. Within the firmware (OS) it had a reboot setup . We set it for every night at a late hour and everything ran for years. Something about memory not dumping within the OS. Can this be applied here? We spent $$$$ for the OS and support. They raked the company over the coals. We tried another coder and platform both here in the U.S.A. and we ran into the same memory stacking issue. So go figure. The rebooting worked on both platforms. I just thought if someone wanted to do an experiment on this Direwolf software it might be a work around. Just my 2 cents.
Allen Higgins
KE8KZO


Troy - K4JDA
 

There's also the NinoTNC from TARPN (less than $30 to build) 
http://tarpn.net/t/nino-tnc/n9600a/n9600a_info.html

and the NucleoTNC design from Mobilinkd (less than $30 to build)
http://www.mobilinkd.com/2019/06/24/nucleotnc/

John Wiseman has recently released a Raspberry Pi port of UZ7HO Soundmodem:
https://www.cantab.net/users/john.wiseman/Documents/QtSoundModem.html

So there are quite a few options.  

 

Last updates on Direwolf were a couple of days ago.  Active users of Direwolf build updated versions since distributions tend to be slow to include updates.  https://github.com/wb2osz/direwolf/commits/dev

On Thu, May 28, 2020 at 9:44 AM Mark Griffith via groups.io <mdgriffith2003=yahoo.com@groups.io> wrote:
Allen,

First let me say I have NOTHING against Direwolf and I fully support those hams that are giving up their time to add to the hobby. I developed the PiGate and PiGate RMS devices, so I'm in that group. I also fully support those hams that are building hardware solutions and there are a few.

The author of Direwolf advises to reboot it on a regular basis. My testing showed that that was true. You could setup a periodic reboot pretty easily on the Raspberry Pi and that would correct any issues that may be there. My point of view is using it with the PiGate and PiGate RMS devices. Since they are designed for emergency use, I would initially say periodic reboots would be unnecessary since these devices would only be in use for a day or two and then shut down until the next emergency.

However, there are lots of folks that use them all the time as 24/7 Winlink email clients or Winlink RMS stations. I have three that are running all the time. The problem then, is when to do a reboot? It would be unfortunate to do an automatic reboot when it is processing an email, or some other necessary function was running. I suppose you could programmatically look to see if something was going on and delay the reboot, but that just adds another layer of complexity.

Others here have said Direwolf does not lock up on them. Perhaps I need to retest, although my tests were done about 6 months ago and Direwolf has not been updated since Oct 2018. I would hate to be advising people on something that is not true.

I spent a lot of time a few years ago looking for a reliable and fairly easy packet communications system to send emergency email through Winlink. I tested all the software solutions that were available at the time and decided to build the PiGate and PiGate RMS devices because I could not find what I was looking for. In my opinion, and anyone is free to think otherwise, the PiGate and PiGate RMS are the most reliable and easy to use setup. This is based upon years of testing and development, and the excellent work of others like Basil Gunn with paclink-unix and John Wiseman with linbpq. My standards are if you can boot a device and do nothing else, and it continues to work month after month without any maintenance, then it is reliable. You get that with the PiGate systems.

And that is my two cents.

Mark
KD0QYN


On Thursday, May 28, 2020, 10:38:20 AM CDT, Allen <alhiggins@...> wrote:

Mark,

When you mentioned about the lockup after days of being on that got me thinking about the OS my past company had that did the same thing. As long as it rebooted every few days all was good. It had to do with when it was always looking for other AP's to mesh with the memory would not dump correctly. Within the firmware (OS) it had a reboot setup . We set it for every night at a late hour and everything ran for years. Something about memory not dumping within the OS. Can this be applied here? We spent $$$$ for the OS and support. They raked the company over the coals. We tried another coder and platform both here in the U.S.A. and we ran into the same memory stacking issue. So go figure. The rebooting worked on both platforms. I just thought if someone wanted to do an experiment on this Direwolf software it might be a work around. Just my 2 cents.
Allen Higgins
KE8KZO



--
John D. Hays
Kingston, WA
K7VE

 

 

https://groups.io/g/direwolf  -- Direwolf community and support group


--
John D. Hays
Kingston, WA
K7VE

 

 

Vincent, 
  There is a project I’ve been working on for a while to create off-the-grid social networks entirely using Amateur Radio, Raspberry PIs, and NO INTERNET for transport.  Just ham radio. 
We’re using design rules which provide for really decent transport using really trivial equipment.  It’s pretty easy to get 2400 baud on surplus commercial 2-way radios.  We had some issues with the performance of the TNC-PI, which was our go-to Radio to Raspberry PI device until recently.  We messed around with Direwolf for a while and I can tell you it works very well.  My only complaints with it were that what we were trying to do with it really wanted a very good sound-card and we wanted our network stations to be scale-able.  Cost wasn’t as much an issue as simplicity.  Our group ended up designing and building our own TNC idealized for our specific project.  We’re giving away the PCBs and CPUs for cost and pointing any outsider at Digikey with a parts list.  People in our local area (central NC) can get the parts from our volume purchase which saves some money. Even in single lots, our hardware USB KISS quad-speed DSP based “NinoTNC" is only $33 delivered to US customers in singles.  You can save $15 or so in shipping by buying and building 2.  No profit taken, and that gives us a little bit of a price advantage!  We can support 8 of the TNCs on a single Raspberry PI with our configuration.  
  Our project uses G8BPQ’s PILINBPQ program for BBS, CHAT and network switch.  

  Our assembly instructions, configuration instructions and whatnot are designed for “every-ham” and we do tech support, promotion and whatnot on groups.io.  

Please check out our web site at http://tarpn.net.  Our TNC is presented on http://tarpn.net/d 

 We use dedicated point to point links for our network for no-compromise performance.  With the 2400 baud mode in our TNC and an off-the-shelf ham radio or commercial 2-way radio we can get on the order of 50 characters per second on multiple links at the same time, asynchronous RX/TX operation for the set of radios.  It’s very nice for running a 20 station CHAT system.    It’s quite cool.  The UI is pretty polished and runs in a web browser anywhere in your house’s LAN, including on tablets and smart-phones.  We swear not to run it over the Internet.  Internet connectivity to the network is entirely by ham-in-the-middle copy and paste.  

  Of-the-grid social network, No Internet required, No Internet desired.  

   Is this what you were thinking of?   The name of our project is Terrestrial Amateur Radio Packet Network, aka TARPN.   We’re really trying to build very large packet networks enabling any-ham to build and participate.  Every station is a backbone hub.  Every station can run any server.  Just no Internet.  It’s quite a kick.  

  Search Youtube for TARPN and NCPACKET. 


        Tadd


On May 28, 2020, at 3:25 AM, Vincent <panserv@...> wrote:

Hi everyone, my first post here.

I have been toying with the idea of setting up a Raspberry pi based BBS system for a very small number of users ( 2 to 5) at slow speeds (1200 and less). I have been away from Ham radio especially packet for years and I can now see that there is a move away from hardware TNC's to software modems. After a little bit of searching I found TNC board from W2FS, the TNC Pi.

I wonder if I may ask a newbee question: is there anything to be gained or lost choosing a box TNC over a software solution maybe like Direwolf ?

 

Mark Griffith
 

I guess I need to test it some more.

Mark
KD0QYN

On Thursday, May 28, 2020, 12:07:31 PM CDT, John D Hays - K7VE <john@...> wrote:


Last updates on Direwolf were a couple of days ago.  Active users of Direwolf build updated versions since distributions tend to be slow to include updates.  https://github.com/wb2osz/direwolf/commits/dev

On Thu, May 28, 2020 at 9:44 AM Mark Griffith via groups.io <mdgriffith2003=yahoo.com@groups.io> wrote:
Allen,

First let me say I have NOTHING against Direwolf and I fully support those hams that are giving up their time to add to the hobby. I developed the PiGate and PiGate RMS devices, so I'm in that group. I also fully support those hams that are building hardware solutions and there are a few.

The author of Direwolf advises to reboot it on a regular basis. My testing showed that that was true. You could setup a periodic reboot pretty easily on the Raspberry Pi and that would correct any issues that may be there. My point of view is using it with the PiGate and PiGate RMS devices. Since they are designed for emergency use, I would initially say periodic reboots would be unnecessary since these devices would only be in use for a day or two and then shut down until the next emergency.

However, there are lots of folks that use them all the time as 24/7 Winlink email clients or Winlink RMS stations. I have three that are running all the time. The problem then, is when to do a reboot? It would be unfortunate to do an automatic reboot when it is processing an email, or some other necessary function was running. I suppose you could programmatically look to see if something was going on and delay the reboot, but that just adds another layer of complexity.

Others here have said Direwolf does not lock up on them. Perhaps I need to retest, although my tests were done about 6 months ago and Direwolf has not been updated since Oct 2018. I would hate to be advising people on something that is not true.

I spent a lot of time a few years ago looking for a reliable and fairly easy packet communications system to send emergency email through Winlink. I tested all the software solutions that were available at the time and decided to build the PiGate and PiGate RMS devices because I could not find what I was looking for. In my opinion, and anyone is free to think otherwise, the PiGate and PiGate RMS are the most reliable and easy to use setup. This is based upon years of testing and development, and the excellent work of others like Basil Gunn with paclink-unix and John Wiseman with linbpq. My standards are if you can boot a device and do nothing else, and it continues to work month after month without any maintenance, then it is reliable. You get that with the PiGate systems.

And that is my two cents.

Mark
KD0QYN


On Thursday, May 28, 2020, 10:38:20 AM CDT, Allen <alhiggins@...> wrote:

Mark,

When you mentioned about the lockup after days of being on that got me thinking about the OS my past company had that did the same thing. As long as it rebooted every few days all was good. It had to do with when it was always looking for other AP's to mesh with the memory would not dump correctly. Within the firmware (OS) it had a reboot setup . We set it for every night at a late hour and everything ran for years. Something about memory not dumping within the OS. Can this be applied here? We spent $$$$ for the OS and support. They raked the company over the coals. We tried another coder and platform both here in the U.S.A. and we ran into the same memory stacking issue. So go figure. The rebooting worked on both platforms. I just thought if someone wanted to do an experiment on this Direwolf software it might be a work around. Just my 2 cents.
Allen Higgins
KE8KZO



--
John D. Hays
Kingston, WA
K7VE

 

David Ranch
 


Hello Mark,

Direwolf on the Raspberry Pi works, but it has a problem with locking up if left running for several days, which requires a reboot to fix. If this doesn't bother you, Direwolf works just fine.

Please stop sending FUD (fear, Uncertainty, and Doubt) about the stability of Direwolf as this is patently WRONG.  I have a Raspberry Pi 3 running Direwolf v1.5 as an APRS Igate which has been running for 227 days and has processed 910,537 APRS/AX.25 frames.  This is all without any form of auto-restart of Direwolf, etc.  I would call that VERY reliable.


When I see people having stability issues with their Direwolf (or general Raspberry Pi) setups, most of those users either have:

   - are using a bad power supply (undervolt)
   - RFI issues (the radio is too close to the Raspberry Pi)
   - poor quality SD card (not using a name brand Class-10 micro-SD card
   - user has not hardened their Pi NOT to send logs to a RAM drive, have a basic firewall, etc
   - etc


I prefer hardware solutions when they are available, but that is just me. One less thing to worry about.

Your choice but software-based TNCs can do a lot more than any hardware TNC out there and perform with better decode rates.  Up to the user.

--David
KI6ZHD

Mark Griffith
 


Hey, let's be civil here. I did some good tests, on Raspberry Pi's that were in excellent shape, and found that Direwolf hung after a few days. If you disagree with my results, you can disagree, but let's not start name calling.

Your results may be different, and I can do more tests to verify my results, but I am not in the business of trying to put down Direwolf as I said. I'm sorry to see you get so hot under the hood.

Mark
KD0QYN

On Thursday, May 28, 2020, 01:18:24 PM CDT, David Ranch <rpi4hamradio-groupsio@...> wrote:



Hello Mark,

Direwolf on the Raspberry Pi works, but it has a problem with locking up if left running for several days, which requires a reboot to fix. If this doesn't bother you, Direwolf works just fine.

Please stop sending FUD (fear, Uncertainty, and Doubt) about the stability of Direwolf as this is patently WRONG.  I have a Raspberry Pi 3 running Direwolf v1.5 as an APRS Igate which has been running for 227 days and has processed 910,537 APRS/AX.25 frames.  This is all without any form of auto-restart of Direwolf, etc.  I would call that VERY reliable.


When I see people having stability issues with their Direwolf (or general Raspberry Pi) setups, most of those users either have:

   - are using a bad power supply (undervolt)
   - RFI issues (the radio is too close to the Raspberry Pi)
   - poor quality SD card (not using a name brand Class-10 micro-SD card
   - user has not hardened their Pi NOT to send logs to a RAM drive, have a basic firewall, etc
   - etc



I prefer hardware solutions when they are available, but that is just me. One less thing to worry about.


Your choice but software-based TNCs can do a lot more than any hardware TNC out there and perform with better decode rates.  Up to the user.

--David
KI6ZHD

Allen
 

Mark,
I did not intend to come off as bashing the  creation of the software. I was responding to a statement.  I habeen on both sides of firmware OS . It was a workaround to locking up becausr of memory stacking and not dumping. That is an observation of my locking issues. Sorry if my words led you to bilieving i was bashing.
--
Allen Higgins
Brunswick, Ohio
KE8KZO

Mark Griffith
 

Allen,

No apologies necessary. I did not think you were bashing. I'm sorry if you thought I thought that you thought that maybe......well, you get the message. :)

Mark
KD0QYN


On Thursday, May 28, 2020, 01:56:25 PM CDT, Allen <alhiggins@...> wrote:


Mark,
I did not intend to come off as bashing the creation of the software. I was responding to a statement. I habeen on both sides of firmware OS . It was a workaround to locking up becausr of memory stacking and not dumping. That is an observation of my locking issues. Sorry if my words led you to bilieving i was bashing.
--
Allen Higgins
Brunswick, Ohio
KE8KZO

Troy - K4JDA
 

From the traffic on several groups.io boards, seems like the is a definite increase in interest in packet operations lately ... it’s a good thing to see!