Homemade Mini Wireless Blue-tooth speaker


You’re away from home and you just wanna blast your favorite song before going out. But alas, all you have is these puny laptop speakers…

No more! Now you can build your very own portable speaker that puts any laptop or phone speakers to shame. The design is simple, with only a small amount of soldering required. Better yet, aside from the enclosure, all the necessary parts can be bought from one place!

Speaker V1

All you do is hit the on switch, pair via blue-tooth to your phone or tablet, then let the music flow!


Here is the parts list for everything you’ll need to put together its electronic guts:

Here is the schematic for putting everything together:

Speaker V1 Schematic


You’ll need to do some basic soldering to hook everything up. For the bluetooth module, I just cut open the wires included in the kit and soldered to those, in case I wanted to unplug the module for using it in something else. However, if you’re feeling adventurous, you could unsolder the connectors, then solder the 5v and stereo out wires directly to the board to save on physical space. I lost the pinout for the mono audio amp, so be sure to read the document that comes with it to see the proper pin outs.

As always, be careful when soldering. I am not responsible for anything bad that happens to you.

At this point, with everything soldered together nice and tight, it should work. Put in some batteries, flip on the switch, and you should be able to pair with your phone via bluetooth. If it doesn’t work, check for shorts in your soldering. If all else fails, you may have overheated one or more of the components when soldering it together, in which case you need new parts.


If you are lucky enough to own or have access to a 3d-printer, then all you need to do is download the enclosure. If not, you could build your own enclosure out of wood or other materials.

You’ll find the solid works files, as well as .STL mesh files. I have a Makerbot Replicator. So, I use ReplicatorG to import the .STL files, export to gcode, then send it off to the printer! I printed using white PLA plastic with the default Replicator settings, using 100% fill, 1 shell, and no support. I found that ABS plastic warped too much to be usable.

After printing the parts, feed the battery clip through the hole in the middle section into the battery compartment. Place the switch snugly into the hole in the side of the middle section. Then, put together the top and middle sections. I used an old soldering iron to melt the two halves together. You can also use certain types of glue, or use a heat gun. After that, stuff the electronics into the top section through the speaker hole. It will be a VERY snug fit, and it took me some time to get everything in. You can glue the various components to secure them, but I didn’t bother. Put the speaker on top so that the screw holes line up. Then, screw it in using 4 small metal screws. Finally, plug in your battery to the clip on the bottom, and use 4 more metal screws to screw the battery lid to the enclosure.

All done!


I am already hard at work on version 2.0! However, I had a few retrospective thoughts on how this version could be improved. Feel free to try these ideas if you’re up for some experimentation.

  • Use this audio amp instead of the one listed above. It’s twice as powerful while costing half as much and taking up much less space.
  • Use higher value resistors for the stereo to mono conversion. The 1K seem to saturate the sound when it’s near max volume. Better yet – buy a consumer stereo to mono adapter.
  • Use a filtering capacitor across the speaker terminals to eliminate some high frequency hissing and noise.
  • Use a piece of foam in the battery compartment to keep the battery from rattling around.
  • Don’t melt the two halves of the enclosure together. It doesn’t look that great.
  • Use black plastic instead of white for the enclosure. It would look way cooler.

Final Notes

That’s about it! I have no idea how long the battery lasts. I’m still on my very first set of 8 AA’s and it’s still going strong after 6+ hours of usage. I would estimate about 8 – 9 hours of playback at middle volume.

If you end up trying this and make any improvements or have any thoughts on the design, feel free to let me know!


Getting Things Done: The Notecard Method

You wake up in the morning, excited to see what amazing things you can accomplish that day. You make a mental list of all the things you’re going to do. Sure, you meant to do these things yesterday, but that’s what today is for!

Fast forward 16 hours. You lay in bed, thinking of all the things you did that day. Wait – nothing from that great list got done? Hmm, well it’s because that thing came up, and I had to do that other stuff, and whatever I’ll just do that stuff tomorrow.

That’s what my days have looked like recently. I realized the devastating spiral of inactivity I was falling into. When you get to a low in your life, you start to re-evaluate. When I look back, I notice how productive I used to be. I started asking, why then but not now?

I think we get into these spirals because we get fixated on something that cannot be resolved, and it blinds us from what’s actually important in our lives. When I was younger, I used to have such a strong drive to accomplish goals. I would make these checklists in my head and be excited to check items off, all without even being conscious of it! This probably stemmed from my love of video games.

In video games, there is (almost) always a goal, with a (usually) literal check-box. From playing so many games, I got really good at applying the same principals to real life. Since I haven’t been playing so many games lately, I’ve been slipping on this habit; or maybe I just got caught up in the wrong things. The point is, I found a way to get me back in the zone.

