Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - vk3bia

Pages: [1]
Hello again,

I have identical two tm-v71 setups on line over 5 years, one is local on the lan here, never missed a beat, the other has the head here and the remote down in Australia and it has been never ending connection problem to the extent I brought another remote radio box which worked for a while then also became problematic with the same issues. Basically all looks good in the RRC status each end but the radio head never comes up.

Pressing the on button gives a connection, no errors in the status page at either end, powers up the remote radio body, makes a small beep but the head does not respond. Further, another press on the button is ignored the system hangs and does not disconnect and power down. It can only be disconnected from the remote status page.

Has any one had a similar issue?

Interchanging equipment from the lan system and remote system shows all equipment and configurations are fine, there is just an issue with the internet system. Both sites are over 10Mbit, good quality routers, we have used more than one model router at both ends with the same result.

I am appealing for anyone who has a working who has a Kenwood working setup who would change their ip and test my remote site and let me try to operate his remote site from my head?

Harry vk3bia

There is an issue with current firmware v2.96 existing from V2.78 at least with remoterig DDNS.

I spent a week mucking about to find out that with a fixed DNS and fixed lan ip and gateway setting the DDNS will not connect properly with remoterig DDNS server. It immediately worked when I changed from fixed ip settings to DHCP.

Please see for details.

Secondly would it be possible to change the DDNS option for DYNdns to another service, one that gives the option of free ddns or at least a trial without requiring a credit card. This would help in debugging.



I have had the remote rig pair running on a local lan for a few years but now I wish to connect the radio to the remoterig ddns server but it fails and shows error code 12 on the status page, I upgraded from v2.78 to the current firmware with no effect.

I think error code 12 means it has communicated with the ddns server but not received the correct response?

From the webbrowser: returns my Current IP Address: with my ip correct. returns: hostname not found.

The RRC has full access to port 80. Even with port 80 fully forwarded to enable access to the RRC from outside the ddns fails.
The RRC is configured with static ip, valid gateway and dns settings.

I saw on this forum somewhere that a software ddns updater that allows sever configuration will work with the remoterig ddns server using the login details created in the RRC for ddnd.remoterig.
The only updater I could find that was freely configurable was ddnsupdate from

This updater allows a log file to be kept. It also allows configuring of the external ip check url, this failed with remoterig ddns server but if you leave the input box empty it will use a default ip check url, I saw it used which returned the correct ip.

The updater is using for the IPv4 update url.

This log entry below  shows its checked the current ip and detected an ip change then "successfully" updated ddns.remoterig with the new IP. Next cycle in 10 minutes it checks the ip is the same and so does nothing more.

However the RRC hostname is still not found on ddns.remoterig  which seems to indicate neither the RRC or the updater program have successfully updated the server,not even once.

To me this above indicates that both the RRC ddns update and the ddnsupdater program on the pc are having an issue with the ddns.remote rig server, I thought maybe there was a problem with the server but 5 days have gone by with no change?

Can anyone confirm the server is normal and or please shed light on whats wrong here, I have tried to give as much info as possible.

[11/11/2018 8:25:08 AM] Checking external IPv4 address
[11/11/2018 8:25:08 AM]
[11/11/2018 8:25:09 AM]   Current IPv4 address detected as 36.75.120.xx
[11/11/2018 8:25:09 AM] IPv4 address check complete
[11/11/2018 8:25:09 AM] IPv4 changed: != 36.75.120.xx
[11/11/2018 8:25:09 AM] Updating dynamic DNS IPv4 to 36.75.120.xx
[11/11/2018 8:25:09 AM]   Using update URL
[11/11/2018 8:25:09 AM]   Update successful
[11/11/2018 8:25:09 AM] Update complete

[11/11/2018 8:35:08 AM] Checking external IPv4 address
[11/11/2018 8:35:08 AM]
[11/11/2018 8:35:09 AM]   Current IPv4 address detected as 36.75.120.xx
[11/11/2018 8:35:09 AM] IPv4 address check complete

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

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
Wi-Fi network   module not present
Unit ID (Banner)   Seaton radio
DHCP   0
Dns server
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   
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)   

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


Pages: [1]