home    builders    Search

buildersTARPN ProjectsNinoTNC USB ➜ N9600a Operation

NinoTNC N9600A Operation

page modified November 8, 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.

For the most part, this document addresses the performance of Versions A2 and later running the latest stable firmware. See History page for firmware release history.

We're just getting started with the documentation. I know it is a bit out of order. It will get better.

I welcome any more comments or instructions to go in this space. Please volunteer whatever you have. Send to the ninotnc email reflector.

Table Of Contents

  1. NinoTNC Readiness
  2. Application Operation
  3. Cabling
  4. Modes - Over-The-Air-Baud - AX.25 vs IL2P
  5. Board Revisions - Differences
    1. Board capabilities
    2. Data radio vs Microphone radio
  6. LED Behavior
  7. Receive
    1. DCD
    2. DCD at wrong bit-rate
    3. RXA scope loop
    4. High Rx Volume Indication
    5. AX.25 and IL2P Receive
    6. Not Full Duplex
  8. USB - serial ports
    1. serial baud setting
    2. MSWindows
    3. Linux and Unix
  9. Transmit
    1. TXDELAY Potentiometer
    2. TX-LEV and TX-TEST
    3. By-the-ear method of TX-LEV adjustment
    4. SDR method of TX-LEV adjustment
    5. Autonomous Transmit of Station ID and Mode
  10. Bootloading a new version of Firmware
  11. Notes for using NinoTNC
  12. A2 Specific Instructions
  13. A3 Specific Instructions
  14. 9600 baud receive eye pattern
  15. USB data dump GETALL message
  16. G8BPQ Node Config
  17. 3d-Printed Enclosures

1. NinoTNC readiness

The NinoTNC CPU is fully programmed with all the firmware you need to support the available modes at the time the CPU was shipped. The NinoTNC is reconfigured by switches, jumpers and two potentiometers. One of our product management mantras is that the operator can visually inspect the NinoTNC to discern the bit-rate, mode and TXdelay settings. We also put the adjustables, LEDs and the test switch out front so even with a box around the device, it can still be tuned up and checked out. We are ever improving the LED diagnostic output and we've got a built-in loopback test so the owner/builder/operator can verify much of the functionality of the NinoTNC without external test equipment.

2. Application Operation

Since this is a KISS TNC, it will be operated by an application that 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.

3. Cabling

The NinoTNC has one radio port which is a D-sub 9 connector (correctly: DE9). This is the same connector used by Kantronics since the mid-1980s and also used by Coastal Chipworks for their TNC-PI. de9 pinout

Some of the more common cables used in TARPN networks are described in Favorite Radios For Linking.

For store-bought cables, especially for ham radios, check out Ham-Made-Parts [hammadeparts.com].

4. Modes - Over-The-Air-Baud - AX.25 vs IL2P

The NinoTNC has 8 modes of transceive operation, 2 of which are expected to be fully interoperable with other TNCs. These two are 1200 AX.25 Bell 202, and 9600 AX.25 G3RUH-like.

The NinoTNC performs packet transmission and reception in 4 different bit-rates and with either AX.25 or IL2P. The NinoTNC selectively transmits AX.25 or IL2P at the configured over-the-radio bit-rate, but it receives either of those two protocols at the configured bit-rate.

The NinoTNC A2 has dip-switch access to four mode-sets, depending on the firmware version. The NinoTNC A3 has dip-switch access to all of the existing 8 mode-sets. The 8 existing mode-sets are:

IL2P is a forward error correction method, not compatible with AX.25 or FX.25. This means that between two IL2P equipped TNCs, the packets are less susceptable to loss in noisy situations. IL2P is described in the Improved Layer 2 Protocol..

All of the externally selectable modes are configured by dip-switches. The A2 NinoTNC may be configured using KISS commands to any of the modes available to the A3, but that configure mode does allow for some confusion and isn't discussed on this page. If you need an A3 mode which is not presented by the A2 switches, please send to our email reflector. In addition, one ham has been known to modify the A2 board so it electrically looks like an A3. This also is a little beyond the point of this web page.

5. Board Revisions - Differences

5-1 Board capabilities

All of the firmware available for the A3 will also work on the A2. The only difference between the two units is the selection of USB components, the selector dip-switch. amd the methods of compensation for microphone levels vs data radio in the TX output levels.

5-2 Data radio vs Microphone radio

The output level selection is done with a jumper, a short, or soldering in a new resistor, depending on the version of PCB, with A2 boards requiring a resistor in the L2 slot to support a microphone radio. Most of the A2 unit sales were to people trying 9600 baud, and the audio adjustment range of the stock A2 was perfect for that. The later versions of NinoTNC made it easier to select output levels by providing a jumper. Install the jumper-header for data radios, remove for microphone radios. See the History, Info, and the assembly instructions plus schematic for the older NinoTNCs and methods of dealing with this modification.

