How to Make Almost Anything > John's class Homepage > Final Project update 11/28/04

 

Final Project: update 11/28/04

 

Legatos: “Legos” for Sound

Physical Modular Sound Blocks for sound and music

Hacks 12/12/04

  • Have all bytes be the same length?

 

To-do 12/2/04:

 

  • Add markups for holes in type A block. Make a run of them laid out on transparent paper
  • Design input/LED block.
  • Check on ordering etching supplies.
  • Nail out details of how the user switches between the blocks w/ the foot pedal
  • Nail down specifics of what the demo will be
  • Find out what transistor to use for LEDs
  • IMPORTANT: add resistor to RX/TX for type A

 

To-do 12/1/04:

  • Check on refund for ordering Digikey stuff. Done. Have RMA number. Need to ship
  • Design type A board : done
  • Figure out making holes on the modela: done. The tutorial is http://fab.media.mit.edu/tools/machining/nc/excellon.html

 

To-do 11/30/04:

 

  • Downstairs:
    • Look for pushbutton switches. Nice ones in Mitch’s stash. Order these. Done
    • Measure dimensions of phone jacks
  • Digikey:
    • Track down last week’s order. Got it.
    • Programming clips for 26 pin micros? Use Tiny26 programming clip
  • PIC
    • Try connecting RX/TX leads with resistor. Works. Don’t use resistor. See test3 code for turning on and off transmit pin
    • Copying contents… Yes. Use programming clip
    • SOIC available? Yes. Check on size
  • Type A
    • Design type A board
    • Making holes with the modela: find tutorial on XLR? Types to make holes?

 

Random notes:

  • Film/ceramic capacitors handle higher frequencies. Tantalum handle lower frequencies
  • GREAT tutorial for Eagle: http://www.interq.or.jp/japan/se-inoue/e_eagle.htm
  • For Eagle you want to export: Top, bottom, pads, vias…
  • Eagle: to figure out how parts lay out upside-down print the mirror of the package

 

Description of Implementation:

 

This will be a demo of the Legatos idea, not a full implementation. It will basically show a scratch/DJ effect with samples:

  • Input blocks will not have knobs. Instead the input will be controlled by ultrasonic sensors on a microphone measuring distance
    • Perhaps I still need input blocks with knobs or at least an LED display anyway?
  • A foot controller will allow the user to choose which input block the sensors are feeding numbers to
  • For the demo, the user can record a few seconds of data, and adjust the speed, amplitude, and pitch of the playback. There will be some sort of looping

 

Block type A:

 

The block has 2 inputs and 2 outputs. Everything is phone cord RJ12. The board, basically an efe without the sensor, will be glued to the bottom of my own Legos block. The top of this block will have Lego’s-like knobs so that a top can be put on and removed.

 

Array Blocks:

 

  • Two types of array blocks:
    • Control (adjusting frequency, amplitude, etc.)
    • Signal (direct audio, as in a buffer)
    • Perhaps this distinction could be hidden from the user?
  • Array blocks take one input: size, which should be in mSec?
  • To input an array, use foot controller:
    • Tapping the left foot controller cycles between the array blocks in the network
    • Tapping the right foot controller “records” values for the array using the ultrasonic sensors
    • Tapping the right foot controller again stops recording

 

Computer Implementation

 

Python code:

  • Polls the blocks
  • Blocks poll each other through DFS
  • The description makes it back up to the Python code, which describes the blocks as a PD file.
  • Sends keyboard commands to load the PD file
  • Sends updates on the input blocks through UDP sockets between Python and PD
  • How can Python check if bytes are waiting in the serial port buffer?

 

Communication protocol:

 

  • There will be a block which translates standard async UART protocol 2-wire to 1-wire
    • Tiny 15
    • Another way?
      • If UART is high and pulled low for start-bit
      • Have 10K resistor between TX and RX
      • RX can receive signal
      • TX will send signal --- but RX will receive this as well. We could ignore this in the software
      • Will TX signal be too weak?

 

  • Commands:
    • Baud rate: 19.2K
    • All commands 2 bytes long so no framing is necessary
    • $00: send ID
      • 2nd byte: # in queue i.e.
        • computer sends $00,00 to query 1st block
          • 1st block knows it is 1st in the queue
        • 1st block send $00,01 to query 2nd block, etc.
    • $01: find array block and turn on LED
      • 2nd byte: signature of block searching for
      • responses:
        • $00: block not in this queue
        • $01 block found
          • Byte 2: # block is in the queue
          • Bytes 3&4: size of block, LSB, MSB
          • Bites 5-9: $fc, $fd, $fe, $ff
      • Also, array block’s LED will be turned on
    • $02: turn off LED array block
      • 2nd byte: signature of block searching for
      • response:
        • $00: block not found
        • $01: block found. LED shut off
        • Bytes 2-5: $fc, $fd, $fe, $ff
  • Responses to $00:
    • Generic format
      • Byte 1: block type
        • Set bit 7 if block has been queued already in this query. If so, blocks 5-n will be skipped
      • Byte 2: block signature for this block type
        • Use bytes 1 and 2 for a complete signature
      • Byte 3: # block is in the queue as received from the send ID command (exactly the same number, NOT the number + 1)
      • Bytes 4-n: data for specific block
      • Bytes n+1 to n+4: end transmission: $fc, $fd, $fe, $ff
    • Specifics
      • LED w/ knob: n = 7
        • Byte 4
          • $00 positive #
          • $01 negative #
        • Byte 5: range of decimal place:
          • $01 range 1-999 (x1)
          • $02 range .1-99.9 (x.1)
          • $03 range .01-9.99 (x.01)
        • Byte 6: number before range adjustment LSB
        • Byte 7: number before range adjustment MSB

 

  • When a block gets queried:

·        Checks to see if it has already been queried. If so, responds with ID only

·        Queries block to its left (1st input)

·        Wait for a response from its 1st input

o       If no response within 1mS, block knows it is the last in the chain

·        Receives response --- transmits response bit-by-bit synchronously with receive

 

Blocks implementation: Specifics

 

 

  • Phone jack pinout:
  •    ----
  •   /    \
  •   ------
  •   1 2 3 4
  • 5V Signal NC Gnd
  • 5v signal must be unregulated
  • update: wouldn’t it be better to surround signal by ground?
  •    ----
  •   /    \
  •   ------
  •   1 2 3 4
  • 5V Gnd Signal Gnd

 

To Do:

 

  • add Jack component in Eagle
  • draw “type a” blocks board layout. Modella the board
  • review necessary components:
    • tiny26
    • SMT socket
    • Programming clip for tiny26 w/ necessary cables, plugs, etc.

 

Questions:

 

  • Best way to convert from 2-wire UART to 1-wire UART?
  • Easy way to make Y-cables from phone cord?
  • Did Raffi order mat’ls?

 

Unresolved:

 

  • How do we tell if we are on a right branch or a left branch?
    • Change protocol: when a block gets queried:
      • Send “L” immediately. Then poll left inlet
      • Send all responses from left inlet
      • Send “R”. Poll right inlet; poll all responses
      • Send ID of block itself.
      • Is response to what number we are in the queue still necessary?