As for me, well, since I can't foresee being able to get back into things in the near future, consider me dropped back off the face of the planet (to use unsped's words) once again. With any luck I'll post again one day.
Sunday, November 9, 2008
Better men than I (aka, Tinct Lives!)
Monday, March 24, 2008
Distinct Tincts
When I decided to go ahead and have my own PCBs made for what would become the Tinct I posted a request for people who would be willing to split the cost of fabrication with me. Two people - Brad Hill and Devon Jones - were brave (or foolish) enough to respond, despite having no reason to have any confidence that the design would work; without them, I probably wouldn't have proceeded because of cost. It's great having people with whom I can bounce ideas around, to whom I can complain when things aren't working, and to whom I can brag when things finally work.
I'm very pleased to report that, a mere week after I completed the first OcTinct, Devon has completed his. We decided to go with computer science-style numbering, so we're calling mine Tinct 0, and his is Tinct 1. Brad isn't slacking off, either, and has been working on a number of monome/Arduino crossover projects, which you can see pictures of on his Flickr page.
A few other quick Tinct updates: I'm pretty happy with the current version of the firmware, and have cleaned up and commented the code to make it usable by others. I'm willing to call this a "release candidate," whatever that means in this context. There are a few minor optimizations I want to try, but I have one that works without any known bugs. I rewrote the TinctSerial program; the serial performance of Processing sucked, so I rewrote it in Python (my first Python program ever). That solved all of my problems, although the current version is a processor hog. Devon taught me everything I know about Python (over IM, no less), so he's going to fix up the code. Finally, the controller board design is forthcoming. I just need to test my power supply circuitry to make sure it works, and then it's time to have the boards made. After that, all that's left to do is build a case!
I'm very pleased to report that, a mere week after I completed the first OcTinct, Devon has completed his. We decided to go with computer science-style numbering, so we're calling mine Tinct 0, and his is Tinct 1. Brad isn't slacking off, either, and has been working on a number of monome/Arduino crossover projects, which you can see pictures of on his Flickr page.
A few other quick Tinct updates: I'm pretty happy with the current version of the firmware, and have cleaned up and commented the code to make it usable by others. I'm willing to call this a "release candidate," whatever that means in this context. There are a few minor optimizations I want to try, but I have one that works without any known bugs. I rewrote the TinctSerial program; the serial performance of Processing sucked, so I rewrote it in Python (my first Python program ever). That solved all of my problems, although the current version is a processor hog. Devon taught me everything I know about Python (over IM, no less), so he's going to fix up the code. Finally, the controller board design is forthcoming. I just need to test my power supply circuitry to make sure it works, and then it's time to have the boards made. After that, all that's left to do is build a case!
Monday, March 17, 2008
The OcTinct is up and running!
The OcTinct, the 8x8 member of the Tinct family (a full-colour monome clone), is up and running! The colours don't show up nearly as well in my videos (if anyone knows how to fix that, please let me know):
Technical details after the jump.
The Tinct is based off of custom-made PCBs and is being driven by an Arduino. The colour of each LED can be independently set, and the colour range is pretty much as close to "true" colour as you're going to get with an LED. The software is fully monome-compatible; the OSC command set is a superset of the monome protocol, adding in commands to control colour. Right now the colour control is pretty rudimentary, but will be expanded. There are two auxiliary analog inputs, which can be attached to anything that gives output as voltage: for example, potentiometers (as seen in the Life video above), or a two-axis accelerometer.
The controlling circuitry is currently all on breadboards, and is a horrible mess. You can see it in the videos. Eventually I'm going to make boards to hold this all nicely, and maybe tuck it into a nice case. Before I do that, I'm probably going to try a redesigned control scheme which uses two microcontrollers instead of one, in order to have a dedicated "video card." If it improves performance enough, I'll keep it that way. This is all about teaching myself electronics, though, so mostly I want to see if I can get the dual-processor scheme working.
Right now it's being powered off of the USB connection, but this is a temporary solution. I'm limiting the current to each 4x4 board via the transistors (I did this accidentally, but it worked out nicely for testing). What this means is that if any colour channel is trying to draw too much current (which occurs when more than 5 LEDs on a single panel are on at full blast in any of the three colour channels), then the colours might go a bit funny or dim. This will be fixed when I get around to building a proper power supply.
I have two extra sets of the custom boards for building this. If you're interested in trying to build one, get in touch (jmg *shift-2* upwardnotnorthward *dot* com).
Wednesday, March 5, 2008
RGB monome clone update and rename: Tinct!
The gist: the video above is of the second version of my RGB monome clone. The reason is looks so much worse that the first version on video is because it is so bright that it saturates my camera's CCD; in reality, it looks much better than the original. It is fully compatible with monome programs and the colour can be changed on the fly via software. The project has been renamed "Tinct," the 4x4 version shown above is called TiniTinct, and that's how I'll refer to them from now on. Right now, production kits are looking unlikely, but I do have a couple of extra sets of the prototype boards if anyone is interested in them. For more details continue after the jump.
As much as I like the name Trinome, I felt it implied a little too close an association with the real monome project. As a result, I was reluctant to actually use that name, and ended up just calling it "RGB monome clone" or "RGB button pad," which are boring. So, I've decided to rename the project Tinct. The 4x4 version shown above is the TiniTinct (pronounced Tiny Tinct), and the 8x8 version will be called the OcTinct. To be clear, the monome folks didn't ask me to make this change - they have been nothing but supportive - but I just decided to make it out of respect for them and their work.
As for the kit: thank you to everyone who has expressed interest. Right now, I just don't think it will happen. Making a kit would require another version of the 4x4 boards to fix small mistakes in the prototype (or designing an 8x8 version of the board), plus making a second board to hold controlling circuitry; this development would be expensive, and it's money I'm not willing to invest. There's also the issue of reliability and capabilities; this is very much a hacked-together project, and if I made it a kit, people would (reasonably) expect certain standards to be met. I'm just not sure I could be satisfied that I was meeting those standards without a lot more investment of time and money in this project. Finally, I just don't think I'm up to the task of providing technical support for a kit of this complexity. I'm finishing off a PhD, and I don't want to commit time to helping others build a kit. So, for the foreseeable future, a kit won't be produced. But, if you really are interested and up for it, there are a couple ways you can get your hands on this.
I have two extra sets (four boards each) of the prototype boards. When I put out the call earlier, I had two people respond, which made the production of these boards financially possible for me. They have their boards now and are working on duplicating my project. They were brave enough to buy the boards knowing that they might not work at all, or not as advertised. Well, now we know that you can at least use them to make a 4x4 monome-compatible device which can change colours on the fly. Soon I expect to have the 8x8 version up and running. A set of four bare boards will cost about $100. Parts will probably be another $100 or so (or much more, depending on the LEDs you get). If you understand and accept the difficulties involved and still want to duplicate my project (Don't say I didn't warn you!), please get in touch. If I hear from 8 people who want single boards before I hear from 2 people who want sets of four, then I'll be happy to sell the boards as single 4x4's. If I hear from enough people who are crazy enough to do this (let's say, six people looking for sets of four), then I'll order more of the prototype boards - on the understand that this is duplicating a prototype, not building a kit, and that minimal support will be provided. If you can't get it to work, don't come complaining to me!
The second way is if an "angel investor" were to appear (rather unlikely, I know). If someone were to pay me a lot of money, I would be willing to continue development on this. Cost would depend on the level of polish in the final product, but I think the least expensive I would do it for would be $1000, with prices rising from there depending on what exactly the demands of the project are. I don't expect this to happen, but I'm throwing it out there in case someone reading has both more money and more passion for this project than I do.
On to the technical details: I wrote my own version of monomeSerial in Processing to make it easier to hack during development. This software takes the OSC commands that the monome MSP patches and Chuck shreds send out, and translate them into serial commands that the Arduino can understand. It also receives the Serial data that the Arduino sends about button presses, and translates them into OSC commands that get sent back to the controlling program. I modified it slightly to create TinctSerial, which does the exact same thing, with the addition of an on-screen colour selector. You click on a colour in the window, and the Tinct changes its colour accordingly. The matching of colours isn't perfect yet, but you get a reasonable approximation of what you choose (and if anyone knows of a good way to accurately translate RGB values to the PWM frequencies needed to match that colour, please let me know!).
The LEDs are being driven by a single TLC5940 16-channel PWM driver. All 16 LEDs are connected to the chip simultaneously, and multiplexing is done over the colour channels. That means that only one colour channel is on at any given time, but it cycles through quickly enough that the eye can't see it. The camera, however, occasionally can, and so you might notice occasional "colour hiccups" in the video; these can't be seen in real life.
Switching from the digital pots to the TLC5940 has huge benefits: much brighter max brightness, and a colour resolution improved at least 20-fold. It does come with downsides, though. The main one is, the TLC5940 requires constant attention from the microprocessor. If too much time is spent doing something else, for example registering button presses, sending serial data, or interpreting received serial data, then the LEDs flicker visibly. Making sure that this doesn't happen has really been pushing my programming skills (which is great, because I always love a challenge). I've been able to get it running in monochrome mode without flickering, but I fear that frequently changing the colour of individual buttons might be impossible to do flicker-free in this setup. Of course, it all depends on your refresh speed. 30fps video might not be feasible, but 10fps might work; many full-colour applications that only require occasional colour changes should be fine. I think this problem could be overcome by using multiple microcontrollers, one to handle the buttons and serial I/O, and the other to take care of the TLC5940. Right now I'm not planning on taking the project in that direction (unless somebody offers me a lot of money to do it, which I doubt). If someone wants to buy my extra boards and give it a shot, you have my blessing.
The serial protocol I'm using is identical to the monome256 protocol, with the addition of the colour command. Since the monome protocol has message id's 0 and 1 reserved for messages coming from the device to the computer, I simply hijacked id 0 and use it to send colour data from the computer to the monome. I initially had some issues with commands getting misinterpreted. In particular, if you changed colours very rapidly you would sometimes get an LED turn on erroneously. This was a very annoying bug. I would think I had fixed it, test it and everything appeared fine, and then as soon as I started filming it it would pop up again. I kept trying to fix the problem in the firmware, but I finally tracked it down to a problem with the TinctSerial program and I believe I've fixed it; at the very least, the error rate is now low enough that I haven't been able to make it happen again. There were also timing issues on the receiving end: initially, the Life program was sending commands to the Tinct much too quickly, and so packets would get dropped. Another timing-related issue which was much more rare caused dropped packets, creating frameshift mutations (did I mention I'm working on my PhD in molecular biology?). These created completely unpredictable effects. I believe I've managed to quash all of these timing issues in firmware.
I caved and bought cheap Ebay RGB LEDs instead of the expensive superbrightleds.com ones. I couldn't help it, they're 1/5th the price! The quality isn't terrible: they are very bright and the colour is quite rich. The only problem is, the colours don't match from LED to LED like the superbrightleds.com ones do. Frankly, for the ~$80 I saved, I can live with it, but in a perfect world I'd use the superbrightleds.com ones.
Friday, February 29, 2008
Boards have arrived!
Wednesday was board-day for me, as both my AVR ICSP breadboard adapter (ordered from BatchPCB) and my RGB button pad (ordered from Advanced Circuits) arrived. Much to my delight (and, to be honest, a little to my surprise), they both seem to work great. If you got in touch with me about the breadboard adapters, you'll be hearing from me soon; some are not spoken for, so if you'd like one, get in touch (jmg shift-2 upwardnotnorthward dot com). Expect a full post on the RGB pad once I've got it all up and running (right now I only have four RGB LEDs, so I'm waiting for more to arrive before I can fully build it).
Oh, and Advanced Circuits included a bag of microwave popcorn with my board order. Seriously.
Wednesday, February 13, 2008
In the works: RGB monome-esque kit
Update: This kit probably isn't going to happen for various reasons. Read about it in this post.
After talking with Brian, and obtaining his blessing (and advice), I've decided to invest the money to produce a custom PCB for an RGB button pad prototype. This design is completely different than my original, offering improved colour-depth and brightness: the pre-prototyping I've done blows the old one out of the water. I hope to have the design completed and the custom PCBs in-hand by the end of the month. What I'd like to do is order a medium-sized run of these boards so that I can split the development cost with like-minded hardware hackers. These would not be "plug and play" kits by any stretch of the imagination: these would require significant extra work to get them to do anything, and comfort working with electronics. The numbers will be kept small, so we can all easily communicate, and hence people who want to participate will need to be in touch with me first. This will be nothing like the monome kits, which are much more user friendly! You have been warned! If you fit this description, I need your feedback, so please read on and respond!
There are a few ways I could do this that I'm considering, each with their own advantages and disadvantages (both for me and for you). This would only be a board with the buttons and LEDs on it, as well as the circuitry to drive the LEDs. No logic would be on-board, that would have to be handled by an external microcontroller, most likely an Arduino (although your favourite board could work, too).
What I'm most likely to make first is a 4x4 button pad design to work with Sparkfun's buttons. It would include a small overhang to hold the circuitry to drive the LEDs, which would interface serially with whichever microcontroller platform you'd like. The serial interface would only control the LEDs; the buttons' wiring would be broken out to control however you like. All of the inputs and outputs will be neatly bundled together in a ribbon cable. Code and schematics for running it off of an Arduino (and possibly other platforms) would be made freely available. It would be possible to daisy-chain multiple 4x4 boards, but this would require more complicated off-board wiring. This kit would be the least expensive option, and also offers the most flexibility. The disadvantage would be that it would require the most outside wiring to get working, especially if you're planning on chaining multiple boards.
What I'd really like to make, personally, is an 8x8 button pad on a single baord, which would include a full serial interface for both the buttons and the LEDs, as well as power circuitry on-board (an 8x8 RGB pad uses a lot of current!). It is highly doubtful that I would do this initially for several reasons: for starters, it would be a much more complicated board for me to design and test. Perhaps more importantly, it would require me to invest in the professional edition of Eagle, which is an additional $600. That's money I need to put up initially, and it's money that would have to be factored into the cost of the boards for any other developers. So, unless feedback is overwhelmingly in favour of the 8x8 pad, this would most likely come later, if the interest existed.
Finally, there's the logic board. For now (and probably forever), this would be an Arduino. If you want to hook it up to something else, then by all means you could do so; if I hook it up to something else, I'll probably post code for it. For now, though, I'm developing on an Arduino and maybe AVR, so that's what I'll offer.
In terms of functionality, it will probably be possible to make this "monome-compatible," like my monomuino project. Of course, the colour functionality would not be accesible in this mode, you would have to pick the colour you wanted to display. I can't stress enough: if you want to build a monome, buy the kits from monome! This is for people interested in hardware tinkering. This device could also be controlled with a to-be-developed custom protocol which supports full colour, but in terms of software to utilize this, it would have to be custom written. Hopefully, if we get together a group of about a dozen people to do this, we'll be able to put together some neat stuff.
Here's what I'd like to hear from you:
After talking with Brian, and obtaining his blessing (and advice), I've decided to invest the money to produce a custom PCB for an RGB button pad prototype. This design is completely different than my original, offering improved colour-depth and brightness: the pre-prototyping I've done blows the old one out of the water. I hope to have the design completed and the custom PCBs in-hand by the end of the month. What I'd like to do is order a medium-sized run of these boards so that I can split the development cost with like-minded hardware hackers. These would not be "plug and play" kits by any stretch of the imagination: these would require significant extra work to get them to do anything, and comfort working with electronics. The numbers will be kept small, so we can all easily communicate, and hence people who want to participate will need to be in touch with me first. This will be nothing like the monome kits, which are much more user friendly! You have been warned! If you fit this description, I need your feedback, so please read on and respond!
There are a few ways I could do this that I'm considering, each with their own advantages and disadvantages (both for me and for you). This would only be a board with the buttons and LEDs on it, as well as the circuitry to drive the LEDs. No logic would be on-board, that would have to be handled by an external microcontroller, most likely an Arduino (although your favourite board could work, too).
What I'm most likely to make first is a 4x4 button pad design to work with Sparkfun's buttons. It would include a small overhang to hold the circuitry to drive the LEDs, which would interface serially with whichever microcontroller platform you'd like. The serial interface would only control the LEDs; the buttons' wiring would be broken out to control however you like. All of the inputs and outputs will be neatly bundled together in a ribbon cable. Code and schematics for running it off of an Arduino (and possibly other platforms) would be made freely available. It would be possible to daisy-chain multiple 4x4 boards, but this would require more complicated off-board wiring. This kit would be the least expensive option, and also offers the most flexibility. The disadvantage would be that it would require the most outside wiring to get working, especially if you're planning on chaining multiple boards.
What I'd really like to make, personally, is an 8x8 button pad on a single baord, which would include a full serial interface for both the buttons and the LEDs, as well as power circuitry on-board (an 8x8 RGB pad uses a lot of current!). It is highly doubtful that I would do this initially for several reasons: for starters, it would be a much more complicated board for me to design and test. Perhaps more importantly, it would require me to invest in the professional edition of Eagle, which is an additional $600. That's money I need to put up initially, and it's money that would have to be factored into the cost of the boards for any other developers. So, unless feedback is overwhelmingly in favour of the 8x8 pad, this would most likely come later, if the interest existed.
Finally, there's the logic board. For now (and probably forever), this would be an Arduino. If you want to hook it up to something else, then by all means you could do so; if I hook it up to something else, I'll probably post code for it. For now, though, I'm developing on an Arduino and maybe AVR, so that's what I'll offer.
In terms of functionality, it will probably be possible to make this "monome-compatible," like my monomuino project. Of course, the colour functionality would not be accesible in this mode, you would have to pick the colour you wanted to display. I can't stress enough: if you want to build a monome, buy the kits from monome! This is for people interested in hardware tinkering. This device could also be controlled with a to-be-developed custom protocol which supports full colour, but in terms of software to utilize this, it would have to be custom written. Hopefully, if we get together a group of about a dozen people to do this, we'll be able to put together some neat stuff.
Here's what I'd like to hear from you:
- Which kit(s) would you be interested in? How many?
- The LEDs I like are from superbrightLEDs.com, and are much more expensive than ones you can find on Ebay, but much higher quality. If I bought a bulk order of those, and sold them at around cost (that's the discounted bulk cost, not the individual LED cost at superbrightLEDs), would you buy them bundled with the kit? (This would add ~$20 to a 4x4 kit, and ~$80 to an 8x8).
- Similarly, would you want the Sparkfun buttons bundled with the kit? This would save you shipping from Sparkfun.
- Can I contact you in the future with questions about the kit, and/or with announcements about the kits' availability?
- Any other questions or comments you might have
If you email me (at jmg -atsign- upwardnotnorthward -dot- com), I will not give your information out to anybody under any circumstances. I will contact you precisely once, to let you know that the boards are available, unless you explicitly give me permission to contact you more, or ask that I not contact you at all.
If you don't trust me with your email address, and never want to hear from me, then simply leave your thoughts in the comments below. That's cool, too.
If you don't trust me with your email address, and never want to hear from me, then simply leave your thoughts in the comments below. That's cool, too.
Monday, February 11, 2008
AVR ICSP 6-pin breadboard adapter
Update: the boards have arrived. If you're interested in getting one, please email me at jmg (shift-2) upwardnotnorthward (period) com.
I think I'm really starting to get the hang of EAGLE CAD; not only is it no longer frustrating, I now really enjoy designing boards in it.
I've been teaching myself about directly programming AVR chips (stay posted for an article on that), and since I'm too stubborn (and cheap) to pay for a development board, I built and have been using an Evil Mad Scientist Labs-style minimalist target board. It works great, but the problem is you more-or-less need a different board for every different type of chip you want to program, plus, you need to shuttle the chip back and forth from the breadboard to the programmer. It would be great to be able to program the chip in-breadboard, by the dual-row header pin won't allow that. You can run wires directly from your programmer to the breadboard, but that's a little messy. So, I decided to make a simple breadboard adapter for the ICSP header.
This has been done before, but I really don't like dealing with perfboard, and I was itching to try having a PCB manufactured, so I designed the adapter and ordered a bunch up from Sparkfun's BatchPCB service. My design is set up so that the Vcc and GND connect directly into the bus lines of the breadboard to save two wires later on. I ordered a bunch of extras, so if anyone out there is interested in one, drop me an email and we'll work something out (assuming they work properly when they arrive).
I think I'm really starting to get the hang of EAGLE CAD; not only is it no longer frustrating, I now really enjoy designing boards in it.
I've been teaching myself about directly programming AVR chips (stay posted for an article on that), and since I'm too stubborn (and cheap) to pay for a development board, I built and have been using an Evil Mad Scientist Labs-style minimalist target board. It works great, but the problem is you more-or-less need a different board for every different type of chip you want to program, plus, you need to shuttle the chip back and forth from the breadboard to the programmer. It would be great to be able to program the chip in-breadboard, by the dual-row header pin won't allow that. You can run wires directly from your programmer to the breadboard, but that's a little messy. So, I decided to make a simple breadboard adapter for the ICSP header.
This has been done before, but I really don't like dealing with perfboard, and I was itching to try having a PCB manufactured, so I designed the adapter and ordered a bunch up from Sparkfun's BatchPCB service. My design is set up so that the Vcc and GND connect directly into the bus lines of the breadboard to save two wires later on. I ordered a bunch of extras, so if anyone out there is interested in one, drop me an email and we'll work something out (assuming they work properly when they arrive).
Subscribe to:
Posts (Atom)
