[Nut-upsdev] bestfortress driver establishes/loses/establishes communication and so on...
aquette.dev at gmail.com
Tue Jan 31 20:16:55 UTC 2012
2012/1/30 Oliver Kluge <ok23 at kluge-digital.de>:
> [Hopefully this comes through. All of today lists.alioth.debian.org was
> down. It could be pinged, but would not answer HTTP requests]
sorry, I forgot to mention the services disruption, including svn repository.
> 66.077820 upsdrv_updateinfo
> 66.288989 upsdrv_updateinfo: received 78 bytes
> 66.289036 send_to_all: SETINFO input.voltage "224"
> 66.289057 send_to_all: SETINFO output.voltage "223"
> 66.289074 send_to_all: SETINFO battery.voltage "26.7"
> 66.289089 send_to_all: SETINFO output.current "0.2"
> 66.289104 send_to_all: SETINFO output.voltamps "45"
> 66.289120 send_to_all: SETINFO ups.load "6"
> 66.289136 send_to_all: SETINFO input.frequency "50.0"
> 66.289152 send_to_all: SETINFO battery.runtime "5940"
> 66.289166 send_to_all: SETINFO ups.temperature "27"
> 66.289185 send_to_all: SETINFO ups.status "OL "
> 66.289200 send_to_all: DATAOK
> I ran this for a quarter of an hour. I have 46 KByte of this if you want...
> Almost always: Every 11 seconds "checksum corruption". And it is always the
> sixth out of six packets (? or communication events, whatever?).
I'm interested in.
could you please post it gzipped privately, or post a link?
> To me this does not look like "spontaneous" checksum errors. These are
> highly regular, and that leads to some _speculation_: Maybe the Fortress
> data handshake protocol is not understood to the last detail? Maybe the
> protocol of the sixth "packet" is just different, maybe it contains a
> "global" checksum that is not calculated out of the packet itself, but the
> entirety of the latest communication? I'm merely speculating, but this comes
> to my mind...
> Obviously the length of communication varies between 42 and 59 bytes, but it
> is always the sixth that goes wrong...
sadly, I only see 1 valid answer (highlighted above)
all other requests get corrupted answers.
AFAICT (I'm not the driver author, nor have any specific knowledge in
"upsdrv_updateinfo: received XX bytes" messages are within the same update loop.
we are asking the device to send (again) the same frame, probably
because of checksum errors.
after 5 unsuccessful attempts, we log the "checksum corruption" message.
I've added some more traces (subversion trunk, r3424), to see both the
number of tries, the current content of the reception buffer.
could you please try it and also send me an archived output?
> Btw, what about RS232 handshake? On Windows, COM1: to which the Fortress is
> attached, is set to 9600 8N1, I see no way to tell the bestfortress driver
> how to set handshake.
8N1 is assumed by default by ser_set_speed(), which is in your case
called with a 9600 baudrate through your ups.conf setting.
the only thing I see ATM is a polling frequency that too aggressive (2
seconds by default).
you can try to change it using 'pollinterval' in ups.conf
on my side, I will dig a bit the Best Fortress protocol.
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
More information about the Nut-upsdev