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 System FAQ

June 1, 2018

This is a work-in-progress….

FAQ #1 – Any other HF bands than 10 meters?

Answer:  Not at this time. We may add 80/40 or 30/17 meters in the future, but that is a big maybe at this time.

 

FAQ #2 – Why only 10 meters, why not a lower band?

Answer:  The 10 meter port’s primary purpose is to provide an additional coverage option for local fringe locations that even the 6 meter 1200 baud packet port struggles with due to noise/distance etc.

Remember 28 MHz behaves very much like 30 MHz VHF-Low with propagation characteristics well suited to the hills and valleys common to our coverage area. 10 meter Robust Packet fills the need.

We are not offering lower bands at this time due to the main HF antenna the site is dedicated to remote HF/VHF station use and that takes priority for now. A future site may allow for a 30/17m port, but no scheduled date of availability or guarantee on that.

 

FAQ #3 – Why Robust Packet, why not one of the soundcard modes?

Answer:  We have not found soundcard modems to be reliable enough for 24x7x365 use at a remote site. It is one thing if the system is down in your basement or over in the corner of your hamshack, but modem evaluation criteria changes when the system is miles away at a tower site. We also wanted a mode/modem that was suitable for BOTH interactive use with packet applications (BBS, Chat server, etc) and message transfers. Lot of the other modes are okay for message transfers as that was what they were designed/optimized for, but often poor choices for interactive connections.

Robust Packet is hardware modem based and gives us an excellent mode for interactive access and plenty of message transfer speed for our particular needs. It also works well with weak noisy signals, has considerable immunity to multi-path, and often works in fringe locations where the 6 meter AFSK packet port will not.

 

FAQ #4 – Is DX use of the  6 or 10 meter ports allowed?

Answer:  Yes, but please yield to any local users on QRG.  The 10 meter port beacons every 10 minutes to help detect band openings.

The 6 meter port beacons an APRS compatible beacon every 5 minutes to help detect band openings. The 6m port also functions as a WIDE1-1 APRS digipeater.

 

FAQ #5 – What is WYJAC, BBSJAC, etc?

Answer:  WYJAC (WA4ZKO-4) / BBSJAC (WA4ZKO-1) is a test/dev node and BBS at our 7-land QTH. The Dry Ridge site is linked to it over a private network, thus you will see those nodes/applications showing at times. It will also allow migration/expansion of the KYPN packet network and applications later on down the road.

Please do not leave messages on the WA4ZKO-1 BBS as it is just a test BBS for now.  Please leave all messages on the K4KPN-1 BBS unless instructed to do otherwise.

 

FAQ #6 – Is telnet access available?

Answer:  Yes, but it will be considered on a case by case basis. For now it is restricted to those with access to the inter-tower KY<>WY VPN LAN/WAN network. Those within VHF/UHF range will be required to have a functional and actively used “RF” packet station before telnet access will be considered. The goal of the packet BBS is to provide a RF only messaging system, not breed laziness and apathy towards having effective RF access.

Yes having a Winlink RMS gateway on the system kind of conflicts with the above LOL. It is secondary to the conventional packet systems. Trust me, it took some convincing for me to even offer it, especially on VHF/UHF.

The K4KPN-14 Winlink gateway is on “probation” as far as I’m concerned. If it’s not used then it will eventually be turned off. If it becomes a PITA in terms of admin or abuse then it will be turned off. Many said they wanted it, now we’ll see if that was just talk and how it will be used 😉
 

FAQ #7 – Does the KYPN systems have backup power?

Answer:  The K4KPN-10 HF RP APRS I-Gate/Digi is at a secure tower site with backup power options.

The K4KPN-1 (BBS), K4KPN-4 (Node), K4KPN-6 (6m digi/I-gate), K4KPN-13 (chat svr), and K4KPN-14 (RMS) systems are located on a private tower site near Jonesville. This site has short term battery bank backup in place to allow it to stay online till manual transfer to an on-site generator.

The K4KPN-15 2m APRS I-Gate/Digi is located in Williamstown. The station has very limited battery backup. Normally it will be shut down during an extended power outage. It should NOT be counted upon for emergency uses. Also note current plans are to decommission it in January 2020.

 

To be continued….

WA4ZKO