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<[email protected]>:
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
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
