Category: ‘TNC’ – Severity: ‘Block’
Uh oh
Tonight one of our VAPN testers had problems accessing the prototype VAPN system on the 1200 port (the only RF port so far) featuring the SCS Tracker DSP TNC with the following bpq32.cfg port settings…
Port settings and Tracker version
; SCS Tracker Port Specification PORT PORTNUM=2 ID=VHF 1200 Port COMPORT=/dev/ttyUSB0; COM Port Address SPEED=38400; COM Port Speed DRIVER=TRKMULTI QUALITY=0 ;Setting to 0 stops node broadcasts on this port MINQUAL=168 ;MAXFRAME=2 ;Max outstanding frames (1 thru 7) ;RESPTIME=1000 ;Level 2 delayed ack timer in milliseconds ;RETRIES=2 ;Level 2 maximum retry value PACLEN=128 ;Max = 236 if using NETROM links ;TXDELAY=500 ;Pretty quick TX/RX radio ;TXTAIL=300 ; CONFIG ; Driver-Specific Configuration PACKETCHANNELS 5 ; Limit to 5 simultaneous connections R 0 ; Digipeating OFF F 3000 ; FRACK: Setting to 3 seconds. N 10 ; RETRY: Setting to 10 0 2 ; MAXFRAME: Setting to 2 T 50 ; TXDELAY: Setting to 1/2 second (50 * 10) @T2 150 ; RESPTIME: Setting interval before ack of received packet to 1.5 seconds. %N 5 ; TXTAIL - new TXTAIL (fw 1.5v) setting in 10ms increments. %B 1200 ; 1200 is the poweron default, but setting it anyway. %F 2000 ; I assume this has no effect on 1200 mode, but setting anyway. %XA 880 ; Set output amplitude to 3 kHz Peak deviation per measurement. %XF 1600 ; Set output amplitude to 400 mV PP per ID-880H manual. %E 2 ; Set lower tone in 1200 mode (fw 1.5s) to 1/2 voltage 6 dB down from high. ENDPORT
The above configuration is based on settings form the BPQ page and has not changed in a while. It may be getting time to begin removing some of the commented out lines.
The firmware revision in the SCS Tracker is 1.5v.
Strange state
The tester reports…
I think I may have hung the node up today. I was trying out another tnc and had to exit abruptly a couple of times…then the node wouldn’t answer and had a weird short carrier response. You may need to reset it.
Confirmed
About 20 minutes later I attempted access and observed the VAPN respond to my “c w4vpn” request, but with a very short and truncated short carrier and tones confirming the earlier report.
State
I looked over the Linux system and the TNC. Both appeared to be active. I accessed the web interface provided by the Linbpq software and it responded fine. There wasn’t much I could do to test the TNC further.
Cycle power on TNC or simply reboot
Moments like this present a dilemma… do I:
- Cycle power on the TNC and see what happens?
- Reboot the server to see if it can re-init the TNC?
I chose the later.
Reboot worked
This was a big test since rebooting can be performed remotely when the system eventually finds its way to the hill. Sure enough it all came back up and the TNC (that was never power cycled) received sufficient reset commands from Linbpq to reset itself to a proper operating state.
Note that the Icom ID-880H was not power cycled either.
I was then able to connect at 1200 no problem and leave a BBS message.
What went wrong?
We can’t be sure what might have gone wrong. It seems the particular way the tester “abruptly” exited may have tripped up the TNC’s AX.25 state machine and placed it into some sort of inescapable state where connect attempts start and respond, but are terminated very quickly.
There really isn’t enough information to discern more. The Linbpq/Tracker (with Tracker in user mode) has been flawless till now. We will attempt to repeat the conditions to see if we can correlate cause and effect.
Of particular interest is what happens if five incomplete connect attempts in a row occur since five is the current setting of the SCS Tracker’s “Y” parameter, aka “Number of Channels.”
We sent a note to the SCS firmware developers to get their take and let them now this event occurred.
