TS-480HX won't power up

[OZ1AXG]

Hi

I am having the same startup problem as described in the thread:
http://www.remoterig.com/forum/index.php?topic=1198.0;prev_next=prev#new

-- > except I have a maximum of 20mS latency time to radio site (normally 12 mS).

My setup have been working fine for a long time until a few days ago when one of the Power supplies failed. I replaced it with a similar sized PSU (slightly different design).

My Radio-RRC OUT1 MODE=Connect is wired to a 240V relay that switches on the PSU's when connected to the control site

When the power switch on the front panel is pressed there's a short beed (normal); PSU goes on on remote site - but front panel is still dead. both's RRC's shows connected.  I can even see "PTT status" is changed at radio site when i press mic PTT.

After a couple of restarts of both RRC and manually changing PSU OUT1 MODE=on/off ect the panels goes on (sometimes many tries ... seems random)

How is this startup sequence timed in the RRC communication ? is there a build in timeout. I'm thing that either sites is missing a "on" command on the serial radio/panel connection ?

Could it bee that the replacement PSU has a slightly longer startup time and that in turn causes a extra delay in this sequence ?

RRC Radio:
Software   2.55
Bootloader   1.10
Compiler   4.6.2
Build   Feb 22 2012 09:52:28

Regards
Flam

[sm2o]

Hi

You cannot do like that, the radio must be powered up before the connection is done, so it's ready to receive data from the front panel. If it worked before it was just luck. If you want to control the PS with the output set it to I/O and controll it manually via the browser instead.

73 de mike

[OZ1AXG]

Well ... i have been lucky then :=) been working that way for a while now.

Its a nice failsafe to have the PSU cutting power if you lose the connection in the middle of a transmission ...

What happens to PTT if connection fails in the middle of a transmission =?=

Flam

[sm2o]

No problem , the PTT status is sent in every RTP frame so if the connection is lost it will release the PTT very quickly

73 de mike

[OZ1AXG]

Hi

Ok, thanks for the quick reply ! i set it to on/off and manuelly controls the control signal.

Regards
Flam

[OZ1AXG]

With the PSU constant on ... im still having trouble with the dead front panel when pressing the power on button.

I end up with this status

Control status:
Name   Value
Control panel   ON
Radio   ON
SIP status   Connected/transfering
Last SIP error   None

Radio status:
Name   Value
Radio   OFF
Connection status   OK
SIP status   Connected/transfering
Last SIP error   None
RTP status   Excellent(59)
UDP cmd status   OK(44)

after this pressing power on seems to be ignored.

[Jan (Microbit)]

Are there statuses also:

RTP status   Excellent(59)
UDP cmd status   OK(44)

on the control side?

[OZ1AXG]

Cant see those on the control side..

Perhaps this is network related somehow ?

Control side (up and running now after 20 minutes restart &on/off):

Status
Name   Value
Control panel   ON
Radio   ON
SIP status   Connected/transfering
Last SIP error   None
RTP Timeout   60
SIP Timeout   0
Rx Jitter buffer size   4
Rx Jitter delay   3
Current audio packet size   20
Current audio quality   2 - Linear 16 bits 8 kHz
...
Input 0   High
Input 1   High
Input 2   High
Output 0   High
Output 1   Low
Output 2   Low
DNS status   OK, remoterig.com = 213.180.92.20


radio is now:
Status
Name   Value
Radio   ON
Connection status   OK
SIP status   Connected/transfering
Last SIP error   None
RTP status   Excellent(60)
UDP cmd status   OK(45)  <-------- was 44 before ... not sure if its important ?

[Jan (Microbit)]

Your radio RRC has a very old firmware, much has been changed/improved since 2.55.

The number within():

UDP cmd status   OK(45)

is a second resolution down counting timer. It should stay 40+ if the UDP command data is received continuously and will start counting down if the data stream is interrupted.

[OZ1AXG]

I made some more tests ... somehow it always ends up with both RRC connected - and every things looks ok - except that the radio RRC reports radio is OFF and the the control RRC reports radio is ON.

Front panel does not respond to further 'power off' commands and my guess is that the control RRC ignores this command since it thinks the radio is ON ?

How come that this difference in radio status occurs ...?

[Jan (Microbit)]

The "Radio ON/OFF" status in a radio RRC is a little bit out-dated since it's only valid in certain modes nowadays. We will change the meaning of it, as well as the "Control Panel ON/OFF" in the control RRC.

Which firmware version does the control RRC have?

[OZ1AXG]

Visited remote site location today. Replacement PSU was dead
so the radio was actually OFF :=)

I have to investigate further why this happens !  no fuses are burned (12v/25A) primary/secondary side on PSU - but very strange two PSU died in one week.


Product   1258
PID   4
Hardware   6
Software   2.30
Bootloader   1.8
Compiler   4.1.2 (WinARM 4/2007)
Build   Dec 16 2010 14:37:11
ROM/RAM   343436/52960
ETH-RAM   2944 (max 3kB!)
ResetSrc   0 [3]
Uptime   909

[Jan (Microbit)]

Visited remote site location today. Replacement PSU was dead
so the radio was actually OFF :=)

I have to investigate further why this happens !  no fuses are burned (12v/25A) primary/secondary side on PSU - but very strange two PSU died in one week.


Product   1258
PID   4
Hardware   6
Software   2.30
Bootloader   1.8
Compiler   4.1.2 (WinARM 4/2007)
Build   Dec 16 2010 14:37:11
ROM/RAM   343436/52960
ETH-RAM   2944 (max 3kB!)
ResetSrc   0 [3]
Uptime   909

Wow!  2.30 is even older than 2.55 

[OZ1AXG]

Well - it works and is very stable - even if it older versions ...

I deduct from the many smilies in your post that a upgrade would be advisable ;=)

I will consider it - when this power fail problem is solved (one problem at the time)

[Jan (Microbit)]

Well - it works and is very stable - even if it older versions ...

I deduct from the many smilies in your post that a upgrade would be advisable ;=)

I will consider it - when this power fail problem is solved (one problem at the time)

Well, if something works why risk break it? I understand that point of view. Though when something finally fails and support is needed then it causes problems, more the older the firmware is, for us trying to help.