The Conference Panel Part 4: Construction

The story so far:
Part 1: taped down some LEDs and learned how to code with Arduino.
Part 2: tried some ideas for construction and geometry.
Part 3: worked out the design for the Mark I.

Time to dive into some actual physical construction

The main strength of this build comes from a GatorBoard back and base.
For those unfamiliar with GatorBoard, it's a very strong foamcore  board with a hard, dense card cover. I've built some very large structures out of the stuff - love it.

The Lighting Channels

The card-stock channel dividers worked pretty well in the proof-of-concept model, so I'm going with that again.

Step 1: Jigs

I constructed this compass out of scrap GatorBoard with a bit from a plastic bottle for the center pivot. I put a thumb tack through the pivot hole in the plastic and a pencil or knife in the marked holes.

Step 2: Drill for the LEDs
Instead of just taping the LEDs to the surface, I'm actually drilling art board for the LED mounts.
A 1/2" Forstner bit makes nice clean holes.

You can see the GatorBoard backing in this photo

Step 3: Carefully cut and score a a few dozen pieces of card stock for the dividers.

Assemble those into pairs so we have double-sided walls with a nice base for gluing.

Step 4: Assemble the lighting channels
The hot-melt-glue and packing tape of the previous model led to a lot of wrinkling. To make sure everything lies flat, I'm using a Scotch adhesive dispenser.

Six hours later, the channels are framed up!

Construction front to back:

Layer 1 (planned), Front Face: 1/8" diffuser material for top half-disc. 1/8" Plexiglass for bottom strip.  Ribbon display is mechanically connected to the face.

Layer 2: Channels: Card stock and art board. 1-3/4" tall. Board is drilled for LEDs, card stock is glued to  fiberboard and itself.

The base is notched so the "channels" layer keys into alignment

Layer 3: LEDs and cable runs: The actual LEDs are plugged into the back of the art board. 2 inches of foam add some depth to the unit and leave room to route the LED wires.

Layer 4:  Back plate. 1/2" GatorBoard. Connectors for the remote "buzzers" will be mounted here.

The whole top half sandwich is held together by two large nylon bolts so it can be disassembled for repairs and upgrades.

Base:

Everything but the main display LEDs is jammed into the base:

