9.6k Packet Myths – 9600 baud packet is not much faster than 1200 baud

July 16, 2019

Claim:  9600 baud packet is not much faster than 1200 baud.

Fact Check:  Not true. Well that is unless you have a strange definition of “not much faster.”

9600 baud packet may not be 8 times faster, but 5+ times faster throughput can be easily obtained off a user port if decent radios are used. If backbone grade radios are used then you can make 9600 go faster. Use backbone grade radios on a full duplex link then it will really push some bits along.

Real world example? After completing some project work at a client’s location down on the river I ran some quick tests off our 2m 1200 baud and 70cm 9600 baud user ports. Same client radio, same antenna, same software, same modem, linking to the same RMS.

Not a lab grade test, but a very “real world” and fair test. Both ports used on the remote RMS are user ports configured as they have been for years. The 2m port is ran about as aggressive as you would want on a 1200 baud port with a variety of client radios connecting. This also includes some users running soundcard interfaces that are often a bit slower on TX<>RX turnaround/recovery times. The 9600 baud port is also running somewhat restrained due to some users having slower radios.

Tests were from my FT-818 based portable HF Robust Packet, 1200 baud, and 9600 baud station using just a mobile antenna on the car in a parking lot. Just shy of a 15 mile mobile to base non-LOS link. It was 92F down on the river and I’d venture to say the “hot humid sunny afternoon effect” was in full effect. Trees are fully leafed out after a very wet spring so foliage losses are high. flat bands, elevated path losses, and some multi-path through the hills all equal a near worst case non-LOS link scenario for that path. Perfect for a real world test.

Could this be done in a more perfect lab like environment? Sure and those results would have value as long as one keeps in mind that the lab is not the real world. Nothing against lab tests, but we don’t operate in a lab here. Thus we prefer to see how things actually work out in the real world 😉

The TNC used on my end was a SCS Tracker DSP TNC running version 1.7m firmware. The RMS gateway was running as one of several applications on top of a BPQ32 node.  TNCs at the RMS Gateway are a KPC-9612+ for the 1200 baud port (so much for the myth that the Tracker is not compatible with Kantronics modems LOL) and a PacComm Spirit-2 TNC for the 9600 baud port. Both running in XKISS mode. Both those TNCs are arguably the gold standard for their particular uses.

Screen shots of the results speak for themselves….

9600 baud packet radio link test. 17k compressed, 28,791 bytes/min.

 

1200 baud packet radio link test. 17k compressed, 4,537 bytes/min.

Signals on my end were nearly full scale on 2 meters and floating around S9 to one bar over it on UHF. It was the middle of the afternoon on a hot sunny day down on the river with some terrain between my mobile and the site so some multipathing was in there but not severe.

Yes just like the Yaesu FT-817 and many of the VHF/UHF all-mode radios the Yaesu FT-818ND is a good radio for 9600 baud packet. It may be “new version bias” at play but I suspect the 818’s receiver is a bit better at 9600 baud. I would love to see ARRL Lab BER test data for it. Yes they are very similar, but contrary to popular myth there are some design changes in the FT-818 vs the FT-817…..hint take a look at the receiver section.

Nope I didn’t buy the FT-818 instead of another 817 for the extra watt of TX output advertised LOL. It is interesting lately watching how the manufactures have figured out how to market to (and milk) the growing appliance operator crowd in our hobby. I wanted to use my 817 for a remote IF radio in the 7-land shack so I needed a 2nd one for travel and 4-land.. The FT-817ND was out of stock and the 818 was on sale so that’s what I got, no regrets thus far.

Sidebar:  If you have a FT-817ND and are happy with it I don’t see a reason to go out and buy a FT-818. If you are in the market for your first or additional radio with the 817/818 capabilities and packaging then by all means consider the FT-818ND first.

FWIW I suspect the Tracker’s 1200 baud mode could use a bit more optimization to decode weak noisy signals better, but it appears the Tracker’s 9600 baud mode is working extremely well. The Tracker is a hybrid software/hardware TNC that can be firmware flashed (free downloads) with new features, bug fixes, and optimizations so it’s only been getting better over time. SCS has been great to work with on bug fixes and improvements.

