Track My Order
Frequently Asked Questions
International Shipping Info
Mon-Fri, 9am to 12pm and
1pm to 5pm U.S. Mountain Time:
Chat With Us
April 5, 2009
News - Enginursday: A new and im…
about 3 weeks ago
A series resistor is indeed the simplest solution, but we have deliberately avoided, not as much due to ripple or efficiency, but more because of voltage sag. At the rated 3A load, and with USB being very picky about the tolerances of the VBUS voltage, you’d be limited to a very small resistor, which would not actually suffice to attenuate the ripple sufficiently.
Thanks for the tip about the battery contact hazard. I haven’t seen this failure occurring with our current circuit, but I don’t know for certain that it doesn’t exist. At least, I haven’t seen the datasheet calling out for any precautions about input stability and it’s possible that the input capacitor alone would be sufficient for smoothing out these transients enough to not throw the switcher out of stability.
TVS diode was my original thinking too, and your reasoning is correct. However, in practice, if you look at real TVS diodes you’ll find that they typically have a pretty large gap between the clamping voltage and the standoff voltage, which would mean that we’d have to seriously derate the max input voltage with this configuration.
Using a different VREG is an option too, but again, considering different practical options and their impact on the overall board size, specs and cost, using the existing VREG circuit with an active suppression circuit was chosen as the sweet spot. I’m not declaring that this is beyond any doubt the best possible solution, only that we’ve definitely considered the options you’re proposing and have concluded otherwise.
about 5 years ago
Additional information on Bluetooth support and an example video can be found here
One way latency is in the order of 4-5ms. What you’re experiencing is definitely not normal. Are you getting this with the example projects too?
Either way, raise your issue on the users forum mentioned above, and people may be able to assist you.
You might be running with “Debug” rather than with “Run”, and the “force close” you’re seeing has a “waiting for debugger connection” on top, which means it just let’s you kill the app if you’re tired of waiting, but will eventually go away by itself when the debugger connects.
This message looks awfully similar to the “force close” you’re getting for an uncaught exception. I was bitten by it myself a few times…
It’s all open source:
What’s incomplete about it?
News - The IOIO and Android Base…
about 5 years ago
Allow me to clarify a bit: the IOIO ships with a bootloader and ‘stock’ firmware installed. The latter can be upgraded / modified with no need for a programmer: the bootloader just pulls a new image from the phone. For that purpose, you’ll need to install a dedicated app on your Android phone. This app does not exist yet on the Android market, but soon will (for free of course).
If you want to upgrade the bootloader, then a programmer is needed. As a1ronzo mentioned, the IOIO itself could function as a programmer for another IOIO, and programming would be done with this same app that’s coming soon.
This is pretty much the same way as it works in Arduino, where you rarely need to upgrade the bootloader, but can do so with another Arduino when needed.
about 5 years ago
I’m working on it and making nice progress. Should be ready soon. Will support seamless fallback to ADB whenever ADK is not available.
Has been done.
It is fairly simple. Might post a step-by-step tutorial on this at some point. In the meanwhile, you may want to check cellbots.com
Bluetooth has higher latency and lower bandwidth than what can be achieved via USB.
IOIO has ~3ms one-way latency and ~300KB/s throughput.
Bluetooth + microcontroller board is also a little more expensive and somewhat more complicated to setup for the novice.
No public wish lists :(
Forgot your password?
No account? Register one!