[Nut-upsuser] MGE Pulsar EX1500 RT comms problem

Daniel O'Connor doconnor at gsoft.com.au
Tue Jul 22 08:07:04 UTC 2008


Hi,
I have the above UPS connected to a FreeBSD 6.2 box and it shows 'data 
stale' very frequently (every few minutes).

I have tried the usual trick of setting maxage, poll interval, etc etc 
but to no avail.

When I wind up logging I see (on mge-shut)

entering shut_get_report(id: 0d, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 16, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 17, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 2f, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 20, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 07, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 0a, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 07, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 04, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 12, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 04, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 12, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 13, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 39, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 37, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 38, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 04, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 12, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 13, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 3e, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 3c, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 3d, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 06, len: 1800)
shut_wait_ack(): ACK received
entering shut_get_report(id: 06, len: 1800)
shut_wait_ack(): ACK received
entering upsdrv_updateinfo()
entering shut_get_report(id: 0f, len: 1800)

And upsd..
write: [destfd=7] [len=15] [ERR DATA-STALE]
sstate_dead: driver for UPS [ups1] says data is stale

Broadcast Message from radar at negrocreek.dnsalias.net
        (no tty) at 7:57 UTC...

Communications with UPS ups1 at localhost lost

sstate_dead: driver for UPS [ups1] says data is stale
UPS [ups1] data is no longer stale
acl_check: localhost: match 1
ACL [localhost] matches, action=1
write: [destfd=7] [len=30] [VAR ups1 ups.status "OL CHRG"]

Broadcast Message from radar at negrocreek.dnsalias.net
        (no tty) at 7:57 UTC...

Communications with UPS ups1 at localhost established

acl_check: localhost: match 1
ACL [localhost] matches, action=1

It seems to decide very quickly that things are stuffed :(

I just built a fresh NUT 2.2.2 (from 2.2.0) but got the same problem.

Anyone have any suggestions?

It does not seem related to the known issue in the mge-shut man page but 
rather that the UPS does not respond properly (or the OS is dropping 
data but I don't see any errors about it).

One other possibility is that noise is being seen on the serial line 
(this system drives a high power VHF radar) - I have asked someone 
onsite to check the cabling but it would be nice if NUT could be 
adjusted to be more tolerant.

Thanks.

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080722/7b6e2114/attachment.pgp 


More information about the Nut-upsuser mailing list