[Nut-upsuser] APC BACK UPS 2200 model BZ2200BI-BR (update)

[Charles Lepple]

On Aug 23, 2015, at 6:26 PM, Mario Lobo <mlobo at digiart.art.br> wrote:
> 
> I hope it helps!

It is a bit easier to read than the ktrace output. Here are the bytes received, without the other messages:

Network UPS Tools - Microsol Solis UPS driver 0.63 (2.7.3.1)
CommReceive: RecPack: (25 bytes) => 00 17 91 49 5e 5e bc fe bb 46 88 ac 1b 0a a0 ed 01 07 07 bb 46 82 ae 1b 09
CommReceive: RecPack: (25 bytes) => a0 04 02 06 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e dc fe bb 47 83 ad 1a 09
CommReceive: RecPack: (25 bytes) => a0 0a 02 07 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e e3 fe bb 46 88 ac 1a 0a
CommReceive: RecPack: (25 bytes) => a0 f4 01 08 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e d1 fe bb 46 88 ad 02 0b
CommReceive: RecPack: (25 bytes) => a0 0b 02 09 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e d4 fe bb 46 88 ad 1e 0a
CommReceive: RecPack: (25 bytes) => a0 1b 02 0a 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e 00 fe bb 46 88 ad 1d 0a
CommReceive: RecPack: (25 bytes) => a0 f6 01 0b 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e da fe bb 47 83 ac 1a 09
CommReceive: RecPack: (25 bytes) => a0 f4 01 0c 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e d0 fe bb 46 88 ad 1e 0a
CommReceive: RecPack: (25 bytes) => 0d 02 0d 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e f5 fe bb 47 83 ad 02 09 a0
CommReceive: RecPack: (25 bytes) => 02 0e 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e d9 fe bb 46 88 ac 1e 0b a0 1d
CommReceive: RecPack: (25 bytes) => 02 0f 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e 07 fe bb 47 88 ac 1c 0a a0 04
CommReceive: RecPack: (25 bytes) => 02 10 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e ed fe bb 46 88 ac 19 0a a0 07
CommReceive: RecPack: (25 bytes) => 02 11 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e ed fe bb 47 88 ad 23 0c a0 4c
CommReceive: RecPack: (25 bytes) => 02 12 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e 41 fe bb 46 83 ae 02 0a a0 1b
CommReceive: RecPack: (25 bytes) => 02 13 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e e9 fe bb 46 88 ad 1d 0a a0 f8
CommReceive: RecPack: (25 bytes) => 01 14 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e e5 fe bb 46 88 ae 1a 0a a0 ef
CommReceive: RecPack: (25 bytes) => 15 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e db fe bb 46 88 ad 1b 0a a0 f2 01
CommReceive: RecPack: (25 bytes) => 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e df fe bb 47 88 ad 1a 0a a0 f8 01 17
CommReceive: RecPack: (25 bytes) => 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e e6 fe bb 46 83 ad 02 0a a0 e3 01 18
CommReceive: RecPack: (25 bytes) => 1d 0d 03 00 00 00 01 00 17 91 49 5e 5e b4 fe bb 47 88 ad 1d 0a a0 0f 02 19
Solis not detected! aborting ...

I highlighted the final character (0xfe/254). It seems as though the code expects the serial stream to always put the 0xfe character at the end of the buffer, but as you can see, that is not the case in the debug output. (The code loops twenty times, so it is not impossible for it to sync: this may be what happened when you ran the driver in gdb.)

We could modify the code to re-sync with the start character, but what concerns me is that a byte gets dropped occasionally. If you run "stty -f /dev/cuaU0 raw", then run the driver with the same debug flags, do you get the same sort of output, where the "fe" character moves left? You might also try unplugging the USB cable, then running the driver immediately after plugging it in again (maybe there is a buffer filling up - that happened a number of years ago on another USB interface on FreeBSD).

-- 
Charles Lepple
clepple at gmail



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150824/9b1191f3/attachment.html>