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.

Messages - vk3bia

Pages: [1] 2
Pix of under the board.

should have been attached on the last post?

Ok James,

No that is where I cut the track going to the head socket where it comes away from a couple of smt transistors,  turns and runs past the speaker socket then under the head socket.

You could solder the new head supply between the cut and the socket but there not much room there and I suspect just under the speaker socket will the smt solder pads for it, I figured the lesser of the evils was to just cut the track there, avoid the risk of shorting to the speaker socket and connect to the head socket pin under the board.


Hi James,

I have a tested spare set of cables ready for you for the D710. In the past I have found US post to Bali is about 10 days hopefully its similar going the other way.

Also you may need to modify the head 9v supply in the RRC if the head starts up and resets continually. Check this with the volume up and the mute open when pressing the on button.

Both my TM-D710 heads have this symptom.

Also I have 2 RRC TM-V71 systems and the same issue causes both of them to exhibit back lighting flicker with loud audio.


The internal RRC head 9/8v power regulator in both my RRCs purchased in 2013 is under powered for the TM-D710 head startup current surge which has all the TNC electronics in it. Newer RRC PCB versions may have been upgraded?

This supply feeds the head and the audio amp and I don't know what else inside the RRC. My solution is to cut the track near the head socket and wire in a XL 6009 or similar voltage regulator module to the socket set to 9v for the Kenwood head. You will need very fine soldering iron and take the upmost care cutting the track, soldering and mounting the module.

Note this voltage is set to 8v or 9v by one of the configuration jumpers to suit the radio in use.

Harry Vk3bia

Ok James,
You have the tm-D710 2m/70cm aprs radio, correct?  If so it uses the same radio body as tm-V71 dual band, I have some of both here.

Give me a day or so to revise the D710 setup and find the cable I used on my tm-D710 head, so I can swap it with the V71 head on the setup now. I remember making a few cables at the time, I think there are spares, I need to check which head.

If you made 10 cables they cant all be duds! The best way I know to check the two cables is,

If you can see the wires are connected to the right pins in those horrid RJ45 plugs, plug the end in the radio, and with a normal meter set in the high ohm range, you should see some continuity to the DC 0v wire of the radio on every pin that is used, also the DC 0v wire in your cable should be zero ohms, the others will be something higher.

Completely open in the megs range indicates the crimp is bad at one or both ends OR the connector is not contacting the pin in the radio when inserted.

Also check for shorts on the adjacent pins. ie 1 to 2, 2 to 3, 3 to 4, etc across the plug.
If all is good repeat the above process from the other end of the cable with it plugged in the RRC.

If you have made a few cables and one passed that test you could be confident you have radio socket pin to RRC socket pin contact.

It can happen that the RJ45 plastic divider guides is burred or some other debris holds of a contact when the plug is pushed in the socket.   The cable looks great, checks out end to end but no contact on one pin when its plugged in will have you tearing your hair out.

We can also check from your head to my remote and visa versa which helps figure out which ends got the issue.

If you can PM me an email addy we can exchange configs etc.

Vk3bia, Bali.     

Hi Mitch,

Yes there have been a few psu swaps along the way to no avail, also we tried separate supplies for radio and RRC, no floating DC common rails, SMPS bites or earth loops, also both sites have good clean reconstituted power.

Network issues or timing are the main suspects, problem is to isolate which country is the issue.

regards Harry.

did you sort this in the end?

I have 2 vm-71 setups, one on lan, one remote overseas by internet, The remote has been up and down for years, more often down and we have never been able to finger it.

The lan systems great, never missed a beat in 5 years.

Everything connects, radio powers up, status perfect both ends, the small connect beep, command port data looks ok in debug, just the head fails to come up. Power down only possible by the remote status page.

Be good to work together on this one, not to many users with these radios.


Did you get this working? I have tm-v71 on a local lan that has worked fine, Sadly I cant say the same for my other one that is remote via internet.

As I recall the same config worked with my tm-d710, just a different cable end on the data cable to the head. I would need to find that cable to verify it again for you.

I think my configs would be fine, you just need change the ips to suit your lan. I have 3 v71s and 2 d710s and I dont know what head came with what radio any more.


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

Sorry for delay in reply Mitch and Mike, I have not had time to revisit this since your posts.

