tarpn_logo
 home    builders    Search

buildersTARPN ProjectsNinoTNC USB ➜ N9600a Operation

NinoTNC N9600A Operation

page modified March 4, 2021
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 distributed 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.
Thanks!!!


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. AX.25 and IL2P Receive
    5. CRC Flicker - High Rx Volume Indication
    6. CRC Latched - Uncorrectable Error in Received Packet
    7. 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. A4 Specific Instructions
  15. 9600 baud receive eye pattern
  16. USB data dump GETALL message
  17. G8BPQ Node Config
  18. 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. See the A2 specific instructions, in this document, for details.

The NinoTNC A3 and NinoTNC A4 have a 4-switch "MODE" dip-switch providing 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. It is more effient than FX.25, often as efficient as AX.25, but still providing forward error correction. This means that between two IL2P equipped TNCs, it is an easy choice to switch to IL2P because 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. In addition, one ham has modified the A2 board so it electrically looks like an A3. This also is a little beyond the scope of this web page.


5. Board Revisions - Differences

5-1 Board capabilities

All of the firmware available for the A4 and A3 will also work on the A2. The A2 only allows 4 MODE-settings where the A3 and A4 can do 16 MODE-settings. At this writing, the A3 and A4 only support 4 different bit-rates, plus two base protocols, AX25 and IL2P. One of the 4 MODE dip-switches, the switch closest to the CPU, is reserved for future projects. As of March 2021 it is a NO-OP. Leave it in the OFF position until it is needed by a new version of firmware.

The A2 units had a daughter card for USB micro connection where the A3 and A4 units have a soldered-down USB-B (printer) socket and an on-board Microchip USB/serial chip.
The A3 and A4 have progressively more complicated and slightly improved TX and RX audio handling.
The A4 has a SIGNALS switch permitting easy adjustment of receive and transmit gain.
The A4 has a selectable AC vs DC coupling, where the A2 and A3 units were always DC coupled.

5-2 Data radio vs Microphone radio

The output level selection is done with a switch, 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. The initial goal of the NinoTNC was to provide a low-cost 9600 baud option as a complement to the Coastal Chipworks TNC-PI. When Coastal Chipworks announced they were discontinuing TNC production, TARPN moved to add 1200 capability to the NinoTNC and thus the NinoTNC A2 was born. It wasn't until the A3 units started production that the TARPN NinoTNC project recognized that the drive level of 1200 baud radios would not be the same as 9600 baud radios and a special "hack" was added, both to the A2 instructions and the A3 boards. This would allow running the output of the NinoTNC to the sensitive microphone input of a ham (or commercial 2-way) transceiver.

With the A2 boards a resistor must be added where none was provided for. With the first release of the A3 boards, a resistor is provided for but a short must be added to optimally drive a data radio (that was a mistake). With the second release (actually the 3rd version) of the A3 board, a 2 pin jumper/shunt position was provided to select data radio (shunt in place), or microphone input (shunt removed). The A4 improves on that "hack" with a switch selectable drive level.

Later in this document are chapters specific to each of the production boards. In addition, the History, Info, and assembly instructions plus schematic have details about individual revisions of the NinoTNC.



6. LED behavior

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

Red D5 CRC BAD
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.

Blue D6 Tx-Queue
Note: Was orange in the A2 and A3 versions. Blue in A4 and later versions.
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.
This LED will flicker very briefly when KISS instructions are exchanged with the NinoTNC. I haven't been able to see this so it must be very brief?
Note: A "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. See Receive chapter.

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

7-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 - "Tx-Queued" - 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 detection 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, a NinoTNC configured for 9600 could transmit right on top of even a strong 1200 baud packet.

