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

[Oliver Kluge]

Hi Arnaud,

if you got tons of material including several protocol revisions, maybe 
a broader approach might useful?

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.

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?

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...

Sorry, I just got a little side-tracked :-)

Yours
Oliver

Arnaud Quette wrote:
> Hi Oliver,
>
> 2012/2/5 Oliver Kluge<ok23 at kluge-digital.de>:
>> Hi Arnaud,
>>
>> Arnaud Quette wrote:
>>>
>>> I hope somebody else with jump in and answer your question.
>>> serialmon (http://www.serialmon.com/) seems to be a good candidate.
>>> but I'm not sure if it allows to dump the snif.
>>> so if you're not in hurry, you may prefer the below solution...
>>
>>
>> Well, I've tried Serialmon. It would enable dumping - but it doesn't work at
>> all.
>>
>> System requirements are Windows 2000 and newer and Dot Net 2.0. Therefore I
>> did not even try it on Vista or 7, but on my trusty Windows XP with latest
>> Service Pack. And of course with Dot Net 2, 3 and 4. 2 has SP level 1.
>>
>> On the first installation run Windows complained that Serialmon does not
>> pass the logo test. I continued with the installation and rebooted.
>> Serialmon then told me that it could not perform software monitoring,
>> because I would either need to reboot or re-install. I rebooted, to no
>> avail. I re-installed (twice), it just doesn't to anything.
>>
>> I even blocked Checkups II from starting by removing its registry entry, so
>> COM1: would not be blocked, and re-installed. Doesn't make a difference.
>>
>> Then I tried to talk to the UPS by hand, with Hyperterminal. The UPS doesn't
>> talk to me, even when I send the password that has been described in your
>> link to the protocol (bearing in mind it may not be the right protocol for a
>> 660 LI).
>
> damn, sorry for the burden :(
>
> in the meantime, I've received tons of materials from my Eaton
> contact, including various revisions of the protocol, and the CheckUPS
> II source code.
> I'm planning on publishing this, but it requires to go through the
> legal loop... so not that fast.
>
>> Btw, in the protocol link it is mentioned that the UPS does do flow control,
>> via XON/XOFF. Maybe this contributes to the disrupted communication of the
>> bestfortress driver?
>
> that may explain things (Ie, difference in flow control handling
> between fortress generations), I'll have to check.
>
> I'll be busy most of this week with other things.
> so please excuse the upcoming lag.
>
> cheers,
> Arnaud