Project 13 - Piezo Knock Sensor

Project 13 uses the Piezo as a sensor... be sure to plug it into Analog pin 5 and not Digital pin 5! (Made that mistake and took me a few minutes to figure out what was wrong.)

When the program runs, the LED blinks twice to indicate the program is running... then it patiently waits for you to tap the Piezo. The video shows it in action.

Sorry for the rat's nest of wires... because I'm using a slightly different type of screw terminal, I used the jumper wires to allow me to share the GND pin. The MakerShield is still making it very easy to wire up these circuits so I'm taking advantage of it while I still can.

One question this program raised - the last bit of the code:

if (ledValue <=0) {ledValue = 0;} I'm not really understanding why this is required (although it is - see Video 2)... if ledValue drops below 0 and goes negative, the ledValue variable should simply jump to 255 when the Piezo is tapped, so it's not like the variable has to count up from a large negative value or anything. My best guess is that there must be a lower limit to the variable and when it hits it, it then "rolls over" back to 255. I may not be expressing that in the proper terminology, but... am I right? Wrong? Anyone have a better explanation for the pulsing?

BTW - A variation of this project is featured in Make magazine, Volume 25 - it's a candy dispenser that uses this technique to "listen" to a person's knock - if the knock is the proper tune, a piece of candy is released down the chute. You can watch an interview with the builder and see it in action in this video.

Make Live

I can't believe I forgot to post about this, but two Wednesdays ago (Jan 26) Makezine.com premiered the first Make:Live online broadcast. The topic of the night focused on the Arduino (and it's also the topic of the latest issue of Make - Volume 25).

The Make: Live event is supposed to occur ever other Wed, so that means a new broadcast will happen tomorrow at 9pm EDT. If you missed the first broadcast, they've collected the highlights of the event in a collection of videos that you can view here. (Scroll down and look for Episode 01 labels.)

Tomorrow's episode will focus on soldering. As I've stated in previous posts, my soldering skills could handle an upgrade... I'm hoping to see or hear something tomorrow that will give me a +1 bonus to my Soldering ability.

Hope to see you there... I'll be logged in as JamesFloydKelly.

Project 12 - Piezo Sounder Melody Player

A fun little project, but I have to say the Piezo buzzer is not my favorite choice of noisemaker. I'm not sure if the video quite captures just how grating the high pitch squeals really are...

One thing I really was glad to learn in this project was the ability to use the #define command to equate a value with a token. Similar, I guess, to a variable, but the value cannot be changed in the program (only at the #define statement). The author did a good job of explaining why this feature is useful with the dot matrix display example... makes sense if you think about it - substituting in a larger display is simple when all you have to do is change the height and width values in the #define statements.

It was also nice to be able to download the code rather than type it in - typing in all those #define statements followed by the tune and the duration information would have been tedious (probably good to do just to hammer in the idea, but I think I've got it...)

One thing I'm still not clear on, however, is the discussion of the length variable. The author divides 26 (notes) by 2 (the number of bytes in a single element) to get a value of 13. The loop will count from 0 to 13, playing the tune(x)... the way I'm reading this seems to indicate only the first 13 (of 26) notes will get played. Am I missing something?

I'm including a video below that I hope doesn't annoy anyone in the room (or office) - it's definitely Puff the Magic Dragon, but I'd never play this for my 8 month old with a Piezo!

Green Appeal

I've ordered a LOT of electronics components over the past 13 months, many of it for my previous blog that covered my work through the Make: Electronics book. One really annoying (to me) business practice I've seen time and time again is best summed up with the included picture here.

On the left is the box I got from Kingbrightusa.com that contained two small plastic baggies, each with a single 8x8 LED. On the right is a small box I got from sparkfun.com that contains a total of 11 different components ordered, packed nice and tight (and with bubble wrap) and shipped in an envelope that was only slightly larger than the box.

By and far, the worst I ever received was a box larger than the one on the left from Mouser.com that contained a single relay. One. Relay. Smaller than a golf ball.

I'm part of the problem, of course... I try to save funds and gas by ordering online rather than driving all over Atlanta buying up pieces from various vendors. Yes, I pay more at Radio Shack, but I'm really starting to think that the amount of gas I use in my truck has to be less than the amount of fuel these big boxes take (by air and ground vehicles).