• Power Supplies (A 10amp 5v supply for the lights and 100ma supply for the electronics)
• Ribbon display (a bunch of Adafruit's 8x8 bicolor LED Matrix with I2C Backpack)
• Arduino
• "Buzzer" hookups ("Tool-less" Ethernet jacks from MonoPrice)
• Audio circuits

I plan to wrap the whole thing with a 4" strip of corrugated plastic to add stability and give the whole thing a little cushioning for durability.

Electronics: The Arduino,  operator display and remote button jacks all live in the base and are connected to the back plate.

All the parts I have assembled so far actually fit in the base. (The upside of measuring first.) But it's really tight. I may hollow out the unlit center cell and put the Arduino and related boards up there.

Next up:

In part 5, I will be focusing on the game show features. I'm hoping to get the two team displays and buttons finished. Hopefully with sound effects.
Stay tuned!

Conference Panel Part 3: MATH!

In Part 1, I taped down some LEDs and learned how to code with Arduino.
In Part 2, I tried some ideas for construction and geometry.

In Part 3, It's time to build an actual prototype.

As I get ready to cut and drill material, it's time for a layout.

The "guestimated" layout worked pretty well, and I learned some important things about the geometry of the structure.

Geometry:

The light cells are demarcated by the dividers, not the LEDs.
A "shared" 0,0 point just adds CPU cycles and significant code space to calculate the color of the cell. Either skip it entirely or let it mix naturally from the neighboring cells.
With 50 LEDS on the double strand, 10 spokes of 5 LEDs
And with no LED in the center, that makes 6 cells per spoke,

I want each cell to have about the same brightness.
The LEDs put out a cone of light 120° wide...  A little inverse-square for the falloff, figure in the reflectivity of the card material...
That's going to be one heck of a mathematical model.
I just need a relative width for the each ring.
Calculating the difference between the area of the arc for outside boundary and the inside boundary would give the area, but maybe there's an even simpler way?

10 spokes is dodecagon. Close enough to round for estimation purposes.

If each spoke is 18° wide (180° divided into 10 spokes), how do we calculate the area of a given cell?

Let's split the 18° isosceles triangle into two 9° right triangles.
Area = 1/2 × r1 (height) × b
And since that's only half the full 18° slice, Area = r1 × b.

How do we get b?

"Slope" of 9° = tan(9) = 0.158384440324536
So base (b) =r1 × 0.1584.
And area = r1² ×  0.1584





My math skills are too rusty to try and solve this multidimensional problem, but that's why we have computers!
I'll just step through all the possible divider positions and determine which configuration has the lowest standard deviation in area.
My first inclination is to just Monte Carlo the model and find a "good enough" solution, but there are a number of assumptions we can make that should make the experiment set small enough to calculate the whole thing.

Assumptions:

• Because the area grows with the square of the radius, no ring can be thicker than its inner neighbor
• Because of the above assumption, no ring can be thinner than the total radius ÷ number of rings

I'm looking for an excuse to practice coding in Python so that's the language I'll use.
You can see the code at GitHub.
Without the optimizations, the program took over an hour to run on my laptop.
With those tests, it took about 28 seconds.
The solution is: [40, 57, 70, 81, 91, 100]
So these are percentages of the radius for each divider to yield a consistent area for each cell.
Let's see what that looks like:

The area-based division is closer to my proof-of-concept model, but the center disc is much larger than I want.

Modify the program to remove the center disk from the calculations and fix its size at 24%, and we get:

Which seems like a reasonable compromise.

Sizes:

While I want to build a bigger display, I also want this to be easy to construct.
Art board and plastic come in 20" x 30" and 40" x 30"sizes.
Biggest power supply is 2-3/8" (60mm) wide
Proof-of-concept model is 1-3/4" deep.

The matrix displays for the base are 1.2" tall. (1.6 with the driver board.)

Transporting the 30" cardboard proof-of-concept was easy. 40" panels are a little too big to comfortably carry around.

This will have to ship or go in checked baggage, so it will need a solid case.
SKB Cases sells an audio mixer case that seems about the right size.
Pelican has a similar case, and flat shipping case that would handle a 40" wide version.
These cases are expensive. Cheapest one would be over $500 with foam and accessories.

I'm mostly concerned about crushing damage, but lightweight case might be adequate.
Philly Cases has lightweight plastic case  with plenty of room for about $200.

So a good transportable size is 32 to 36 inches wide.
Next build will be 34" wide (17" radius) with a 2.5" base yielding a height of 19.5 inches.

*UPDATE*
Yeah, Yeah... Since I only need the ratios of the radii, I didn't need to calculate the are of the wedge. I could just use the whole circle instead with the old π r².

2013 Predictions

I was quite ill this time last year and so didn't get my annual prediction post up.
Here we go for 2013!

Google

Google Glass

Google Glasses will dominate the presentations at Google IO, although developers won't actually have their samples.
There will be no retail product in 2013.
Mobile connectivity will prove to be a problem. We can't all have a team of people with parabolic WiFi antennas, so using the glasses "in the wild," will  be of limited appeal.

Google Fiber

Google will fully provision the Kansas City "fiberhoods" months ahead of schedule and hold a second round of neighborhood sign-ups.
They will announce the next two cities to get Google Fiber with registrations opening up 2014.
There will be solid rumors, but no announcements, of a Wireless service from Google.

Social

Google Plus will continue to be popular with the nerd crowd, but make little progress against Facebook.
Google Search will announce a new deal allowing better coverage of Facebook or Twitter.

YouTube

The "channel" model and algorithmic curation will prove to be unpopular with viewers, and before the end of the year, YouTube will be restructured around individual shows and personalities.
Even though I predicted it years ago, and I've been wrong, I still think YouTube will pick up a cancelled TV show. I think it's much more possible this year now that NetFlix has picked up Arrested Development. It will be a challenge to find a traditional television show that can operate within a new media budget, but it will eventually happen. Why not this year?
We will see new YouTube apps for set-top devices, televisions and possibly a dedicated YouTube box.

Apple

No Apple Television

Broadcasters will not play ball and Apple will not be able to put together the licenses needed to launch the television product in 2013.

iPhone & iPod

Apple will drop the iPod nano and introduce two new form factors for the iPhone. One of which will asymmetrical.
Apple Maps will continue to be a sore spot.

Microsoft

Windows 8/RT

