Mihai Popescu wrote:
Had anyone any success with this usb wireless in recent snapshots.
Following some hints that this chip is not properly powered from USB
port, I hardwired it to the power supply of the computer, but the
result is the same: it fails to load the firmware.
Nevertheless I had some interesting results using some custom usb
cable prepared for some measurements. After a few plug-in actions, the
500mA fuse of my multimeter was destroyed. It looks like there is a
current spike at plug-in time, greater thatn 500mA.
But, switching to a bigger scale and moving the usb wireless module on
another OS, I got aprox. 130mA current draw in a working state.
I tried to recompile the 5.9 release kernel with some added delays in
the code, but I got some errors like syscal 114 and another numbers at
boot time.
It sounds more like a capacitor charging up within the device. Seems a
bit weird for a wireless module, but I guess this could be a decoupling
cap. If your 500mA fuse blew the first time you plugged it in but not
the second time, it was just drawing the current to charge some
capacitor up.
Then when you plugged it into another OS, the cap was already
(partially) charged, so the current spike was not as large, or as long.
A spike that is too short will not blow a fuse, even if it is a
fast-blow one, unless the current is much higher than the fuse itself. A
fuse is really designed to protect against situations which could result
in overheating of the conducting paths (wires, PCB tracks, etc).
Maybe try again after shorting the power pins on the USB plug on the
wireless adapter for a few seconds (or better yet, instead of a short,
use a bleed resistor of something like 10ohms to discharge the cap).
An oscilloscope is great for picking up such transients, since a
multimeter typically has a latency for registering these kinds of
transients.
Something like:
+--[scope]-+
GND-> | | <- Probe
| |
(-) --+--[1R0]---+-----[LOAD]---- (+)
