Author Topic: vpn linked kenwood v71 systems dies  (Read 8356 times)

vk3bia

  • Newbie
  • *
  • Posts: 19
    • View Profile
    • Email
vpn linked kenwood v71 systems dies
« on: 2015-01-01, 14:27:37 »
We have 2 identical remote rig kenwood v71 systems, ones been running without fail for 12 months the other one was only commissioned a few weeks ago, the settings are identical. One remote is on the local lan (150 mtrs apart), the other is remote on a vpn still part of the local lan (5000KM apart).

The second system worked as configured from switch on although we had some problem with the vpn dropping off for the first week but the remote 5000km away was fine. After fixing the vpn keep alive the remote unit radio appeared to have died a day later. There is nothing to indicate a problem with configs or connection. Turning the head on starts the connection, no errors, a beep from the local unit the remote rigs connect but the head never comes on. We checked the radio on a another head and it was fine, we put another radio on the remote and it powered up normally. ONCE. why it worked once for the first switch on is a mystery.

Changing the ips and pointing the 2 head ends to opposite remotes makes no difference, neither head end can turn on the problem remote.

We have checked the ttl cables between the radio and the remote rig  and all check ok. We suspected a problem with the remote rig ttl comm0 interface buffer (assuming there is one without a circuit diagram available)or the rj45 socket, and the debug on the remote comm0 would show it.

This is the "turn on" debug by telnet for the remote that works.

duplex: New Audiocoding 102 (8 KHz)
duplex: New Audiocoding 102 (8 KHz)
New UDP CmdTxPort=13002
duplex: New Audiocoding 102 (8 KHz)
duplex: New Audiocoding 102 (8 KHz)
duplex: New Audiocoding 102 (8 KHz)
New UDP CmdTxPort=13002
R-> Radio ON requested
rtp enable [192.168.2.227/13001 192.168.2.227/13001]
R-> Connection established, radio ON, audioQuality=2
duplex: New Audiocoding 102 (8 KHz)
R-> Sending 'radion on' 0x30 0x31 0x0D
COM0-RX: 0d [1]
COM0-RX: 0d [1]
COM0-TX: 80 41 0d [3]
COM0-TX: bf ff ff ff 0d [5]
COM0-RX: 30 31 0d [3]
COM0-TX: c0 30 44 0d [4]
COM0-TX: c2 30 36 0d [4]
COM0-RX: 37 0d [2]
COM0-RX: 32 30 0d [3]
COM0-RX: 33 38 0d [3]
COM0-RX: 34 48 45 4c 4c 4f 20 0d [8]
COM0-RX: 37 0d [2]
COM0-TX: c0 30 44 0d [4]
COM0-TX: c1 30 30 0d [4]
COM0-TX: c2 30 36 0d [4]
COM0-TX: c3 30 30 0d [4]
COM0-RX: 40 8a 80 0d [4]
COM0-RX: 5a 20 20 33 34COM0-RX: 5a 20 20 33 34 33 32 31 35 4f 4f 84 89 81 80 80 80 80 80 80 80 80 80 80 80 80 80 0d 5b 20 20 30 52 41 4e 47 45 52 20 80 91 81 82 80 80 80 80 80 80 80 80 80 80 80 80 0d [56]
30 30 0d [61]..................................................

This is the one that does not work.

duplex: New Audiocoding 102 (8 KHz)
duplex: New Audiocoding 102 (8 KHz)
New UDP CmdTxPort=13002
duplex: New Audiocoding 102 (8 KHz)
duplex: New Audiocoding 102 (8 KHz)
duplex: New Audiocoding 102 (8 KHz)
New UDP CmdTxPort=13002
R-> Radio ON requested
rtp enable [192.168.2.226/13001 192.168.2.226/13001]
R-> Connection established, radio ON, audioQuality=2
duplex: New Audiocoding 102 (8 KHz)
R-> Sending 'radion on' 0x30 0x31 0x0D
COM0-RX: 0d [1]
COM0-RX: 0d [1]
COM0-TX: 0d [1]
COM0-TX: 80 43 0d [3]
COM0-TX: 80 43 0d [3]
COM0-RX: 0d [1]
COM0-RX: 0d [1]
COM0-TX: 80 43 0d [3]
COM0-TX: ff 0d [2]
COM0-RX: 0d [1]
COM0-RX: 0d [1]
COM0-TX: 80 43 0d [3]
COM0-TX: 80 43 0d [3]
COM0-RX: 0d [1]
COM0-RX: 0d [1]