RT will be a retail disaster. Consumers will buy a "Windows" product that doesn't have windows and that doesn't run existing Windows software.
Enterprise will ignore Windows 8 for years. For companies that finally moved off of Windows XP, Windows 7 is working fine.
Windows 8 will be very popular on laptops.

Hardware

Next gen console will be announced and demoed. Shipping in 2014.
Surface tablet will be discontinued. Other hardware manufacturers will be reluctant to make their own versions.

Facebook

I've been wrong many times predicting a flattening of Facebook's growth.  So let's just assume it will continue to grow...
Facebook will buy a media production company to create proprietary content for Facebook members.

Transportation

Electrics

No significant increase in sales of electric and hybrid cars in the US.

Autonomous Vehicles

Most states will have laws on the books allowing autonomous vehicles by the end of 2013.

Crazy-Ass Wildcards

• Makerbot Industries or another 3D Printer company will open a store in The Mall of America.
• Turnips will be the next big food trend.
• 50 Shades of Gray will finally fall from the Amazon Top 10 list.
• Another popular dinosaur will be removed from the official list.
• SpaceX will announce a launch date for a manned moon orbit mission.

Arduino Project: The Conference Panel Part 2

In this Part 2, of The Conference Panel project, I'll look into the actual geometry of the LEDS and ways to shape the display.

"Sign Expo #26 - Untitled" by KarmaBlue

Laying out the bare LEDS gave a diffused light with ill-defined edges. Inspired by an art deco lamp and the "cans" used in channel letter neon signage, I added reflective dividers between each lighting segment.

Arduino Project: The Conference Panel

This year, I attended Nerdtacular in person, and the NSFW show at DragonCon via live stream.
These events had audience voting in the form of sound. I remembered when I was a kid, on TV they would often put a camera on a VU (Volume Unit) meter to show just how loud the audience was.

I think they quit doing that for a number of reasons:

"VU Meter" by Iain Fergusson

• Most of the time, the meter just pegged so no difference was detected
• Big hassle for the sound guy to set up another microphone and mixer send
• People closer to the microphone would have a bigger "vote"
• Black needle on a white face not very telegenic
• As we moved to digital technologies, an analog VU meter looked old-fashioned

But some sort of SPL (Sound Pressure Level) meter would still be handy for these events.

I've also been looking for a project to learn more about Arduino.

So I sketched out the initial design for The Conference Panel.

If the project works, it would be used at these conferences to simplify some of the show mechanics.

Design goals:

Basic Features:

• Big and bright enough to be seen by the audience in a hotel conference room
• Small enough to sit on a panel discussion table or hang from a lectern
• Light enough to hang from a booth wall if needed
• Durable and shippable
• Single power cord (and optionally battery powered)
• Based on regular Arduino Uno

VU Meter Features

• Built-in microphone
• Fast VU meter display
• Self-calibrating SPL meter

Game Show Features

• Buzz In mode with lockout
• Answer clock
• Simple show host controls
• Sound effects
• Wheel of fortune spinner and other random generators

Party Features

• Beer resistant
• Music-synched light display

Home Features

• Webcam light panel with color temperature control
• Deco lamp mode

The Design

I'm treating this like a software project. I want to create a Minimal Viable Product at each stage and iterate over the design.

Physically, I think the final project will be built on a gatorboard back and interior panel with a plexiglass front and a corrugated plastic perimeter. There will be a base where a "ribbon board" display could eventually be attached to the front and which would serve as storage for the cables and buttons.

There are a number of unknown factors that need to be defined for this project to work:

• Can an Arduino drive enough LEDs fast enough to create a clear display?
• How hard will it be to code?
• Given the presumably fast sampling rate, can we slow or average the values into something can be meaningfully displayed?
• What material should be used for the front face?
• Is an Arduino fast enough to sample the audio and drive the display at the same time?

Phase 1

• Get some addressable lights
• Lay them out in a radial fashion
• Write some code to display a VU-style meter.

Phase 1 Goals

• Learn the basics of Arduino programming
• See if addressable RBG LEDs are fast enough to perform the task.

I picked up a strand of Adafruit's Diffused Flat Digital RGB LED Pixels. There are 25 bright "pixels" per strand which are individually addressable via a simple serial protocol.

Then I created a layout that would place the 25 pixels on a big "dial" without cutting the strand.

The blue "pixels" aren't used in the display. But by leaving them connected, I don't need to cut and solder my strand.

