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 😉



SCS Tracker DSP TNC Firmware v1.7F Available

June 19, 2018

SCS Tracker DSP packet radio TNC firmware version 1.7F is now available for download from the Files section of the Robust Packet Yahoo Group or via the the beta firmware option in the SCSupdate program.

An easily overlooked source code formatting error snuck into a subroutine portion of the code in a way that didn’t throw any errors when compiled. This impacted the HDLC state machine’s ability to properly track multiple incoming frames. This is the bug detailed in some of my recent RP Group postings.

While this should be considered “beta” firmware for now, it appears to have solved the above problem. My initial testing is showing the problem resolved. If you use your Tracker DSP TNC for VHF/UHF packet then you should strongly consider installing this free firmware update.

NOTE: I have SCS looking into another packet mode bug that is on the transmission side of things. The TNC will never send more than 2 frames regardless of MAXFRAME settings. This may be a Winlink Express bug and more testing is needed. This would generally only impact 9600 baud users with degraded upload speeds.

Do note that RPR is hard coded to limit maxframe to 2 by design. This issue does not impact RP mode.

My thanks to John KX4O of VAPN for his help and testing.

Thanks to SCS for their excellent ongoing support and desire to further improve the Tracker DSP TNC for both ARPS and non-APRS uses.