TNC-X build

This article documents the build of a TNC-X, a basic KISS only TNC using modern components, including option of an on board USB interface.

TncX01

Above, the PCB after assembly and cleaning.

TncX02Above, the underside of the assembled PCB.

TncX03Above, the view inside the case of the fully assembled and tested TNC. The headers and cables used on the DIN interface and 3.5mm socket are not part of the kit.

TncX04Above, the finished TNC complete.

Setting tx audio output

The TNC lacks any useful facility to producing continuous tones at 2.2kHz and 1.2kHz to set the deviation accurately and check pre-emphasis. The back channel carrier is at a relatively low frequency (487Hz) and does not provide an accurate setup for 2.2kHz modulation, nor does ie allow one to check the pre-emphasis is working properly.

This TNC was setup using an R2000 comms analyser with a modulation display calibrated in kHz deviation, and adjusting the audio output until the 2.2kHz tone components just made 3.0kHz deviation. The 1.2kHz component could then be observed at around 1.5kHz deviation confirming proper operation of the transmitter pre-emphasis.

Observations

The kit with case and USB option was selected. The use of an FTDI USB interface chip was an important factor in buying the TNC.

Though one could be forgiven for thinking that the TNC-X is an implementation of the design laid out in (Hansen 2003), the TNC-X appears to have only a 2 pole high pass filter on the audio input.

Price was reasonable, delivery was prompt, PCB was good quality and assembly was easy (apart from a couple of missing capacitors).

The kit just worked, no problems encountered. Bezels are not supplied with the LEDs and I can see them getting pushed into the case easily. Adjusting TxDelay was a bit of a trial, unlike most, this sends garbage during the TxDelay period then two characters of frame code and into the frame. Adjustment required recording the transmitter output with another receiver and measuring the TxDelay period on the recording, and iteratively adjusting it.

Little consideration is given to proper lineup facilities for many TNCs, possibly contributing to the observation that most AFSK signals are grossly overdriven.

The receive side of the modem seems a little more tolerant of overdriven signals than the AN7910 chip in another TNC (see The extent to which APRS works is often an accident), but will not decode the worst local digi (VK2RHR-1).

Overall, I was quite satisfied with the kit which was easy to build and worked as I expected it should.

There is no mention of support for KISS command codes in the documentation, and (Hansen 2003) says My experience is that KISS
mode programs very rarely use these commands and at this point I have not supported them in TNC-X
… so it appears to be a half-baked KISS implementation. TxDelay is controlled by a pot, and it appears that you cannot vary Persistence, Slottime, or Txtail. I say appears because the documentation supplied with the TNC-X doesn’t make it clear that it ignores all KISS commands, nor the parameter values that are locked in to the implementation.

I needed to ask the developer about how he had implemented the persistence algorithm. I was advised that the curret implementation ignores KISS commands and has a fixed p=25% and SLOTTIME=100ms.

The data carrier detect (DCD) is sensitive to data at HDLC frame codes, and does not respond to noise (or even data at 1200Bd until it contains a frame code). This is an advantage and it can be run open squelch, and it is not likely to be locked out by squelch drift or an interfering signal that is not valid HDLC data. The disadvantage of requiring frame code for DCD is that other modems that send isochronous preamble (eg some Argent Data products) will not activate the TNC-X DCD and it is possible for the TNC-X to try to transmit over them during the isochronous preamble. (It is arguable whether Argent’s approach is compliant with the HDLC recommendation.)

Improvements

Possible improvements to the design include:

  • fully implementing KISS, including command codes;
  • a method of creating 1200Hz and 2200Hz tones for lineup; and
  • send frame codes during the entire preamble to make observation of TxDelay easier;
  • implement SMACK.

I would buy again for an end user device but not for infrastructure, in fact I considered their TNC-Pi kit for a stand-alone javaAprsSrvr but the postage seems excessive.

To allow accurate lineup for some performance tests, I have created alternate firmware which creates a test signal alternating between 1.2kHz and 2.2kHz every 5s.

References

  • Hansen, J. 2003. TNC-X: An Expandable Microcontroller-Based Terminal Node Controller. http://tnc-x.com/dcc3.doc (accessed 20/07/14).
  • TNC-X