Nut upsuser - Mar 2019 - UPS Requiring URB_INTERRUPT with Megatec Protocol

Hello,

I have a UPS unit with a USB Interface that appears to work with the
blazer_usb and nutdrv_qx drivers.  I have tried all combinations of
subdriver and protocol and the result is always the same.  The values
returned are all zero's.

The issue seems to be the same as
https://github.com/networkupstools/nut/issues/307

Attempts to send a command to silence the beeper or trigger a battery test
also fail.

One interesting observation was when using the UPSmart program provided
(Guangdong IDKG) in Oracle VirtualBox (Win7VM) on my Fedora laptop was that
the nut drivers would show values.  As soon as the UPSmart was stopped, the
values returned would stay the same and wouldn't update.

Observing the usb chatter in wireshark showed that the UPSmart program
received and sent an URB_INTERRUPT to 0x81 EP.  This was happening in a
pattern of receive/send URB_INTERRUPT followed by 5 GET_DESCRIPTOR
request/respond.

The UPS is cheap and cheerful, details can be found here
https://www.jaycar.com.au/650va-390w-line-interactive-ups-with-lcd-and-usb/p/MP5205
The badge on the front says 'DIGITECH Computer', model MP5205

I opened the case up and removed the comms board, but there's nothing much
to go on.  I was able to get details off the only IC on the board, but it's
a generic microcontroller.

I'm keen to get this to work but I'm a bit green on the hardware
programming side of things.  So if there's grunt work to do, let me know
what the next steps are.

Regards,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20190305/574a0d49/attachment.html>

> I have a UPS unit with a USB Interface that appears to work with the
blazer_usb and nutdrv_qx drivers.  I have tried all combinations of subdriver
and protocol and the result is always the same.  The values returned are all
zero's.
>
> The issue seems to be the same as
https://github.com/networkupstools/nut/issues/307
>
> Attempts to send a command to silence the beeper or trigger a battery test
also fail.
>
> One interesting observation was when using the UPSmart program provided
(Guangdong IDKG) in Oracle VirtualBox (Win7VM) on my Fedora laptop was that the
nut drivers would show values.  As soon as the UPSmart was stopped, the values
returned would stay the same and wouldn't update.
hmm... this sounds familiar.
You're not related to GitHub issue #674
(https://github.com/networkupstools/nut/issues/674), right?
> Observing the usb chatter in wireshark showed that the UPSmart program
received and sent an URB_INTERRUPT to 0x81 EP.  This was happening in a pattern
of receive/send URB_INTERRUPT followed by 5 GET_DESCRIPTOR request/respond.
This was the same thing I got to, the last time I looked into that
(after #307, there have been some other topics on the lists or on
GitHub, I can't remember exactly now).
> The UPS is cheap and cheerful, details can be found here
>
https://www.jaycar.com.au/650va-390w-line-interactive-ups-with-lcd-and-usb/p/MP5205
> The badge on the front says 'DIGITECH Computer', model MP5205
>
> I opened the case up and removed the comms board, but there's nothing
much to go on.  I was able to get details off the only IC on the board, but
it's a generic microcontroller.
>
> I'm keen to get this to work but I'm a bit green on the hardware
programming side of things.  So if there's grunt work to do, let me know
what the next steps are.
I don't expect this to work, but could you please test
https://github.com/networkupstools/nut/pull/638 ?

Also, if you're open to (building and) testing what I throw at you, I
can try to implement something to mimic what's in #307 / #674.

(for future reference, and before I forget about this one, apparently
-at least for #674- #638 did the trick, so it was just the order of
the commands sent to the device that mattered, and interrupts were not
involved)