Electrical output

From OLPC
Revision as of 10:07, 15 August 2007 by Homunq (talk | contribs)
Jump to: navigation, search

Just as the Measure activity allows direct input for sensors, it is useful to have a direct electrical output for robotics, LED's, and other purposes.

Possibilities:

  • Audio port: This would theoretically support a highly gradated, relatively precise, d/a output, at low currents. No word on whether this works.
  • You can blink LEDs by connecting them to modem control signals. Advantages: the relevant connector (phone cord) is widely available and cheap (or even scavengable)
  • USB to serial adapters are readily available. They work fine for simple things, but aren't great for microsecond level timings. A quick search finds prices under $20.
  • GPIO's on motherboard. Pretty much anything could be done using unused GPIO's on any of the chips, however since there's no easy way to access the gpio's, a soldering iron would be needed to get to them, unless an internal "pin header" was used to attach to them - even that would require disassembly to access it, unless an external port\connector was added, which would prohibitively add to cost. If this isn't added to the release software, it won't be possible for individuals to add it without a developer key, as an interface would need to be added to access GPIO's.
  • ntp uses one of the modem signals to catch the PPS (pulse per second) timing. Many kernels have a hack to grab the time when a modem signal changes state. USB adds a lot of jitter. (this is actually input, not output.)
  • USB to printer port adapters are also available. I've never played with one. Prices are under $40. Advantages: number of parallel outputs (how many? - at least 8 out and 8 in, + some more depending on exact port type. All pins are digital. Some can provide significant current (maybe enough for small motors), and most use TTL levels. See [1] for details. Provides no power rail - a data pin set to high must be used instead, or a seperate power supply. Timing is limited by software - everything must be "bit banged" for most home made electronics, so timing is good to tens of microseconds, but reduced a lot depending on kernel configuration. CORRECTION: If it's USB rather than native, then it'll suffer USB "jitter", and would be very bad for "home made" systems at clock frequencies faster than hundreds of Hz. - USB frame time is 1ms)
  • OLPC just had a summer intern, User:Arjs, who worked on the Measure/oscilliscope activity. We also talked about an OLPC digital gadget prototyping dongle with a USB-equipped microcontroller like those available from, for example, Atmel. Those chips cost a dollar or two and Arjun can get all the other parts really inexpensively in India where he lives.
  • For applications requiring a higher level of current/power, there is the power line of the USB ports. Would it be possible to separately power up/down the USB ports on the two sides? Hack them to power up/down programmatically, against the USB spec? (Unlikley - it may be possible to power all ports on or off together though, although that might kill the internal wireless - if only OLPC wasn't secret about the schematics we'd be able to find these things out.)