I'd like to create a process to programmatically turn-on/activate a separate USB device connected to my computer...Thinking another way to state the problem, I want the Arduino to complete the USB power circuit and then "turn off" on a schedule.

In an essence, I'd like to have my Arduino facilitate the manual process of un-plugging a USB into my computer (lets say for 5 seconds) and then re-plugging it in (let's say for 5 mins)-- rinse and repeat on a schedule....I'd like to have this coded/programmed though (I'm ok in the Arduino IDE -- sample code would really help me out a ton though) -- I'm not going to setup an actual servo to do this.

I thought getting a Arduino Shield would be the right place to start but I'm really lost. I also thought getting a USB cable with a flip power switch might be another way to tackle the problem too-- but I haven't started to mess with it yet.

Any ideas or resources to point me in the right direction are greatly appreciated. Thanks so much.

I'm not aware of any off the shelf "shields" which would accomplish this goal. Since you do not seem to want your Arduino device to play either the USB host or client role, but rather to interrupt power to a difference device, a traditional USB shield is probably not going to help.

Rather it would be useful to look at how the small minority of USB hubs that implement software control of downstream power on a port-by-port basis do it - USB allows for this, but doesn't require it, and most hub ICs have output pins to drive power switches, but don't include them.

Switching the 5v USB VBUS needs to be a done with a "high side switch" - a P-channel MOSFET would be an obvious candidate, but it has been historically harder to find good ones. Some time ago I ordered a few Richtek RT9701GB USB power switch ICs - apparently they are actually more effective N-channel FET's packaged with surrounding circuitry to make them usable on the high side - but that project was shelved so they remain untried. If you are up for creating an extremely simple surface mount board to hold them (or can find one already made) they might be worth a try.

At the crude end you could probably use a relay board. There are hubs sold with mechanical power buttons that can be very useful when debugging USB-based embedded systems as you can power cycle them without constant unplugging, and this would be a sort of automated version of that.

It's an interesting question however, if removing the power to a USB peripheral while the data lines remain connected is proper. This is problematic in the simplest design of an ESD protected input, as the built in protection diode means that the data signal ends up trying to power the unpowered IC, something it isn't usually rated to do, but actually USB circuitry may be more complicated. An original USB "A" connector is made with the power and ground pins longer than the data ones, in the intent that they connect first. Pragmatically, I've seen numerous USB devices survive data connection without power - but it could be interesting to read the specs (both USB and of the data sheets of particular devices implementing it) and see what they say about this.

Another tactic could be to get one of the hubs with buttons, take it apart, and wire a relay across one of the buttons.

Or, if you did get one of the rare USB hubs that actually includes controllable downstream power switches, an investigatory dive into the depths of your computer's USB stack should theoretically yield a way to control them from software there, potentially eliminating the need for the Arduino/Teensy.

At the crude end you could probably use a relay board.

hmmm, you RAAAANNNNNGG? (yes finally a reason validating my existence!)

Sorry, but I just couldn't resist chiming in on this topic. So what I can add is:

I have a Teensy 3.2 - RPi2 contraption at a site which is impersonating a USB mouse, from the security NVR's perspective (think Fred Sanford meets Frankenstien) And since I just couldn't grok using the serial UART (I think) I did everything using relays and optocouplers. So I SSH my way into the RPi's using Putty to initialize a VNC connection (just once per restart; although ugly, this sure beats the trauma of BASHing commands into RPi which elf up its bootup behavior to autostart VNC) So now instead of dreary CLI hell I have an ARM friendly release of the latest Arduino 1.6.13 IDE(emphasis on GUI !!) which (as of like the last few months) NOW SUPPORTS Teensy 3.2 with Teensyduino! (meaning support for teensyloader as well) Pretty slick, huh? Write Arduino sketches "anywhere on earth" with full GUI support and flash them onto a Teensy (well at least it's impressive to me...)

OK, so now comes the crude hacking of ugly relays I salvaged dumpster diving (that's pronounced "F-R-EE") The flaw in my setup is how to get the freshly programmed Teensy to change hosts? So I built an mechanical A-B switcher (2 hosts sharing a single client). Originally I was way cautious so I used four double pole relays for pluging/unplugging in a 5 step process controlled by three of RPi's GPIOs. USB power supply lines from the Teensy feed the poles on a DPDT relay, disconnecting Teensy from all power if energized. N.C. contacts feed the poles on another relay that selects one of two hosts. The N.C. contacts on this relay feed the NVR, so that if control circuitry fails to deliver power to any given relay coil, the "normal" contacts default to Teensy being fully connected to the NVR, which normally doesn't shut down. The Rx & Tx lines were wired the same way.

When jumping from host to host, I used the rule for PA amplifiers to remember: last to power up, first to power down. The five step sequence is derived from this rule, which is: ENERGIZE SIGNAL RELAY, ENERGIZE POWER RELAY, TOGGLE SWITCHING RELAY, KILL POWER RELAY, KILL SIGNAL RELAY This is the weakness in my system, because I use the same script regardless of the host. The middle step is just "toggle" and led to a sloppy protocol. Rigorous fool-proofing shouldn't allow a script to end with the A-B selector having an energized relay since the fall-back safety configuration was hard-wired for all relays being in their normal, unenergized state. As long as a relay is energized, the script keeps running would be best practice. So, being lazy and absent-minded, it wasn't long before I rebooted the RPi with the Teensy still attched. Sheer terror. And the next time, merely anxiety. Subsequent breaches of protocol became simple annoyances. So now, protocol is a joke, reboot has all the dignity associated with an episode of Jersey Shore! (translation the signal/power concern hasn't been an issue in this situation)

Bottom line, mechanical port switchers have worked great for me. After the Teensy project is complete, I plan on using it to switch a USB drive between the NVR to archive important files, and a RPi for file sharing over the web. And remember, mechanical switchs (with relays belonging to the family) are still superior to Silicon based devices in many way. For example, leakage current in mechanical switches is almost nil, they have no polarity constraints, consume no current, and produce no noise in a static state.

And finally, regarding this passage:

Another tactic could be to get one of the hubs with buttons, take it apart, and wire a relay across one of the buttons.

I'd like to share a gem I unearthed on eBay: a finer link you cannot find and is as fresh as today's date. So here's a hub that I think matches your description:

http://www.ebay.com/itm/NEW-7-Port-High-Speed-USB-2-0-External-Multi-Expansion-Hub-with-ON-OFF-Switch-LO-/161831365420?hash=item25ade6ab2c

Yes, that a 7 port hub with a toggle switch and indicator led on each port. Delivered right to your door for the tidy sum of US$3.01 What kind of numbers does it benchmark at? Hmmm. you might be missing the point. It's a 7 port UBS hub with bells $ whistles with FREE SHIPPING for 3 BUCKS !!!

(CLEAR)

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.