Posted on

Long Overdue

Having been busy for the past several months, I’m just now able to refocus on all of my projects, including the POV Poi one that’s been sitting idling.  Every day I stare at the two batons, yearning for me to pick them up and do some work.  Alas, the time has finally come.

Unfortunately, while I haven’t been able to work on them for months, I have been able to toss around ideas with other folks and one thing became rather apparent: we are in dire need of a specific development board.  For me the whole problem is that for any kind of developing that I want to do, I need to have one of the batons connected to the computer as I work.  This gets annoying, having to rip them open every time, especially since they are also still in the R&D stage.  And recreating the circuitry on a breadboard each time is a pain, not to mention having to deal with a bunch of jumper wires, any one of which can get snagged and pulled out, causing testing to stop to figure out why all of a sudden things stopped working.

So I thought, why not make a permanent development board?  One based on the current hardware, plus the ability to add more later.  Things like an accelerometer, an RTC, card reader, Bluetooth, RF, battery charging circuit, a buck/boost circuit, etc., etc.  I’m sure over time more people will come up with more ideas.

With that in mind, I started working on the current hardware being used for my specific project, the POV poi batons.  What are all the items that are currently in them, and what remains to be added still:

  • Atmega 328p (change)
  • Li-Ion charging circuit (add)
  • Buck/Boost circuit (add)
  • Micro SD card reader
  • ADXL345 Accelerometer (add)
  • DS3231 RTC (add)

From there, others have suggested adding support for Bluetooth as well as RF, with the latter being the most requested right now.  Someone also asked for a pony but that just isn’t going to happen.

First thing I wanted to change was the micro controller: switch it out for an Atmega32U4 for its native USB capabilities.  However I soon discovered it doesn’t have enough interrupts for all of the peripherals.  While the Arduino bootloader supports five interrupts, four of those are on pins that are being used for communications such as Serial and I2C, leaving me with just one.  Both the ADXL345 as well as the DS3231 have interrupt capabilities.  So does the more common nRF24L01+ RF device.  While one can certainly use them without the interrupt, why limit the end-user?  All of a sudden, using the 32U4 became impossible.

Enter the new AT91SAM3X ARM series!  Those things are massive!  With all kinds of capabilities, including an interrupt on up to 103 IO lines.  103!!  It also has native USB capabilities, as well as USB OTG, meaning it can also act as a host to other USB devices.  This opens up all kinds of options.  Now I only need to convince myself that I can indeed work with these controllers, maybe build a breakout board first, see if I can even get that working correctly before moving on to a larger system.

Remember when in an earlier post I mentioned how ideas flow in my head?  Just as I started writing this post here, I came up with another thought: a multi processor development board.  Why have a development board that’s specific to one processor?  Why not make it so one could swap out processors and continue developing?  I know it’s possible, after all Atmel already did it: the STK600!  Taking a cue from that, I thought, “Why not build a development board where one can swap out the processor to whatever they’re using, or want to use?”  It would mean making a “motherboard” onto which you can plug in daughter boards with the processor of your choice.

Dear Brain,

Please stop thinking long enough for me to catch my breath.

Yours Truly.

Posted on

Code Freeze!

I’ve come to realize that I have too many ideas in my feeble little brain to add to this project.  However, I also realize that if I continue to develop and incorporate them, I will never get to a product I can call “final”.  So, as of today, I have frozen the current code.  It is what it is, and it will remain as such.  I will continue to work on what’s currently there, bug fixes, small improvements, however I won’t be adding anymore features.  Anything left on the list will remain there for the next revision.  There’s just too much to be working on right now and I continue to push the project further back because of that.  No more!

Freeze

So, with that said, here’s where the project stands:

  • Four strips of 48 full color LEDs arranged in a square tube shape, inside of a round polycarbonate tube.
  • Final tube length will be somewhere around 18″, though we are diligently working to make that shorter by an inch or two.
  • One Li-Ion battery to power the whole unit, which also includes a charging circuit for the battery.  Charging will be done via a USB connection.
  • The light stick can use full color images, stored on a micro SD card which is inserted into the stick.
  • Images will require pre-processing into a custom file for now, which is limiting this design from going into full production.  (Future development will switch to a standard BMP image format.)
  • A control file is used to arrange the images in the order in which they are to be displayed.
  • This control file will also allow the user to set the speed in which each image repeats, how long each image is displayed, and how long to wait before the next image is displayed.
  • A three-way switch will provide the unit a way to power just the control board for updating of the firmware, or both control board and LEDs for a running show.
  • A trigger button will allow the performer to turn the unit on but not have it display anything till the button it pressed.  The same button also stops the display and resets it back to the beginning of the control file.
  • A soft glowing LED will be the indicator of the unit being powered and waiting to start the display.
  • Upon first power up, the unit will display a red-to-green gradient chase indicating battery voltage.
  • During a show, if the battery voltage drops too much, the unit will simply stop displaying anything.  (Future development will allow the unit to lower its brightness and continue to run before ultimately cutting out completely.)
  • A swivel will allow the unit to rotate freely while being spun.
  • Future firmware upgrade is possible, as will minor hardware changes.

