It's also worth mentioning with respect to the new piece for Coachella, that I've acquired a few new tools that are making the process much quicker and easier. First and foremost, and really the centerpiece of it all, is the new Tektronix TDS3024B Oscilloscope. This baby has been on my wishlist ever since playing such a huge role in my senior design project success back at UIUC, and with the days counting down fast to Coachella, I decided I needed all the help I could get, and it really has been a big help.
I often describe working on electronics without a good scope as being comparable to trying to work with your eyes closed. It's not necessarily impossible but it increases both the time and frustration of even simple tasks by orders of magnitude. It's much easier to work intuitively when you can see what's happening right before your eyes. The image above, which I grabbed just to confirm that the duty cycle of the PWM was changing (in this design, the duty cycle of the PWM is also capable of changing faster than the eye can perceive), shows in yellow, pink, and green the CS, MOSI, and MISO lines from the FPGA to the SD card, and in cyan one of the channels of PWM out to an LED. Prior to this I had an old Tek265 analog scope which was useful in many circumstances, but for things like the serial bus debugging of the past few days, just didn't do the job. The 3024 has 4 channels @ 200MHz with all sorts of advanced measurement capabilities, FFT, advanced trigger, and a 640x480 color LCD. It also sports its own internal web server so getting screen captures is as simple as opening a web browser. The only negative is that when debugging a 50MHz serial bus on a 200MHz scope, the waves are pretty distorted, so a higher bandwidth wouldn't hurt. I wouldn't trade the advanced features for more bandwidth though, and to up the bandwidth to 500MHz crosses the line into 5-figure territory, which just wasn't in the cards this time. The reality is that the 3024 has been capable of everything I've asked, and I couldn't be more pleased with my decision on this one.
Also very helpful has been the Intronix LA1034 LogicPort USB Logic Analyzer. A logic analyzer is essentially an oscilloscope that trades the ability to see analog voltage levels for the ability to see lots of channels at once — in the case of the LogicPort, 34. It's somewhat limited in its sample storage capacity, which limits the length of data you can view at one time, but it mostly makes up for this with really smart triggering, which lets you focus that limited view on exactly what you want to see. The software also decodes serial buses, so it turns the SPI data and clock wave forms into hex that you can read directly (shown in the image below), which has been invaluable in the past few days. It's also an incredible bargain, when you compare with hardware solutions that (in Tektronix) start at $10k. The LogicPort is no $10k piece of gear, but it's a great addition to the lab that I'm very glad to have made. Plus, it's made in the USA by a small American company doing great work, which is always nice to support when the opportunity arises.
For the past few months, and really accelerating in the last couple of weeks, Dad and I have been working on a new piece, set to debut at the Coachella Valley Music and Arts Festival April 25-27. At its core will be a much improved spherical display with high-res surface complemented by volumetric accents, all in 24-bit color. On-board will be on the order of 10GB of removable flash memory, combining the increased resolution and color depth with a much greater potential show length as well as much easier program changes. All of this will lend itself toward a renewed focus on content, which is a very exciting thing for me as a big step toward the high-definition three-dimensional canvas which I originally envisioned with the ORB.
To make this a reality, I've finally crossed the void into the world of FPGA, and I'm loving it. The ability to quickly create massively parallel hardware in a few lines of code is really powerful. It takes a bit of getting used to, but within a few days I was generating the beginnings of working code in VHDL, largely with the help of Volnei A. Pedroni's Circuit Design with VHDL and the Altera Cyclone III Starter Kit. Now, just under a week into serious development, I feel as though I've got a pretty good handle on things, so the learning curve isn't as steep as it initially seemed, particularly if you've got some crossover experience developing both software and hardware.
As is unfortunately too often the case though, the learning curve seemed steeper when it came to using some of the pre-existing libraries I found. I needed SPI to access the flash memory, and so I started looking for libraries. The Altera board shipped with Quartus II which I'm using for all of my development and is a pretty nice package. Quartus leads you directly to Altera's NIOS soft-core processors with all kinds of great add on modules. These designs are cool because they allow you to set up part of the FPGA to act as a microprocessor meaning you can develop in a typical procedural language like C where appropriate, using the hardware definition languages only where necessary. The demos were easy to walk through and I thought I had everything figured out — until I read about the $2500 per seat licensing fee.
I'd heard of OpenCores and it sounded like a really cool project so I thought I'd check it out. OpenCores is essentially Sourceforge for HDL (hardware definition language) designs, albeit much less trafficked. It appears that there is some great work going on there, but at my level of knowledge, the documentation was just insufficient for my needs. If I really needed a fully-featured CPU running on my chip I'm sure I could have figured it out given enough time, but as it stands it's far from plug and play. And as the countdown timer on coachella.com continually reminds me, the show starts in 45 days, 17 hours, 28 minutes and 26 seconds. So it's time for action.
As it turned out, I spent a bit more time tweaking the SPI module I had been writing prior to looking at the soft cores, and with just a bit more effort, got it up and running. I then began work on a state machine that controls the SPI module and passes the data out to a set of PWM modules which actually control the LEDs. I'm still working on scaling the code and getting some of the finer control functionality implemented, but all indications are that with a few more days of work the code will be 99% complete. Then its on to PCB design, construction, and content.
In parallel with the electronics, Dad's hard at work building two chassis, one to ship to Manhattan for me to use as a framework to finish the electronic development and another to finish out in time for Coachella. We've got a totally new look this time, a bit more design-influenced and incorporating some cool high-tech materials. I'll get some photos of that part of the process up here as soon as they become available.
Thanks to everyone who came out tonight to the closing party of the Interactive Youth exhibition at Material Connexion. I'd also like to thank everyone at Material Connexion, who hosted a great event, especially the outstanding Ben Rosenthal, Project Manager for Public Programs.
Also, in from the archives is a link from back in May from the Popular Science How 2.0 Blog about the ORB at Maker Faire.
Jimmy and his team were great. We shot a short interview which should air on Jimmy Kimmel Live! within the next couple of weeks. Jimmy said he "felt like the Mona Lisa" and that his mug on the ORB was "the most beautiful thing I've ever seen". MAKE!
This comes to you from a quiet hotel lounge on the east side of Denver on our way to the MAKE Magazine Maker Faire, where we will join some 400 makers (including a handful of ITP'ers such as Andrew Schneider, Team Botanicalls, Giana Gonzalez, Tom Igoe, and last but not least, FabInfo instructors Toru Hasegawa and Mark Collins) with ORB and ultraORB in hand and ready to exhibit. A few tens of thousands of attendees are expected of all ages and all walks of life and I'm expecting a fantastic time sharing our work with the curious as well as exploring the rest of the exhibits. I'm also slated to give a talk/demo on Thursday's Maker Day, a day of events held specifically for the exhibitors and other presenters and organizers.
Maker Faire is held at the San Mateo Fairgrounds in San Mateo California and is open to the public on May 19-20. Advance tickets are $15 for adults, $10 for students 21 and under, and $5 for children 12 and under ($20/$15/$5 respectively on-site). Hope to see you there.
The presentation of the ultraORB at ITP Thesis week is now online and can be streamed here or downloaded here. I'm working now to improve the programming, moving toward displaying controlled geometric objects Tuesday and Wednesday at the ITP Spring Show.
LEDs are soldered and testing is underway. There are a few minor bugs to tweak out with the lighting and then it's on to full assembly and programming. The color balance is a bit askew, but that's an issue for another day. 48 hours to go...
Here's a view of 1/8th of the final assembly with LEDs in place. 280 LEDs to go.
Resting atop the PCB is the CNC machined aluminum board mount, holding in the foreground one of the four DC-DC stepdown converters from short-circuit.com. The board mount is topped by the three conductor commutator assembly, handmade from readily available materials and a few custom laser cut plexiglas spacers. The commutator mates with a set of brushes to deliver +15VDC, GND, and a timing signal from one of a pair of hall effect sensors mounted on the assembly rotating about the vertical axis (each quadrant of each PCB also has its own hall effect sensors to sense rotation about the horizontal axis).
For those of you who haven't been following along with the in-person presentations, here's a little clip of video that was shot about a month and a half ago, showing the ultraORB concept in action. This is a demo and concept test with 4 single-color LEDs — the version due to be presented this coming week will have a total of 320 tri-color LEDs under microprocessor control to create a truly three dimensional persistence of vision display.
Just under 100 hours to go until the first display of the ultraORB at my thesis presentation, Thursday, May 3 at 8:40pm. There is still a lot to do, but things are moving forward. 16 microcontrollers are interfacing with 128MB of onboard flash memory and my laptop through 8 dual-channel USB interfaces. Now it's on to wrapping up a few loose ends and then soldering the 320 RGB LEDs. Then on to the first spin. Stay tuned...
After a couple of days of intense soldering, the first major task is complete. The 960 0201 LEDs are all in place. It's funny, after two days of work, the boards look almost entirely the same to the naked eye. While I can barely focus on the screen to write this (seriously — now I understand what it's like to need glasses, if thankfully temporarily), the upside is that after soldering almost 1k 0201 parts, the 0402 package parts look like bricks and are easier than ever to handle. In any case, I'm here to say that it is very possible to hand solder 0201 parts. Time to go clear the head and get ready for another day of soldering tomorrow. In the meantime, here's the view from the soldering station:
The circuit boards are here, having made the trip from the GoldPhoenix fab in Wuhan, China to Manhattan in about 36 hours. The parts are here, a day early in typical DigiKey fashion. Now it's time to start burning some flux. Before I do, though, here are a couple of quick photos from the unpacking process.
The virgin board. I have a pair of these to solder, with at a guess maybe 3-4k SMD pads each. It looks like I won't be seeing much daylight for the next week or two.
If you've ever wondered what $2k in DigiKey parts looks like, wonder no more. Not all that impressive on the surface, eh?
Finally there is some positive progress to report on the latest ORB. The circuit boards have been designed and ordered (thanks, as usual, to Shane @ GoldPhoenix) and the CNC milled aluminum circuit board supports are completed and in hand. Many thanks to David Gotter (bio) and Rob Klaus of D&R Machine for their excellent work and patience in helping me through my first design for CNC fabrication. Check out David's other project, Further OPTIONS developing "innovative vehicle entry systems for wheelchair-bound individuals". D&R offers extremely capable and affordable machining services and is open for long-distance business via Internet and mail order. Contact them for your next project.
I'm also very excited to say that this piece has become a three-generation project. In addition to my collaborator and father, Ron Sears, my grandfather Jim McCoy is contributing his masterful woodworking and finishing skills to this project. Everything is in line for a beautiful piece.
This week, my biggest test thus far will begin: a massive soldering undertaking centering around 320 surface mount RGB LEDs, and a matching 960 resistors in 0201 packages. That's 0.024" x 0.012" for those of you keeping score at home. In addition, the design utilizes sixteen 80-pin PIC microcontrollers and a slew of other circuitry. If I can still focus my eyes well enough to see the audience at thesis week, I'll call it a victory. Starting later this week, when the parts and boards arrive, I'll be posting photos and possibly video of the assembly process right here on this blog.
For now though, here's a peek at one of the pair of aluminum board mounts fabricated at D&R Machine. There's much, much more to come, culminating in an initial exhibition at the ITPThesis Week and Spring Show, on May 3 and May 8-9, respectively.
I was doing the first of many parts orders from DigiKey, a massive online supplier of electronic components, for the semester, and finally decided to make an OpenSearch plugin for Firefox. This lets you search for DigiKey parts from the search bar in the upper-right corner of OpenSearch compatible browsers. I've only tested this in Firefox 126.96.36.199, and I'm pretty sure that it won't work in IE7 (surprise!) because IE7 doesn't support POST requests for OpenSearch plugins. Get Firefox.
The format for creating these plugins is a very straightforward XML file. You can find the docs on how to create your own on developer.mozilla.org.
NOTE: This plugin is in no way supported by the Digi-Key corporation. Please do not bother them with help requests if it doesn't work properly (probably because you are running IE). Contact the author with any questions or problems - at which time I will probably just tell you to Get Firefox.
Posted on January 22, 2007 1:35 PM
Top|Share this story:
December 26, 2006
The Orb Makes the Virtual Rounds
Since the warm reception at the ITP Winter Show The Orb has been getting a good amount of attention around the blogosphere. Here are some of the mentions of which I'm aware (in rough order of appearance):
Posted on December 26, 2006 2:09 AM
Top|Share this story:
December 17, 2006
With 7 hours and change to spare, the Orb is ready for showtime...
Posted on December 17, 2006 6:32 AM
Top|Share this story:
December 13, 2006
Position sensors are active and the PICs are timing — we have control. The fully interrupt-driven PIC C18 code is not yet displaying bitmaps, but simple algorithmically generated patterns are displaying easily at no less than 260 pixels per revolution (in the bottom pair of images with the blue and green grid, each vertical line corresponds to 10 angular steps). The position sensors for each side are slightly misaligned, which is causing a convergence problem in the interlacing, but that will be a quick fix by simply moving the hall effect sensor on one side or the other. On a brighter note, the simple firmware is doing a relatively good job of adjusting for a wide range of operating speeds. The display looks best at the full rated motor speed of around 1600 RPM, but the wiring needs more securing before it can run continuously at that speed.
Up next is creating code to save and read bitmaps (and animation) to and from the flash memory for full control. In the meantime, here are some photos of tonight's work:
Posted on December 13, 2006 4:27 AM
Top|Share this story:
December 12, 2006
Spinning (with the governor on)
The wiring is mostly in control, and with a speed control on the drive motor keeping the revs reduced, everything appears relatively stable. A little more checking, cleaning, and tweaking and hopefully we'll be at full speed soon. Then it's on to position sensing and beyond the test patterns.
Posted on December 12, 2006 2:38 PM
Top|Share this story:
The LED wiring is complete — no spinning until they are tied down tomorrow morning.
Posted on December 12, 2006 2:40 AM
Top|Share this story:
December 11, 2006
The Orb (working title) Glows
Steady progress on the Orb (still looking for an official title — Orbital is the current favorite). Here's progress from installation of all four logic boards along with the pair of power filtration boards, through 25% illuminated. This is all just with simple test patterns, no real programming yet.
Here are some photos from the last few days of development on the 3D display:
Bending of the laser cut plexiglas strips into the rings that hold the LEDs around the custom form, also laser cut from MDF
Mounting the plexiglas ring on the frame
One of the first tests with the plexiglas ring installed. Runs perfectly and looks incredible even with no LEDs
The pair of power filtration boards are installed, along with a pair of incomplete logic boards for physical testing
Fine pitch TSSOP deadbug work. Unfortunately, soldering the leadless CASON package took some practice, and in the meantime everyone ran out of stock. So the choice came to either shrink the memory capacity (and the corresponding animation length) or to handwire a TSSOP in its place. Clearly the latter was the choice. Yes, there is a TSSOP-28 Atmel DataFlash hiding under the left side of that pile of wire.
Posted on December 10, 2006 2:13 AM
Top|Share this story:
December 9, 2006
City Streets, Northern Lights Installed at NYU's Kimmel Center
The location on the second floor provides at once an intimate environment for enjoying the piece from the student study lounges and good sightlines for viewing from the entrance lobby as well as from outside the building from Washington Square Park as well as Laguardia Pl.
City Streets, Northern Lights is on loan to the Kimmel Center for an undetermined period of time.
Posted on December 9, 2006 2:20 PM
Top|Share this story:
I'm pleased to say that the programmer setup was effortless and problem-free, paired with an Iogear GUC232A USB-Serial converter. Along with the student (free) version of the Microchip C18 compiler, I'm fully set up for hotel room PIC development on the MacBook Pro.
Now it's time to go stuff my soldering iron into my suitcase. See you all again from across the pond.
Posted on November 29, 2006 1:58 AM
Top|Share this story:
November 18, 2006
Orb: First glimpses
I'm back in St. Louis (Jersevyille actually) and just got to see the frame for the Orb for the first time about an hour ago. It looks fantastic. Here are a couple of photos. I can't wait to start putting the pieces together. The red and amber streaks are just a pair of LEDs rotating on the frame in 3D space. 64 tri-colors addressing somewhere between 16k and 32k points in space should be pretty mindblowing.
Posted on November 18, 2006 3:16 AM
Top|Share this story:
November 12, 2006
The PCBs for the 3D spherical display are in, and here's a sneak preview of the beginning stages of assembly:
As I get farther into the assembly process (the entire system will use four identical copies of this board) I will attempt to get some action photos detailing my surface mount soldering process. This is my first time soldering a .5mm pitch QFP package (the PIC18LF8722) and I was pleased to find that it wasn't bad at all. The only remaining question mark then is the 8CASON package of the 64Mbit Atmel flash memory (shown at left upside-down next to its final home). It fits an SOIC-8 footprint, but with no width to spare, and it is a leadless package, so there is no pad or lead for me to solder with my iron. I'm optimistic about soldering it with ITP's rumored hot air station, so hopefully tomorrow you will be seeing photos of at least one fully completed board and one smiling student, and maybe a hot-air soldering tutorial from a rookie's perspective.
Otherwise, all is proceeding well. Here's a preview shot of the fantastic frame and support mechanism that my father is currently crafting for the project. This photo is a few days old, and the piece is coming along great. We should be starting to put all the pieces together within the next few weeks. Stay tuned...
I should also mention that I am trying Kester 331 Water Clean flux and the matching solder for the first time and it is incredible. At the first impression at least, soldering is just as easy as with the standard 44 flux/solder that I have been using for years, but the flux residue comes off the boards with a hot water rinse almost instantly. It's far easier to clean 331 with hot water than it is to clean 44 with acetone and alcohol, and obviously much more appropriate to do so in my apartment. I highly recommend it. Of course it is still leaded solder, so don't forget to wash your hands.
Posted on November 12, 2006 3:23 AM
Top|Share this story:
November 5, 2006
PCB Tools Overview
Michael Ang and I are teaching a DriveBy at ITP on Monday the 13th about electronics without breadboards, which is to say PCB design, production, and surface mount soldering. In the meantime, I thought I'd give a quick overview of my toolchain from PCB design to production. More details to come, both at the DriveBy and on this site. But for now...
The freeware version of this package lets you draw boards up to 4" x 3.2". It's a great package, with solid part libraries, and good functionality to easily add your own custom patterns. It's equally at home with surface mount or through-hole designs, and it's the tool we will focus on at the DriveBy.
There are a few quirks to the interface that take some getting used to. First, in order to act on a group defined by the Group tool, you need to right click. On the Mac, this is substituted with a command-click (Make sure 'Emulate three button mouse' is active in the X11 Preferences). So to move a group of items, group them with the Group tool, then switch to the Move tool, command-click, and you're off.
Secondly, the Copy tool oddly only works with single items. To copy a whole group, you first use the Group tool to select them, then switch to the Cut tool. Command-click (note that this doesn't cut in the sense that Windows users are used to, but actually is more like copy), and then switch to the Paste tool to lay down the copy.
The next stumbling block is getting your files exported in the right format to get PCBs manufactured. Virtually always this means Gerber files. Here is a good tutorial from SparkFun about this. For my recent project, a 3D dimensional spherical surface display (PCB shown at left), I actually used the .cam file from the tutorial to do my export. The job is still processing, so we'll see how it goes.
For my last few projects, I have used Gold Phoenix PCB for production, and have been very satisfied with the service. They can go down to 4 mil trace/space (for an extra fee), and also have cool extras like colored soldermask (also for an extra fee), and a good expedited service (also for an extra fee - surprise?).
The special at Gold Phoenix typically is for one board of around 1 square foot. This means that, since the free version of Eagle can't handle designs over about 3"x4", we need a way to combine multiple designs after the fact into one panel.
GerbMerge to the rescue. This is a Python app that takes the Gerber files exported from Eagle and combines them into a single design using random placement to find a near-optimal layout.
It requires mxBase 2.0.4 and SimpleParse to install. Once installed, you control it using a configuration text file, which you have to customize to the specifics of your project (filenames, number of copies of each board, etc.). There is a sample configuration file in the documentation that will help you get started. Here is mine from this last project, if it might help.
Finally, once your boards are designed and panelized, you will want to take one last look at your files to make sure that all is correct before sending them (and your money) off to have the PCBs fabricated. There are a number of ways to accomplish this, but my favorite of the moment is gerbv, an open source package created specifically for this task.
There is a Windows port linked from the SourceForge page, but for Mac, the easiest way to get it is through DarwinPorts. It grabbed a whole list of dependencies for me completely seamlessly. You will have to add /opt/local/bin to your path if it isn't already included, though.
When it is all installed you can run it with the files you want to see as command-line parameters, giving you a view of your output files like the one shown here.
This skips about 99% of the process of designing a board, but hopefully will be helpful in getting some tools setup and being able to start playing. Again, the DriveBy on Monday the 13th will cover this and more in more detail, so come with your questions or feel free to post them in the comments to this entry.
Microcontrollers (in this case PICs) programmed with identical code. Physicality (pin layouts, etc) may differ from node to node within certain restrictions.
The network uses the standard RS-232 serial protocol for data transfer, with the addition of a proprietary signaling system that uses the same wire to send ready-to-send, ready-to-receive, and receive-success messages. Each packet consists of the target node address, the address of the sending node, the hopcount, and a four byte payload.
Data is transfered serially using a wired connection.
In the protocol, locations are specified by an eight bit address, allowing up to 255 nodes. In the current hardware implementation, however, the nodes are addressed at boot time by hard-wiring four pins of the microcontroller, thus limiting the network to the four low-order bits of the address, or 16 nodes.
The stack for this implementation is very simple, as (using the Internet comparison) only levels up to and including the IP level of the stack are included. A TCP-like protocol could be constructed atop this stack, and then any desired application protocols further atop that protocol. As it stands, however, the network implements:
[End to end addressed packet transfer]
[RS-232 plus additional signaling]
[TTL logic I/O]
Each processor in the video is connected to a set of three LEDs, enabling the viewer to see network traffic in process.
Red -> Node is transferring data
Yellow -> Node is receiving data
Green (in combination with Red or Yellow) -> Transfer / Receive succeeded
Blinking green and yellow -> Packet arrived at ultimate destination
Each node has a local address (in this case, 0-5). Each node can then send a packet of data to any other address in the network. The transport protocol is simple (and unreliable) and consists simply of handing the packet off to a random node, attempting first to connect to any node which is not the source of the data. Thus if node 0 sends a packet to node 4, if the packet is not addressed to node 4, node 4 will attempt to pass the packet on to any node connected to it that is not node 0. If this fails, it will pass the packet back to node 0.
The video shows 5 packets being sent from the lower right node of the network to the node in the upper left corner. This shows the variable routing and a few of the possible routes a packet can take in the process.
The network was designed to be a lowest common denominator of mesh network design - a basis for possible future development. As such, it is a success. With a limited number of nodes, packets move from point A to point B in a reasonable number of hops, but it is clear that a good deal more work would be in order to develop a scalable network.
Fig. 1 - Schematic of TX/RX circuit
The network consists of PIC microcontrollers communicating via RS-232 serial with the addition of the ability to use that same data line for signaling from the recipient both of ready to listen and data received signals. This is achieved using the circuit shown in Fig. 1. The transmit pin for each data line is connected via a resistor to a second pin of the microcontroller which is configured as an input. Then this second pin is connected to the receive pin of the remote device. Then when a node wants to transmit, it asserts its TX pin high, which also raises TXACK and RX to high through the resistor. Then, assuming the there is a remote device connected that is not busy and sees the signal, it asserts its RX pin low, which pulls the TXACK pin on the transmitting device low as well (the resistor prevents an over-current between the two driven outputs). The transmitting device sees this ready signal, waits a specified small amount of time for the receiver to enter listening mode and then sends the data. After the data is sent a similar exchange takes place to confirm receipt.
Routing takes place via an extremely simple protocol. Each device can be connect to as many as three other devices. These connections are sensed each time a packet is sensed via the protocol described above. When a packet originates, it is sent randomly to one of the three possible connections or the first one that successfully receives it. If the packet is not at its ultimate destination, it is forwarded to another random node, with precedence given to nodes that are not the node from which it was received. This prevents two node looping. Even this one simple rule provides an enormous reduction in hop count over a purely random scheme and creates a somewhat usable, if poorly scaling, network.
Fig. 2 - Probabilty calculations for arrival in 5 hops or less across 6 nodes
As you can see in Fig. 2, for one particular simple six node topology, the probability of a packet arriving from one extreme of the network to the other in 5 hops or less (without making a loop) is 75%. In Fig. 3, two nodes are added, and while the similar case (no loop) entails only one more hop, delivery only succeeds within six hops 56% of the time.
Fig 3. - Probabilty calculations for arrival in 6 hops or less across 8 nodes
On the other hand, in the six node example, by tolerating a single loop which allows up to 9 hops, the probability of success increases to 93.75%, which can be seen in Fig. 4. Analysis of the eight node example quickly becomes difficult because of the greater number of combinations of loops, but it seems that allowing one loop (up to around 12 hops) increases its chances of success to around 78%. Time permitting, computer simulation would allow a better analysis of larger networks of this type.
Fig 4. - Probabilty calculations for arrival in 12 hops or less across 8 nodes
I did not have a specific numeric estimate of performance prior to construction and analysis, but the six node network performs somewhat better than I expected and the eight node network somewhat worse. This horrendous scaling could be improved with a topological shift to a small world system, where a number of these meshes could be connected together via specifically designated router nodes with the address space configured such that it can be deduced from the address whether a packet should stay within a subnet or propagate onward to another. The relative success of the mesh with small-scale networks suggests that this could be a workable solution, although the benefits over a more standard non-mesh topology are dubious given the rudimentary routing system.
The routing system itself could be improved if the size of each subnet remained relatively small by implementing a backpropagation system, wherein each packet was tagged with the address of each node through which it passed. Upon receipt of the packet, this information could be sent back to each of the nodes that were involved in the original transaction, and the hopcount of the outbound and inbound packets could be compared with any hopcounts of previous steps that were stored in memory to, over time, find an optimal next hop to reach any node in the network. This activity may need to be limited in order to balance the risk of flooding the network with optimization messages with the desire to adapt quickly to changes in topology.
After this first foray into mesh networking, I must say that I am pleased at the results of the basic implementation and would like to spend more time in the future to investigate and experiment with various learning schemes that could improve performance and scalability.
Posted on October 17, 2006 4:07 AM
Top|Share this story:
October 11, 2006
Read Modify Write Errors (Why the **** aren't my LED's blinking right?)
This is an issue that I have encountered on virtually every PIC-based project that I have ever worked on. Trying to do something possibly as simple as turn a series of LEDs on at a time becomes a frustrating exercise in futility. Why?
It has to do directly with how the PIC modifies an I/O port when you set a pin individually. (NOTE: this may not apply to all models of PIC hardware, but I have encountered the effect in a wide variety of PIC devices).
When the PIC sees a command such as
it actually must read the entire PORTB from the pins into an internal register. This happens regardless of whether or not the pin is configured as an input by the TRISB register. Then it modifies bit 0 in the register and finally writes the entire byte from the register out to the I/O port.
Doesn't sound so bad, right? Well usually it's not, unless you do something like:
In this case with an LED connected directly from the PIC pin to ground, when the PIC reads PORTB from the pins, it reads the voltage across the LED, because that is what is connected directly to the pin. Unfortunately, depending on the color and exact makeup of the LED, this voltage will be anywhere from 2-4V, because the current through the LED is limited by the PIC to around 20mA (which is a good thing unless you like the smell of burning silicon).
In the worst case, with a typical red LED connected, the pin voltage will be in the neighborhood of 2V, which is low enough to be read by the PIC as a zero at least part of the time. This leads to a situation where if you were to execute a block of code like
it's quite possible you will end up with only the LED on PORTB.2 turned on, since when the second HIGH statement is executed, pin B0 might be read as low and then get re-set to low, even though that clearly is not the intent of the code.
So what can you do? The simplest (and probably most correct) thing to do in this case is to simply add a resistor to limit the current through the LED external to the PIC. This means that the full 5V from the power supply shows up on the PIC pin, ensuring that the PIC will keep high the pins that are supposed to be high
This effect can also occur if there is a capacitive load on the pin, which can in some cases mean just excessively long wires, or a capacitor of course. The likelihood of this increases as the frequency of the signals gets higher.
This leads to another potential approach that I have used with good results (actually it's how the PIC running at 40MHz is operating with 32 channels of firmware PWM in City Streets, Northern Lights). This alternate approach is to leave all of the port pins set high (PORTB = %11111111), but to use the TRIS registers to turn the outputs on and off. In many cases, making a pin an input is effectively the same as driving it low, and this certainly works in the case of LEDs.
This means the above sequence of turning three LEDs on consecutively would look like this:
LOW TRISB.0 ' note that making TRIS low makes the pin an output,
' driving it high -- don't forget to invert your logic
The situation/solution is the same if you are coding in PICC or even PICASM. My understanding however, is that the AVR that is the core of the Arduino uses an internal shadow register that eliminates this problem, although I haven't checked it firsthand. You can also perform this function manually in the PIC by declaring a variable that acts as a stand-in for the PORT register. You then modify this and write the entire byte to the port manually, like this:
shadowB var byte
shadowB = %00000000
PORTB = shadowB
PORTB = shadowB
PORTB = shadowB
PORTB = shadowB
Being the most complex, this is the solution I use least often. Typically I make sure my outputs are isolated with resistors and then use the TRIS method if I am doing something high speed, like PWM or capacitively loaded.
Hopefully this makes a little sense of some of those random problems that plague your breadboard from time to time.
Posted on October 11, 2006 9:42 PM
Top|Share this story:
August 26, 2006
City Streets, Northern Lights
We just launched a new website for my father and his artwork at ArtMagnitude.com. Our work was very well received during exhibition at ITP's Spring Show and Summer Gallery and we are now seeking opportunities for sale or further exhibition of the piece. For more information, contact firstname.lastname@example.org.
Posted on August 26, 2006 9:40 PM
Top|Share this story:
April 11, 2006
Northern Lights Demo Applet
For Living Art and Nature of Code, I am working on a simulation of the Northern Lights with Anne Hong for an art piece (introduced in this post) by my father, Ron Sears. I have mocked up software using Java and the Processing libraries to start experimenting with algorithms to control the light. The applet is based upon a simulation of 32 fixed color high-output LEDs arranged on 4 PCBs that will be mounted behind a large plexiglass lens inside a frosted streetlight globe (simulated with a gaussian blur in the applet), and uses a combination of trig functions with varying relative phase to approximate the dancing effect of the Northern Lights.
The code has been developed with portability to PIC C in mind, using lookups into a 1024 point quarter-wave 8-bit rectified sine table instead of real-time trig computation in order to save processor time with the intention that the simulation can run along with interleaved 32 channel PWM control on a single PIC18F4520 running at 40MHz.
Posted on April 11, 2006 3:11 PM
Top|Share this story:
NIME - Performance Plan
For my Chua performance I intend to use my analog chua circuit, with an X-Y interface made of slide potentiometers along with the variable inductor I have constructed previously. On the display will be the analog oscilloscope output, possibly processed with Max/Jitter.
Sonically, I envision the performance to start out very slowly, with solo Chua starting with quiet, simple, near-sinusoidal oscillations (near-circles on the display). Gradually the sound will get slightly more chaotic but still dry, and a simple electronic beat will enter. The Chua will stay dry for awhile, but as a bit of synth is added into the beat, effects will start to be added, opening up the stereo effect and adding a bit of delay. This will gradually build to a climax, which will be full on chaotic Chua with a bass enhancer shifting material down to the lower octaves and getting a very intense rumble in addition to the chaotic top end. At an appropriate moment, this will give way to dry simple near sinusoidal Chua with beats. The beat will stop, and then the Chua wave fades away.
Posted on April 11, 2006 3:02 PM
Top|Share this story:
Posted on February 7, 2006 9:45 PM
Top|Share this story:
February 2, 2006
My Original Chua Project
Back to where the madness all began. I just found this link to the first project I did involving Chua's oscillator as an undergrad in 2000 at the University of Illinois Urbana-Champaign with Morris Chukhman, who at the time was a graduate student in mathematics, for a class on the physics of electronic musical instruments taught by Steve Errede.
We succeded in building an analog implementation of Chua's circuit, learning about the details of the required components and where non-idealities were not acceptable. We then experimented with combining the circuit with traditional digital effects as well as perturbing the system with the output of an electric guitar, as in the photo. These sessions produced the recordings which led to the use of the system in my sound design project at SIUE with Nathan Ruyle.
Posted on February 2, 2006 9:35 AM
Top|Share this story:
January 30, 2006
Simulating the Auroras - UCalgary Research
This work from the University of Calgary outlines a scientific approach for simulating the visuals of the Aurora Borealis. It is too computationally intense to run on PIC hardware, but the procedure can probably be simplified somewhat or else possibly it can run on an embedded PC system that talks to a PIC which controls the LED drivers. In any case the site, and particularly this Technical Report, is a good starting point and source of info about the simulation.
Simultated images of Aurora Borealis
Posted on January 30, 2006 12:37 PM
Top|Share this story:
December 24, 2005
Vibrato - Touch Sensitive Musical Instrument
Vibrato is the final project Anne Hong and I did for Physical Computing last semester. The photo at left shows the layout, seven tubular illuminated keys, with linear proximity sensors that detect the position of a finger touch anywhere along each tube. By touching the key anywhere along its length, the user plays a corresponding note of the music scale, with the octave depending upon which third of its length is pressed. Subsequently, the user can slide the finger on the key to perform pitch bend or vibrato effects.
The sensors used were Quantum QT401 linear touch sliders on custom designed PCBs embedded within each key, with 3M Photographic tape used as the required resistive element. A 12" piece of the 3/4" wide tape has a resistance around 75k-Ohms, perfect for this application. More details are available on the project site.
Upon further refinement, the project has been requested for display in ITP's Spring 2006 Show.
Posted on December 24, 2005 6:57 PM
Top|Share this story:
Welcome. I have started this site for myself and others as a memoir of my trip through life and, for now, the Interactive Telecommunications Program experience and as a place to log the ideas and thoughts that otherwise seem to slip away. I look forward to comments and criticisms, helping and being helped, and whatever else comes my way. Life is good.
For decades, musicians have been experimenting and working with electronic synthesizers to generate sound. In some cases the reasoning is logistical - often it is prohibitively expensive, for example, to haul a heavy and expensive piano or organ to a venue. Many times, however, the goal is creative expression in the generation of new and previously unheard or unharnessed sounds. Chaotic oscillators, including the example discovered by Leon Chua, open the door to a new universe of sonic possibilities.
Chua's oscillator is a system described by a set of three differential equations that can be realized either in digital form or in analog form using opamps and passive circuit components, simple in appearance, but extraordinarily complex in its analysis and behavior. In the video, you are listening to two of these three signals, at first from Chua's circuit acting alone, and later from this same circuit used similarly to a module in an analog synthesizer, acting through effects and with varying levels of this effected signal feeding back to further perturb the behavior of the oscillator. The video is a phase plot of the two dry (non-effected) signals from the circuit (one moving the display beam left and right, and the other up and down) on an analog oscilloscope.
The sounds from Chua's circuit are widely varied, ranging from pure sine waves to almost pure noise, with many varied behaviors within. Period doubling and intermittency effects can be particularly useful from a sonic standpoint, especially when processed through appropriate effects, such as delays, reverbs, resonant filters, ring modulators, and pitch shifters. A suitable control interface for the many parameters of the oscillator and effects system is necessary for full realization of the sonic potential of chaos.
This system found extensive use in a sound design for Marisol at Southern Illinois University at Edwardsville and was received with very positive responses from critics, audiences, cast, and crew alike. The eerie sounds generated by the combinations of chaotic oscillator with effects fit the bill perfectly to accent the dark, apocalyptic tone of the play, but certain ranges of the system's behavior and combinations of effects, and possibly even by utilizing different chaotic systems, can produce sounds with a wide and emotionally expressive variety.
Future opportunities in this area of research include mapping the system's parameter-space behavior (the complexity of which is astounding - consisting of fractal-like clouds of points where various behaviors take place), using this information to develop new methods and interfaces for control, the use of gyrator circuits to lessen the expense and simplify control of the circuit's reactive elements, investigating the effects of various feedback loop effects topologies, the use of multiple interacting systems to create further sonic variety, implementation in digital form (which could reduce cost and potentially simplify many control problems, likely at the cost of fine nuance in the behavior), and similar investigation of or exploration for other suitable chaotic oscillator systems.
Below are a few pictures of the phase plots of the Chua circuit's behavior. Click on the picture to hear an audio sample of the sounds of chaos. Note how at the end of the series, the stable attractors that appear as the variable inductor (pictured at right with circuit board) is increased decrease in pitch roughly with the musical scale. This is inherent to the behavior of the system - these four stable tones are like islands in a sea of chaos as the value of the inductor is changed - and while these islands don't always align the intervals with our musical scale, behaviors like these could still be valuable in harnessing the system musically.
Photos (click image to hear mp3 sound clip):
The next seven pictures and sound clips illustrate the musical tune of the Chua's stable orbits as the inductance is decreased, and the chaotic behavior between these orbits. The tuner software has been calbrated to F3 = 92Hz, but I believe that the base frequency of this behavior could be tuned by changing the capacitances of the circuit.
The plots below are from a MATLAB simulation of the chua oscillator system. X and Y directions each correspond to varying a particular parameter of the system and the Z direction (represented by height and/or color) is a calculated value that reflects the level of chaos in the waveform by measuring the spread of the frequency distribution of the signal using an FFT and additional mathematical processing of the frequency spectrum..
Higher values of Z (brighter colors and/or higher altitude) indicate that the output power is spread among more frequencies, which is indicative of the onset of chaos and corresponds to more harmonics and/or more chaotic noise in terms of audio output. Lower values of Z indicate simpler tones, to a minimum of 1 when the signal is at a single fundamental frequency or 0 when there is no AC signal, as in the case when the system comes to rest at a steady-state (DC) solution.
The graphs act as a map to the oscillator's behavior. Within a simulator, or with the parameters scaled to real-world component values in a hardware implementation, they should allow one to pick a range of behavior and find combinations of parameters that fulfill the requirements.
Click the pictures to enlarge:
Posted on December 25, 2004 11:00 AM
Top|Share this story: