Electrical output

From OLPC
Revision as of 03:20, 12 May 2008 by Cjl (talk | contribs) (cat)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to 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. Each of the following presents different trade-offs in terms of cost, number of independent lines available, voltage accuracy, timing accuracy, and power available.

Possibilities:

  • Audio (headphone) port:
    • This would theoretically support a highly gradated, relatively precise, d/a output, at low currents. No word on whether this works. (2 outputs/ stereo?)
  • Modem
    • 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)
    • 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-based add-ons
    • 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.
    • 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)
    • There are also things like this with 24 GPIO lines.
    • OLPC just had a summer intern, User:Arjs, who worked on the Measure_/_Oscilloscope 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.
  • USB hacks
    • 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.)
  • Screwdriver and soldering iron
    • 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.
    • There is a serial port driver visible in the OS. Rumor has it that this is serial port capability built into some chip on the motherboard (CPU?). It is not clear what would be necessary to get these wires connected to something; at a minimum, it would be a soldering activity which would be more or less dangerous for the laptop.