I'm glad to see that these companies want to protect my order and keep it from getting damaged, but there's got to be a better way. I really have to give a HUGE hand to sparkfun.com for their efforts in reducing waste - I have a strong feeling this is a choice they've made and not just happenstance. And even if they are trying to save money by using less packaging, that's still a big plus in my book.

So... I guess what I'm trying to say is try and order from sparkfun.com if you can... if this kind of thing bothers you. And please let me know if you are aware of other electronics supply companies that don't just throw a couple small resistor bags into the nearest shoebox (or larger).

Sorry for the rant... now back to the blog.

Project 11 - Piezo Sounder Alarm

Project 11 is very simple to wire up... and the program is one of the shortest we've seen so far. It uses a sine wave, again, to generate values that fluctuate, allowing the piezo buzzer to warble like an alarm.

I've got the sound from the unedited program playing in the first video. It's loud... and obnoxious. This would definitely annoy a brother or sister who entered your room without permission! I modified the variable value to start with a base of 1000 (instead of 2000) and the alarm has a lower tone... but still loud.

I'm amazed at the volume generated from this tiny device - it was the smallest one in the bins at Radio Shack. I'm sure the larger ones require more voltage, but little fella is rated for between 3 and 20 volts. I'm glad I'm not hitting it with 20 volts!

Project 10 - Serial Controlled Mood Lamp

Project 10 opened up a lot of questions - all of them related to the code and not the actual electronics. I have to admit that I read over this project about four times, just trying to get my hands around the code. (The pseudo code at the end of the project is very helpful - read it!) But still... there are a LOT of things in this project that are not likely to be familiar to those new to programming. For instance, on page 72, the author refers to a "pointer" - I know what that is (and sort of how it works) but it may be totally new to some readers... (the author does explain it briefly, but it's BRIEF and really more confusing IMO than anything else... but chalk that up to my limited C/C+ and general programming knowledge in general...)

Let's see... what else...

I think there's also an assumption here that the reader will understand that the Serial.available command is not going to start until the Enter button is pressed and sending your RGB values but that's not expressly stated.

There's also no explanation of why the numChar is limited to 15 characters. I'm guessing that spaces are ignored, because in the example "R255, G255, B255" (including the ending NULL), if I count the spaces, I'm getting 17 characters just as the author states... but if it gets cut to 15, that means the last 2 characters get deleted, right? If not the NULL, then at least the '55' at the end of the 'B255' - I may need someone to explain this a bit better.

Page 73 - the author explains the * as designating a pointer, but he states it's been added to the variable name as '*data' - but the code in the book and the code I actually ran has the * added to the char data type - char* - any ideas why? Simply a typo?

The rest of the code, especially parsing the RGB code you type in and having it checked and then routed to the right LED - got it. Not a problem.

Overall, I like the power that Project 10 demonstrates (controlling things via a keyboard) but much of the code is still confusing to me... and I imagine it will be to a lot of readers. I certainly don't have time to dive deep into the C/C+ programming language right now, so I'll just accept that not everything makes sense right now and take what I can and move on...

Project 9 - LED Fire Effect

Project 9 was easy to wire up - I simply replaced the RGB LEDs from Project 8 with two yellow and one red LED. The resistor values are high enough that I don't have to worry about burning them out.

Without the diffusion provided by the white paper, the flicker is easily visible to the naked eye. I got a much better result getting the fire effect as you can hopefully see in the video. Once again, I didn't have to modify the author's code for Project 9, so no screen capture of my code here.

Also, I'm still using my MakerShield here... the mini-breadboard is just the right size for these early projects, but the upcoming projects are going to require a bit more space and a larger breadboard. Still, it's a nice little shield and definitely reduces the clutter for these smaller experiments.

I spent a few minutes digging around looking for two white LEDs (I know I have a few somewhere) but couldn't find them... so I'm not going to attempt the extra modifications for Project 9 (welding effect and rescue vehicle lights). The Welding Effect would simply require tinkering with the random flickering of the blue and white LEDs... and the Rescue Vehicle Effect would require a non-random timing of the red/blue LEDs...a trivial task at this point in time.