[Nut-upsuser] mge-utalk ESV8+ comm problem

[Ivo Karabojkov]

Hi!

Here is my Debug (-DDDD) output of mge-utalk during the malfunction. Do 
you want to capture new one (when it works)?

Greetings,
Ivo


On 19.10.2012 10:21 ч., Martin Loyer wrote:
>
> Dear all,
>
>> Ivo, we really need your implication to solve *your* issue!
>>
>>             I have an old ESV8 UPS down here, and I did code patching
>>             years ago to
>>             support old model on nut.
>>
>>         is your ESV8 still working?
>>
>>     For sure :)
>>     This UPS is strong! By now, it is 18 years old :O
>>
>>
>> made to last until the end of time ;)
>> ah, good ol' MGE time.
>>
>>             But, I got some bad effect, like Debian bug you
>>             mentionned on your email.
>>
>>             Would be difficult for me to gain access to an ESV8+, but
>>             we can work
>>             together to test.
>>
>>         even to me. all this goes back to MGE time, now defunct for 5
>>         years.
>>         the only things that survived is the Comet and E Series DX
>>         (see below)
>>
>>     I may have access to an old ESV8+. I gave one to a friend of
>>     mine, years ago.
>>
>>
>> that would be nice
>>
>>
>>             I can make some test, but I need more information. Could
>>             you send me your
>>             debug log?
>>
>>         I think I've found a Comet and a E Series DX (so speaking
>>         UTalk) at Eaton today.
>>         this is the kind of things that becomes rare nowadays!
>>
>>         on the patch side, I'd also like to:
>>         - add some more inter-char delay, since mge_command() only
>>         has 100 ms.
>>         I've just checked again Utalk spec [1], and we should be at
>>         least 500
>>         ms between commands.
>>         the point here is that this inter-char delay is not satisfied
>>         with
>>         commands that do not receive an answer (such as Z)
>>
>>     Interesting. If we are hearing too fast, it's not that good.
>>
>>
>> we're *talking* too fast actually ;)
> You're right ! ... I talked to fast ;)
>>
>>     For specific commands (such as Z), we may just wait and ignore
>>     any answers (as we did by the past).
>>
>>
>> not sure to get your point!? we still ignore the result of 
>> mge_command(... Z)
> Fore sure :D
>>
>>
>>         - see the result of Marek's mention, i.e moving the double Z
>>         before the Si test.
>>
>>     For sure. I dig on my archives, and found a serial spy log taken
>>     on Windows between PSP and ESV8.
>>     Z is send twice, then AX 1, then SI 1.
>>
>>
>> yep, with 500 ms inter-commands... I still have access to that code ;)
>>
>>     By the way, I worked a lot to make support of programmable
>>     outlets. By now, it is not supported (even for recent UPS,
>>     working on usb-hid). I may test and patch.
>>
>>     @Ivo: could you send me your log file?
>>
>>
>> @Martin: how do you want to proceed on the UTalk issue?
>> I can either provide a (set of) patch(es), or few directions...
>>
> Let's wait Ivo's answer and log files. Then, I'll try to fix it. Then 
> we test it, and validate on severals UPS. If OK, I'let you publish 
> patch Arnaud.
>
> If I have some time, I can work on programmable outlet, with limited 
> support to onboard one (no external outlet plugged in daisy chain).
>
> Martin
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20121019/1d06ad22/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Output.tar.gz
Type: application/x-gzip
Size: 19329 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20121019/1d06ad22/attachment-0001.bin>