The Notecard Method

It’s pretty simple: at the start of each day, grab an empty note card. Label the date at the top, and a blank for the “score”. Then, write down 10 check-boxes, with 10 things that you want to do that day. At the end of the day, tally up the check-box’s and mark your score at the top.

You should write down 10 things such that at the end of the day when you lay down, you could look at the completed list and say “I WIN AT TODAY. GOOD JOB BRO.”

Here is mine for today:

Notecard Example

The goal is obviously to check off as many as you can that day. In addition, to keep the motivation going, you can try to beat your score for the previous day. If I don’t check off an item that day but it’s important, I split it up into two smaller tasks and add them to the card for the next day.

Finally, it’s very rewarding to look through your pile of notecards from the previous days. You see all these check marks next to things that you’ve done and you feel even more motivated to keep up your streak. At the end of the week, seeing a stack of 10 / 10’s feels amazing.

And with that, I check off my last item for the day, going to bed excited for the days to come.

Asteroids in JavaScript

Enjoy this classic game written in JavaScript, the most foul language I’ve ever had the displeasure of learning. Half way through, I wanted to quit, but I put aside my hate to give it a chance. It’s not that it’s hard to learn. This game only took a couple hours, including the time it took to learn JavaScript. The problem is that it has so many serious (and well documented) design flaws. That said, the source code is in plain text for your viewing pleasure, courtesy of JavaScript. Suffice to say, this is my first and last JavaScript game.

Click on the game then press space bar to play. Use the space bar to shoot, and the arrow keys to move. The goal is to make the rocks dead, while keeping the triangle alive. That’s right, you are a triangle. At least I didn’t make you a square. Who wants to be a square?



I always had a sketchy feeling about JavaScript thus I never bothered to learn it. It looked stupid. After having learned enough to make this game, I realize that I was right. It is stupid. Too bad the whole internet is built on it. JavaScript is like a rotten, termite infested wooden frame holding up a giant mansion full of cat pictures and porn.

It’s OK though, I’ll just write my own language. I’ll call it: BLEM. Best Language Ever Made. Don’t worry I took a class on this, therefor I MUST know how to write it right, right? Wrong, I dropped that class. Good thing you don’t actually need school to know how to do stuff that matters. Hate me yet? It’s alright, hate just means there’s room for understanding. Hate me even more now?  Good, that means it’s working!

Seriously. I’m going to write a right (coincidentally, using my right to write – it say I can in the constitution).

Coding Standards

Just like writing a readable piece of text, code should be written with the intention that it will be read later (and work).

When writing English, it helps readers when words are spelled in a consistent manner, certain words are capitalized, and punctuation is inserted into a reasonable place. When it’s not like that, people will often interpret the text as trash and invalid, even if the underlying material is actually valuable.

Code is the same way.

I don’t know if people don’t realize they’re doing it, are doing it on purpose, learned the wrong stuff, or just don’t care, but C/C++ code is some of the most horrid stuff to look at sometimes. Even in some well know libraries, applications, and operating systems – there is some ugly code out there.

I highly recommend anyone writing a C/C++ application to adhere to a very strict style to ensure that it will be understandable and maintainable in the future.

I agree almost 100% with everything in the Google C++ Style Guide.

Please read it.

Everyman Sleep Cycle

Hmm its been almost a month since my last update. I hope this doesn’t turn in to a trend…

To name just a few excuses:

  • Been on a few trips – Electric Zoo FTW
  • Started going to school again
  • Got lazy
  • Started a new sleep cycle

Though one of these distractions actually made me want to write about it, so maybe it doesn’t belong on the list…

I want to talk about the new sleep cycle that I’m on, called the Everyman cycle.

It’s a form of Polyphasic sleep. In summary, polyphasic sleep has you sleeping not for one extended period (8-ish hours), rather you spread out your sleeping over the course of the day. In the Everyman cycle, you sleep for about three hours at night, then have three evenly spaced, twenty minute naps throughout the day.

I have been on it for almost 4 days now. As I write this, I am approaching my 4am – 7am sleeping period.


The main objective here is to have more time in the day. Why more time is better should be obvious. The secondary objective is to build self-discipline in order to enhance other aspects of life. This cycle builds discipline because it requires mental energy to stick to a mostly fixed schedule every day, while also providing a reward for succeeding.


As with any new sleep cycle, it takes time to adjust. In the case of Everyman, it tends to take a couple weeks to be fully adapted. For me personally, it has not been unbearably difficult. The worst part is waking up at 7am after only 3 hours of sleep. I already messed up once and overslept because I drank the night before. Drinking is a BIG NO NO when adapting to this cycle. It forced me to not be tired enough to take my naps later on, which messed up my rythm a bit. Strategies I have been using to help me along:

  • Set alarms on phone to go off when a nap should start and (obviously) end
  • Have a sugary / caffeinated drink next to alarm
  • Attach motivating note to alarm that I have to see before I can turn it off
  • Keep the lights on, even for the 4am – 7am sleep

So Far?

So far, I am impressed. Traditionally I have been an insomniac and long sleeper. I don’t like going to sleep, but when I do I like to hibernate for as long as possible. I would sometimes sleep for 10 – 12 hours a day.

With this new cycle, I have been tired, but never so tired that I would pass out if I lost concentration. Some times, I’ll have had more energy than I can remember having in a long time! My dreams have been very vivid. I even had a lucid dream earlier today, which I don’t get often. Concentration and motivation also seems to be improved, with anxiety reduced (probably because my mind is too tired to do it). Most importantly, the extra 4 hours a day is amazing. I feel like each day lasts forever, and it can be hard for me to remember all the things that I was able to do that day.

Overall, I am very excited to see how my life changes once I completely adapt to the new cycle. The main challenge for now is to just not mess up for the next couple of weeks…

Gemini Physics Development 3: Progress Update

Its been a while since my last update…


One of the main complaints I see with other physics engines is that the interface is too complicated or hard to use. The past week or two, I have been working towards a straightforward API that gracefully exposes all of the various features that Gemini offers.

The core of Gemini is written in pure C with zero external dependencies other than the standard C header files that should be available to any half decent C89 compliant compiler. It is data driven, meaning most parts of the engine are configured by simply modifying fields of a struct.

While the C interface is very clean, some (including myself) prefer a more object oriented approach. Therefor, I have also written a C++ wrapper on top of the C interface. Both API’s are efficient and memory-leak friendly (as in, hard to memory leak). They have also been designed to allow easy integration with scripting engines.

From the beginning, it was in the design to support single, double, and fixed point precision. I was debating how to include these different modes. As it is now, the mode is specified by the library you link with. In addition to a numeric precision mode, you can also choose between a 32-bit or 64-bit build for your platform. At present, there are no optimizations in the 64-bit build, but that will hopefully change. The alpha release should include builds for the following platforms: Windows, Linux, OSX, and Android.

For the next build (the beta), the plan is to fix various bugs that pop up, add a selection of user requested features, add an iPhone build, and add a C# wrapper interface.

Technical Developments

In addition to the major API work, I have also been added some cool features to the engine itself. No video today – next time :)

The first major improvement was in the constraint solver. The new constraint solver, which I’ll call the adaptive solver, solves selectively until the error from all constraints and collisions reach a user specified value. This means there are less parameters to tweak, and you can easily adjust performance of the solver to suit your needs.

The second major improvement is the addition of friction. Normally this might not be considered a major improvement – but in the context of the verlet-style framework that Gemini uses, it was very tricky to get right. It supports both static and kinetic friction with coefficients that can be based on real world ones, as described here.

In order to keep the implementation fast and to easily support many of Gemini’s features (such as serialization), there needs to be a minimal amount of state stored between each simulation step. This is why friction was so tricky – normally physics engines keep a cache of contacts which they can rely on to store various values that help with solving during the next run. With Gemini, very minimal caching goes on. Most of this information therefor needs to be derived during the next solving step, including that used for friction and stacking.

A slew of other features have also been added (which you will see in the next video). These include:

  • Stable stacking – a side effect of using the new adaptive solving mechanism and friction detailed above
  • One sided edges – particles can pass through one side, but are blocked on the other
  • Rigid body constraint – solves all constraints of a body at once, causing quicker convergence and more accurate rigid shapes
  • Rope constraint – similar to the rigid body constraint, a special constraint that solves chains of constraints more quickly and which keeps rope more stiff
  • Time of impact ordering – before, order of impact was not considered, leading to the occasional ghost force
  • Air drag and wind – applied to each edge independently based on its velocity and the wind direction
  • Various forms of collision filtering – allows for a simple form of depth based on layers, and things like rag-dolls where certain limbs should not collide
Implementation Specifics

I’ve been getting many questions above specific features and how it all works internally. While I can’t give away all the secret sauce, I will give as much as I reasonably can.

How does the solving work?

The solver uses Jacobi style iteration to solve constraints. Since we use verlet integration, we can directly move particle positions when solving both cosntraints and collisions. In the demo shown in a previous post, constraints are iterated a fixed number of times, while collisions are iterated until there are no more continuous collisions or a maximum iteration count is reached. In the previous demo video, I believe I used 10 iterations for constraints, and a maximum of 10000 iterations for collisions.

