home    builders    Search

buildersTARPN ProjectsNinoTNC USB ➜ Configuring a TARPN for NinoTNC

 Configure TARPN for NinoTNC

last changed September 22, 2020

As of May 25, 2020, the NinoTNC is specifically supported by the standard TARPN configuration.
The URL repository used for the start of support is apr2020. Please review the TARPN groups.io history for updates. If it's 2021 and this page hasn't been changed, it's probably worth poking tarpn@groups.io for updates.

The way we manage TNCs in the G8BPQ node software provides 12 ports, numbered 1 through 12, where TNCs may be assigned and serviced.

As usual, tarpn config may be used to enter the configuration for NinoTNCs, or the configuration in node.ini may be edited manually. If you get in trouble editing node.ini, tarpn config may be used to clean it up.

Updating to apr2020

The TARPN programming should support migrating from june2019 or 2020tadd to apr2020 by using these commands in sequence:
cp node.ini old-node.ini       <‐ this backs up your node configuration.
tarpn url                         <‐ this changes what generation of TARPN scriptfiles you are using.
tarpn update                   <‐ this downloads the new script files.
tarpn config                   <‐ this rewrites your configuration file to support the new ports for NinoTNC.

When you do tarpn url, you will be prompted to change your url. Enter http://tarpn.net/apr2020

New installation with NinoTNC

I'm sorry that there are still many references to TNC-PI in the TARPN web-pages which need to be converted to NinoTNC references with corrected information. It's a work in progress. As of now we plan to continue supporting the $48 TNC-PI in existing installations but we're hoping to make the $30 NinoTNC the primary solution. The NinoTNC is considerably easier to get working and it is easier for hams to hook up tools to diagnose problems. One big change, for instance, is that we are no longer recommending an oscilloscope for new node installs, even though it is easier to use a scope on a NinoTNC than it was on a TNC-PI. The NinoTNC has a much wider acceptable range of receive level than the TNC-PI did so the process of tuning to an acceptable receive level is not as difficult or critical.

The flaw in the NinoTNC, for now, is that resetting the Raspberry PI triggers a port enumeration which organizes the list of USB devices based on some hardware ordering. It's hard to force the NinoTNCs to show up on specific named device ideas. We're working on that.

The solution for now is to restart the Raspberry PI using tarpn restart and then assign all of the ports, and then after they are assigned and the node is running, decide which ports are which using the TEST-TX button and qt-term, or by listening on the ports and figure out which neighbors are on which NinoTNC. Once you have a map of which port gets which NinoTNC, go back to tarpn config and rearrange the ttyACM# device names to straighten things out. Once you get the port order correct, and unless you unplug a NinoTNC and plug it into a different USB, the order should stay the same.

The solution to the ordering flaw will be to assign a unique string to the NinoTNC and then use that unique string in node.ini and tarpn config. We'll hopefully roll that out this fall.

Here's an example 7 port node. Only 6 ports are connected to radios, the last port is connected to a NinoTNC but only hooked to a radio for testing.

pi@taddpacket ~ $ cat node.ini
maidenheadlocator:35.892, -78.687
infomessage1:6 port node in North Raleigh
infomessage2:port 5  222.32  link to FIN   horizontal yagis 3 miles,     1200 baud
infomessage3:port 6  144.31  link to FFVC  vertical omni 8.5 miles,      9600 baud
infomessage4:port 7  441.475 link to JAY   crappy antennas, 2 miles      4800 baud
infomessage5:port 8  446.475 link to TILL  vert omni to yagi, 1.5 miles, 4800 baud
infomessage6:port 9  147.555 link to DOUG  horz beams, 1.1 miles,        9600 baud
infomessage7:port 10  51.12  link to AARON horizontal moxons 7 miles,    1200 baud
ctext:North Raleigh near Outback Steakhouse linked to FFVC, AARONL, DOUG, TILL, FIN, JAY













pi@taddpacket ~ $ 

Frame Ack (FRACK) Values

The FRACK is specified in milliseconds from the initiation of a transmit packet, to the reception of the acknowledgement of that packet. If the other end of the link is supposed to acknowledge a packet, and its packet does not arrive before the end of FRACK time, your node will send a query transmission. If FRACK is too small, the query transmission could be sent even if the other end would have answered.

Now here is the bizarre part.
The G8BPQ node program does not care that packet transmission is not instantaneous. The FRACK timer starts as soon as the G8BPQ program hands the TNC the packet and a retransmission will happen if the G8BPQ program doesn't get the acknowledgement before the FRACK time expires.

The Raspberry PI to NinoTNC communications link is at 57600 baud.
A 256 byte packet would take (256*8)/57600 seconds = only 35mS to send to the NinoTNC.
The timer starts then.
The NinoTNC will send the 256 byte message at the bit rate you have selected.
256 bytes at 9600 baud will take 213mS to send, plus the TXDELAY preamble bits, call it 30mS for a good radio, and then the other end has to get the message into G8BPQ, answer it, send the message back to the NinoTNC, and transmit it, and then your NinoTNC has to receive the response message (up to 256 bytes) and THEN the FRACK timer can't have expired.

So.. the total FRACK amount for 9600, assuming 50mS radio TXDELAY, is (35mS*4)+(213mS*2)+(30mS*2)=140+416+60=616mS
The FRACK amount for 1200, assuming 150mS radio TXDELAY, is (35mS*4)+(1707*2)+(150mS*2)=140+3414+300=3854mS.
As you can see, the FRACK for 1200 baud has to be much longer than the FRACK for 9600.
I would recommend using a larger value on each, just to cover inconsistancies in the behavior of the programs and radios.
2000 is probably just fine for 9600, and 8000 for 1200 baud.
Keep in mind that the FRACK timer expiration only helps you if a packet is corrupted.

Other info about the node.ini file

In the demonstration node.ini file shown above, port 11 is used for in-house testing.

The port details are completely ignored, and the port is not created for G8BPQ, if the port is marked as DISABLE

The port details may look complex for ports 11 and 12, but actually the node.ini description for those two ports, and the rest, are hiding an enourmous amount of detail. The TARPN programs automate the creation of the G8BPQ node configuration. The G8BPQ node expects a full set of specification details for every port. In the case of TNC-PI and NinoTNC, many of the configuration details are already obvious once we know what the TNC is. Many of the terms used in configuration of a NinoTNC port (or a TNC-PI port) are known to the program and are automatically configured. In addition, the TARPN programs insist that all ports support a dedicated link to a single other station. Since this is true, other G8BPQ configurables are also obvious, and so are taken care of automatically.

Ports 11 and 12 require you to set more configurations to allow you to pick two from many different kinds of TNCs, and assign them to those ports.

TARPN Tools for NinoTNCs

These commands are new for NinoTNC: tarpn usb and tarpn flash.
The usb command checks to see what devices are attached which may be NinoTNCs and optionally reads the CPU firmware version from the NinoTNC.
The flash command changes which firmware version is loaded into the CPU on the NinoTNC.

Read more about the tarpn commands on the tarpn command list web page.

© Tadd Torborg, 2019↝2020 -- all rights reserved