To test this layout in the real world, I just eyeballed the layout and taped the strand to a box.

So far, so good!

In Part 2, I'll work on the mechanics of the light and try techniques for creating a clearer display.

Sugru

Recently, the good folk at Adafruit Industries introduced us to Sugru.



Sugru is an air-cured silicon material that's good for lots of things.
I used my white Sugru for fixing a frayed original iPod Touch cable.

There's an allergy warning on the package, and I have no idea if I'm allergic to these crazy chemicals, so I used my nitrite gloves.
The material was easy to form, and the repair is working great!
In fact, I used this repaired cable to transfer the photo from the iPhone for this blog post.

Next time I do a fix on a cable that has connectors where orientation is important, I will use a bit of contrasting Sugru to indicate which side is "up."
Permanent marker doesn't seem to work very well on Sugru, and it will just look cooler to have the color molded in.

I've become one of those Sugru fanatics. This stuff is amazing. Stay tuned for more projects!

Adventures in Python

"6502" (cc) by Blakespot 

I’m an old-school coder.
Cut my teeth on BASIC and FORTRAN.
That was over two dozen languages ago.
Programmed primarily in Assembler for about 15 years.
I’ve dabbled in the dark art of self-modifying Assembler.
I fell in love with the off-putting perl.
Lua and I will always remember that time in Azeroth.
I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched c-beams glitter...

But this story isn’t about the past.

It’s about the future, and Google’s dominion.

Google loves python.
Google runs the Internet.
Best learn to love the python.
There are reasons besides appEgine to learn Python: The Raspberry Pi is designed to teach Python and will be a very Python-centric environment. I’ve noticed a trend with programmers I respect slowly moving to Python from PHP.
I think PHP still performs a valuable role, and that good code can be created in PHP, but I’ll happily acknowledge there has to be a better way.

My dabblings in Python have been limited to modifying the occasional command-line script and attempting to code some XBMC addons.

And I didn’t like it.

I’m assuming this was because there were some basic things about the language that I didn’t understand, and that the framework for XBMC is it’s own gnarly beast.

I even have a real project in mind to test my hopefully growing skills.

So let’s learn some Python!
My favorite computer language book is Advanced Perl Programming http://shop.oreilly.com/product/9780596004569.do

Most of the Python educational materials are aimed at beginning programmers. While reviewing the basics is a good exercise, I’m more concerned about variable scoping, abstraction, and data structures than “hello world.”

Given the title, I thought “Learn Python the Hard Way” would provide a lot of CS context, but it’s aimed an even more naive audience than all the learn-to-program-with-python courses and books. The context has more to do with how to read and type code than syntax and data structures.
I actually did read the entire thing on the web. It clearly explained some basic nomenclature and how projects are laid out.

“Dive Into Python” runs at the right speed, but hasn’t been updated since 2004. So I’ll pass.

LearnPython is current, covers the basics and has advanced tutorials. I don’t think I’ll start there, but it looks like a great reference.


The most promising appears to be the course Google uses to get programmers up-to-speed on Python.
http://code.google.com/edu/languages/google-python-class/

Not pretty. Not simple. Just right!

Google's Python Class

Section 1: Python Setup

I’m doing this on a Mac with BBedit.
Nothing really to do.
Everything worked as expected.
Google recommends spaces instead of tabs for indenting.
I’ve run into this on a number of open-source projects recently.
Again, being old-school, I remember the days when bytes were scarce. It also seems like “hard-coding” to use spaces instead of tabs.
But since it appears this has become a standard, I’ll embrace the space.

Section 2: Introduction

Interpreted - duh, it’s a scripting language.
Loosely Typed - like.
Run-time evaluation - potentially better for security.
Case Sensitive - like.
Newline for statement delimiters - I have no preference.
Indentation matters? I’m intrigued and alarmed. Actually this explains why my earlier attempts at modifying Python code failed. It never occurred to me that changing from spaces to tabs would break code.

Now we get into an actual program file. The traditional “hello world.”
We see an *import*, the main(), and the boilerplate that calls main().
Everything is perfectly sensible except the way main() is called. Seems odd to do it by using a special variable, but I can see the flexibility down the road.
Variables don’t have a delimiter. This makes sense with a loosely typed language, but I love perl’s way of being  able to cast a variable by just using the appropriate delimiter.

