Advances in DSP over these past couple decades have been responsible for some of our most important technological leaps — MRI scanners, mobile phones, digital image sensors, etc. — but despite that, it doesn’t always get the attention or interest it deserves. Unfortunately, the reason for this bad reputation is woefully clear: most of the literature out there on DSP is extremely opaque, heavily focused on the theoretical not the pratical, and it all tends to be written by domain experts for domain experts, steeped in their own distinct domain language. There’s room and a need for all of that … but it does make it pretty rough for non DSP people to take advantage of some of the enormous benefits even the simplest DSP algorithms can offer.
Thankfully, people interested in improving the reliability and usefulness of their data have a friend in Dr. Stephen W. Smith, author of “The Scientist and Engineer’s Guide to Digital Signal Processing“. Dr. Smith not only provides an excellent overview of many of the key concepts and filters you’ll use solving problems in the real world day to day, but he does it in an extremely easy to understand and accessible way, with an emphasis on implementation not just abstract theory (though the theory is often explained with clarity and reasonable depth as well). A lot of the most common DSP ‘filters’ and algorithms are covered — FFT, FIR, IIR, moving averages, etc. — and they are all accompanied with intentionally ‘basic’ implementations in code in … well … Basic.
In an particularly enlightened stance, Dr. Smith also takes the unusual step of letting you decide entirely for yourself if this is the right book for you, since the entire book is available online free or charge, chapter by chapter in PDF format! You can get printed copies of Amazon, and if you find the book useful it’s worth support the author (I ordered my copy 20 minutes after digging into a single chapter), but if you’re on a tight budget, you’ll be bound to appreciate his generous and open gesture!
Any other good DSP resources for beginners out there that your found noteworth? Toss them up in the comments below so other people can benefit as well!
While this is somewhat of a specialised book, if you have to do any work with image processing (OCR, shape recognition, etc.), there are some good frameworks out there, but there’s hardly an abundance of easily accessible information on the subject if you need to implement something yourself. Algorithms for Image Processing and Computer Vision (2nd Edition) is one of the better books available, and while — like most specialised technical books — it isn’t cheap, it is a good value given the amount of information it covers in one place.
You’ll wanna pull up a really comfy chair before you dive into this one, but have you ever found yourself digging through Eagle’s 317,424 different canned footprints, hoping one is kinda, sorta, almost, maybe good enough for that new sensor you found on Digikey? Shamelessly dig and despair no more! … Our new mammoth guide on creating manufacturable footprints in Eagle is here to ween you off that nasty canned footprint habit, and get you firmly on the road to non-dependency!
Microchip has a great app note where they’ve compiled all kinds of useful little SW and HW hacks as a ‘tips and tricks’ guide. wondering how you can connect a bunch of switches or buttons to a single pin? They’ve got you covered. Have a look at Compiled Tips ‘N Tricks yourself to see what problems you can solved differently on your next project.
Probes have a significant effect on the signals you see on your scope at high speed, and you need to be particularly careful with the GND connector to avoid large ground loops which will distort you signals. Have a look at this informative video on the topic from mikeselectricstuff, showing how to capture some high speed output from an iPod nano.
While we really suggest buying the NFC Breakout for use with libnfc (it was literally designed with this goal in mind!), Jerome Bernard posted up some details on getting the NFC shield working with libnfc on a Mac. Thanks Jerome for taking the time to share the details with other shield users. Have a look here!
Digging around for some information on MEMs gyroscope manufacturing processes, I came across this excellent white paper that explains a lot of the options that manufacturers have making low cost gyroscopes. MEMs is a really fascinating business to be in, with very real manufacturing challenges, but some very unique opportunities as well. Most of the driving force behind MEMs in recent years has been smart phones — by far the single biggest market for MEMs gyros! — but the DIY and HW world definitely benefits from this since it’s never been cheaper or easier to get high quality motion sensors. Curious how MEMs gyros are made? Have a look at: A Critical Review of the Market Status and Industry Challenges of Producing Consumer Grade MEMS Gyroscopes from Invensense.
Our TSL2561 digital light sensor has always been a popular breakout. Part of what makes this board so useful is actually the Adafruit driver, and that extra bit of effort that went into providing useful values like ‘lux’ instead of 0..1023 etc. It’s easy to get raw data out of any sensor, but that’s not always very useful if you want to do something useful with these sensors. Raw data needs to be converted to real world values, but this often takes more work than everything else in the driver put together, at least if you care about accuracy.
Using the Lux Equation from Taos gives a good overview of what’s involved in taking that raw sensor data and making it useful, taking into account easy to overlook values like the glass attenuation factor, etc. If you’re interested in things like color correction, Calculating Color Temperature and Illuminance also has some good details on accurately converting RGB sensor data to color temperature.
Part of the motivation behind the new Adafruit Unified Sensor system is to make it easier to give people real world values without having to do all kinds of matrix multiplication yourself … but sometimes it’s useful to see what goes on behinds the scenes, and know how to calculate some of this stuff yourself as well. All the real magic is in the fine print and the details!
Working on a driver today, I had an excuse to dust off some long forgotten .Net tools. In case other people aren’t aware of how easy it is to decompile apps written in .Net (and why this is useful even for HW people), have a look at our new learning guide: Decompiling .Net Apps
I’ve been on a bit of a sabbatical leave these past few weeks, just to take some time to recharge my creative (and technical) batteries. I love what I do, and I feel lucky to be able to design, build and test interesting stuff all day long. Most of all, I love seeing how people take that work and do amazing things with it. I can’t overstate how grateful I am to be a small part of this amazing community! But sometimes — even in a situation or job you love, with colleagues you appreciate, etc. — you really need to step back and try to remember what got you excited about this stuff in the first place … to make sure you’re focusing your attention on the right things with the right priorities.
A big part of the reason I wanted to take a bit of a break was to look at all these (literally) hundreds of drivers I’ve written, boards I’ve designed, chunks of code I’ve collected, and see what can I do with it all. I’ve never had easier access to more data, more easily, but it’s never seemed more challenging to do something genuinely creative and useful with it. I’ve spent my last few weeks trying to finalize a pair of boards that themselves aren’t terribly interesting (there are probably a couple hundred wireless sensor platforms out there!), but it’s really just a spring-board for some other ideas I wanted to explore trying to visualize some of the amazing invisible stuff that goes on around us. I posted some technical details up about them on my own website, but honestly the technical side is secondary and I rolled my own just to use the parts I’m familiar with and already have a zillion drivers for.
I’ll post some more details about some of what I wanted to do with these boards once I get the first batch in and have 100 or so assembled later this month, but I thought it would be fun to mention what I was up to all the same … even if in this case the core platform isn’t really the main objective! LPC1xxx 1GHZ Wireless Board Preview
Adafruit has always prided itself on going the extra mile. We always try to provide the the best breakouts possible, but we also put that extra bit of effort into making sure we have a driver for each of those products as well. You want to get started with your new HW as soon as you pull it out of that box … we’re happy to try to make that possible to the best extent that we can! Call it the Adafruit Difference.
That said … writing all those drivers can be pretty time consuming, and then you need to add some example code on top of them to show how the driver works. While I was digging around inside the Android source code for something different, I noticed the intelligent way they abstract away all sensor data down to a single C typedef. The dial went straight to 11 in my head, and the first thing I thought was: ‘why am I not doing this?!?’. I pulled out an MCU and tried to adapt the Android code (conveniently written in C), slimming the typedefs down a bit, adding a couple sensor types, … but keeping the same general structure. After a bit of trial and error, the Adafruit Unified Sensor Driver was born. Driver use and development will never be the same (at least for me)!
We have a reasonably complete tutorial on how the Unified Sensor Driver System works … but you can also have a look at the source code for Adafruit_Sensor on github. In a nutshell what does this do, though? Essentially, it takes any supported sensor type (accelerometers, gyroscopes, pressure sensors, light sensors, etc.) and converts the raw units used by the system (0..1023) into standard SI units on a specific scale. Every accelerometer using the system will report acceleration in m/s^2, pressure sensors will all use hectoPascal (hPa), light sensors use SI lux units, etc.! No more 0..1023 … you get units you understand out of the box and every time!
Don’t know which accelerometer to use, or what speed or resolution you need? No problem … start with whatever you’ve got, and you can just drop in any other ‘Unified’ sensor later. You’ll get exactly the same SI unit types and scales, call the same two functions, and all you need to change in the single line constructor! No more out of stock headaches … just take any other similar sensor and use that as a stand-in, and you don’t have to relearn a whole new driver and set of functions.
But have a look at the learning guide, the source code, and try it out if you have a product that currently has a ‘Unified’ drivers (there’s a list here). And above all, let us know what you think and what can be improved. This is still a bit of an experiment for us, but it definitely feels like the right direction to move things!
I just got back from a quick day trip to Embedded World in Nuremberg. EW is one of the better embedded shows since it’s a lot more engineering and lot less marketing than some of the competing shows in Europe (Electronica, etc.). Click on through if you’re interested in my thoughts on my brief (if somewhat difficult to digest!) trip to Europe’s best show! (more…)
Some good news for fans of the popular mbed platform … the core libraries are now available on github under an open source license! You can read the announcement here, but this is good news for a platform that was already very easy to use and powerful, and this announcement will hopefully get people who might have been turned off but it’s semi-closed nature to take another look! Curious what it’s all about? You can grab an mbed right here and get started with ARM yourself today!
Switching power supplies can offer much better efficiency than linear supplies, but they’re also a bit trickier to get working and require more components and more precise component selection. How do you evaluate switching more power supply circuits? In reality there are a lot of parameters to test often requiring specialised equipment — things like a DC load to test efficiency, special probes for your scope, etc. — but there’s a good article at Scope Junction on the topic: Stability Testing A Switching Power Supply.
The articles assumes you have access to some fairly high end equipment (a network analyser, etc.), but it’s an interesting read just to see some of the real world considerations that you need to keep in mind with commercial design and how much testing really goes on (or should go on) in the manufacturing process.
Some manufacturers do this better than others. I have vivid memories of working as an apps engineer being tasked with helping a Japanese company using a brand new and complex MCU in their product. Every time I saw an email from them in my inbox (daily) I winced because I knew it would be another incredibly precise question involving very specific values or test conditions and I’d have to call up the chip design team to get the test parameters and see what was up … it was never much fun, but it did instill in me a lot of respect for the testing efforts they went through, and sometimes they were right and identified one or two issues that got past the validation team MCU side. It was a wakeup call for everyone, but a good one. Testing matters, and often testing can be as much or more effort than initial product development.
Have any horror stories where you wish you had put more effort into testing yourself or had to compromise because of deadlines and it ended up biting you in the back-end? Post them up in the comments below!
Adding a LIPO battery charger to your latest project? You might find AN10910 worth reading from NXP, which presents some strategies to reduce the risk of working with LIPO cells and battery charging in general.