6. LED behavior

In version 2.73 and later, the five LEDs have this behavior, from left to right:

This LED has multiple functions. The primary function is the CRC was bad indication. This rare event means that the NinoTNC received a complete packet which must contain a 16-bit Cyclic Redundancy Check number but the CRC calculated for the bits of the packet did not work out to the same number sent as the CRC in the packet.
The second function of the LED (added in version 2.7) is to flicker when the audio coming into the NinoTNC exceeds the voltage range permitted for received packets. This won't usually hurt the NinoTNC but it does indicate that the receive volume is set too high. Using this indication, an operator can open the squelch on the receiver, then turn the volume control until the CRC LED flickers a little, and then to turn it down until the flickers stop. This will set the receive volume to an ideal level for the NinoTNC to perform the best decoding of the received packet.

Orange D5 Tx-Queue
This LED is shows that one or more packets are stored in the NinoTNC, waiting to go out. The NinoTNC is inhibited from transmitting by detection of channel activity, or by timing.
Note: The "stranger" feature was deleted in later versions of firmware. See the History page.

Green D4 Rx Packet
This LED lights when a packet is received and decoded successfully. It stays illuminated for 2 seconds, or until an undecodable packet arrives.

Yellow D3 DCD
Data Carrier Detect.
This LED lights when a bit clock is detectable in the received audio. This can flicker on non-packet data, but NinoTNC is really quick to recognize good packet data.

Red D1 TX
This light is illuminated when the CPU drives the Push To Talk circuit on the NinoTNC. If that circuit is working, the radio should be made to transmit.

7. Receive

6-1. DCD

The NinoTNC has a very good Data Carrier Detect. It prospers with open squelch. The DCD is agressive and can activate, or deactivate, in milliseconds. The algorithm (it's done in the CPU) looks for coherance between wave-form edges in the incoming signal, approximating the bit-time of the select bit-rate. If DCD detect is off, the NinoTNC will run a slot-time calculation and P-Persistance and may begin to transmit if there is a queued packet. LED D5 will indicate that there is a queued packet waiting to go out. If the DCD detect is on, the NinoTNC is looking for an 8-bit sync phrase, signalling the start of an AX.25 frame, or a 24-bit sync phrase, signalling the start of an IL2P sync frame.

7-2. DCD at wrong bit-rate

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 from packets heard at the wrong 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.

7-3. RXA scope loop

The NinoTNC has an RXA scope loop to which you can hook an oscilloscope, or test signals. One of the production tests is to connect the TXA loop to the RXA loop and see if the receiver is decoding the tranmitter. It is just as easy to connect another NinoTNC's transmit signal, i.e. TXA of #A to RXA of #B. Then TXA of #B can connect to RXA of #A. Now you have a packet link on the bench, enabling exploration of the interaction of the software at two hosts, on your bench.

In TNC-PI days we recommended that every node operator have a scope because the TNC-PI liked having packet audio come in at just less than 1 Volt Peak to Peak. The NinoTNC is comfortable with 3 V P-P and can do pretty good work down to under 1 Volt Peak to Peak. This means that receive level adjustment (aka transceiver volume knob) is not so picky. You can still use a scope at the RXA signal to observer the performance of the radios. It is very informative to see some wave-forms passing through the radio and the RXA scope loop makes this trivial to do, even in a hurry.

7-4. High Rx Volume Indication

In versions 2.73 and later, the DCD LED will flicker if the receive volume is too high. With the squelch open (loud rushing noise), adjust the receive volume up until the DCD LED starts to flicker, and then bring it down until the flickering stops. The NinoTNC is happy with you leaving the squelch open. That will let the NinoTNC start working on the receive packet sooner, since the squelch is already open.

7-5. AX.25 and IL2P Receive

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). The synchronization phrase for AX.25 and IL2P are different. The NinoTNC can recognize 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. This switch is ignored for receive decode.

7-6. Not Full Duplex

Except in the moments right after the the 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.

8. USB - serial ports

8-1 serial baud setting

Even though the NinoTNC uses USB, there is still a serial baud configuration. This describes the speed the USB-serial interface chip (FTDI or Microchip) uses to talk to the CPU on the NinoTNC. The NinoTNC expects 57600 baud, 1 stop bit, no parity, for the USB/serial interface.

COM and tty device name assignment:

The host OS will scan the USB ports at boot time and enumerate the USB serial devices.

8-2 MSWindows

A MSWindows computer will assign COM port numbers. A Linux host computer will assign /dev/tty names in the order of what hardware/physical USB hub and socket it finds them on, with a separate sort for FTDI vs Microchip. Tthe USB devices which are FTDI (NinTNC A1 and A2) will show up in the device directory, /dev, as /dev/ttyUSB0, /dev/ttyUSB1, etc. The USB devices which are Mocrochip MCP2221 (NinoTNC A3 and later) will show up in the device directory, /dev, as /dev/ttyACM0, /dev/ttyACM1, etc.

