Re: [EXTERNAL] [RaspberryPi-4-HamRadio] TNC-Pi Now Available


FX.25 vs IL2P
When to move to 9600
Direwolf vs TNC-PI vs NinoTNC

FX.25 vs IL2P
  FX.25 has an advantage over IL2P on multi-station channels because you don’t have to get everybody to update to a FEC equipped TNC to understand FX.25.  IL2P TNCs can receive both AX.25 and IL2P simultaneously, but an IL2P transmission will not be understood by a non IL2P equipped station.   
  IL2P has an advantage over FX.25 in that the packet is smaller.   

  IL2P is ideal for point to point links where both stations can be running compatible equipment.  Since that’s what TARPN does, it makes sense for our NinoTNC to use that. 

If more TNCs and Direwolf would adopt IL2P, we might be better off in the long run, but it is a hard slog to do that.    
IL2P technical documentation is here: 

When to move to 9600
  On the subject of graphs and when to go to 9600, I think the question is backwards.  The TNC isn’t going to be the problem.  It’s the radio or community that I think are the issues.  Would a person take an existing radio and TNC and just updating the TNC to get 9600?   The radio is a much more expensive thing to change out.   A 9600 TNC is really cheap.  Some Direwolf 1200 installations will do 9600 just for the ask.  NinoTNC is only $30-ish so that’s the maximum one would need to pay to update the digital section.  But who has a 9600 capable radio just sitting around doing 1200 for want of a TNC?  That’s a crazy amount of wasted hardware.  We can get a Ft2980 for $140 and that’s a really good receiver, 80watt transmitter, but it’s only 2400 or 1200.  What does it take to get the equivalent 9600 radio (VFO controls with display) and a rational TXDELAY (150mS or less)?   

 On the surplus market there are several 4800 and 9600 capable transceivers for $150 or under.  It takes some amount of interest and tools to make them go, but if there are a dozen potential users of the equipment in your area, it’s easily a worthwhile investment for one of them to master the radios.  

 So, going from 1200 to 9600, from what I can see, is a function of radio and packet-community work, but not really much of a TNC problem, anymore.   It used to be that a 9600 baud TNC was a big deal.  Just six or seven years ago the TNC was going to cost $200 to $400.  Not anymore.  Direwolf and NinoTNC have brought the price down to $15 to $30.  

Direwolf vs TNC-PI vs NinoTNC
 The choice between Direwolf and NinoTNC is pretty easy too.  It’s funny comparing these two when the conversation started with TNC-PI.  TNC-PI was really only barely comparable to Direwolf or NinoTNC.  It seems sort of like comparing a 2020 Silverado and F150 when the conversation started with a 1969 El Camino.  The TNC-PI was single bit-rate, sensitive to RFI, required TNC-PI specific mounting/cabling for multi-port operation, had a very specific receive signaling level or it received badly, erased it’s configuration if the radio was powered when you turned off the TNC-PI, has insufficient indicators and you can't see both of them at the same time, you can't adjust the transmit level without unstacking the TNC-PIs.  It scored well against $200 TNCs when it first came out.  Now its an $80 apparatus that has become a dinosaur.  It’s only advantage over NinoTNC is that it fits in an older enclosure.  

    If you don’t mind the configuration hassle, and can follow directions well, the Direwolf is pretty easy, especially with the Fe-Pi board.  It has an advantage in that the software platform is huge and fast.  The only hassles with Direwolf beyond that are scaling it up to multiple ports, or trying to make it do things with the wrong audio hardware.  It becomes experimental and annoying.  Go with the recommended audio devices.  It’s something of a home-brewer’s thing.   If you CAN home-brew, and CAN master configuration, there’s almost no point to looking beyond Direwolf for a single-radio ham-station.  Things become somewhat custom at > 1 port.   Direwolf really shines when it comes to other-than VHF/UHF packet.  NinoTNC doesn’t touch many of the things Direwolf can do.  However, NinoTNC has displays that work without having a screen on.  You can determine if your link is working without a laptop or dedicated screen.  
  The TARPN NinoTNC is much easier to use, if it does what you need. It’s ideal for a 1200 to 9600 baud VHF/UHF packet station.  It’s usable with completely off-the-shelf cables.  It’s a USB-KISS TNC kit with a KPC-3-like radio socket.  It’s also compatible with TNC-PI cables.   You can test your radio/TNC interface and adjust levels and delays with just an extra HT and doesn’t even require a computer.   

  TARPN went with a hardware TNC because it is much easier to promote a hundred station vhf/uhf packet network into existence across a wide area if you can give trivial repeatable instructions for constructing the network hardware.  Direwolf didn’t lend itself to node stations built by every-ham, and especially not when it came to 4 port nodes.  We took NinoTNC and made it really easy and really obvious to assemble and operate.  We’re continuing to improve it.  The next version will have even more versatility.  Same great selection of built-in data rates, same selection of indicators and controls, but we’ll be able to work with even more radios without individuals having to customize the radio interfaces.   Some radios have really low receive audio output, require a very low resistance PTT, have transmit audio voltage and impedance ranges that are really specific and very different from each other.  Making a TNC which can adapt to this range of equipment was quite a challenge.   

