NinoTNC N9600A Operation
page modified August 27, 2020
Specifications may change without notice.
Do not use this device in any situation where the loss of life or property would be the result of the device misbehaving or failing.
If you go beyond this rule, you are self-certifying this device.
This device is built by hobbyists for a hobby project.
We do not certify that this design, or any particular unit, is sound.
Use it at your own risk.
We're just getting started with this stuff.
I welcome any more comments or bullets or instructions for this space.
Please volunteer whatever you have.
Send to the ninotnc email reflector.
Since this is a KISS TNC, it will be operated by an application which knows how to control a KISS TNC.
Except for hams running the TARPN installation and using the scripting and applications as provided for those installations, we are not supplying the application.
Except for the TARPN installations, the configuration of the application is out of scope, so far, for our instructions.
The NinoTNC has one radio port which is a D-sub 9 connector (corretly: DE9).
This is the same connector used by Kantronics since the mid 1980s and also used by Coastal Chipworks for their TNC-PI.
The NinoTNC has a RXA scope loop to which you can hook an oscilloscope.
In TNC-PI days we recommended that every node operator have a scope because the TNC-PI really liked having packet audio come in a just less than 1 Volt Peak to Peak.
The NinoTNC is comfortable with 3 V P-P and can do pretty good work all the way down to under 1 Volt Peak to Peak.
This means that receive level adjustment (aka transceiver volume knob) is not so picky.
The NinoTNC listens to one bit-rate only, i.e. 1200 baud or 2400 baud, or 4800 baud, or 9600 baud).
If a 2400 baud packet comes in while the NinoTNC is configured for 1200 baud (switches) the TNC will completely ignore the 2400 baud packet.
The DCD indication is not designed to work on alternate bit-rates.
It is likely to falsely detect DCD on noise or on other bit-rates, for very short intervals, but in practice, if there is 1200 baud traffic, a 9600 NinoTNC could transmit right on top of a strong 1200 baud packet.
If you set the NinoTNC to decode some bit rate, it will look for an incoming synchronization phrase (at that rate and with the implicit modem tones) which repeats over and over during the TXDELAY in any TNC.
The synchronization phrase for AX.25 and for IL2P are different.
The NinoTNC can catch either synchronization phrase
and will turn on the packet decoder for the appropriate protocol when the synchronization is received.
Setting the IL2P vs AX.25 switch on the TNC just tells it what it is transmitting.
It has no affect on the receive decode.
Except in the moments right after TEST-TX button is released, the NinoTNC will either transmit or receive.
If the NinoTNC is decoding alternating bits it will light its DCD light and will refuse to transmit.
USB ports and Linux
Linux scans the USB ports at boot time and enumerates
the USB serial devices.
The USB devices which are FTDI (NinTNC A1 and A2) will show up in the device directory, /dev
, as /dev/ttyUSB0, /dev/ttyUSB1,
The USB devices which are Mocrochip MCP2221 (NinoTNC A3 and later) will show up in the device directory, /dev
, as /dev/ttyACM0, /dev/ttyACM1,
The issue with using USB serial devices as TNCs, and which we must put up with for now, is that the Raspberry PI will enumerate the NinoTNCs and assign /dev/tty
names in the order of what hardware/physical USB hub and socket it finds them on.
If a TNC is removed after the enumeration is complete, the /dev
names will not be reassigned until the next operating system reset.
Unplugging a TNC and then plugging the USB into a different port will result in the TNC re-appearing, possibly as the same name.
But the name isn't sticky through reset!
Consequently, if the TNCs are assigned and some are replugged, and then later the Raspberry PI resets, the TNCs will show up with a new enumeration and the node will not function correctly.
The work-around for this behavior that we're using for now, is after your NinoTNCs are all plugged in, reset the Raspberry PI.
Now use the TNCs in the "final" enumeration.
There is a linux command as part of the TARPN scripts, tarpn usb
, which is idealized to show you what NinoTNCs are present and what you have assigned to your node.
The same result can be found by doing these two commands:
ls -l /dev | grep -e "ttyUSB." -e "ttyACM."
and if you are using G8BPQ's pilinbpq
grep "^COMPORT=/dev/" bpq32.cfg
The point of the commands is to allow you to see that the ports you have assigned to the node are, in fact, the ones you have available.
After you reset, and the enumeration has completed, you can unplug a NinoTNC, do the commands, and then plug the NinoTNC back in.
This will let you know which tty device is missed, and therefor matches the temporarily unplugged NinoTNC.
Make sure you plug the NinoTNC back into exactly the same USB socket.
For the TARPN installs, it is our plan to, in the short term, come up with a feature which will additionally enumerate the TNCs as /dev/tarpn18.104.22.168
and so on, based on the physical port to which the NinoTNC is attached.
This way the configuration you are using can specify the NinoTNC by port and you can expect that port number to remain through reboot, even if another NinoTNC is added or removed.
The long term goal is the NinoTNCs will identify themselves by some serial # and we'll enumerate the serial numbers into the /dev
That's another project.
Hopefully we'll be able to relase that solution to the general Linux community.
We'll see how things develope.
The NinoTNC has several transmit features including the TEST-TX button, IL2P transmit mode, and AX.25 transmit mode.
I'll try to describe all of this as this document evolves.
We'll also have to go into what KISS commands are implemented and how to use the NinoTNC-specific KISS commands.
The NinoTNC has a 2100 byte KISS input frame buffer to capture host-generated KISS messages.
That means the NinoTNC can afford to be given seven 256byte host-transmit KISS packets, and store them all simultaneously.
If a KISS packet is pushed to the NinoTNC when there is not enough space to store an entire KISS frame in the selected transmit mode (i.e. 256 or 1023 bytes of encoded packet), the host's KISS transmit frame will be silently ignored until it's FEND end byte.
The NinoTNC can actually handle more than seven outgoing 256byte frames in AX.25 mode because it has three transmit buffers which are filled with already encoded messages, so depending on selected bit-rate and channel activity, it is possible to have 10 fullsize outbound packet frames in the NinoTNC at once.
The NinoTNC does not artificially limit the number of outgoing packets stored in the from-host serial buffer.
Until the NinoTNC frees up an encoded-tx-ready-to-transmit buffer, it does not check to see what kind of KISS frame, or how long, has been received from the host, so you could buffer up quite a few short packets.
Each of the three encoded-tx buffers can hold one and only one transmit packet.
The IL2P mode can accept a 1023 transmit message in IL2P mode.
That means that if there is less than 1023 bytes free in the from-Host serial buffer, and the NinoTNC is in IL2P mode, the host's new outgoing KISS frame will be ignored.
Because of the encoded-transmit-buffers, mentioned above, it is possible for the NinoTNC to queue 5 full-length IL2P packets.
This will take some finess because of KISS's specified silent-ignore in an overlow condition.
The TXDELAY potentiometer adjusts the amount of time the TNC waits after keying PTT, and before sending the packet.
While waiting for that short delay to end, the TNC sends FLAGS or a 10101 pattern.
For the 1200 AX.25 mode, at the point of transmission, the data will be slightly more random looking than that because there is a differential encoder which performs an expected bit randomization.
The packet receiver knows about this and does the translation automatically, so on the scope it won't look quite so obvious.
In IL2P modes or G3RUH 9600 mode, the data is set as a 101010 pattern.
TX_DELAY setting will depend on the transmitter and receiver involved in the link. TX_DELAY adjusts the number of preamble words the TNC sends after keying the PTT line but before data appears in the bitstream.
This gives time for transmitter relays to switch, as well as AGC and AFC circuits to settle in the receiver. TX_DELAY is best set by trial and error, starting from a low setting.
The TX_DELAY response is exponential (same amount of pot rotation at top scale results in much more preamble), and different for 1200 and 9600 modes.
In 1200 mode, the minimum pot setting gives 32 bits of preamble (27 milliseconds), and the maximum pot setting gives 1200 (1 second). In 9600 mode, minimum pot setting gives 112 bits of preamble (12 milliseconds), and the maximum setting gives 8656 bits (901 milliseconds).
In practice, most setups should work fine at about half-rotation on the pot. If you want to optimize link throughput, you'll want to back off the TX_DELAY until the receiver stops receiving packets, then slowly increase until packets start coming through, then add a little more for a buffer.
TX-LEV and TX-TEST
The NinoTNC has three output adjustments:
- The TX-LEV potentiometer adjusts the TNC transmit level (voltage/volume) over one of two voltage ranges.
- Jumper J6 (in NinoTNC A3r3 boards) or a series output resistor in older boards, controls which range the TX-LEV adjusts within.
- The third adjustment is TXDELAY, described above.
The TX-TEST/PTT pushbutton tells the CPU to key the radio’s PTT line, and generate a sine wave test tone at 999hz.
The level this tone is generated with may be used to calibrate the TXLEV potentiometer.
The NinoTNC is designed to generate the appropriate sine wave level so if TXLEV during TX-TEST is appropriate for the other end’s receiver, so will the TXLEV be during a real packet.
When TX-TEST is depressed, the NinoTNC will generate the 999hz sign wave.
Once TX-TEST is released, the NinoTNC waits most of a second and then generates both a USB message, and a transmitted packet.
The USB message shows up as a KISS packet-received frame with an information frame containing the text ":Test Packet by USB
The transmitted packet will be generated in the mode and bit-rate selected by the switches.
The destination callsign used will be ID
The origin callsign used will be the last callsign your station used as mycall
to transmit a packet.
The callsign is stored in EEROM so it is recalled and used even after power is interrupted.
If no transmissions have been commanded over KISS, the callsign used will be N9600A-3
The NinoTNC will assert Push To Talk, and send the packet, using the Tx-level and Tx-delay specified by the potentiometers.
At the same time the NinoTNC is transmitting the test message, it is also listening for that exact packet.
While the NinoTNC does not normally do full-duplex, in this case it can because the transmitted packet is pre-engineered to permit this.
The received packet is also decoded and presented over the USB and will contain the text ":Test Packet
The LEDs on the NinoTNC will show that DCD comes on, and then a good RX packet (green) or a bad packet (red).
If the TX-TEST packet tansmission uses the N9600A-3 callsign, and if it is looped back, the NinoTNC will show TX and DCD and then RX and STRANGER. Or, TX and DCD and then CRC BAD.
The STRANGER LED's purpose it to show you that a packet was heard with a callsign other than the one you are talking to.
Since you are looping back, it would hear your own callsign, which, depending on the firmware version, may be a stranger.
By-the-ear method of TXLEV adjustment
There are a few ways to set the TX_DEV pot.
For many applications, especially with AFSK 1200 mode, setting by ear will be good enough.
Attach the radio you'll be using for packet to a dummy load and the NinoTNC.
- Use an HT to listen to the transmitted signal.
- Set the TXLEV to maximum
- Press the TEST-TX button and adjust your HT to a low volume level suitable for putting right next to your ear.
- While continuing to hold TEST-TX, adjust the TXLEV down until you can start to detect the level dropping on the HT.
- Move the TXLEV pot up and down to exactly find the threshold where the level starts to drop.
- Move the TXLEV pot to just below the threshold.
- The tone should be about as loud as audio from your favorite repeater.
SDR method of TXLEV adjustment
If you have access to an SDR receiver stick, you can use it to make a very precise transmit deviation setting with the TX_DEV pot.
The 999 Hz tone generated by the TEST TX button can be used to find the first bessel null, which will occur at 2.405 times the tone freq, resulting in about 2.4kHz deviation.
I found a paper by KH6HTV that explains the theory: kh6htv.files.wordpress.com/2014/10/an-14-fm-deviation.pdf
This video linked below demonstrates how to set the transmit deviation for an N9600A TNC using the built-in 999Hz tuning tone and a cheap USB SDR.
In the test setup, an N9600A2 TNC is connected to a TAIT TM8105 radio set to transmit on 145.510 MHz.
Software is SDR Console v3.0.14 on a Windows 10 PC.
CubicSDR works on a Macintosh.
Receive bandwidth on the SDR software is set to 250kHz, AGC on, WFM.
The TX DEV potentiometer on the TNC is at minimum at first, then slowly increased while holding the TEST TX button.
Proper deviation is reached when the center spike in the spectrum display is dipped to minimum.
This takes advantage of the first "Bessel Null", which happens when FM deviation is 2.405 times the frequency of the transmitted tone (999Hz in this case).
2.4kHz provides minimum-shift deviation for 9600 baud transmitted data.
I made a screen grab video of bessel null tuning procedure and posted it on YouTube.
Read the description first for the instructions, I didn't have a microphone available to narrate over the video:
Youtube: TARPN NinoTNC -- Use RTL-SDR Dongle for TX-DEV adjustment and measurement
Final thought about setting transmit deviation: each radio will be a little bit different, and the correct setting will depend on whether you are using a microphone input or a data port input to get the TXA audio into the transmitter.
I have recently found that I need to add resistance in series with the TXA line to increase the TXA output impedance when using the microphone input of a TK-760. Just a series resistor will do the trick.
You can put this in your TNC cable on pin 1 of the DE9, or you can replace the L2 wire jumper on the board with a resistor. I've found resistor values from 10k to 100k to work fine with the TK-760 microphone input. If you find that the audio always sounds overdriven no matter how low you set TX_DEV, try adding a resistor.
Notes for using the NinoTNC
The configuration for all modes on Version 2.x of the NinoTNC firmware is to set the USB device's communications rate to 57600 baud.
That's the data rate between the USB chip and the NinoTNC's CPU.
Set the FRACK for your control program to 4 seconds for 1200 baud and 1 second for 9600 baud.
The TEST-TX button can be used to help analyze the setting of the TX-DEV potentiometer by watching the signal with an SDR dongle and appropriate software.
The TX-DEV setting will need to be re-done if a new radio or new baud setting is selected.
The TX-DEV potentiometer is immediately effective, being an active part of the transmit audio output circuitry.
The TX-DELAY potentiometer is read by the CPU after
every transmisison and then the transmit behavior is affected by the value read.
Changes to the TX-DELAY pot setting are only effective on the 2nd transmission after the change is made.
The TXA output to the transceiver is expected to have about 1.65v DC offset.
IL2P mode, Improved Layer 2 Protocol, is useful when talking to another IL2P-configured NinoTNC because it reduces the rate of errors in your transmissions.
The NinoTNC's receiver is always looking for both AX.25 and IL2P packets. It won't discriminate one from the other as far as the host computer is concerned.
The IL2P vs AX.25 switch controls what kind of packet is transmitted, but doesn't do anything to limit the packets received.
Consequently, two NinoTNCs could be set to opposite modes and work just fine with one another.
The TNC does not attempt to decode at different bit-rates, however.
A2 specific instructions
The A2 NinoTNC and the A3 NinoTNC use the same firmware.
Everything the A3 is capable of, the A2 can also do.
The only issues with the A2 are the fragile USB connector, and the limitations of the two bits worth of switches.
The A2 shipped with version 2.20 of the firmware.
The switch positions supported with that version are:
|0-0||9600 baud GFSK IL2P|
|0-1||9600 baud GFSK AX.25|
|1-0||1200 baud AFSK AX.25|
|1-1||1200 baud AFSK IL2P|
Version 2.41 shipped with the A3 r3 board.
That verison of the firmware modifies the switch positions to produce this table:
|0-0||9600 baud GFSK IL2P|
|0-1||9600 baud GFSK AX.25|
|1-0||1200 baud AFSK AX.25|
|1-1||2400 baud DAPSK IL2P|
As of this writing, July 31, 2020, version 2.41 of the firmware is available for order on ETSY for $5
A3 specific instructions
You'll be doing 1200 baud Bell 202 modem, 2400 baud with a ??? modem and AX.25 protocol with a voice radio, or 4800 or 9600 baud G3RUH modem with AX.25 protocol with a data radio.
Alternatively you can select IL2P with all 4 baud selections.
The switches on the NinoTNC A3 can select 16 different modes but the 2.3.5 firmware included with the A3 in initial shipment will only use 8 of the modes.
The SSB switch will have no affect.
When any of the 3 switches closest to the LEDs are changed, the NinoTNC will reset, show the 4 LED sweep pattern back and forth once, and then the TNC will encode and decode as instructed by the switches.
The 8 modes available are:
|0-0-0-0||FM+GFSK+LO+AX25||9600 baud AX.25|
|0-0-0-1||FM+GFSK+LO+IL2P||9600 baud IL2P|
|0-0-1-0||FM+GFSK+LO+AX25||4800 baud AX.25|
|0-0-1-1||FM+GFSK+LO+IL2P||4800 baud IL2P|
|0-1-0-0||FM+AFSK+LO+AX25||2400 baud AX.25|
|0-1-0-1||FM+AFSK+LO+IL2P||2400 baud IL2P|
|0-1-1-0||FM+AFSK+LO+AX25||1200 baud AX.25|
|0-1-1-1||FM+AFSK+LO+IL2P||1200 baud IL2P|
The table isn't completely correct as 2400 and 4800 are not strictly AFSK or GFSK.
9600 baud receive eye pattern
You can get the 9600 receive eye diagram at the RXA scope probe.
Set the trigger for 1.65 volts
G8BPQ node confing
For non-TARPN nodes built with G8BPQ, you must define a port to talk to the TNC in the bpq32.cfg file.
The definition will be slightly different for 1200 baud vs 9600 baud and may also be tailored for the radio.
Here is an example G8BPQ port definition for 1200 baud using a 2m ham radio:
ID=p2p link to k1qsy-2
Here is a G8BPQ port definition for 9600 baud using a Tait TM8105 data radio:
ID=p2p 9600 link to k1qth-2
Interesting Reads from G3RUH and others
AMSAT article 109 by G3RUH
WD6EHR 9600 baud handbook