Wondering what that binary attachment was? Here you go. A very useful graphic for those that work EmComm in the SE USA this weekend. With 9600 baud packet you can have that downloaded, reviewed, and moved onto other tasks before 1200 baud is halfway done downloading it.

Tropical Storm Barry weather graphic. Well under a minute to pull that down over 9600 baud packet radio versus nearly 4 minutes if you used 1200 baud.

True nearly 4 minutes versus a fraction of that may be NBD in some situations or a huge boost in messaging capacity and turn around time for other situations. Regardless, to claim 9600 baud packet is not much faster than 1200 baud is easily proven to be just another packet radio myth.

In closing I suspect this particular myth is just folks repeating what they heard or read as gospel. Sometimes I think it’s just an excuse to avoid learning something new and making packet radio even more useful. Regardless they obviously have never actually seen or used a properly configured 9600 baud packet system. Trust me once you use 9600 baud packet it will be painful to go back to 1200 baud for all but APRS and the lightest of duty needs.

No the above is not a dissing of 1200 baud packet in any way.  Hey, gotta be careful now that Perpetually Offended by Everything Syndrome seems to be infecting the hobby lately 😉

 

73
WA4ZKO


Inbox ?s Frequencies, 80 Meters?

November 5, 2018

Apparently starting blogging again after several months of being scarce results in a rash of inquiries. Since I have a rare Monday afternoon off after unpacking the car and running errands this morning I’ll tackle a couple things.

Frequency wise nothing has changed this year other than the addition of APRS to the six meter port of the Jonesville node. Below should make a good quick reference:

BPQ32 Node KYJVL - Jonesville, KY EM78PP 
Port 1: 441.0500 MHz 9.6k   (primary user port)
Port 2: 145.6900 MHz 1.2k   (user port)
Port 3: 223.6600 MHz 1.2k   (user port, low speed linking)
Port 4: WAN            (intrasite Canopy/VPN links)
Port 5: 28.1480 MHz USB RP  (user port)
Port 6: 50.6200 MHz 1.2k    (user port, APRS Digi/Gate)
 
NODE = K4KPN-4
BBS  = K4KPN-1
CHAT = K4KPN-13
RMS  = K4KPN-14

Some have asked if there will be an 80m RP port? Maybe a temporary one next Fall, but it will involve whether or not some spare gear becomes available. I’m not going to go “buy” gear just for an 80m port because it’s not going to be a viable band at the future site. Problem revolves around space constraints, local noise floors (80 is nasty there), and control op privileges.

10 meters may have to be it for HF depending on who eventually takes over daily control op responsibilities of all K4KPN gear. The two most likely future control ops are still “techs” so that plays into things – I’m doing some nudging LOL. The trustee/control op questions will be part of the decision making on what bands move to the future site. Technician class licensees can both use and be control ops of that 10 meter robust packet port above so NBD there.

 

WA4ZKO

 

 

 

 

 

 

 

 

 


K4KPN BBS & RMS Gateway are Available

June 9, 2018

KYPN would like to announce the full availability of the KYPN Dry Ridge BPQ32 based packet radio site as of June 9, 2018.

The following packet radio applications are available:

K4KPN-1    BBS
K4KPN-4    Node
K4KPN-13  Chat/Conference Server
K4KPN-14  RMS Gateway

The above packet radio applications are normally available 24x7x365 to appropriately licensed amateur radio operators on the following frequencies/modes:

SYSTEM PORTS:
441.0500 MHz 9600 baud *
145.6900 MHz 1200 baud
223.6600 MHz 1200 baud *
28.1480 MHz USB dial, 28.1495 CF, Robust Packet “NET10R” *
50.6200 MHz 1200 baud **
* High availability, primary port.
** Dual-use port, both general use & 6m APRS WIDE1-1 Digi

All 5 bands and 3 modes are published to the Winlink channel listing.

Recommended user software:

KYPN recommends Outpost Packet Message Manager version 3.0.0.333 for BBS access. Full installer is available for download here.

KYPN recommends Winlink Express v1.5.12.0 or newer for RMS access. Available for download from here.

