Dear Daniele,

I have some news regarding the Driver: I applied the patch you sent me 
(https://github.com/zykh/nut/tree/issue-441) and it works correctly (obviously 
in Level 5 of Debug I see "missing CR...etc..").

As for now there are 2 modification I'd like to suggest you:


- For Online Type UPSs the Megatec protocol describes that the battery voltage 
is provided in the form of V per Cell, not V per block, but the driver doesn't 
care because I see 2.21V instead of 36V in UPSC (Battery.voltage). I think that 
this should be corrected so the customer can see the string voltage and not the 
single Cell voltage (Megatec 0.06).


- About battery low and high guesstimation the formula uses these values:

batt.volt.low = 104 * batt.volt.nom / 120   (for a 12V VRLA --> 10.4V 
batt.volt.low)
batt.volt.high = 130 * batt.volt.nom / 120   (for a 12V VRLA --> 13V 
batt.volt.high).
In my opinion these values are not correct (a 12V lead acid battery can be 
charged up to 13.8V while discharged to 9.6V)

Instead I would suggest:
batt.volt.low = 100 * batt.volt.nom / 120   (for a 12V VRLA --> 10V 
batt.volt.low)
batt.volt.high = 135 * batt.volt.nom / 120   (for a 12V VRLA --> 13.5V 
batt.volt.high)
with this correction we have also some "Safe Margin", I mean that more or less 
all the UPS I tested will charge and discharge the batteries at those values.
I would like also to ask you if for this first time we can send you the sources 
instead of the Diff patch and for the future we will study how to send it in 
the format required (if you have any link explaining the diff, etc. please send 
it, it will be useful for me).

The question from Stefano Pongiluppi (my colleague) has been solved because 
we'll not use Blazer anymore.
Thanks again for the support!



Best Regards,

Gabriele Taormina

UPS Strategic Business Unit

Field Application Engineer

Phone:     +39 0522/207046

Fax:           +39 0522/207005

Address:  Via Rodano 1 - Reggio Emilia - 42124 - Italy

Email:       [email protected]<mailto:[email protected]>

<mailto:[email protected]>Website:  
www.ups.legrand.com<http://www.ups.legrand.com/>

Website:  www.legrand.com<http://www.legrand.com/>

[1506322600142_legrand-vector-logo.png]



________________________________
Da: Daniele Pezzini <[email protected]>
Inviato: domenica 29 luglio 2018 00:50
A: Stefano PONGILUPPI
Cc: Gabriele TAORMINA; [email protected]; Thierry DESTRUEL
Oggetto: Re: [Nut-upsdev] Adding drivers to NUT?

> The problem with "blazer_usb" driver ("blazer_ser" works correctly) is
> related to the following commands:
>
> - "F" and "I": when the KRAULER subdriver check these UPS answers it uses
> wrong constants to check the lenght of the received packets, so these
> commands are considered as "not available" by NUT. In particular, without
> the availability of the "F" command, is not possible for NUT to calculate
> the battery capacity level. In my opinion this is a problem of the driver,
> because our UPSs respect the communication protocol document from Megatec
> and also because the blazer_ser works fine. We have tested different UPSs
> models but the problem is the same.

OK, if, as I am inclined to think, the cause is simply the lack of the
closing CR, once the GitHub issue I mentioned before is fixed, these
problems should disappear in nutdrv_qx (while we could easily apply
the same set of changes to blazer_usb, or change the expected length
to not consider the closing CR, I don't want to touch it right now, as
it already works with USB devices that don't terminate the Q1 reply
with a CR and these other things are not critical, and I want to keep
an easy way for users to get back to the current working behaviour,
just in case...).

Please, try nutdrv_qx from this branch:
https://github.com/zykh/nut/tree/issue-441
A log of the driver started with a debug level of 5 would be useful.

> - "Q1": in this case the problem is only relative to the debug mode ("short
> answer"); in normal mode it works correctly.

Are you sure blazer_usb complains in debug mode even with the Q1
reply? What version are you using? Because, unless the USB read fails,
it shouldn't, if the reply only lacks the closing CR...
This should only be a problem with nutdrv_qx (and it should now be
fixed in the branch I just linked).

> - "battery.voltage high/low: the values used in the formula are not correct,
> indipendently by the UPS used.

Can you elaborate a bit more on this one?
Do you have any suggestion on how to improve our calculations?

________________________________

Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir 
des informations sensibles et/ ou confidentielles ne devant pas être 
divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous 
recevez ce message par erreur), nous vous remercions de le notifier 
immédiatement à son expéditeur, et de détruire ce message. Toute copie, 
divulgation, modification, utilisation ou diffusion, non autorisée, directe ou 
indirecte, de tout ou partie de ce message, est strictement interdite.


This e-mail, and any document attached hereby, may contain confidential and/or 
privileged information. If you are not the intended recipient (or have received 
this e-mail in error) please notify the sender immediately and destroy this 
e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution 
or other use of the material or parts thereof is strictly forbidden.
_______________________________________________
Nut-upsdev mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Reply via email to