Day: December 10, 2015

There’s a Maker Faire in three weeks, and your group wants to design and build a binary watch to give to attendees. You don’t have much time, and your budget is $3 per watch. What do you do? If you are [Parker@Macrofab] you come up with a plan, buy some parts, and start prototyping.

[Parker] selected the PIC16F527 because it had enough I/O and was inexpensive. A cheap crystal and some miscellaneous discrete parts rounded out the bill of materials. Some cheap ESD straps would serve for a band. He did the prototype with a PICDEM board and immediately ran into the bane of PIC programmers: the analog comparators were overriding the digital I/O pins. With that hurdle clear, [Parker] got the rest of the design prototyped and laid a board out in Eagle.

There is surprising variation in the performance of SD cards. They are not all created equal and the differences can impact the running of your Raspberry Pi, no matter which model. [Jeff Geerling] wondered exactly how different cards would affect system performance. He ran a number of tests on cards ranging from cheap no-names to well-known brand names. The no-name cards fared pretty badly but even among the brand names there is considerable variation.

[Matt] over at Raspberry Pi Spy also tested SD cards and found similar differences. Both tested microSD cards. [Jeff’s] tests were solely on the Pi while [Matt’s] were on Windows 7, Ubuntu, and a Pi.

The discussions in the blog about what to measure were as interesting as the actual results. That lead to determining which software tools to use for the measurement. For example, a system doing a lot of small database reads and writes might work better with one SD card while a system storing and then streaming videos might work better with another card. Another interesting result is that the Pi’s data bus greatly limits the access speeds. [Jeff] measured much higher speeds running the same tests using a Mac with a USB dongle. The cards are capable of much more than the Pi can deliver.

[Matt] also checked the capacity of the SD cards. There are a lot of fakes floating around marked with higher capacities than they actually support. Even getting a brand name card may not help since some are counterfeit. So beware: if the price it too good to be true, it very well may be.

Almost by definition, the coolest technology and bleeding-edge research is locked away in universities. While this is great for post-docs and their grant-writing abilities, it’s not the best system for people who want to use this technology. A few years ago, and many times since then, we’ve seen a bit of research that turned a Kinect into a 3D mapping camera for extremely large areas. This is the future of VR, but a proper distribution has been held up by licenses and a general IP rights rigamarole. Now, the source for this technology, Kintinuous and ElasticFusion, are available on Github, free for everyone to (non-commercially) use.

If you’re thinking about using a Raspberry Pi to take Kintinuous on the road, you might want to look at the hardware requirements. A very fast Nvidia GPU and a fast CPU are required for good results. You also won’t be able to use it with robots running ROS; these bits of software simply don’t work together. Still, we now have the source for Kintinuous and ElasticFusion, and I’m sure more than a few people are interested in improving the code and bringing it to other systems.

What’s it like to build a run of 100 prototypes in your basement? Get a first-hand account as [Zach Fredin] discusses his development and production of NeuroBytes. The system is a set of electronic models that represent neurons. Connecting them together into different networks helps to teach about how the human nervous system works. It’s a wonderful concept, and was recognized as a finalist for Best Product in the 2015 Hackaday Prize. More recently, [Zach] tells us it has been granted Recommended Status for a Phase I SBIR National Science Foundation grant. Looks like [Zach’s] new job is all NeuroBytes and is well funded. Congratulations!

Check out [Zach Fredin’s] talk from the 2015 Hackaday SuperConference, then join us after the break to dig further into the details of the project.

Projectors are getting a lot less expensive these days, what with China pumping out Pico projectors by the boat load and all. But did you know it’s not that hard to convert an old slide projector to digital? [Alec Smecher] shows us how with a 1950’s LaBelle 75 slide projector, and the result is pretty awesome.

Digital projectors can use a few different technologies to work. The best, and brightest is DLP (Digital Light Processing) by Texas Instruments — which is pretty well the world-wide standard for high-end, high-lumen digital projection. It works by bouncing red, green, and blue light off of three DMD’s (Digital Micromirror Devices) which have an array of tiny 2-position mirrors, with each representing a pixel.

One of the older technologies is LCD, which is even easier to understand. You shine white light through a color LCD, and there is your projection. All you need for a projector, then, is an LCD, a light source, and a bit of optics.

If you’ve ever turned a rotary encoder or pushed a cursor button and had it skip a step or two, you’ve suffered directly from button bounce. My old car stereo and my current in-car GPS navigator both have this problem, and it drives me nuts. One button press should be one button press. How hard is that to get right?

In the last session of Embed with Elliot, we looked into exactly how hard it is to get right and concluded that it wasn’t actually all that bad, as long as you’re willing to throw some circuitry at the problem, or accept some sluggishness in software. But engineers cut corners on hardware designs, and parts age and get dirty. Making something as “simple” as a button work with ultra-fast microcontrollers ends up being non-trivial.

And unsurprisingly, for a problem this ubiquitous, there are a myriad of solutions. Some are good, some are bad, and others just have trade-offs. In this installment, we’re going to look at something special: a debouncer that uses minimal resources and is reasonably straightforward in its operation, yet which can debounce along with the best of ’em.

In short, I’ll introduce you to what I think is The Ultimate Debouncer(tm)! And if you don’t agree by the end of this article, I’ll give you your money back.

If you read Hackaday regularly, you’ve probably heard that you can use a LASER to create graphene. There’s been a bit of research on how to make practical graphene supercapacitors using the technique (known as LIG or LASER-induced graphene). Researchers at Rice University have been working on this, and apparently they’ve had significant success inducing graphene capacitors on a Kapton substrate. The team has published a paper in Advanced Materials (which is behind a paywall) about their work.

In particular, Rice claims that they have easily produced supercapacitors with an energy density of 3.2 mW/cubic centimeter (that’s what the University’s website reports; they probably mean mW-hours/cubic centimeter) with capacitances near one millifarad per square centimeter. A key benefit of the construction method is that the capacitors continued to work after researchers bent them 10,000 times. A flexible capacitor is useful in wearable devices that would often flex, or in a device like a cell phone that could bend in your back pocket as you sit.