More details can be found on the K4KPN-1 packet BBS under messages #1 thru 8.

More details in future blog posts and the work in progress draft KYPN System FAQ.

 

The KYPN team.


Packet Update, Winlink, Is Ham Radio Dying? Puerto Rico

May 26, 2018

Since the inbox shows some got worried when we went west early with only the APRS gate/digi project done I guess an update would be a good idea.

We went west for a friend’s wedding.  Pro Tip: Few things can compare to a wedding set against the Teton Mountains. Since we spent most of the post-holiday Winter season in 4-land I also had several 7-land biz/personal items needing attention. I flew back and the XYL is driving back as she wanted to stop and visit with her Iowa family.

For the worries about the packet stuff getting done this Spring/Summer? Well I had been waiting on two Liebert UPS systems to come in so I can finish up the power and remote control side of the “packet/HF” rack. They are in and this looks like a somewhat slow weekend/week ahead so we’ll see what gets done this week. completion time = good question. Between work and Dad’s health issues I’m not going to commit to any timelines on hobby stuff as I can barely nail down a work schedule beyond a week out. It is what it is, family and work come first.

What’s going to be put on the air?  Well I can say for sure that a 10m RP port and a UHF 9.6k port are coming. Our core occasional EMCOMM needs can be met by a local packet BBS with a 10m RP port plus a UHF 9.6k port. I’m still back-n-forth on spinning up the 2m/220 1.2k stuff. Granted we have lost several local ops in the last decade or so due to SK and job related moves, but I’m frankly more than a little shocked at how dead ham radio seems around here and across Kentucky.

A lot of area packet and voice infrastructure has came and gone within the last few years. “Lack of usage” is usually the reason given. Even worse I often hear sysops of existing gear commenting that they really can’t justify keeping unused stuff on the air. Several have said they’ll run it till they take storm damage then it will not be repaired. Use it or loose it folks.

APRS activity for “Dayton” seemed to be down somewhat. On that note, one of the western Kentucky ops emailed me that he came up for Dayton and could not hit a single Winlink packet gateway with his D710. I looked at the Winlink gateway map below and could only ask where are all the gateways? Lexington/Frankfort is a dead zone??? Several of the WKY gateways seem MIA. The SE KY gateway doesn’t exist, it is actually just a misconfigured Georgia gateway.

ky_rms_pkt_map_dayton_wknd_20180520

The other day I was at a tower site and tapped into a VHF-Hi antenna port to a nice true 6 dBd omni up at 210′ AHAG that I can hit repeaters from Lexington/Richmond, Louisville, and up into Dayton/Columbus from. Fired up Winlink Express, pulled the freshly updated channel list below and could not hit anything. Granted I was just using 4-5w from a FT-817 (very possible 25/45w could change things) to a 150-160 MHz optimized antenna. Still that’s not much of a gateway selection list compared to a few years ago. Lot of previously active systems around here are gone, misconfigured, or off the air for some reason. Yes I checked for the EMCOMM group.

RMS_Packet_few_20180526

Past chats with some of the Winlink sysops I know all reveal a common thread. Folks talk of wanting this or that infrastructure and it sees a brief burst of interest then activity just fades away. One sysop that shut his gateway down told me it was seven months before someone asked about his gateway’s status LOL.

In fairness this is not just a packet problem, we also see similar with the current state of D-Star, DMR, and the analog repeater scenes. I ran our group’s portable analog repeater from a couple sites from October 2017 till early May 2018. I kept it patched into a couple systems so I could both record and monitor any activity on it.  Over all that time the repeater’s total transmit time was just over 52 minutes. 99% of that was just the IDer running from lots of kerchunking, only four unique callsigns heard beyond mine, and two brief QSOs. As I told the guys, no need of risking that to storm damage for that amount of activity so it is back in storage till this Fall.

Several have commented that the hobby is dying a slow death. While I’m not going to be that dramatic the hobby is definitely facing some serious activity related challenges in most areas of the country. This even includes areas which used to be hotbeds of activity. We now have a boatload of paper hams and hams that have gone or remain inactive for a wide variety of reasons.