Interesting both your comments, I will have to investigate further as soon as I get time to revisit the issue, because when using dhcp the DDNS updater worked with it but seemed a bit hit and miss.
 I have grave doubts this is router related in this case, my routers service a lot of devices all with fixed IP with port forwarded and translated external ports. but please let me test further with the RRC before saying more, I reply now to acknowledge your comments from last week.
However port forwarding to the RRC 13000-> 13002, 23, 80 ports all work fine on fixed ip here, just the DDNS updater fails.

To complicate things the government here (Indonesia) block and redirect all offshore DNS lookup ports though local servers to block radical islamic and porn sites etc, any site on the block list gets a dummy IP returned. This might slow down an ip update being retrieved by nslookup but not on the page, however having said that, the No-IP service updated by the 2 fixed IP voip PBX,s here seems almost instant.

Please correct me if I am wrong, I was of the understanding DDNS interaction is all done on HTML port 80, the client finds and gets its current IP from the server, if its different to the clients last recorded IP  it then recontacts the server with an update to the new IP, all on port 80. If so I don't see how the DDNS updater would need port forwarding?

Regards Harry.

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.


This has to be a bug which was known in 2014.
The issue was in v2.78 and the current firmware v2.91

The remote rig DDNS works if you use DHCP instead of static IP.

I can not imagine anyone would want to use DHCP with a server device like this, especially when most users have to port forward to the device on a known ip.

To make this work the router must be capable of assigning a MAC address with a fixed IP, not all have this facility.

I have 2 internet connections to the site, fortunately both routers are capable of assigning a MAC address with a fixed IP.

Thanks for your help Mitch, I picked it from your post of 2014.


This excerpt below is from telnet to the radio RRC.

Even thought its set to it seems to be looking to dyndns? does return the correct ip but the RRC DDNS  status gives a different IP.

From the device status webpage DDNS info we have:
Own IP:<<<<< different and wrong IP!

from telnet : System, dns

----- DYNAMIC DNS -------
Dynamic DNS check inter : 10
Dynamic DNS host [0/1/2]  : 1
Dynamic DNS host name   :
IP check host name      :
Own host name           :
Username                : rrc1258-6693
Password                : b7irgpia

Hostname : DynDNS: timeout

DynDNS: Checking if external IP has changed.

DynDNS: Checking if external IP has changed.
DynDNS: timeout

How can it be only I have these issues, is my RRC possessed or something?


Ok Mitch,

no I was not aware of the up to 15 min delay till it all settles down but I guess its had plenty of time over the last week, but i will wait longer after changing settings.

Yes the 1 week dyndns test offer would have been handy for debugging but I just closed the tab when the credit card request came up. I thought I saw more DDNS options in the web switch somewhere in my searches.

In Telnet it is sending out ### dns response [1] timeout about once a minute but it seems to have a working dns?

### dns response [1] timeout


Thanks for the response Mitch.

Yes I had the error code page from searching before. To access the RRC webpage from outside I can use ip or FQDN, the fibre router has the option to use the no-ip ddns service, just using forwarding port 80 to verify the RRC has full access on port 80 while trying to find the problem.

Likewise using the configurable external update program, because apparently they are supposed to work with (same protocols for DDNS) and its got logging it makes a handy tool for fault finding, it it works I can compare its network interactions with ddns.remoterig compared to the RRC.

However as there a 2 inet services available here, ddns from the routers is not viable and normally there is no pc to run clients. The RRC is the obvious but also only option.
Restarting the RRC does not help, even going to site and doing a power up restart does not help.

Also now a small change.
now we have "unknown" for the RRC's ddns status rather than code 12, it also links to further info page as below

Own IP:

Last reply:

rue;bsa.src = url;(document.getElementsByTagName('head')[0]||document.getElementsByTagName('body')[0]).appendChild(bsa);}netbro_cache_analytics(requestCfs, function(){});};</script></body></html>

The Own IP: is in the correct country but not the correct IP, calling the page does have the correct ip however.

Concurrent with DDNS IP:, shows no result.

CHK IP: as below indicates the RRC has working DNS server access. currently using googles

IP Lookup Details:

IP Information -

Host name:



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

Pages: [1] 2