<html>
<body>
<font size=3>Alexander,<br>
I have just done a test with your code and it does work.
<br><br>
I was doing my work on the latest stuff from SVN to see if
that would help in my investigations. I did not apply the patches from
previous mails, just used the code in the later modules (the patch
process produced errors).<br><br>
It does not matter which version we use as both work for me,
now. We just need to implement a few more commands into your code, if we
use that, and work out how to implement the code that sends data to the
UPS, ie the S<n>, S<n>R<m> and T<n> commands. I
also want to implement the TL, C and CT commands, but I whilst I
can see the reaction to these it is a little difficult to work out the
code to use.<br><br>
I think the F command may need a little more work as I think
it may need to issue the '0x01' command first to get the
manufacturer.<br><br>
Anyway, both sets of code work, for me at least, so it is up
to the powers that be to decide which way to go.<br><br>
Regards<br>
Jon<br><br>
Output from upsc command with your code<br><br>
battery.charge: 95.0<br>
battery.voltage: 27.00<br>
battery.voltage.nominal: 24.0<br>
driver.name: megatec_usb<br>
driver.parameter.pollinterval: 2<br>
driver.parameter.port: auto<br>
driver.version: 2.1.0<br>
driver.version.internal: 1.5<br>
input.frequency: 50.0<br>
input.voltage: 246.5<br>
input.voltage.fault: 140.0<br>
input.voltage.maximum: 246.5<br>
input.voltage.minimum: 246.0<br>
output.voltage: 246.5<br>
output.voltage.nominal: 240.0<br>
ups.beeper.status: disabled<br>
ups.delay.shutdown: 0<br>
ups.delay.start: 2<br>
ups.load: 12.0<br>
ups.mfr: <br>
ups.model: JP01053T<br>
ups.serial: unknown<br>
ups.status: OL<br>
ups.temperature: 25.0<br><br>
<br>
At 09:36 2/02/2007, Alexander I. Gordeev wrote:<br>
<blockquote type=cite class=cite cite="">Jon, Carlos,<br><br>
I've tried to explain what I have achieved but I see that you
haven't<br>
got it. Let's try again.<br>
(Sorry, if all this is because of my bad English, I'm not a native<br>
English-speaker.)<br><br>
Jon wrote::<br>
> Here is a level 4 dump of the output I
currently get. This<br>
> shows that apart from the first call which is to the
comm_usb_recv<br>
> without calling the comm_usb_send first, most of it is working.
The<br>
> functions I have not implemented end up doing what the original
code<br>
> did, ie set_report, get_interrupt.<br><br>
Jon wrote:<br>
> I am using Serial-Over-USB to drive my UPS.
I have taken the<br>
> work that was done for the AGILER interface and added the
ABLEREX<br>
> interface. However, I could not get the 'get_interrupt' command
to<br>
> work. It would not return any useful data. So I had to change
the<br>
> 'set_data code' to issue 'usb_get_string_simple' and translate
the<br>
> character requests into index numbers. The 'get_data' just reads
a<br>
> static variable that is set by the 'set_data'. In this way I can
get<br>
> most of the functionality working.<br><br>
1. I've asked you to test the patch I supplied without any change,<br>
because<br>
> Our devices seem to be mostly identical!<br>
That means that only one _subdriver_ is needed. So the functions<br>
get_data_krauler/set_data_krauler are ready to work with your UPS
too.<br>
I see no point in writing this subdriver once again, as you did.
They<br>
are just quite similar, really.<br><br>
2. Also I don't get why have you prefered 2 month old patch,<br>
which won't compile against current trunc, as the base for your
work.<br>
I've reworked it, as I wrote about a week ago. What I did:<br>
- renamed all the functions like in serial.c. So now you don't
need<br>
to change megatec.c in any way. If you don't understand why I did
it,<br>
please refer to the discussion that took place in December.<br>
- fixed some bugs from the original patch. And, I believe,
didn't<br>
introduced new ones. I've checked everything hard. However, not
all<br>
the bugs (that original code has) are fixed yes. There are at least
2<br>
of them yet. I'll work on them.<br>
- wrote a new subdriver to support my own UPS. Again, I'm sure,
it<br>
_will_ support somehow your device. I thought that you could
figure<br>
it out.<br><br>
One thing I haven't done: UPS commands. I had to stop adding
features<br>
after I met the bug I've already written about yesterday:<br>
> ...<br>
> Trying to match device<br>
> Device matches<br>
> HID descriptor, method 1: (9 bytes) => 09 21 00 01 00 01 22 70
02<br>
> HID descriptor, method 2: (9 bytes) => 09 21 00 01 00 01 22 70
02<br>
> HID descriptor retrieved (Reportlen = 624)<br>
> Unable to get Report descriptor (-8
<img src="http://messenger.msn.com/MMM2004-08-11_11.52/Resource/emoticons/75_75.gif" width=19 height=19 alt="Eye-rolling">: Invalid or incomplete
multibyte or wide character<br>
> No appropriate HID device found<br><br>
I guess, this bug is specific to my UPS. But I don't know it for
sure<br>
<img src="http://messenger.msn.com/MMM2004-08-11_11.52/Resource/emoticons/sad_smile.gif" width=19 height=19 alt="Sad smiley"> So, please, test my code without changes and send all output to
me.<br>
It will be really great.<br><br>
Of course, I'll test your code too. Maybe, it will stop the bug...<br>
I'm looking forward for the patch.<br><br>
Please, tell me if you have any questions...<br><br>
Carlos wrote:<br>
> The idea is to keep megatec unmodified, and up until now a
simple<br>
> USB communications layer with the same API as the serial layer
would<br>
> make this possible. The only catch was the need to add
"subdrivers"<br>
> to support different models, but otherwise this layer could
even<br>
> prove useful for protocols other than megatec. <br><br>
> The original agiler interface by Andrey Lelikov modifies<br>
> "megatec.c" to add that USB layer, but I think it should
be just an<br>
> outside file with the same API as the serial layer, and linked
at<br>
> compile time to generate an ablerex specific driver, even if it is
megatec specific.<br><br>
> Then 1) would be "serial.c", 2)
"megatec-transport-usb.c", 3)
"megatec-transport-ablerec.c"<br><br>
> But don't worry about that just now. It is more important to see
it<br>
> working, this refactoring can be done later. <br><br>
> When I have some free time I'll check which one of these
transport<br>
> mechanisms my own UPS uses. Then I'll be able to help in
refactoring<br>
> whatever code we have by that time.<br><br>
Well, I've done this refactoring.<br>
Sorry, if you've received this message twice!<br><br>
-- <br>
Alexander
<a href="mailto:lasaine@lvk.cs.msu.su" eudora="autourl">
mailto:lasaine@lvk.cs.msu.su</a><br><br>
<br><br>
<br><br>
<br><br>
<br><br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
Nut-upsdev@lists.alioth.debian.org<br>
<a href="http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev" eudora="autourl">
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev</a></font>
</blockquote>
<BR><BR>
<TABLE width=400><HR>
<P style="FONT: 9pt/11pt verdana"><a href="http://www.avast.com">avast! Antivirus</a>: Outbound message clean.
<P style="FONT: 8pt/11pt verdana">Virus Database (VPS): 000709-2, 01/02/2007<BR>Tested on: 2/02/2007 11:45:10 AM<BR><FONT color=gray>avast! is copyright (c) 2000-2007 ALWIL Software.</FONT></P>
<TBODY></TBODY></TABLE>
<BR>
</body>
<br>
</html>