Kentucky has nearly 10,000 licensed hams so “where the heck are they?” is a fair and obvious question. I found it revealing awhile back when the primary ham radio mailing list for the state revealed only about 450 subscribers when they began a move to another mailing list system. I just looked and only around 190 have migrated to the new system after several months. One does not need to be a Harvard MBA to be floored by those numbers. Yes it’s easy to be a Negative Nate on this stuff, but Step 1 to fixing a problem is recognizing that you have one.

When asked about the latest ARRL licensing proposal I can only respond with “I  don’t think lowering our standards once again is going to change much. The downsides are many for a hobby of technical pursuits. I do thank the ARRL for the free lunch.”  For those wondering about the “free lunch” portion of that? Well I made a lunch bet back in 2016 that if ARRL membership continues to decline then expect another push to lower licensing standards.

To be blunt, the further “dumbing down” of the hobby is not the fix unless the problem revolves around fixing the flow of subscription/advertising money. You know it’s not like passing the current General class test is so difficult. Common to hear stories of folks that take the Tech test, pass it, then be handed the General for giggles and either pass it or barely fail it. It’s not like during the last solar cycle we had Techs piled up deep on the sweet chunk of 10m spectrum they already have access to. Since chasing “quantity” (ahem money) hasn’t worked out so well maybe it’s time to try focusing on quality?  I could go on and on but this post will likely be long enough as is LOL.

So back to VHF/UHF packet…..

Considering all the above I’m obviously going to have to ponder how much 1200 baud VHF gear I want to put on the air. Would it see enough BBS and Winlink usage to justify it? If it wasn’t for already having the gear and putting in the extra rack space for the remote HF-UHF station then it wouldn’t even be on the table for consideration.

 

My stance on Winlink….

I’ve never been overly warm to the VHF/UHF side of Winlink. It doesn’t make as much sense as the HF side of Winlink does. One of the locals did make a reasonable argument that since the Dry Ridge site serves several counties across a handful of power grids and ISPs then there are a few EMCOMM scenarios when VHF/UHF packet Winlink access could be useful, especially at 9600 baud.

I’ve never been a huge fan of Winlink for a variety of reasons. Some are security related, the abuse that goes on, software stability, software roadmap stability, and ability to audit what content is flowing over systems under my license. Let’s examine each one of these..

  1. Security remains a big concern. Moving things onto a certain cloud provider doesn’t help make one feel all warm and fuzzy but I get why they did it.
  2. The abusive use of Winlink on HF remains a concern. Sounds like it’s gotten worse now that the solar cycle has forced more and more of the HF Winlink folks down onto already crowded lower HF bands.
  3. Software stability issues remain. Client software glitches are one thing, but gateway software needs to be rock solid. We are now how many years into the development of the RMS software?
  4. The software roadmap appears as spastic as ever. There is really no reason why the version silliness needs to go on to the degree that it does. I mean come on after all this time surely we can have long term production versions that do the basics and do them well. Then have a beta fork for those that wish to play with whatever new shiny soundcard mode is the current rage. If I put RMS services on my gateway and it’s a never ending PITA of having to upgrade and revalidate new software versions then RMS will quickly go bye bye. I can always use the SMTP functions in BPQ32 for my own limited “Plan D” backup email needs.
  5. The ability of the sysop to audit content flowing over his/her RMS gateway is a mandatory requirement in my book. If you can’t inspect the content flowing over your system then how do you detect abuse and ensure rule compliance. While it’s not as good as it could be I will  credit the WDT for giving RMS gateway sysops some ability to review messages flowing over their gateways. Does it need improvements? Yes, but it is a start in the right direction.

So as you can hopefully see there are many things being considered in regards to what will be reinstalled and what new features will or will not be available.

 

Packet TNC options…..

Some have commented they would consider saving up for some packet gear if they knew with some certainty about what is going to be available long term. 10m RP (Robust Packet), 9.6k UHF, and maybe the 6m/220 1.2k baud AFSK ports should be around for the long haul. Due to how noisy the VHF band can be in some of our needed coverage locations I may convert the 6m 1.2k port to RP also. If I put the 2m 1.2k and 220 1.2k ports back online their future will be dependent upon their usage levels which I will examine in a couple years to see if they are worth maintaining.

