[Nut-upsdev] bestfortress driver establishes/loses/establishes communication and so on...

[Arnaud Quette]

Hi Oliver and Stuart,

2012/2/13 Arnaud Quette <aquette.dev at gmail.com>:
> 2012/2/7 Oliver Kluge <ok23 at kluge-digital.de>:
>> Hi Arnaud,
>
> Hi Oliver,
>
>> if you got tons of material including several protocol revisions, maybe a
>> broader approach might useful?
>
> this is to be expected from me.
>
>> I don't want to talk you into rewriting all this code, but I see space for
>> some improvement and let my imagination run wild :-) Nut drivers make a
>> difference between Fortresses and "newer Fortresses" without really drawing
>> a sharp line.
>
> that's the aim.
>
>> Are those different protocols fundamentally different? I mean, is a division
>> of different Fortress models into two separate nut drivers actually
>> indicated? Is there a revolutionary change instead of evolution?
>
> I don't see a revolution, but indeed an evolution.
>
>> If not, what about joining the two? If yes, could the division line which
>> model needs which driver be made more visible? Or could the driver instruct
>> the user to it's counterpart if the user chose the wrong one?
>>
>> Wow, all these changes must have meant tons of work for the engineers of
>> those days, bearing in mind that a UPS with such capabilities needed a PCB
>> full of circuits. And indeed the Fortress has a really large PCB compared to
>> contemporary models. And in those days there were no firmware updates.
>> Firmware was forever and essentially had to be bugfree (maybe we should
>> re-vitalize that old paradigm :-) I'm not sure if I saw even an EPROM in
>> there, maybe the code is inside the processor...
>>
>> At the time when this thing was built, if somebody would have told that a
>> time would come where I would update the firmware of my phone, my VCR and my
>> TV every couple of months :-)
>>
>> And at the time you had to support a bunch of operating systems, there were
>> unix versions, Windows, an OS/2 version. I'm quite amazed that the Checkups
>> Windows driver even runs on 7 and Vista, even 64 bit...
>
> good ol' engineering!
>
>> Sorry, I just got a little side-tracked :-)
>
> no problem, it's always good for health ;-)
>
>
> I've just started studying these docs, so no news yet...

I'm slowly progressing on that topic.
So far, the only thing I've seen are:
- the 50 ms delay should be 75 ms
- XON/XOFF are indeed to be enabled.

A patch is attached.
To apply it, from within the toplevel NUT source directory, use:
$ patch -p0 < /path/to/bestfortress-1.diff

Could you please apply it, recompile and report back as previously?

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bestfortress-1.diff
Type: text/x-patch
Size: 2169 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120217/876589c1/attachment.bin>