SO from this the good radio is sent COM0-TX: 80 41 0d [3] and COM0-TX: bf ff ff ff 0d [5] and responds with COM0-RX: 30 31 0d [3]. the bad one is sent COM0-TX: 80 43 0d [3] and COM0-TX: ff 0d [2]then responds with COM0-RX: 0d [1]. In fact it seems to be just sending 0d's.

The line COM0-RX: 34 48 45 4c 4c 4f 20 0d [8] is the HELLO which appears at  switch on.

Assuming the 0d is an EOL as normal, it seems the radio is actually sending them. Or is the remote rig expecting a time constrained  response and creating the empty string in debug. Considering the radio works on a head directly, both ttl cables we made measure out ok, is it fair to say the ttl out to the radio is not working ether component, socket or dry joint?




This is the remote status and config dump after restarting both units, and pressing the head on button.

Info
Name   Value
Company   Microbit
Product   1258
PID   4
Version   7
HW   8
Software   2.80
Bootloader   1.10
Compiler   4.6.2
Build   Aug 14 2014 10:31:10
ROM/RAM   460316/41904
ETH-RAM   2944 (max 3kB)
USB-RAM   15348 (max 16kB)
Battery-RAM   4
ResetSrc   0 [3]
Last WD Reset   10
Uptime   0 Days, 1 Hours, 17 Mins, 4 Secs
    
Serial number   6684
MAC address   00:1e:fd:01:90:bc
IP address   192.168.140.160
Netmask   255.255.255.0
Gateway   192.168.140.1
DNS   192.168.140.1
Wi-Fi network   module not present
Settings
Unit ID (Banner)   Seaton radio
DHCP   0
IP   192.168.140.160
Netmask   255.255.255.0
Gateway   192.168.140.1
Dns server   192.168.140.1
Eth-type   5
IP-interface   0
Web page user   
Web page pwd   
Web page user(saving)   
Web page pwd(saving)   
Program mode   5
Control panel   0
Sip password   xxxxx
Sip contact   
Auto connect   0
Audio quality   2
Audio dual-rx   0
Codec out gain   255
Codec inp gain   0
Codec inp HPF Hz   3
Codec inp preamp   1
Codec inp attenuation   0
COM0 baudrate   57600
COM0 data bits   8
COM0 stop bits   1
COM0 parity   0
COM0 Program mode 3 char timeout   2
Use USB Com Port as COM0   0
COM1 mode   0
COM1 baudrate   9600
COM1 data bits   8
COM1 stop bits   1
COM1 parity   0
COM1 rts/cts   0
COM1 terminator (hex)   00
Use USB Com Port as COM1   0
COM2 mode   0
COM2 baudrate   9600
COM2 data bits   8
COM2 stop bits   1
COM2 parity   0
COM2 terminator (hex)   00
Use USB Com Port as COM2   0
COM3 mode (USB-COMFSK)   10
UDP cmd port   13002
UDP audio port   13001
SIP port   13000
Web server port   80
Telnet server port   23
Rx jitter buffer size   4
Rx jitter delay   3
Audio packet size (ms)   20
RTP tx mode   0
Disable audio tones   0
Audio tones -db [70-0]   30
IP identification (morse)   0
Full duplex   0
PTT-off mute delay   0
IP Type-of-Service (dec)   0
Yaesu power-on/off   0
UDP antenna-switch port   13010
UDP cmd min-data-size   0
Check interval   0
DDNS Host name   0
Own host name   
Username   
Password   
Enable   0
Speed wpm [0/10-40]   0
Iambic   1
Paddle reverse   0
Weight [25-40]   30
Side tone hz [0,300-1500]   800
Side tone -db [50-0]   20
Lf delay ms [0-500]   0
Key delay ms [0-250]   50
PTT activated by Keyer   0
PTT tail delay ms [0-999]   0
Speed pot min wpm [5-99]   10
Speed pot max wpm [5-99]   40
IN0 mode   0
OUT0 mode   0
OUT0 mode   0
OUT1 mode   0
OUT1 mode   0
OUT2 mode   1
OUT2 mode   1
USB RTS as PTT   0
USB DTR as CW   0
Enable ping watchdog   0
IP address to ping   
Ping interval (seconds)   300
Startup delay (seconds)   300
Failure count to reboot   3
1: Name (SSID)   
1: Password (PSK)   
2: Name (SSID)   
2: Password (PSK)   
3: Name (SSID)   
3: Password (PSK)   
4: Name (SSID)   
4: Password (PSK)   
5: Name (SSID)   
5: Password (PSK)   
6: Name (SSID)   
6: Password (PSK)   
7: Name (SSID)   
7: Password (PSK)   
8: Name (SSID)   
8: Password (PSK)   
Status