Plus sign for string concatenation. Now this I don’t like this for loosely typed languages since it’s ambiguous with addition.

Each file defines a module with its own namespace. This I like a lot.

That was a great introduction! Let’s learn some specifics.

Section 3: Strings

Clear description of delimters and escape sequences. I think this might be a typo:
String literals inside triple quotes, """" or ''', can multiple lines of text.
Perhaps “can contain?”
And here we encounter the most consistent failing of Google. How do I provide feedback on this typo?

Back to the lesson...
Here we learn that there is no automatic conversion of string and numeric values. So that makes the + concatenator a lot more acceptable.

The section on printf-style string expansion mentions using parentheses to span multiple lines. I thought we needed \ to cross multiple lines? I fear this is gonna get confusing...

Section 4: Lists

Bracket syntax is common form for both declaration and indexing. Assignment (=) doesn’t duplicate lists, just creates a symbol table pointer. While I like this, I’ve seen many inexperienced programmers spend a lot of time tracking down problems related to having two variables point to the same object.
I wonder what the Python equivalent of .duplicate() is?
The for, in, and range constructs all make sense, but I must admit, I’m still a bit bothered by the lack of a indicator at the end of a loop. This indentation-as-structure thing just feels odd.
Linear arrays (Lists) are all well and good, but how about lists of lists? Associative arrays? We see some of the object nature in the List methods, but I feel this section ended too soon. I look forward to more information on complex structures.

Section 5: Sorting

This section is a bit disorganized. The bits about sorting are clear enough. The sorted() construct seems very practical and easier to understand than the sort in perl, for instance.
sort() is a lot like Lingo’s sort in that it just modifies the array. Although it is unclear if it keeps it sorted like Lingo does.
But then we introduce “tuples” without explaining why they should be used. From a compiler design point-of-view they are intriguing since we could make some optimizations. But I suspect they exist more for conformance checking of objects. But it seems this part should be in the Lists section.

List Comprehensions also seems like it’s in the wrong section. A handy construct for array munging. I can see why web devs would like this - perfect for processing form input.

Section 6: Dicts and Files

Ah... Here we get our associative arrays/objects. Apparently they are called “dicts” in Python.
We also learn of a reason to use tuples: since they are immutable, they can be reliably used as keys in hash arrays.
We also revisit the % expansion in strings. This time with an associative array basically doing token expansion.
File operations are pretty familiar to anyone who’s done file operations in pretty much any language.
There’s an odd little piece of basic programming advice at the end of this section called Exercise Incremental Development. Seems out of place and slightly condescending here.

Section 7: Regular Expressions

Apparently, I’m “the regex guy” on most of the teams I work with. I learned sed back when I was first introduced to unix-style operating systems and have used regular expressions pretty much daily since then. Let’s learn about the regex in Python!
search() and findall() are pretty clear, but I’d just as soon return a string or array instead of a “match object.” Perhaps we’ll learn of some reason for this added complexity later.
Non-greedy syntax is the same as perl. Whew! I’m thrilled that “Python includes pcre support.” Makes my life a whole lot more consistent.
I’ve skipped the exercises so far, since most of this has been straightforward information, but I’m going to play with the Baby Name Excercise.
The Baby Name Excercise drops us immediately in the deep end. We are given a folder of HTML files with baby name popularity information in tables.
We get to read files, parse HTML using regular expressions, build structures to hold the data, format the data and return it from a function.
It look a lot of flipping back to the lessons, but it was a good exercise.
I got the syntax for join() wrong a couple time though...
text = '\n'.join(names)
just seems odd. I realize it’s a string method iterating over a parameter, but traditionally we see this as a list or object method.
After completing the exercise, I looked at provided solution. Their solution did not handle cases where the same name was in both the boys and girls columns. I learned how to reference elements in a more complex data structure while constructing my solution.

Section 8: Utilities

Here we get the usual interfaces for shell and file operations. Try/Except construct is introduced. This construct seems very similar to the try/catch in most languages.

The exercises were great an applied to things I want to with Python right away.

After the introduction

I was able to put my newfound Python skills to work right away fixing a gPodder scraper.
I also used Python for a little log analysis where I would normally use perl.

So far so good!

The next section on the Google class is a bunch of video. I've never found video to be a particularly good medium for learning programming, but I'll give it a shot the next article in this series.