An issue with using USB serial devices as TNCs, and which we must put up with, for now, is that the Linux or MSWIndows OS will enumerate the NinoTNCs at computer reset, and will then assign the USB/serial devices as they are ordered. After another host computer reboot, the ordering is done again.

If a TNC is removed after the enumeration is complete, the /dev names and COM port numbers 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 host computer resets, the TNCs will show up with a new enumeration and the node will not function correctly.

The workaround for this behavior that we're using for now for Raspberry PI and Linux, is after your NinoTNCs are all plugged in, reset the host comuter Now use the TNCs in the "final" enumeration.

On MSWindows, you can identify the USB/serial devices in the device manager. Unplugging and replugging one of the NinoTNCS will allow you to see which COM unit is which NinoTNC.

8-3 Linux and Unix

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 application,
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 therefore matches the temporarily unplugged NinoTNC.
Make sure you plug the NinoTNC back into the same USB socket.

For the TARPN installs, it is our plan to, in the short term, come up with a feature that will additionally enumerate the TNCs as /dev/tarpn1.2.1.5 and /dev/tarpn1.2.1.6 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 list. That's another project. Hopefully, we'll be able to release that solution to the general Linux community. We'll see how things develop.

9. Transmit

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 the encoded packet), the host's KISS transmit frame will be silently ignored until its FEND end byte. The NinoTNC can handle more than seven outgoing 256byte frames in AX.25 mode because it has three transmit buffers that are filled with already encoded messages, so depending on selected bit-rate and channel activity, it is possible to have 10 full-size 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 are 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 finesse because of KISS's specified silent-ignore in an overflow condition.