Name   Value
Radio   ON
Connection status   OK
SIP status   Connected/transfering
Last SIP error   None
RTP status   Excellent(59)
UDP cmd status   OK(44)
SIP command timeout   0
Rx Jitter buffer size   4
Rx Jitter delay   3
Dual Rx   0
Current audio packet size   20
Current audio quality   2 - Linear 16 bits 8 kHz
SIP Out port   13000
SIP In port   13000
Audio Out port   13001
Audio In port   13001
Command Out port   13002
Command In port   13002
External SIP In port   13000
External Audio In port   13001
External Cmd In port   13002
Other party   192.168.2.226
Input 1   High
Input 2   High
Output 0   Low
Output 1   Low
Output 2   Low
Dynamic DNS status   Unknown
Ping status (watchdog)   Off
DNS status   OK, remoterig.com = 193.202.110.185
Active profile:   Default
PTT status:   OFF
Antenna-Switch (IP)   not connected

If any one can help shed some light on the debug result it would be great as I have to figure the next step. Probably sent it to their dealer in Australia who sourced the remote rig. He might be sympathetic, i plan on getting a couple more.

harry
 
« Last Edit: 2015-01-01, 17:02:56 by vk3bia »

Jan (Microbit)

  • Software Developer
  • Administrator
  • Hero Member
  • *****
  • Posts: 1832
    • View Profile
    • Email
Re: vpn linked kenwood v71 systems dies
« Reply #1 on: 2015-01-07, 16:12:17 »
Assuming the 0d is an EOL as normal, it seems the radio is actually sending them. Or is the remote rig expecting a time constrained  response and creating the empty string in debug. Considering the radio works on a head directly, both ttl cables we made measure out ok, is it fair to say the ttl out to the radio is not working ether component, socket or dry joint?
There is no time constrains involved in program mode 5 since there is an explicit "End of Message"(0d) so it seems that the RRC only gets 0d, or at least that is what it thinks. One would need to "spy" on the data coming from the radio outside the RRC to find out if the data is there or not.
Always include type of hard/software and version when asking for support.

vk3bia

  • Newbie
  • *
  • Posts: 19
    • View Profile
    • Email
Re: vpn linked kenwood v71 systems dies
« Reply #2 on: 2015-01-07, 17:31:07 »
Thanks for the reply Jan,

Ok that,s good enough for me, the EOL is coming from the radio, I just was not sure how the data buffer and debug worked. I fully agree an ttl/rs232 and Realterm to look at the data would be my line of attack but it's not possible with the gear deployed 5000km away.

But since posting we have managed to get a cro on the 2 ttl lines midway along the cable at the site, it shows whats probably that EOL as healthy looking positive going data from the radio. But from the remote rig to the radio its a high level with negative  going spikes.  please see the 2 pix attached from the cro. DSCF2728.JPG is what looks like  bad data from the remote rig,DSCF2729.JPG is into the remoterig from the radio.

Of note there is no activity on the lines till the remote rigs connect, then its whats observed in the pix and the debug


Looks to me we need to verify the buffer between the processor and the socket in the remote rig. This information is not in the manual, as far as I can tell its all of the other interfaces but not comm0 but Mike has responded with the circuit and layout from the remoterig site contact page.
Hopefully we can sort it out now.

many thanks Harry
« Last Edit: 2015-01-08, 03:16:37 by vk3bia »