Command set of (x)ATNCs
Matjaz Vidmar, S53MV
Back in the times of AX.25, the TNC or network-node firmware was usually programmed into an EPROM. This required a specialized EPROM programmer, usually connected as a peripheral to the 8-bit home computer. Some specialized software was required to use each particular programmer.
The firmware was distributed in many different ways: as a source code yet to be compiled, as a hexadecimal image of the EPROM content and frequently as a programmed, ready to use EPROM device to be plugged into a socket on the printed-circuit board. Worst of all, besides the firmware some parameters had to be adjusted and then stored in the EPROM, requiring difficult firmware modification or even recompilation, frequent EPROM erasure and reprogramming.
In the 21st century, the semiconductor industry imposed a different approach to firmware programming. Complex system-on-a-chip devices are all available in SMD packages with large numbers of pins. Sockets for such devices are unreliable and prohibitively expensive if available at all. Stand-alone EPROM devices were replaced by an on-chip FLASH memory. Although a FLASH memory is much simpler to erase than an EPROM, it still requires a much more complex programming procedure than a static RAM.
All modern devices support In-System Programming (ISP) as a standard feature. Blank (unprogrammed) devices are first soldered into the final circuit board and then programmed using some dedicated pins. A very loose standard called JTAG was modified by individual device manufacturers to fit the needs of their particular devices.
Microprocessor-based devices also include In-Application Programming (IAP): the application running on the microprocessor can modify the content of the FLASH located on the same chip. Program parameters are stored in FLASH and can be simply adjusted by the firmware. The running firmware may include loading new firmware versions as well.
The ATNC family includes several different devices with programmable FLASH memory. The NXP (Philips) LPC2xxx microcontrollers include 512kbytes of FLASH program memory to store both the firmware (ISP) and several operating parameters (IAP). The Altera MAX3000A family of Complex Programmable-Logic Devices (CPLD) include their own FLASH memory to store their logic configuration (ISP), equivalent to an electrical circuit diagram.
The NXP (Philips) LPC2xxx microcontrollers contain a 32-bit ARM7 microprocessor. The ATNC firmware is written in 32-bit ARM assembler. The ARM assembler source code uses the extension ".s" and is written using a conventional text editor like "Windows Notepad".
Three different programs are required for the firmware compilation. First, "ARMASM" will actually compile the program into an object version with the extension ".o". Second, one ore more object files have to be linked with "ARMLINK" into an ELF binary machine code with the extension ".axf". Since the latter is usually not supported by FLASH programmers, "FROMELF" may be used convert the result to more standard formats like INTEL-HEX (extension ".hex").
Hopefully, the final user will never have to perform the above procedure, either with the stand alone compilers nor with the compilers built in an even more complex programming tool ("Keil" etc). The main idea of NBP is to keep everything simple including the firmware. Firmware updates are not planned. All firmware parameters can be adjusted from the running firmware through IAP.
On the other hand, the final user will have to program the ARM machine code in INTEL-HEX format into the FLASH of the actual microcontroller chip. FLASH programming of the LPC2xxx family always goes through the built-in "bootloader" software. The latter allows the chip manufacturer NXP (Philips) to improve the FLASH technology while keeping the user interface unchanged!
The LPC2xxx "bootloader" FLASH programming can be performed in two different ways: through the JTAG port and through UART0. The program "H-JTAG V0.9.2" only requires a simple cable called "CigoTAG" ("Wiggler" compatible) from the PC LPT port (must be a real LPT port, USB/LPT cables do NOT work!) to the JTAG port of the (x)ATNC:
Programming the ATNC/MATNC with a commercial USB JTAG, a pull-down resistor may be required on RTCK to enable the JTAG inside the LPC2138 (LPC2148). After programming with a JTAG cable, the JTAG connector on the (x)ATNC is used for different jumpers. The ATNC/MATNC uses a jumper on pins (TRST) 3-4 to enable UART0 control of the ATNC/MATNC (short) or save one memory block (open). The EATNC uses a jumper on pins 11-12 (RTCK) to specify the smaller memory of LPC2368 (short) or larger memory of LPC2387 (open).
All ATNC/EATNC/MATNC versions use a jumper on the unused JTAG pins 19-20 to invoke (short) the "bootloader" on UART0. In this case firmware programming is performed by the "FlashMagic" software connected through any PC COM port (may be USB/COM) to UART0 of the (x)ATNC. I recommend "FlashMagic" for the final user while "H-JTAG" is better suited for firmware development. In particular, I used "FlashMagic Version 5.50.1860" on most occasions.
Programmable logic uses less standard JTAG versions. Different manufacturers use different FLASH programming protocols that are only supported by their own programming tools. Altera MAX3000A devices can be programmed both by the old "MAX+plus II" software as well as with the new "Quartus".
The Altera devices used in the (x)ATNC family and BPSK transceiver family were all initially programmed with the "MAX+plus II 10.2 BASELINE" software. The actual circuit diagram is stored in the ".gdf" design file (binary) while the device selection, pin assignments and various options are specified in the ".acf" file (open ASCII text). Several other files are generated by the programming tool, but the most important is the ".pof" file containing binary information to be programmed in the FLASH of the EPM3064ATC44 CPLD.
The ".gdf" design file is fully compatible with new software from Altera and was ported successfully to the new "Quartus II 11.1sp1 Web Edition (32-Bit)", but the device selection, pin assignments and option selection had to be done once again from "Quartus". The final result is again the ".pof" binary file. Altera also provides a stand-alone programmer for the ".pof" design files.
The Altera programming tools support different JTAG programmers. The simplest are the LPT/JTAG cables "ByteBlaster" and "ByteBlasterMV" (Multi Voltage). A functional equivalent to both original Altera cables is the simple "CigoPLD" that works with both the "MAX+plus II 10.2 BASELINE" and the "Quartus II 11.1sp1 Web Edition (32-Bit)" on real LPT ports (USB/LPT cables do NOT work):
WARNING! CigoPLD uses a different signal allocation on the same 10-pin connector as original Altera cables. This was done on purpose to allow longer cable lengths with additional wires providing shielding among different signals. Both the CigoTAG and CigoPLD work with flat cables of 2m or more, although 60cm is the recommended length. The general rule with LPT cables is to avoid using additional buffers (74HC125 or 74HC244) that generate interference with longer cables. The standard LPT-port damping networks and a few additional damping resistors do the best job! If a commercial USB CPLD programmer is used, an adapter between the Altera pin allocation and the CigoPLD pin allocation is necessary!
A successful firmware programming of the microcontroller and/or CPLD already includes most of the troubleshooting in a system-on-a-chip design. In order for the programming to work, all supply voltages must be present, all clocks must be present, the reset circuitry must work etc. All of them may be checked with simple instruments.
Control of the ATNC/EATNC/MATNC could be established in several ways. AX.25 equipment like the "KISS/SLIP TNC" or the "10Mbps TNC" was controlled with simple AX.25 UI frames sent through the KISS interface, but working AX.25 terminal software is no longer available today. A Telnet or HTTP interface like in commercial WLAN (WiFi) equipment requires several protocol variables to be set to some default values, like the Ethernet MAC address, the IP4 default address and all timing parameters of the complex TCP/IP protocol.
In order to keep NBP hardware as simple as possible, a simple 9600bps, 8bits, no parity asynchronous communication is used for the control of the (x)ATNC in plain-text ASCII. Besides "FlashMagic", UART0 is dedicated to this control communication. In the ATNC/MATNC this communication has to be enabled by a jumper (short) between pins 3-4 of the JTAG connector.
The (x)ATNC accepts commands as ASCII strings terminated with a (CR) or any other control character except (BS). Only the lower 7 bits are decoded, the MSB is stripped away. Strings can be edited with (BS) or (DEL) both acting in the same way, deleting the last character in the buffer (if any) and replying (BS)+(space)+(BS) to the ASCII terminal.
The (x)ATNC replies include one or more ASCII strings. Each string should not contain any control characters except being terminated with (CR)+(LF). The ASCII replies are stored in a circular buffer of less than 2kbytes. In the case of too many and/or too long replies, entire sections of text may be removed while the message is truncated at arbitrary points.
At power-on, the (x)ATNC will present itself with an ASCII string including the hardware type (EATNC), software date (21.08.2011) and processor ID (1700FF35=LPC2387, new version):
Commands are simply entered as ASCII text. Upper or lower case does not matter as long as the string is not forwarded somewhere else in converse mode or stored as text with the command "J". An empty string is an unknown command! The command "R" is similar to a power-on reset.
An on-line list of all available commands is available with the command "?". The list is different for the ATNC, EATNC or MATNC. The example below shows the EATNC reply:
A detailed description of all commands is available in:
ATNC/EATNC commands (SLO)
In the following presentation the (x)ATNC commands will be briefly explained in a logical order. Not all commands may be present in different versions of (x)ATNCs. Some settings may not have any effect in some particular operating mode while they are critical in other modes.
Many commands may include one or more parameters. Only the parameters typed after the command letter will be modified. If no valid parameter follows the command letter, the parameters actually stored in RAM will be displayed.
All ATNC/EATNC/MATNC settings are stored in FLASH as an 1kbyte large block starting at address 0x7B000. Rather than typing individual parameters by hand, the settings block can simply be cloned using "FlashMagic" or "H-JTAG". Care should be taken that the settings block is always cloned between identical devices only, like ATNC-ATNC, EATNC-EATNC, MATNC-MATNC, running an identical version of firmware! Finally, do not forget that each (x)ATNC requires its own, usually different NBP address as well as its own, necessarily different Ethernet MAC address...
The transmission timing parameters (commands "S" and "T") are required when the (x)ATNC is connected to a radio transmitter:
Slot time, sync-head time and tail time are all specified in microseconds. Some slow radios (old 13cm BPSK transceiver) may require a longer sync-head time. The tail time is required to flush all FIFOs in the (x)ATNC and transmit at least one final HDLC flag.
Two different values are specified for the p-persistance. The first value is the conventional p-persistance waiting for an inactive DCD. The second, much lower value, ignores the DCD to allow some degraded communication even in the case of continuous interference.
The NBP retry parameters (command "P") are only used with NBP over radio. They have no effect in the KISS mode nor in the "inverse" HDLC-KISS mode (MATNC). In addition to the maximum number of retries Nmax and retry time constant Tretry, the MINBLOK congestion-control parameter is also specified in the same command:
All timing and retry parameters shown in the above examples are appropriate for an 1.2288Mbps link using a ZIF-BPSK transceiver. MINBLOK=5 is appropriate for an ATNC or MATNC with 15 or 16 available memory blocks or an EATNC with a LPC2368 and 20 available memory blocks. For an EATNC with a LPC2387 and 45 available memory blocks a higher MINBLOK=15 is recommended.
In order to use NBP, several addresses need to be set up:
All addresses are usually represented in the modulo (36) format as strings of letters and numbers. Amateur-radio callsigns can be used as NBP addresses. The most important setting is the station's own (my) address with the command "M". This setting turns on NBP in the (x)ATNC.
Two separate paths are specified for the service channel (command "N") and as a default path for IP4 or AX.25 frames (command "I"). Address paths may have up to 16 individual addresses. The last address is the final destination while all other addresses specify the network nodes where the data frames are going to travel. The service channel and/or the default path may be turned off by inserting zero in their address paths.
The operation of an ASV local wire loop is specified by the command "L":
Frames addressed to destinations in the "L" list will be sent to the local wire loop, while all other frames will be sent to the radio link. A frame sent to a broadcast "*" destination will be sent both to the radio link and to the wire loop. Inserting zero in the "L" list switches UART1 to SLIP mode.
An EATNC operating solo may require at least one nonzero entry in the "L" list to turn off SLIP and enable the Ethernet port. This single entry may be the station's own address. In this case "M" and "L" settings are identical.
Inserting the broadcast address "*" in "L" effectively disables NBP on the radio link, since all frames are sent to the local wire loop. An "*" in the first place (or solo) in the "L" list completely disables the radio HDLC interface in the ATNC/EATNC to save CPU power.
The setting L=* may not make any sense in an ATNC. The settings M=0 and L=* disables both NBP and the radio link, switching an EATNC into an Ethernet-SLIP converter. Finally, the setting L=* invokes the "inverse" HDLC-SLIP mode of a MATNC.
The ASV node skip is further controlled by the order in which the individual addresses are entered in the "L" list. Besides their own NBP address, all (x)ATNCs also process the data frames addressed to destinations from their own "L" list. Then the sending (x)ATNC#A finds the distance to the destination (x)ATNC#B in the local wire loop by looking at its own "L" list. For example, a destination two (2) hops away must be entered in the second (2) position in the "L" list! Every member of a local wire loop therefore requires a different, carefully compiled list "L" to reach the correct destination in the ASV node-skip mode.
Besides the default path, the ATNC/EATNC/MATNC are able to perform different routing for up to 10 particular IP4 addresses or up to 10 particular AX.25 callsigns. The operation of this additional NBP routing table is controlled by the command "A":
The operating mode of the NBP routing table is selected by:
A ! 0(enter) ...IP4 routing off,
A ! 1(enter) ...IP4 routing read only,
A ! 2(enter) ...IP4 routing auto update without default path,
A ! 3(enter) ...IP4 routing always auto update,
A ! 4(enter) ...AX.25 routing off,
A ! 5(enter) ...AX.25 routing read only,
A ! 6(enter) ...AX.25 routing auto update without default path,
A ! 7(enter) ...AX.25 routing always auto update.
Routes can also be added manually with the command:
A (IP4/AX.25 destination) (NBP path)(enter) ...add new route or modify existing route.
Routes can be removed by omitting the NBP path in the above command.
In an unattended station (gateway, server, IP camera etc) it makes sense to keep the FLASH table A empty and the auto update on (modes A!2 or A!6) without default path. The table A will grow automatically as traffic comes in.
In a home or office station with human-operator presence it makes sense to store additional routes to known destinations (servers, IP cameras, AX.25 callsigns etc) in FLASH. Auto update may be either off (modes A!1 or A!5) or on (modes A!2 or A!6) without the default path.
Always-auto-update modes A!3 and A!7 are useful to monitor all traffic. The FLASH table A list may be kept empty in this case.
The command set also includes a few critical system settings:
The UART1 baudrate (KISS, SLIP or local wire loop), selected with the command "B", only becomes effective after restarting the (x)ATNC by storing all parameters to FLASH.
The Ethernet mode can be set 10 (10Mbps), 11 (10Mbps with MDIX), 100 (100Mbps) or 101 (100Mbps with MDIX). Any other number invokes AutoNegotiation and AutoMDIX. The latter setting (may be 0 for convenience) is usually the best choice.
The Ethernet MAC address should be set to something different form all other Ethernet LAN members. Besides the broadcast address, multicast addresses starting with an odd first byte should be avoided! Both the Ethernet mode and MAC address are written to peripheral registers, requiring a restart of the EATNC by storing all parameters to FLASH.
The most dangerous command "Q" is used to change the crystal or clock frequency. The latter is exactly four times the former. The firmware will check that the two numbers are within reasonable limits and that the second entry is exactly four times the first entry. Besides all checks, the new values must be written to FLASH and the system restarted.
A wrong setting of "Q" will change the baudrate of UART0 to some strange value making any further commanding impossible. The only way back is to erase the whole 1kbyte FLASH parameter block starting at 0x7B000 with "FlashMagic" or "H-JTAG". An erased parameter block includes a far too high clock frequency. This will be detected as an error at the next system start and replaced with the default value (14.7456MHz crystal).
A very important timeout is set by the command "W". In SLIP mode, it defines when to flush the SLIP-frame buffer to allow switching back to the Hayes-modem "AT" commands with the string "+++". In Ethernet mode (EATNC only), it defines how much to wait after an ARP request. 10000 microseconds (10ms) is an acceptable value for both. The value from an erased FLASH will block the Ethernet port for more than one hour after the reply to a single ARP request is lost!
The MATNC modem settings also include a constant that has to be written into the A/D-converter clock divider at system start. The latter only becomes effective after restarting the MATNC by storing all parameters to FLASH.
The complete block of parameters is written to FLASH with the command "F". The latter requires typing the key 123456789 to avoid unwanted modifications of the FLASH content. After successfully writing to FLASH, the ATNC/EATNC/MATNC will reboot to refresh the registers of all affected peripherals.
The ATNC/EATNC/MATNC firmware includes several commands for status monitoring:
All NBP addresses can be displayed in modulo (36) format (default) as well as in hexadecimal format. The latter may be selected by the command "H" and may be useful for testing. All eight (8) hexadecimal digits of a 32-bit NBP address are always displayed to distinguish from the modulo (36) format with one to seven (1..7) characters.
The command "K" is used without any parameters to look at the two A/D telemetry values on most occasions. A single parameter in the command "K" allows switching the telecommand output locally. The default telecommand output is zero (switch off) after reset. The second parameter, if specified, sets the hexadecimal password for remote commands. The password should be stored in FLASH!
The commands "U" and "V" are used to select which frames are displayed. The default setting after reset corresponds to the command "U": only service-channel data frames reaching the final destination will be displayed. In addition to the frame content (with any control characters stripped away), the address path will be shown in all cases.
The command "V" will display all frames, data and acknowledge, traveling through the (x)ATNC. In addition to the address path and frame content, the (x)ATNC port as well as the pseudo-random, lifetime or distance tag will be displayed. The (x)ATNC port and direction is described by a single letter:
L ...frame received on the local wire loop,
R ...frame received on the radio HDLC port,
S ...frame sent to the local wire loop and
T ...frame sent to the radio HDLC port.
First, the command "V" is very useful to learn how NBP works. Second, the command "V" is useful for troubleshooting, especially when setting up the local wire loop with the command "L". Finally, the command "V" may be used for traffic monitoring. In this case it may be useful to switch the (x)ATNC to protocol-less KISS mode to listen to all traffic on the radio channel.
The command "X" displays the Ethernet-PHY status and the last-heard MAC address in an EATNC. It is very useful to identify what is wrong with the UTP cable and how the Windows or Linux on the other end of the UTP cable crashed. A repetitive "X" display once per second may be turned on or off, the reset default is off.
The command "Y" includes six (6) hexadecimal parameters as two groups of three parameters for each telemetry channel. The raw A/D output is always displayed regardless of the "Y" settings. The A/D output is first multiplied by the first parameter, then divided by 1024 and finally the second parameter (may be negative) is added. The display includes a decimal point before the last digit. The third parameter specifies up to four ASCII characters to display the units (V, C, % etc). Control characters (zeros) are simply not displayed.
The command "Z" displays the status of the (x)ATNC: the DCD%, the PTT%, the number of free-memory blocks, the number of loops-per-second (free CPU capacity) and the (x)ATNC up-time (days/hours/minutes/seconds). A repetitive "Z" display once per second may be turned on or off, the reset default is off.
Ethernet is a protocol that may transfer different payloads on the same physical channel. Ethernet frames include their own Ethernet-MAC addresses, a type field specifying the payload, the payload itself and a 32-bit CRC:
All Ethernet hardware generates/looks for the standardized 8-byte SYNC at frame start and automatically generates/checks the 4-byte CRC at frame end. An Ethernet frame may include additional framing (start, stop, sync) depending on the particular physical channel used.
The 48-bit Ethernet addresses are supposed to be assigned by the equipment manufacturer. Each individual product should have its own, globally unique "unicast" address. Everyone is supposed to listen to the broadcast address consisting of all (48) logical ones. Rather than correcting some old software bugs, "multicast" addresses were invented to make our life more difficult.
The Ethernet payload is specified in the 16-bit TYPE field. The same field could also be used for frame length, but this is usually not done. A very large number of TYPE fields are specified for different protocols. In practice, only three different TYPE fields are used: IP4, ARP and IP6.
Ethernet specifies both the minimum and maximum size of the payload. The minimum size is required by some old physical channels and may require padding small payload frames with zeros. The maximum size may be increased in the future, but the 1500 byte MTU is a world standard today, supported by all known hardware including the EATNC.
Since Ethernet includes its own addresses, routing of higher-level protocol frames is required. Initially, Ethernet routing was performed by hand-written routing tables. The Address Resolution Protocol (ARP) was invented to automatically build and update routing tables. While ARP is a separate protocol supporting IP4, ARP is built into IP6 right from the beginning. Today (2012), most Ethernet equipment including the EATNC only supports IP4 and the corresponding ARP.
When an IP4 frame has to be sent over an Ethernet network, an ARP request for that particular IP4 destination is sent to the Ethernet broadcast address first. Hopefully, an ARP response is received in time, specifying the Ethernet-MAC address for the requested IP4 destination. The IP4 frame can now be sent to the specified unicast MAC address. The latter may be stored together with its corresponding IP4 destination in an ARP cache to limit further ARP requests for the same IP4 destination. The ARP cache is flushed after some time (usually 2 minutes) to keep it periodically updated.
The ARP cache might grow several orders of magnitude larger than the number of different Ethernet-MAC addresses in a local-area network. Since most IP4 destinations, in particular the external ones, are only reachable through a single Ethernet-MAC address, the latter may be considered the default gateway. IP4 frames for external destinations simply send an ARP request for the default Ethernet-MAC address or use the corresponding entry in the ARP cache:
In order to separate local from external IP4 addresses in a simple way, an IP4 address domain is usually defined. Individual ARP requests are only required for IP4 destinations inside the domain mask. A single ARP request is required for all IP4 destinations outside the domain mask. In order to use the same ARP protocol in both cases, a default-gateway IP4 address is invented. The latter may not and needs not to correspond to any existing IP4 host! The only thing that matters is that some piece of equipment answers with an ARP response containing the default-gateway Ethernet-MAC address.
In order to understand the settings of an EATNC, it is very important to understand the above description of the ARP, IP4 domain and default gateway into detail! The EATNC is not an IP4 host. Yet the EATNC has to perform Ethernet routing tasks that are more complicated than those found in a Windows computer or a LAN router. The IP4 domain settings of an EATNC are therefore necessarily more complicated!
An EATNC may be connected to a single Windows computer. An EATNC may also be connected to an Ethernet switch supporting a LAN with many IP4 hosts like Windows computers, IP cameras etc. Two or more EATNCs may also be connected to an Ethernet switch supporting a LAN with many IP4 hosts. An EATNC may be connected to an IP4 router not performing NAT. NAT (Network-Address translation or IP4 masquerade) may be turned on in an IP4 router and an EATNC may be connected to either side of the NAT. Finally, DHCP requests (automatic IP4 address assignments) may be either handled or blocked, depending on the network configuration.
In order to fulfill all of the above requirements, the EATNC Ethernet routing is specified by two different commands "D" and "G". The command "D" specifies the IP4 domain for the incoming traffic from the Ethernet LAN to the EATNC. The command "G" specifies the default gateway for the outgoing traffic from the EATNC to the Ethernet LAN.
The command "D" specifies how are incoming ARP requests handled by the EATNC. Both an accept domain and a reject subdomain are defined:
The EATNC does not answer to ARP requests outside the accept domain. The EATNC does not answer to ARP requests inside the reject subdomain either. The EATNC only answers to ARP requests inside the accept domain but outside the reject subdomain. All incoming IP4 traffic to the EATNC's unicast address is routed to the NBP network afterward.
If two or more EATNCs are connected to an Ethernet switch, care should be taken that their domains do not overlap! Only a single EATNC or another Ethernet device is allowed to answer to an arbitrary ARP request. An ARP response actually means that the corresponding EATNC or another Ethernet device knows the path to the requested IP4 destination.
If a single WinXP computer is connected to an EATNC, no special domain setting is required. WinXP is therefore happy with:
D 0.0.0.0 0.0.0.0 255.255.255.255(enter)
The same is not true for the stupid Win7. At least the domain 169.254.x.x needs to be blocked, else Win7 does not work.
The command "G" specifies what ARP requests are sent by the EATNC to the Ethernet LAN and how are the corresponding ARP responses handled by the EATNC. In particular, the command "G" specifies the default gateway, the mask relative to the specified gateway and the ARP cache lifetime:
The EATNC will send individual ARP requests for all IP4 destinations inside the mask applied to the specified default-gateway IP4 address. The EATNC will send a single ARP request for the specified gateway for all IP4 destinations outside the specified mask.
If a single Windows computer is connected to an EATNC, there is no gateway! An ARP cache lifetime of 100 seconds is always ok:
G 0.0.0.0 0.0.0.0 100(enter)
The "D" and "G" settings are completely independent!
In an amateur-radio network, it makes sense to use fixed IP4 addresses from the 44.x.x.x domain. Using fixed IP4 addresses we do need any almighty servers to find our correspondents. If automatic IP4-address assignment (DHCP) is desired, it is better done in the local IP4 router. The EATNC accept domain has to be set to avoid generating ARP responses to DHCP requests. Conflicts with other DHCP servers that may be present in the NBP network are thus avoided.
An interesting application is to use an IP4 router to bounce IP4 traffic from an EATNC back to the same EATNC. Together with the NBP routing mechanism built inside the (x)ATNC family, this allows connecting users that do not know the configuration of the NBP network nor the exact location of their correspondent, when the above-mentioned IP4 router acts as a server.
The EANTC nor the whole idea of the NBP network is NOT TO COMPETE WITH NOR TO FIGHT other technologies like IP4 routers or WLAN (WiFi) networks. The idea of NBP is to COMPLEMENT other technologies to build an even better network!
Besides setting up the operating parameters of the ATNC/EATNC/MATNC, the UART0 control communication is also used for simple text chatting, remote commands and link measurement through the NBP service channel. To send information to the NBP service channel, the corresponding address path has to be set with the command "N" and the (x)ATNC has to be switched to the converse mode with the command "C":
Any text typed after the command "C" will be sent to the NBP service channel. An empty line, (enter) only, will switch the (x)ATNC back to command mode. Any additional empty lines will be understood as unknown commands by the (x)ATNC. A time interval may be specified in the command "C" to repeat sending the last typed line indefinitely. This is useful to observe remote telemetry and/or to periodically issue reset commands (power cycling) to recover crashed Linux equipment (routers, IP cameras) at a remote location.
Remote commands are identified by the string "////" at the beginning followed by a single ASCII character to specify the command. Remote telecommand requires adding the same hexadecimal password as entered with the command "K" into the remote (x)ATNC. A software reset can be issued to the remote (x)ATNC by sending the hexadecimal password twice.
A short information text of up to 64 ASCII characters may be entered with the command "J". This text can be read remotely with the command "////?" to get some useful information (location, frequency, bit rate, IP4 host) about the remote station. All remote commands can be disabled by erasing the information text!
During network setup and/or troubleshooting, a simple, quick and efficient link measurement is very required. The (x)ATNC family may perform repetitive echo measurements once per second with the command "O":
The echo-measuring data frame includes a time tag and a pseudo-random test sequence of the specified length in the command "O". The round-trip time, number of test bytes and number of error bytes found is displayed for every received reply. The time tag is also used for the pseudo-random root, so every test frame contains different test bytes. If broadcast NBP addresses "*" are specified with the command "N", a very large number of replies may be received for each interrogation.
The echo measurement is based on the remote echo command "////>". If a service-channel data frame starts with the sequence "////>" (interrogation) or "****>" (reply) and contains a sufficient number of bytes, it will be decoded as an echo measurement by any (x)ATNC rather than displaying its raw content.
(AX25) (LINK) (NBP) (ATNC) (CMD) (RTX) (NEW) (HOME)