home    builders    Search

buildersTARPN ProjectsNinoTNC N9600A ➜ Configuring a TARPN for NinoTNC

 Configure TARPN for NinoTNC

last changed April 5, 2022

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.

New installation with NinoTNC

The NinoTNC, being a USB device, will be given a device name by Linux in an order determined by port enumeration. The first NinoTNC discovered will be labelled /dev/ttyACM0 and the next will get /dev/ttyACM1. When Linux boots, it will walk through all of the available USB ports enumerating the USB devices and assigning them /dev names in order, and depending on the USB hardware discovered. The NinoTNC is using a Microchip USB interface so it shows up as /dev/ttyACM##. FTDI interfaces will show up with /dev/ttyUSB##. The assignment of /dev/ttyACM## will be continuous until all ports are evaluated, but non NinoTNC ports are not counted. So, you can see a NinoTNC on the first port and the 4th port, and they will get 0 and 1. If a 3rd NinoTNC is plugged in after boot, it will be given /dev/ttyACM2 (emphasis mine) even if it is plugged between the first two NinoTNCs. Now, when Linux is restarted, the TNCs will be assigned 0, 1, 2 in order of port enumeration. This means that any assignment we've made to link the 2nd TNC with some certain radio frequency and radio behavior will be applied to the wrong NinoTNC.

We came up with 3 different solutions for this. The first solution was too difficult, so we eventually abandoned that. It involved giving the NinoTNC a serial number which would be printed on a lable on the NinoTNC, but reading out the serial # was a real chore. We found another way which was to just watch what neighbor was heard on a particular port, and then assigning the port number as mapped in our configuration (node.ini) file. This means that we won't have port assignments until after the neighbors are heard. This is slightly annoying but not a show-stopper so we'll stick to that until we come up with new network software that lets us get some ID from the NinoTNC while the node software is running.

Here's an example 4 port node.

pi@taddpacket ~ $ cat node.ini
maidenheadlocator:35.892, -78.687
infomessage1:4 port node in North Raleigh
infomessage2:port 1  144.31  link to NANCY  vertical omni 8.5 miles,      9600 baud
infomessage3:port 2  441.475 link to RICHRD crappy antennas, 2 miles      4800 baud
infomessage4:port 3  446.475 link to TILL   vert omni to yagi, 1.5 miles, 4800 baud
infomessage5:port 4  147.555 link to DOUG   horz beams, 1.1 miles,        2400 baud
ctext:North Raleigh near Outback Steakhouse linked to NANCY, DOUG, TILL, RICHRD




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, if only to cover the inefficiencies of the radios, but there is actually a bigger problem. Once in a while the node will attempt to send a packet to the NinoTNC while the other end is gearing up to send a packet. The FRACK could need to account for 3 full length packets. But that doesn't happen very often.
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 lost or 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 usb

The TARPN USB command works two different ways, depending on whether the node is running or not. If the node IS running, it can read the /dev directory and pull out the NinoTNCS, and it looks at the node.ini file and shows you want neighbors you have defined. The command also looks at data created by the TARPN utilities during node operation and can show a display with information about the NinoTNC including switch settings, version number, and even the callsign of the neighbor.

If the node is NOT running, the command does not have access to the NinoTNC information, but it will show you the USB ports and the defined neighbors.

pi@taddpacket ~ $ tarpn usb
#### =TARPN vbullseye138=

#### USB -- Analyze node.ini
####        and show ttyUSB and ttyACM devices (NinoTNC) found in /dev

#####  List of tty ports called out in node.ini
#####  --- start
#####   --- end

#####    -- if node is stopped, this can directly read the USB-id
#####       and version # the NinoTNCs.

#####    -- This is the NinoTNC status last received by the node.
#####       See the Date/Time for currency.
Date  Time Port AsnNghbr FWver Board Switch  Baud Modu  FEC   TXD
04-05 17:41 p1  KB2TNR-2  4.06  A4r1  0001  >9600 GFSK  IL2P<  53
04-05 17:32 p2  KM4EP-2   3.14  A4r1  0011  >4800 GFSK  IL2P<  53
04-05 17:46 p3  K4RGN-2   3.14  A3    0011  >4800 GFSK  IL2P<  43
04-05 17:44 p4  N3LTV-2   3.14  A4r1  0101  >2400 DAPSK IL2P<  106

#####    -- This is a list of the USB devices in the /dev directory.
pi@ffvcnode:~ $


If the node is running, the tinfo.sh command will show lots of detail about the node and the NinoTNC specific details, as above.

pi@taddpacket ~ $ tinfo.sh
#### =TARPN vbullseye138=
TARPN vbullseye138
lat/lon coordinates: 35.90286, -78.859576
TARPN Updates URL:   https://tarpn.net/bullseye2021
Linux UPTIME:        18:26:07 up 1 day,  3:49,  4 users,  load average: 0.22, 0.35, 0.48
Node started:        Mon 04 Apr 2022 02 36 24 PM EDT  Node background Service is (AUTO)
Raspberry PI Reset:  2022-04-04 14:36:10
TARPN HOME:          is running              TARPN HOME is set to START
TARPN-HOME build-utc:Jan 16 23:19
TARPN-HOME install:  Mon  4 Apr 14:25:25 EDT 2022
Rasberry PI Hardware:type 4 B 2GB made in UK
OS version:          Raspbian GNU/Linux 11 (bullseye)
Ethernet MAC:        dc:a6:32:52:b7:32   CPU temp=45.2'C   SDcard=1649095913
TARPN Installed:     Apr  4 14:12
UpdateApps Last run: NEVER

Date  Time Port AsnNghbr FWver  Board Switch  Baud Modu  FEC   TXD
04-05 17:59 p1  KB2TNR-2  4.06  A4r1  0001  >9600 GFSK  IL2P<  53
04-05 18:11 p2  KM4EP-2   3.14  A4r1  0011  >4800 GFSK  IL2P<  53
04-05 17:57 p3  K4RGN-2   3.14  A3    0011  >4800 GFSK  IL2P<  43
04-05 18:16 p4  N3LTV-2   3.14  A4r1  0101  >2400 DAPSK IL2P<  106

Undervoltage Events found in Log file = 0
My IP address is
Router info:default via dev eth0 proto dhcp src metric 202

pi@ffvcnode:~ $

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

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