That’s it for now.  The rest has all been pushed to a next revision (or I’ve forgotten about it here.)

 

Posted on

Procrastination

Did some hardware shopping after practice today.  I’ve been trying to figure out how to attach things to the tubes and what not.  For now, I’ve settled for a simple bolt and nut arrangement with a plastic plug.  By drilling a hole through both the tube’s sidewall as well as through the plug, the bolt will hold both of them together and there’s no risk of the plug flying out.  The top bold has a small (fishing) swivel attached which protrudes through the plug.  This will then get attached to whatever chain I can find.  Looked around for that too but I wasn’t happy with what I found.  I don’t like open-ended chains, those where the ends are simply curled in, as opposed to welded in.  Over time they expand and when you’re spinning something, that can spell disaster.  I’ll have to go back to the hardware store and see what other options there is that’s small and doesn’t weight fourteen tons.  I still need to grind the protruding bolt and get it flush with the nut, but for now this’ll do.

After spending some time making a new video clip (in other words, procrastinating on doing other stuff), I decided to do some code fixes while the video was processing.  We now have the ability to control each image in terms of how fast the same image will loop and repeat, how long it will be displayed, and whether there is a pause before moving on to the next image.  Had to squash a bug while at it too!

Opted to use some more traditional images for testing.  These all came from the original PixelPoi source files, which also happens to be the design I’m improving on.

[click on each image for a larger popup]

Tomorrow is “hardware day”.  I’m going to try and focus all of my attention on the controller part so I can get that done and maybe send it off for manufacturing.

Posted on

Color Adjustments

After all the testing done so far, I decided to play with some image manipulation.  All images get shrunk down to 48 pixels tall from whatever size they originally are.  This poses a problem with sharpness.  So I spent the evening doing some testing with a little bit of re-sharpening of the image.  I say a little bit because any tiny change will be too much.  Ultimately I settled for some values that were just enough to get some details back.

The next step was lowering the image gamma.  With the LEDs being so bright, just about anything I put up was getting washed out.  Normally on a computer you’d set a gamma value of 1.2.  Here, I had to lower that to 0.4.  Big swing.  But, the results are much better:

[click on each image for a larger popup]

Posted on

Capture Time

I decided to cobble together one baton.  A couple of things were immediately obvious:

  1. It’s a bit of a pain trying to solder *inside* of a square tube
  2. Thin PCB warp too much
  3. Small pads coupled with thin traces tend to break or lift off of the PCB very easy
  4. Need to find a better way to interconnect the PCBs, both while daisy chaining, as well as sideways to its neighbor

Despite all of that, I did manage to attach the battery to the PCBs, and left it tethered to an external controller through a very long ribbon cable.  I don’t have the design for the actual controller done yet, so I had to use an external one.  This was actually advantageous.  Especially since I realized that I could easily go up to a 1″ diameter tube and still be okay.  I’ll have to rework the PCBs for the LEDs a bit, but that’s not a big issue, in fact it may be a bit cheaper in the long run.  But, more importantly, it gives me an additional 3mm to work with for the controller.  That may not seem like a lot, but 3mm translates to 118mils, which means I can place seven 8mils thick traces in that space.  That is important!

Other things that became apparent after I started playing with it:

  1. Need to reverse the placement of the battery and controller – this may be the solution to having wires connected to the LEDs
  2. Need to make changes to the code and put the image delays in the control file, not the image file itself *
  3. Taking video capture just doesn’t work as well as watching the real thing
  4. Taking pictures however, works beautifully. 🙂

20130730-001

This is what the video looks like, when captured at 30 frames per second.  It’s nowhere near as awesome as seeing it with your own eyes.

* Besides storing delays, there are other items on the list:

  1. Add proportion calculator for images of various widths
  2. Switch to a 24-bit BMP format instead of the arbitrary RGB storage engine used now
  3. Add the ability to have a (longer) delay between images
Posted on

Design Evolution

One thing I learned a long time ago was to document progress.  Having been using EagleCAD as my main circuit design and layout program, combined with eagleUp, it’s pretty easy to spit out some simple renderings of a design.  The advantage of this is that I can easily pull a design into a CAD program, such as SketchUp, and see how things fit together, down to whatever accuracy I want.  Back in the olden days, you design something in the hopes that it would fit, or you build an enclosure around it.  Nowadays I can start with an enclosure and decide how to fit something in it.  And while this at times can be a bit problematic, in the end it’s a great asset.