NinoTNC is documented here:   Operation manual, assembly manual, history, and general information. 
   NinoTNC uses a completely new (for ham radio) modulation which is pretty good at fitting through the filters of ‘regular’ radios.  Documented here:



On Oct 20, 2020, at 12:00 PM, David Ranch <rpi4hamradio-groupsio@...> wrote:

Hello Mark,

I've done lots of testing and with proper parameter setting was able to get slightly more than 4 times the speed of 1200 baud.  Here are the graphs.  Below, two tests at 9600 baud compared to 1200 with the fastest 9600 baud achieving almost 3600 bps.  Notice, of course, that 1200 baud is actually lots less than 1200 bps due to the overhead of the AX.25 protocol.  You only get an actual 700-800bps.

Your graphs only re-enforce the point I was trying to make to Byron.  For very small APRS packets on HAM-class radios, there just isn't much benefit to run at 9600.  Yes, it will be a nit faster but not a lot faster.  Then add in there is a lot more downsides as the 9600bps G3RUH signal is a much less robust signal than the 1200bps AFSK signal.  Maybe an alternative approach of using say 4800bps FX.25 would show improved speed and robustness but that would need to be tested.  There are now a few TNCs out there now that support FX.25 mode:  Direwolf (Dev branch), UZ7HO Soundmodem, this ESP32 based one: ( : ), and there might be others as well.

The next graph shows file transmission times.  You can see that as the size of the file increases, the actual time of the transfer decreases a lot.  So transferring a 112kb file at 1200 baud takes about 19 minutes but the same file at 9600 baud is slightly more than 4 minutes.  That is a significant increase.  But smaller files show no big different due to the AX.25 protocol and how it works.

Yes, 9600 is a LOT faster for very large data payloads such as Winlink, classic BBS work, etc.  The critical point here is maximum payload sizes to lower the ratio of payload to AX.25 frame overhead.

The only difference in parameter settings between the two 9600 baud attempts was changing the TXDelay from 500ms to 200ms.  Some further tuning would yield better results.

Imagine what you would see if you had a pair of legacy Tekk radios that support 20ms! 

When I have some more time, I'd like to compare this with the Nino TNC working in FEC mode at 9600 baud.  It should be faster without having to deal with too many packet rejects and retransmissions.  Perhaps someone else could do it as my experimenting time is limited.

Yes.. I'd be really curious too though I'm curious how this new IL2P FEC mode would compared to say FX.25. 

From my perspective of sending email, the Winlink B2 protocol automatically compresses all text in an email before sending.  This can makes sending email very fast.  A 10 or 20k email goes in just a few seconds.

I've always been disappointed that AX.25 TNCs never supported any form of compression.  Many of the better analog dial-up modems back in the day had MNP4/5 compression which made a MASSIVE difference for many types of traffic.  Overall, the B2 protocol is a lot better than nothing but it's far from state of the art.  This URL is an interesting short read: ) and I'm also surprised that big programs like RMS Winlink hasn't attempted to modernize the compression part of their program as I bet a lot more speed can be found.


Join to automatically receive all group messages.