Help getting started with Netduino project

Hello, I am new to the Netduino Plus world. I am familiar with .NET and was part of the original beta and use .NET as part of my day to day work. I am familiar with the .NET Compact Framework and have used it extensively. When I am not programming, I do a lot of photography and have written .NET code to interface to an Olympus camera. As a side project and to help me with a photograph I want to take, I thought I would try my hand at a netduino Plus project. However, I am a software guy, I am not a hardware guy and my last digital class was back in 1990. Here is what I would like to create: I would like a device that when a button is pressed generates a random audiable sound that would then cause a timer to start, the device would then record an split time when "it" hears a sound. For example, the crack of two sticks being slammed together and continues to record splits until a predetermined number is reached (e.g 10 cracks of the sticks) or when the button is once again pressed. I then want to output these splits and total time to a laptop. The device should have an LED or LCD that displays the running time, at a min the last split or best case, up to 10 splits. I have no idea what hardware components I need or how to wire them up. I have purchase a basic digitial breadboard with a book to help me learn/remember but I was hoping someone can help me with netduino Plus specifically. Any other books, PDFs etc you can recommend would also be helpful

Hello TurboPascal, and welcome here. Your nickname reminds me my "golden age" about programming. I am not sure to understand your goal at all. You'd like to create a device having a button. When the button is pressed, a sound must be generated. Which kind of sound? How long? That sound should start a timer. So, the button itself could start the timer? Have to be a kind of "microphone" to "hear" the sound? Then you talk about "record". What do you mean about "record"? Are you expecting to capture several snapshots from your camera via Netduino? Also, it is not clear to me the exact role of the display and the PC/laptop. Cheers

Hello TurboPascal, and welcome here. Your nickname reminds me my "golden age" about programming.

I am not sure to understand your goal at all.
You'd like to create a device having a button.
When the button is pressed, a sound must be generated. Which kind of sound? How long?
That sound should start a timer. So, the button itself could start the timer? Have to be a kind of "microphone" to "hear" the sound?
Then you talk about "record". What do you mean about "record"? Are you expecting to capture several snapshots from your camera via Netduino?
Also, it is not clear to me the exact role of the display and the PC/laptop.
Cheers

I cut my teeth with Borland Turbo Pascal thus the name. I still have all my Borland and Delphi books but I primarily work on C# and Java these days with my preference being C#.

Ok, maybe I can explain this better in this way:

1) User presses a button which initiats a buzzer or other type of audiable sound after a random delay of 1 to 5 seconds. The sound is emitted through a small speaker. The sound is to allow a human to know to start an activity. When the buzzer sounds it also simultaneously begins a timer.
2) When a certain "known" sound is recorded (heard) by the device, the device after validating it was a valid sound, trips the timer and records the split however the timer continues to run. The split time and the running time are both displayed on the LCD screen for a user to see similar to a stop watch.
3) After a predetermined number of "known" sounds are recorded (i.e.) and the split times for those sounds are saved, then the timer stops and the time at which everything has stopped is recorded (total elapsed time since initial button press). Optionally, the user can press the button to stop the timer (total elapsed time since initial button press is then saved).

When I say, "known" sound, I mean I want to record a sound -- for example, a hand clap, a bottle breaking, two sticks struck together and I only want to record the split for sounds that device records that are very close to the originally recorded sound. For example, if I record the sound of a bottle breaking, I do not want the timer to trip because of someones voice, only of other bottles breaking. Bascially, the timer is tripped based on the know amplitude and frequency of a sound within certain thresholds.

I want to be able to take all the data I record -- sounds, intervals, split times, total times and I want to connect the netduino device to a laptop so I can take that data put it into a spreadsheet or other program and then analyze the information. Ultimately, this would then allow me to set my camera to capture certain events in high speed without guessing.

And while there are commercial devices that do do this already, they are far more than what I would like to spend and I figure this will be more fun and I can tweek to my hearts content -- ultimately interfacing to my DSLR

Sorry if I was too vague in my initial question.

Now your goal is surely more clear. The only info missing is about the magnitude of the times involved, and their precision. Until you don't ask time accuracy under 5-10 ms, (almost) everything could be realized. However, the biggest problem is the sound recognizer. What you are asking is much like a sound recognizer, than a simple freq/amp detector. Otherwise the circuit would be very very easy to realize. A generic sound is composed of many frequencies composed together, having an amplitude changing over time. For instance, you may play the A note both on a guitar, and on a flute. Both the instruments generates two different sounds having the same frequency (e.g. 880 Hz), maybe the same amplitude as well. However it is clear that you hear two totally different instruments. I don't know what's the best way to realize a sound recognizer, surely you can not do it using a Netduino, and probably you need a DSP. A possible approach could be done via correlation: record your reference sound as a bunch of samples (e.g. wav); to detect, the sampler will sample the microphone as a continuous stream; the "most recent" part of the stream is taken and "correlated" with the reference. The result of the computation gives "how many the pattern is matching the reference". Another approach would be using the neural-networks, similarly as they are used for the handwriting recognition. In both the ideas the calculations are a lot: you must use a very good machine such a fast PC or a good DSP. Anyway, I surely will choose to buy one! Cheers

Now your goal is surely more clear.
The only info missing is about the magnitude of the times involved, and their precision.
Until you don't ask time accuracy under 5-10 ms, (almost) everything could be realized.

However, the biggest problem is the sound recognizer.
What you are asking is much like a sound recognizer, than a simple freq/amp detector. Otherwise the circuit would be very very easy to realize.
A generic sound is composed of many frequencies composed together, having an amplitude changing over time. For instance, you may play the A note both on a guitar, and on a flute. Both the instruments generates two different sounds having the same frequency (e.g. 880 Hz), maybe the same amplitude as well. However it is clear that you hear two totally different instruments.

I don't know what's the best way to realize a sound recognizer, surely you can not do it using a Netduino, and probably you need a DSP.
A possible approach could be done via correlation:
record your reference sound as a bunch of samples (e.g. wav);
to detect, the sampler will sample the microphone as a continuous stream;
the "most recent" part of the stream is taken and "correlated" with the reference.
The result of the computation gives "how many the pattern is matching the reference".
Another approach would be using the neural-networks, similarly as they are used for the handwriting recognition.
In both the ideas the calculations are a lot: you must use a very good machine such a fast PC or a good DSP.

Anyway, I surely will choose to buy one!
Cheers

Thank you for the reply, time is not that critical because there are other losses that cannot be compenstated, for example, a camera flash is only so fast and so is the time for a camera to actuate the trigger. something in the 30ms range would work if my math is correct.

I am just playing around, do you have a recommended mic and speaker setup I can start with just to get started with hooking things up. Baby steps!

Thanks