[I am CC'ing Alexey from Powercom in case he has seen any of these issues with the Raspberry Pi hardware.]
On Jun 10, 2013, at 1:05 PM, Mārtiņš Puķītis wrote: > I took the log. Here's what happened. > Broadcast Message from nut@rasp > (somewhere) at 16:18 ... > UPS BNT500AP@localhost battery needs to be replaced > > occurred when for the first time value "1" was read as > "UPS.PowerSummary.PresentStatus.NeedReplacement", on this line: > 6409.240690 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: > Input, ReportID: 0x0a, Offset: 6, Size: 1, Value: 1 > It happened for 9 times, but the message appeared only on first. Correct, upsmon throttles the REPLBATT event: http://www.networkupstools.org/docs/man/upsmon.conf.html (search for RBWARNTIME) > Broadcast Message from nut@rasp > (somewhere) at 17:33 ... > > UPS BNT500AP@localhost on battery > occurred when UPS.PowerSummary.PresentStatus.ACPresent turned to 0 on this > line: > 10921.069403 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, > ReportID: 0x0a, Offset: 2, Size: 1, Value: 0 If you turn up the debugging level from 2 to 3, the driver will do a hex dump of the report buffer. Offset and size are bits, so if the ACPresent bit is 0, that's what the driver reports. > Here I also see a suspisious frequency value 70. How is this possible? > 43194.046966 Path: UPS.Input.Frequency, Type: Feature, ReportID: 0x1e, > Offset: 0, Size: 8, Value: 70 Similar situation to ACPresent - if those are the bits coming in, that's what the driver reports. Granted, there are cases where usbhid-ups might be misinterpreting those bits, but as you can imagine, it is hard to test all of the corner cases. We should be getting an error message from usbhid-ups if the USB reply is not long enough. > At 2:58: > 44790.984549 Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, > ReportID: 0x0a, Offset: 2, Size: 1, Value: 0 > Here all voltages and frequencies are OK, so I don't understand why ACPresent > is 0. usbhid-ups does not look at voltage and frequency to determine whether AC is present. Voltage and frequency values can be averages over time (with the averaging being performed in the UPS microprocessor), so the driver simply trusts the ACPresent bit returned by the UPS. I'm starting to wonder if the USB controller or driver in the Raspberry Pi is flaky. We have seen odd issues with other ARM/Linux boards, and none of the symptoms are the same as on x86 PCs. Do you have a desktop or laptop Linux system where you can test this? -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
