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

[Oliver Kluge]

Hi,

Arnaud Quette wrote:
 > 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.

Since the polling intervall is currently set to 2 seconds, and there is 
a 2 seconds gap between all of the six communication events, I would 
think they are all complete polls for themselves, somehow being 
interrupted before the 80 bytes have been sent that Stuart writes about. 
Then why checksum corruption at number six and never before that? Since 
all the other communication attemps are also terminated early, they 
should have checksum corruption, too...

 > 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?

I'm no expert in Subversion. How do I tell it to refresh its local code 
base before I rebuild?

Btw, since we are talking about 80 bytes per communication, why don't we 
just dump the entire serial communication to a file, both upstream and 
downstream? Maybe together with time/date stamps as a hex/ASCII file?

 > 8N1 is assumed by default by ser_set_speed(), which is in your case
 > called with a 9600 baudrate through your ups.conf setting.

Okay. What would happen if I had not set baudrate?

 > 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

At the moment it is even set to 2. I'll try a different one. But it 
seems to me that the Windows driver from Best Power polls just as 
aggressively, or even faster.

Thanks
Oliver