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.
- Port numbers 1 through 10 are reserved for NinoTNC versions A3 and A4, both of which use /dev/ttyACM## as their USB address in Linux.
- 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 1 through 10, since they appear to be KISS serial TNCs, providing up to 12 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.
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
nodecall:ka2dew-2
nodename:tadd
bbscall:ka2dew-1
chatcall:ka2dew-9
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
infomessage6:not_set
infomessage7:not_set
infomessage8:not_set
ctext:North Raleigh near Outback Steakhouse linked to NANCY, DOUG, TILL, RICHRD
local-op-callsign:ka2dew
neighborA:KB2TNR-2
frackA:2000
neighboB:KM4EP-2
frackB:3000
neighborC:K4RGN-2
frackC:4000
neighborD:N3LTV-2
frackD:6000
neighborE:NOT_SET
frackE:9000
neighborF:NOT_SET
frackF:9000
neighborG:NOT_SET
frackG:9000
neighborH:NOT_SET
frackH:9000
neighborI:NOT_SET
frackI:9000
neighborJ:NOT_SET
frackJ:9000
usb-port11:ENABLE
portdev11:/dev/ttyUSB0
speed11:9600
txdelay11:1000
frack11:5000
neighbor11:KA2DEW-11
usb-port12:DISABLE
portdev12:/dev/ttyUSB1
speed12:57600
txdelay12:1000
frack12:9000
neighbor12:NOT_SET
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
neighborA:KB2TNR-2
neighborB:KM4EP-2
neighborC:K4RGN-2
neighborD:N3LTV-2
##### --- 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.
ttyACM0
ttyACM1
ttyACM2
ttyACM3
#####
pi@ffvcnode:~ $
|
tinfo.sh
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 10.0.0.200
Router info:default via 10.0.0.1 dev eth0 proto dhcp src 10.0.0.200 metric 202
pi@ffvcnode:~ $
|
Read more about the
tarpn commands on the
tarpn command list web page.