The main solver loop is roughly:


How do you prevent lock ups?

The lock up problem does exist. However, its only a problem when there are fixed particles or impossible situations involved. For example, if you had two static edges that are moved to trap a particle in between them, it would iterate forever. As far as I’m aware, this is an unavoidable problem, and you simply need some extra logic to account for these situations. My solution was to add a “max iterations” parameter to keep it from freezing. Even without fixed points, it can still take hundreds of iterations sometimes which will cause some delay (as can be seen in the video when i play with the rope). In my latest updates to the solver, it solves more selectively and intelligently to almost completely eliminate this issue.

How does the collision ordering work?

The ordering didn’t make as big an impact as I thought. In the videos in previous posts, there is actually no ordering going on, not even local ordering per particle. I’m solving ALL TOI collisions for each particle! It doesn’t appear to have much of an effect on number of iterations required, just the correctness of the results. Without the ordering, you can shoot a particle at a static line and it will affect things on the other side of the line (which is obviously incorrect). In the latest solver updates, collisions are correctly ordered which fixes this problem.

How do sliding particles from edge to edge not snag on corners?

Gemini sweep tests all collisions, however when resolving collisions, we add a little bit more to the correction in order to keep the particles a certain distance from edges. This amount is so small that its not very noticeable, and facilitates in solving many of the numerical rounding problems when sweep testing. A side effect of having the particles maintain a slight distance from edges is that particles can smoothly slide around without snagging.

What about friction?

I assumed that friction would be an easy addition to the framework.

It was not…

When I first implemented friction, it appeared to work nicely and was actually very easy to add. I applied a position correction to each particle based on how much it moved relative to the edge’s tangent. This works until you have objects stacking. Then, numerical error adds up and you see objects slowly drift apart, and ultimately tumble over. If you don’t care about stacking, that solution will work. What I ultimately spent a week trying to figure out, I need to keep as part of the secret sauce :)


I wish I had a video to show today, but I am in the process of updating the test bed application using the new API, so it’s not exactly impressive to look at. In the next post, I will show off some of the new features mentioned above, and talk more about whats coming up, as well as the alpha release.


The other day, I was thinking about graphics styles in video games. I realized that the old 8-bit style graphics never really got old for me. Maybe the newer generations don’t get it, but seeing 8-bit Mario always cheers me up.

I came across some blogs that show how to use Photoshop to turn any image into an 8-bit version. I don’t have Photoshop, so I wrote a simple application that does it for you!

It has both a command line tool, and a GUI on top of that. There are only three parameters, but it produces a satisfying effect. The GUI tool can only process one image at a time, but you get to play with the parameters. With the command line tool, you simply drag and drop as many images as you want onto the application, and it automatically converts them all for you! You can also run an image through twice or more, making the effect more pronounced.

Here are a few others:

You can download the application here.

It won’t work if you don’t have .NET 4.0 installed, but if you have windows then you most likely already have it.

Gemini Physics Development 2: Android Proof of Concept

The other day I started on Gemini Physics, and have been making great progress since then.

I fixed several small issues, and started making the c++ interface pretty. But most importantly, I got it running on android! That may not be very exciting for some, but its an accomplishment for me since it’s the first time that I’ve messed around with the NDK before. I can’t get over how painless the process was…

The NDK is basically a tool-chain that allows you to run native C/C++ code on android. Many programmers know that most android development is in Java. For Gemini, I didn’t want to use Java because I need every ounce of performance from the device, and because it’s already in C++. Why port to another language?

The new NDK is very easy to use. You can develop with it without ever touching java, and you can do it on windows without cygwin.

If you want to make your own NDK based applications, you need the Android SDK, NDK, and either Eclipse or Ant. After you have those, follow “Exploring the native-activity sample application” tutorial at the bottom of the NDK download page.

Next on the list is friction and rigid body constraints.

GPU List Class for C#

I was doing some GPU compute testing and I realized that it was quite painful to actually get data on to the GPU. I ended up spending most of the time just trying to copy some data over. So, I finally broke and wrote up a C# IList<T> implementation that is fully GPU backed. It fully implements the interface, and makes it very easy to get data on and off the GPU.

It’s easier to explain what I mean by just looking at some usage code. This is a basic GPU particle system, with all the data transfer totally encapsulated inside the GPUList.

It is not implemented to be super fast, rather super convenient. So if you ever want to do a GPU compute test using SlimDX, but don’t feel like dealing with the hassle of data management, this class could be useful for you.

You can get the Visual Studio project and source here: Download GPUList Project

You’ll need Visual Studio 2010, and the latest release of SlimDX.

One post at a time