[Nut-upsdev] bestfortress driver establishes/loses/establishes communication and so on...

[Arnaud Quette]

Hi Oliver,

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
this protocol):
"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.

cheers,
Arnaud
-- 
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/