Two decades of experience showed the 220 band was more useful than the 2m port. This was due to being cleaner spectrum and greatly reduced desense/bleed-over issues when we worked along side our public safety systems which are predominately 150 MHz. 145 MHz also tends to be full of various noise/QRM sources and that problem is only getting worse.

 

The ARRL / ARES Puerto Rico Adventures?

My KP4 trip was months afterwards and unrelated to any of that hot mess. I’ve heard both some first hand accounts and a lot of second hand stuff including the thought provoking interview the HRN crew did with a couple ops that went into post-hurricane KP4 for disaster relief. In short I could write a mini-novel on that topic. I’ll just hit on a few key points here that will be lengthy enough.

First – The ham radio failures in more than a view major drills and disasters of the last couple years should serve as major wake-the-heck-up calls for the EMCOMM folks. I’m around a lot of LMR and EMA folks for my day job. Trust me today many of these leaders are not impressed by the local ARES groups and are going to call the MARS folks first. Lot of this is due to past bad experiences and the often correct observation that their MARS teams are both better equipped, better trained, and thus more likely to meet a particular EMCOMM tasking.

If ARES wants to sell itself as the ones to call for when all else fails then ARES better be equipped, trained, and well practiced at operating under such conditions.  Hint – it takes more than fancy radios and go kits.

Second – Please DO NOT send folks into disaster zones with only soundcard modes for Winlink needs. Yes I concede that it sounded like they had to put that HF gear together quickly (didn’t already have it????) with portability and accountability in mind. Still for the love of Pete equip them with quality Pactor modems that are going to work better under the often marginal conditions of such deployments. Keep the soundcard modems as backups if you wish. That “you get what you pay for” saying has some merit to it.  Hint – there are reasons why SCS doesn’t sell soundcard Pactor software when they could make a fortune if they did.

PS – SCS would probably deeply discount Pactor modems to such official staged HF disaster go kits if asked via the proper channels. They have been generous towards good causes in the past. Hint hint hint hint!

Third – Even at this point in the solar cycle, down there, that time of the year, the higher bands will often be your best friends so take appropriate antenna system(s) with you. This “we’ll do it all on 80/40m” mentality continues to be a recipe for failure. 60m NVIS will be handy and having a good antenna for the WARC bands is a really good idea. Be aware that 15-10 meters may not only be open some during the day but may provide some nice SNR on the link. The propagation predictions within the Winlink software are barely useful for the lower bands and can’t predict all the propagation modes on the higher bands. A good op learns HF propagation, understands both solar cycle and seasonal changes, is aware of single/multi hop short skip possibilities on the higher bands, checks the beacon subbands, and tries to use the highest band available for a particular path.

Forth – It seems time for AMSAT to start dreaming big again. Imagine what could be done with a 9600 baud store-n-forward digital bird or two up there. Yes that is easier said than done, but we also need to think beyond HF.

All the above aside, at least some aspects of the KP4 deployments in 2017 were moments ham radio could be proud of even if it was an ugly year for ARES stateside. We also got a real world lesson on the importance of knowing how to handle formal traffic and the NTS folks have things to be proud of.

I see some latched onto the lack of good ICS over the deployment cycle. Not thoroughly knowing both sides of the problems revealed afterwards I would refrain from bashing that aspect of things. As someone that was a first responder for nearly two decades I can tell you that regardless of what you are told beforehand you need to go in prepared to walk right into chaos. You’re not there because things are going well. You must be flexible, able to prioritize, work as a team, and able to adapt on the fly to various surprises. These are situations poorly suited to those that can only function off checklists in textbook scenarios. Ultimately they got a limited crew in, did some good, and then got everyone out safely. Could it of gone better? Of course it could of. There will always be room for improvement.

Non-ham politics of the Puerto Rico disaster? Well in many ways KP4 was a long neglected mess before recent events put it front and center. It did not get that way overnight and it will not be fixed overnight. I think the bigger question is will the repaired infrastructure be well maintained long term? Can their previously struggling economy recover from all that has happened?

WA4ZKO