How to replicate the AENSBox

From CSL Wiki

Jump to: navigation, search

Here is a list of components and roughly how to replicate them:

Array Assembly

  • 4 microphone preamp boards
    • condenser microphone module is RTI1207A, only available from the manufacturer in singapore
    • Other components are available from digikey
    • schematics and layout. these are on a CD which i have at home. however they are not up-to-date; i have a hand-drawn diagram of the modifications, but it would be very advisable to update the schematic and respin the board, and probably use a different connector.
    • extra credit: develop a power supply filtering circuit so the mics can run off the main battery.
  • emitters are piezo tweeters from parts express http://www.partsexpress.com/pe/showdetl.cfm?&DID=7&Partnumber=270-041
  • wire routing board
    • the array has a pcb that bridges between the mics and the cables from the array to the cpu box; however if the connectors on the mics changed, this board would also want to change. the cable from the cpu box need only carry:
      • 4 analog channels (we used one twisted pair for each)
      • 1 output channel for the piezos
      • power, if you power the mics off the main battery
    • i have schematics and layout for the current pcb on the CD
  • mechanical array
    • lexan cage, to hold the microphones, with standoffs (standoff screws need lock washers!)
    • pvc pipes to hold the microphone preamps; mics are glued to top of pipe with hot glue; strain relief on microphone wiring (currently cat5 cable); screw intended to compress lexan to grip pvc pipes
    • aluminum brackets to hold emitters, and wiring to wire emitters in parallel.
  • desirable fixes to mechanicals
    • IF using same lexan cage arrangement, turn the ID and OD of the pvc pipe near the bottom of the pipes so that they are uniform. as it is the pipe diameters vary and the gripping scheme did not work. also, the strain relief plugs were made different sizes to fit the different pipe lots ( ??? that was the brilliant idea of the machine shop guy)
    • IF the mic boards are respun they might be substantially narrower which would enable narrower pipes. in the current setup the pipes for one mic can physically block the other mics and can cause problems
    • or, the mic boards could be respun onto a single board that hosts mics positioned some other way. for example, positioning the mics on a hemisphere would be better
    • The lexan as currently built has additional unused features (holes etc) that were originally planned but design changes left redundant.
    • I have a solidworks model for the original array parts and i think also for the aluminum emitter brackets although i need to look for that...
  • hardware
    • the hardware is all readily available english-unit fasteners.. mostly 4-40 and 6-32 machine screws.

CPU box

  • power supply
    • two external power inputs: 12V in and 16v charger in
    • power inputs are run through switches to switch main power supply between wall adaptor and battery; and another switch to connect the battery to the charger or to the main power; internal Li+ battery
    • power supply (12-16v) fed to audio power amp and slauson
  • cpu and peripherals
  • audio wiring
    • wiring interconnect board to mount XLR mic connectors (these are the connectors on the digigram dongle) and wire them over to the connector going to the array
    • an audio power amp hacked out of a dell PC speaker, with the output going to the interconnect board and the input coming from the headphone jack on the digigram dongle (1/8" stereo plug)
    • a hand-made opto-switch to gate power to the audio power amp based on gpio output from the cpu board
  • design problems to fix
    • desperately needs external LED power indicator
    • audio power amp is absolutely terrible.. terrible shielding problems, should be replaced with simple custom board and integrated with gpio switch
    • replace digigram dongle, eliminate XLR madness
    • better battery / charging system
    • some kind of mass storage solution beyond 1GB. usb? 1GB is the limit with the pxa255 sd-card slot
    • expose serial console easier
  • i have a CD with the original designs for the wiring board and the top panel; however the wiring board changed and might want to change more, and the panel holes are very different because we switched to the slauson from the stargate, etc... also, if the XLRs were removed and the audio amp fixed the whole thing could be a lot smaller.

Software

  • kernel
  • system/application software
    • we have a large tarball of tools, compilers, arm libraries, and arm binaries that work on the slauson. this is not currently in a publically accessible place but can readily be acquired
    • once the tarball is untarred in /usr/arm-linux, then you need to download emstar and build for the nims-stargate platform.
    • part of that tarball includes images that are installed on the onboard flash, containing the linux root filesystem and basic kernel.
    • to configure the slauson we start by loading one of these standard "firmware versions", and then upgrade it, by copying on our modified kernel and then copying in a tarfile full of updated modules, additional libraries, and software. basically the tarball is maintained as a big patch against the "basic" root fs image.
      • most of the tarball is additional libraries that are not included in the basic distribution and the kernel modules to match the new kernel version we load. the patch was created by:
        • manually copying the libraries out of the development toolchain,
        • installing the modules built from compiling the patched kernel, and
        • installing the "emstar" application software
    • the software that comes from emstar is built from cvs, and through a particular script the subset of the software that is required is copied into a directory structure, which is included in the tarball
  • modifications to the software at all levels can be integrated onto the nodes...
    • changes to emstar application software can be run via NFS or copied onto the node, following the same installation procedure to grab the binaries and libraries and copy them over
    • changes to the kernel or modules can be integrated by recompiling the kernel and then installing it and the new modules
    • new libraries can be copied over and placed in the appropriate locations
  • "rbsh" is a useful tool for managing these nodes all at once -- it's a broadcast remote shell tool that interacts with a daemon that is installed as part of the big filesystem patch tarball. See How to run the system standalone for information on using rbsh.
Personal tools