When I first thought of this POV Poi design, I started thinking of what an acceptable tube width would be.  1″ seemed too big, though now I’m finding out that there are even larger ones.  But I’m also considering weight.  What’s acceptable?  I don’t know.  But that’s why we create prototypes; mainly to find problems and to also get it into the hands of an actual performer and see what they think.

Originally, I had the entire controller board on a single layer, sitting right in the middle of the polycarbonate tube:

 

This quickly became a problem.  It’s hard to route all the components on a single board.  There are some large ones on the bottom that restrict where I can place a trace, and the parts up top are very small, very tight and I quickly ran out of room to lay down any traces.  And it was also too long.  I want to try and keep it as short as possible, ideally shorter than the battery itself which is 65mm long.  I have to think of balance here.  And the overall length of this virtual tube was also getting to be about 43.5cm long (or about 17″ long.)  That seems long to me, but again, I’m not a performer so until I can get it into the hands of an actual performer, I won’t know.

So I started working on a two-tiered design instead.  This gives me the added advantage of possibly wedging it into place inside the tube, or adding a guide in the tube that will hold it in place so it doesn’t rotate.  That’s all nice, but I still need to route it all and I’m getting dangerously close to the 50mm limit I imposed on myself.  I still want to shorten the overall length a bit, so that’s enough room for a 3″ chain to go on the end that then ties to whatever the performer wants to hold in their hand, whether it’s a small ball, or a leather strap.

 

I still need to add control buttons, if I decide to incorporate the ability to have image folders in this revision.  And with the idea of a short staff, that means breaking out some control lines to communicate to the controller on the other end of the staff.  Potentially using I2C lines.  However, if in the future I want to add a gyro and/or accelerometer to the design, I may need those lines.  We shall see.

Posted on

Signal pull-downs

Pushing data as fast as I am, the signal was getting clobbered by itself through reflection.  The IC datasheet recommends having series resistors after a certain length between ICs, however since I am nowhere near that, I didn’t bother to put anything in.  As it turned out, the data was getting corrupted and adding pull-downs solved it.  This is my attempt at a Macgyver-fix.  Future revisions will have proper pads and SMD resistors.  File this one under lessons learned.

Posted on

Reliance

It’s one thing to know you can potentially use a “card detect” feature on a micro SD card connector.  It’s a whole different ball game when something goes wrong with it.  Take the above for example, an Adafruit micro SD card reader that I’ve had a little over a month now.  The card detect pin worked as it should, closed when there was no card present and open when I inserted one.  However, I soon started noticing some issues with it.

For one, the switch would open as a card was being slid in, as opposed to when it’s locked into place (and therefore available to be read from.)  While this may very well be the design of it, it posed a small problem for my design.  I was hoping to use it to trigger the code to react on it, however you can’t start using the card till it is actually locked in place, which isn’t what happens when that switch goes open.  So that’s problem number one.

Second, I started noticing at times the switch would remain open even after removing the card.  Or just wiggling the card itself would cause the switch to open and close sporadically …  Imagine if your code is meant to react to it opening or closing, and suddenly it changes states like that.  That would cause havoc on the code side.  And while I could potentially incorporate some debounce for it, how do you really make sure it works.  Check once, wait a second, and try again?  And because this works via the SPI bus, it already takes about 1-3 seconds to timeout.  So I could just loop it again and again, but then who’s to say it won’t just get stuck and/or crash.  Not a good design of course.

So for now, I’ve decided to ignore the card detect switch, at least till I can find a more robust connector.  For now the code will look for one thing: did it initialize?  It’s a simple ‘yes’ or ‘no’ state.  Either it works or it doesn’t, regardless of what the problem might actually be.  This isn’t ideal, but it will have to do for this specific revision.

Posted on

Spinning!

Now that I have a few strips made, I decided to do a test spin.  Okay, so I’m not really spinning the string, it’s the camera that’s spinning.  I placed the string on the floor, mounted the camera above it and spun it.  It’s the same thing as when you’re spinning the string, the images get distorted the same way.  Now I can tell what kind of images work best.  It also gives me an idea to maybe warp an image before hand so that when they are displayed while spinning, they get warped back into shape and maintain the proper distortion, or no distortion at all.  That remains to be seen though.

Posted on

Speed 2

Managed to procure a reel of LED strip made with the LPD8806 driver.  What a difference!  The first thing that was immediately apparent was that this reel had 48 pixels per meter as opposed to the 32 on the WS2801 strips.  Bonus!  My design uses 48 pixels, so this was perfect for testing.  I just needed to cut one single meter, hang it up, and start testing.

I started with a modest delay of 750 microseconds.  It worked like a charm.  Than I started dropping it, first to 500, then to 250, 100, 50 … zero!  To my amazement, with no delay what so ever, the updating worked without any data corruption.  This is well past the speed that I would need it to update!