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 email@example.com
The way we manage TNCs in the G8BPQ node software provides 12 ports, numbered 1 through 12, where TNCs may be assigned and serviced.
- Port numbers 1 through 4 are reserved for I2C (ribbon cable) connected TNC-PI.
- Port numbers 5 through 10 are reserved for NinoTNC (USB).
- Port numbers 11 and 12 are reserved for other USB TNCs and the configuration permits the use of USB-to-serial connected full featured TNCs operated in KISS mode.
The NinoTNC can be used on either or both of these two ports in addition to ports 5 through 10, since they appear to be KISS serial TNCs, providing up to 8 ports for NinoTNC
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
by using these commands in sequence:
cp node.ini old-node.ini
<‐ this backs up your node configuration.
<‐ this changes what generation of TARPN scriptfiles you are using.
<‐ this downloads the new script files.
<‐ 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.
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
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
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.
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.
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
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
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