9-1. TXDELAY potentiometer

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 (the 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, the 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.

9-2. TX-LEV and TX-TEST

The NinoTNC has three output adjustments:

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 for 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 then 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 transmission uses the N9600A-3 callsign, and if it is looped back, the NinoTNC will show TX-queue, TX and DCD and then RX. Or, TX-queue, TX and DCD and then CRC BAD.

9-3. 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.

9-4. 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.

9-5. Autonomous Transmit of Station ID

If the NinoTNC is configured to operate in IL2P or 2400, 4800, 9600 baud, it will do an autonomous transmission at 1200 AX.25 every 570 seconds during which there was KISS initiated activity. The autonomous transmission will be done at 1200baud AX.25 and will include a link to a TARPN web-page with the technical description of the modulation and protocol. This provides an obvious satisfaction of the question of whether we are intentionally obscuring the transmission through the use of undocumented protocols or modulation. The answer to that question becomes an obvious "no".

The NinoTNC will not transmit autonomously if no KISS transmit packets were sent to the NinoTNC in the past 570 seconds, or if the NinoTNC is operated at 1200 AX.25.

The NinoTNC will use send-from the Host's callsign (which gets stored in NinoTNC EEPROM), to transmit the ID and it will be sent to IDENT.

10. Bootloading to a new version of Firmware

The NinoTNC contains a facility to allow a host computer to push a new firmware version to the NinoTNC.
For TARPN node operators, see the tarpn flash command.
For Raspberry PI users of Raspbian Buster who are not using the TARPN node suite, see tarpnflash bootloader page.
For MSWindows and other users, we have a Python script and instructions [github] here.

Bootloading board version compatability

The older versions of firmware are provided so NinoTNC owners can revert to the "factory" original version. This might be useful for debugging system operation.

The bootloading process starts with the host computer telling the NinoTNC CPU to configure itself such that it runs the bootloader program every time it resets. Then the NinoTNC resets, causing it to run the bootloader client program. . You can see that the bootloader client program is running because the left 4 LEDS come on at the same time. Then the host starts sending lines of Hex data, via USB, to the NinoTNC's bootloader program, which the NinoTNC CPU programs into itself at the appropriate locations.
After all the hex data is received, the Host commands the NinoTNC to configure itself to reset into the TNC program, and then reset.
If the bootload process is interrupted, before the end, the NinoTNC may still reset into the bootloader program. Again with the 4 LEDs on at the same time. This is a problem. While it would conceivably be possible to resume a bootload which was interrupted, the programs were not designed with this in mind. The bootloader is cheap. While revising the bootloader scheme to be robust is possible, and is on the list of things to do, what we have is what we'll be working with for a while.

If you are part of a project with several NinoTNCs, it might be worth acquiring a MPLAB PIC-KIT. These are available on eBay for $30 once in a while. The new price is around $60 [microchipdirect]. PIC-KIT 3 or PIC-KIT 4 will work. The PIC-KIT can write to the NinoTNC CPU regardless of starting state. If you are going to be using one of these, we'll try to help you get started with it. Perhaps another web-page could be created detailing the software and procedures for running this.

We don't recommend bootloading firmware older than what shipped with the particular board, as some board-specific circuitry may exist that the older firmware can't live with. You may end up with a non-bootable NinoTNC. Backward compatibility is something we're striving for so you should be able to run new firmware on old boards. Forward compatibility is much harder and, in the interest of minimizing cost and complexity, we have not insisted on compatibility between old firmware and new boards.

11. Notes for using the NinoTNC

The configuration for all modes 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 NinoTNC always listens for IL2P and AX.25 packets at the selected bit-rate.

The NinoTNC modems at 1200 AX.25 and 9600 AX.25 should be compatible with industry TNCs and software TNCs. The NinoTNC 2400 and 4800 baud selections are not expected to be supported by other devices at the time of our launch. We're publishing the details of these so there shouldn't be a problem with the other providers following our lead if they desire.

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.

The NinoTNC expects KISS commands to set SLOTTIME and PPERSIST. Defaults are SLOTTIME 50 and PPERSIST 225.

12. 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-09600 baud GFSK IL2P
0-19600 baud GFSK AX.25
1-01200 baud AFSK AX.25
1-11200 baud AFSK IL2P

Version 2.41 shipped with the A3 r3 board. Version 2.41, and later versions, of the firmware use the switch positions to produce this table:

0-09600 baud GFSK IL2P
0-19600 baud GFSK AX.25
1-01200 baud AFSK AX.25
1-12400 baud DAPSK IL2P
As of this writing, July 31, 2020, version 2.41 of the firmware is available for order on ETSY for $5.

13. A3 specific instructions

You'll be doing 1200 baud Bell 202 modem, 2400 baud with a DAPSK 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 any of the 4 baud selections. The IL2P vs AX.25 selection affects the transmitted packet. The NinoTNC always receives IL2P and AX.25 packets in the selected bit-rate.
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 effect.
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-0FM+GFSK+LO+AX259600 baud AX.25
0-0-0-1FM+GFSK+LO+IL2P9600 baud IL2P
0-0-1-0FM+GFSK+LO+AX254800 baud AX.25
0-0-1-1FM+GFSK+LO+IL2P4800 baud IL2P
0-1-0-0FM+AFSK+LO+AX252400 baud AX.25
0-1-0-1FM+AFSK+LO+IL2P2400 baud IL2P
0-1-1-0FM+AFSK+LO+AX251200 baud AX.25
0-1-1-1FM+AFSK+LO+IL2P1200 baud IL2P
The table isn't completely correct as 2400 and 4800 are not strictly AFSK or GFSK.

14. 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

15. USB data dump -- GETALL message

Each time the TX-TEST button is released, the NinoTNC will generate and send a block of data to the host computer. If the host computer is displaying or logging the monitored packet data, this message may appear to come in over the air, or appear to be transmitted. It actually is not going over the air or taking up channel time.

The NinoTNC can also send this message on demand using a KISS command 0x0B (GETALL). The NinoTNC is capable of autonomously generating this data and sending it back to the host computer. This is subject to change. Please write to our email reflector if using this command. The TARPN project will use this data to diagnose node and network operation.

The data contains fields separated by the "=" sign. Each field has a 2 digit hexidecimal ID code, followed by 0 to 8 digits of hexidecimal data, in most cases, or is in ASCII text where specified.
00 firmware version (4 character ascii text string)
01 KAUP8R -- KISS Accessible User Programmable 8-character Register. May be used for USB device-ID. Erased by bootloader.
02 up time in milliseconds
03 board id (0 = A0, A1; 1 = A2; 2 = A3; 3 = A4r0 (all pre-release A4); 4 = A4r1)
04 switch positions (some bit-manipulation required to match with actual switch)
05 there is no #5
06 configuration mode
07 AX25 received packet count
08 IL2P correctable received packet count
09 IL2P uncorrectable received packet count
0A transmit packet count
0B preamble word count (multiply by 16 and divide by baud to get preamble time in seconds)
0C main loop cycle count since boot
0D PTT On time in milliseconds
0E DCD On time in milliseconds
0F Received data byte count (excludes preambles, flags, syncwords, etc)
10 Transmit data byte count (excludes self-generated ID beacons, preambles, etc)
11: Number of erroneous bytes corrected by IL2P FEC
If the TNC doesn’t reboot for other reasons, it will reboot itself after 23 days to prevent millisecond counter rollover (32 bits).


------------------------------------------  p6   2020-10-12 22:28:57

16. 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     

17. 3d-Printed Enclosures

Click here to go to the 3d-print-ninotnc web page.

Interesting Reads from G3RUH and others

AMSAT article 109 by G3RUH
WD6EHR 9600 baud handbook
© Tadd Torborg, 2020 -- all rights reserved