DCD detect is based on the data-slicer’s guess about how well it has synchro its regenerated bit clock to the zero crossings in the signal. It needs to see 4 zero-crossings sequentially in sync with its regenerated clock, i.e. at the same bit-rate, to declare that it detects data. The data slicer is constantly trying to synchronize its regenerated bit clock via a software PLL applied to the sliced receive audio. When it sees 4 sequential zero-crossings in sync with its own regenerated clock, it turns on the LED, and sets an 80 bit timer to “coast” and hold DCD. Each bit that goes by without sync, the 80-bit timer is decremented. When it hits zero, DCD is de-asserted and the LED is turned off.

7-3. RXA scope loop

The NinoTNC has an RXA scope loop to which you can hook an oscilloscope, You can also drive test-audio directly into the RXA scope loop instead of having to wire up a DE9 connector just for some experimental scenario. One of the NinoTNC Kit Assembly 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, without tying up two radios.

In TNC-PI days we recommended that every node operator have a scope because the TNC-PI liked having packet audio come in at a critical voltage level, 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 around 0.3v 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. 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-5. CRC Flicker - High Rx Volume Indication

In versions 2.73 and later, the CRC LED will flicker if the receive volume is too high. With the squelch open (loud rushing noise), adjust the receive volume up until the CRC 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.6. CRC latched - Uncorrectable Error in Received Packet

The CRC LED will come on at the end of a received packet which was not delivered to the host because of errors (uncorrectable errors in the case of IL2P), but only if the failing packet is in the same protocol (AX.25 vs IL2P) as the most recent 'good' packet. The CRC LED will stay lit for 2 seconds, controlled by a timer, regardless of other activity running simultaneously on the NinoTNC. The NinoTNC will continue to perform transmit and receive, as called for, during this 2 seconds. It is allowed behavior for the NinoTNC to display CRC error for a previous packet and RX PKT (green LED) for a following packet, at the same time.

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

In the video, the TX DEV potentiometer on the TNC is at minimum at first, then slowly increased while holding the TEST TX button. Alignment to the selected 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.

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

The NinoTNC provides 4 different tones which may be used to select a specific deviation. Select the different tone by using the MODE switch. The middle two switch positions (of the A3 and later NinoTNCs) will select between the four available tones. Switch setting of
X00X will generate a 999hz tone which will drive a bessel null at 2.4khz deviation.
X01X will generate a 500hz tone which will drive a bessel null at 1.2khz deviation.
X10X will generate a 2079hz tone which will drive a bessel null at 5khz deviation.
X11X will generate a 1248hz tone which will drive a bessel null at 3khz deviation. Note: Wider deviation than the minimum will result in better decodes with weaker signals. It is up to the operator to know how what the ideal deviation is, and to make adjustments to reach that ideal. The operator should keep in mind the capabilities of the radio on the other end of the link, the adjacent channel implications of a wide signal, and the rules for your country. In dedicated point to point applications, the deviation will be idealized for the capabilities of the receiver on the other end of the link. In multi-cast applications (APRS for instance) the ideal deviation will be regional or national.
For 1200 baud APRS applications in the USA, 3khz is likely to be the most ideal of the available selections.

More notes:
Deviation is set with the TX_DEV pot.
Changing the operating mode switches does not change NinoTNC transmit deviation, but does change the tuning tone.
The "best" deviation will be based on many factors, such as the specific radios used in the link.

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.

Data radio vs Microphone radio

compare revision 2 with revision 3
There are two different shipped versions of the A3 board. We ordered a total of 810 copies of the A3.

r1

The test version, "r1", only 10 boards ordered, several built, used the same output drive circuit as the A2 board.

r2

While we were still testing the evaluation r1 boards, the community reported that the A2 TNC was overdriving the microphone input of certain radios.
For the next spin we added a resistor R3 in the output circuit to try to compensate between the drive level required for data radios (the intial design was for 9600 only) and the drive level required for microphone-input radios.
We ordered 200 units of the "r2" boards and sold them via ETSY.
After we started shipping the "r2" version, the community reported that some data radios were now underdriven even at max TX-LEV. So we now had to short across R3 when using the NinoTNC A2 with a 9600 baud data radio or a radio with 9600 support.

