[Nut-upsdev] Driver for Cyberpower PR2200
Arjen de Korte
nut+devel at de-korte.org
Tue May 1 07:53:15 UTC 2007
> Arjen,
>
> Ran another set of tests tonight... And added results to the
> spreadsheet:
> http://www.lvahs.com/pr2200.xls
This is a surprisingly useful addition! It turns out that the micro
controller in the UPS is somehow directly powered by the batteries inside.
Which means if you disconnect them, there is no communication. This gives
a nice idea how the PowerPanel software deals with the autodetection.
>From the results it is clear that indeed the detection of the existing NUT
'cyberpower' driver (sending 'F\r' @ 1200 baud) is alternated with the NUT
'powerpanel' driver (sending 'P4\r' @ 2400 baud). This indicates that
we're probably on the right track by including these in one driver.
> Schedule off does not appear to send any commands to the UPS whatsoever,
> so I think it's completely handled in the software.
>
> The schedule "on" is mated with a scheduled "off", and creating the
> scheduled event doesn't send any commands to the UPS. So the "ON"
> details must be sent to the UPS as a "wait this long and then turn back
> on" command after the powerpanel software is already shutting down the
> computer.
We already know how this looks, from the commands in other 'cyberpower'
like drivers. No need to check this out.
>> Furthermore, it looks like, the UPS also has a self-test mode
>> (in the SETUP window). Could you try that one?
> I exercised the self test mode. It seems to send a T<x>\r command.
Good!
> The spreadsheet shows a self test triggered for 10 seconds (T 4Ch \r), and
> another for 20 seconds (T 98h \r). I also canceled the test, and the
> cancellation sends a (C 54h \r). No matter how long the test was set
> for, the cancellation command was always the same.
That is what I would expect.
> I tried many settings from 1 second to 34+ seconds (although not
> exhaustive) here are the codes for each that I tried:
>
> 1 second -> 07
> 2 -> 0F
> 10 -> 4C
> 11 -> 53
> 20 -> 98
> 21 -> A0
> 22 -> A7
> 30 -> E5
> 31 -> EC
> 32 -> F4
> 33 -> FB
> 34 -> FF
>>34 -> FF
Excellent! Short of some rounding errors, the testing time is probably the
(decimal value / 7.6). Good enough probably.
> I also tried a few other tests... There are sheets in the spreadsheet
> file for each of these:
>
> 1) Pull the plug on the UPS, and start the power panel software while
> the UPS is on battery. I didn't see anything different in the startup
> sequence here (other than the fact that the final value of "input
> voltage" indicates that it is OL.
>
> 2) UPS being powered off from front panel switch while powerpanel is
> monitoring it.
>
> 3) UPS batteries disconnected (while powered off), UPS is powered on...
> It beeps like mad, powerpanel software started and data was collected.
> It didn't appear to communicate with the PC at all in this state (all
> the commands time out).
See above. This provided actually very useful output.
> 4) UPS is powered down, and a "wiring fault" is created by disconnecting
> the ground on the line feeding the UPS's outlet. UPS is powered on and
> it illuminates it's red "wiring fault" LED. Powerpanel was started and
> communication was captured. I didn't notice anything different in any
> of the registers read by powerpanel in this state.
Neither did I. I didn't expect this either, since there is nothing you can
do through software to correct this. It requires manual intervention.
[...]
> Let me know if there is anything else that you need and if you need my
> help in any way.
Well, some free time on my hands would be nice. :-)
Seriously, for now I have plenty to work with. I'll let you know when
there is something available for testing.
Best regards, Arjen
More information about the Nut-upsdev
mailing list