r3

We modified the design again to add a jumper to selectively short-out the resistor. This version, "r3", has J6 jumper to perform the output level selection. Put the shunt over J6 if using the NinoTNC A3 in data radio service. Remove the shut for use with a microphone input. Over the next six months we ordered and sold 3 sets of 200 units, via ETSY.

14. A4 specific instructions

The A4 board has two 4-bit DIP switches labelled SIGNALS and MODES.

MODES switch

The A4 has switches to select 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 first switch, OP1 vs OP2, is for an optional parameter and is not checked by firmware, so far.

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:

x-0-0-0FM+GFSK+LO+AX259600 baud AX.25
x-0-0-1FM+GFSK+LO+IL2P9600 baud IL2P
x-0-1-0FM+GFSK+LO+AX254800 baud AX.25
x-0-1-1FM+GFSK+LO+IL2P4800 baud IL2P
x-1-0-0FM+AFSK+LO+AX252400 baud AX.25
x-1-0-1FM+AFSK+LO+IL2P2400 baud IL2P
x-1-1-0FM+AFSK+LO+AX251200 baud AX.25
x-1-1-1FM+AFSK+LO+IL2P1200 baud IL2P
The table isn't completely correct as 2400 and 4800 are not strictly AFSK or GFSK.

SIGNALS switch

a4 board, closeup of signals switch

The normal state of this switch for a Microphone-input transceiver is OFF-ON-ON-OFF.

The signals switch affects transmit and receive audio, and also enables an external inhibit input.
Pushing the switch toward the edge of the board is ON and also the "1" position.
Pushing the switch toward the TARPN logo at the bottom of the board is OFF, and also the "0" position.


15. 9600 baud receive eye pattern

You can get the 9600 receive eye diagram at the RXA scope probe loop. Set the trigger for 1.65 volts


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

Example:

------------------------------------------  p6   2020-10-12 22:28:57
KK4HEJ-15>IDENT:
=00:2.76=01:13FAAAAut=02:0010FB70=03:00000001=04:00000002=06:00000001=07:00000000=08:00000011=09:00000000=0A:00000022=0B:00000012=0C:02157BDF

17. 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:
PORT
PORTNUM=1                                
ID=p2p link to k1qsy-2     
TYPE=ASYNC                                
PROTOCOL=KISS                         
FULLDUP=0                      
COMPORT=/dev/ttyUSB1
SPEED=57600                    
CHANNEL=A                      
PERSIST=225                    
SLOTTIME=20                   
TXTAIL=1                       
QUALITY=1                      
MINQUAL=81                     
MAXFRAME=1                     
FRACK=6000              
RESPTIME=40                    
RETRIES=20                     
PACLEN=236                      
UNPROTO=ID                     
L3ONLY=0                       
DIGIFLAG=0                     
DIGIPORT=0                     
USERS=1                        
IGNOREUNLOCKEDROUTES=1  
ENDPORT

Here is a G8BPQ port definition for 9600 baud using a Tait TM8105 data radio:

PORT
PORTNUM=1                              
ID=p2p 9600 link to k1qth-2     
TYPE=ASYNC                             
PROTOCOL=KISS                          
FULLDUP=0                              
COMPORT=/dev/ttyUSB0
SPEED=57600                      
CHANNEL=A                              
PERSIST=225                            
SLOTTIME=20                            
TXTAIL=1                               
QUALITY=1                              
MINQUAL=81                             
MAXFRAME=1                             
FRACK=2000                             
RESPTIME=20                            
RETRIES=20                             
PACLEN=202                             
UNPROTO=ID                             
L3ONLY=0                               
DIGIFLAG=0                             
DIGIPORT=0                             
USERS=1                                
IGNOREUNLOCKEDROUTES=1                 
ENDPORT

18. 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↝2021 -- all rights reserved