Dr. Damien's Development - The Xylophone Project I - Data Acquisition Concept

[DFGray]

I am currently working on a xylophone/marimba tuner to aid in making xylophone bars for a homemade xylophone. This project will be the basis of my next few posts showing the process of creating a solid LabVIEW application. For this post, we will look at the first stage - concepts.

First, we need to know what we are trying to do. The resonant frequencies of a rectangular block of wood are not integral multiples of each other. This results in a discordant sound, especially in larger blocks. The resonant frequencies can be tuned by selectively shaving the wood. However, we need to determine what resonant frequencies exist and how far they are from being integral multiples of each other. This is the purpose of the LabVIEW project. For more information about tuning xylophone/marimba bars, check out this reference.

Attached is my first try at data acquisition. Since we are tuning a musical instrument, we use the sound API. In this case, we use a streaming method in a producer/consumer architecture. A software trigger is used to determine the start of the note being struck. A data subset is then taken for FFT analysis.

This VI is useful to determine the design parameters of the final product, such as trigger level and signal duration. It can also give some ideas for GUI. While this code is functional, there are only two frequencies visible and their ratios are not shown. It works for data acquisition, but is a poor GUI.

Next week we will continue the concept phase with GUI design concepts.

[Ben]

Thank you Dr Gray!

So let me summarize some leasons from this post.

1) Prototype code is NOT a finished application. Prototypes are used for adderessing risk factors and detemining design requirements.

2) Determine your design BEFORE you start to code your application.

Ben

[Andrey_Dmitriev]

I also would like to say thank you, DFGray, its a nice idea to show whole process of creating a full application from the beginning to the end.

Also I agree with Ben - prototype is far away from completed application (but always good for proof of the concept).

For "full" process we should going through requirements/design phases, and it will be very good if you will include these steps into your project, otherwise it will be not fully complete process.

For example, I usually follow the steps for commercial applications:

Idea->Marketing Functional Specification -> Software Requirements Specification -> Design Requirements Specification -> Development -> Proof of requirements coverage->Testing -> Release

or with prototyping

Idea->MFS->Small Prototypes and snippets->SRS->Solid Prototype->Design->Development->Proof->Testing->Release.

I see nothing wrong if small pieces of code from prototypes will be transferred into final application - they just should be fully covered by Test Plan.

From my point of view it will be nice if you will use Requirements Gateway in this project - I would like to see this tool in action.

Best regards,

Andrey

PS

The only problem - that Xylophone is required for this project. Just played with your VI without xylophone (I have simulate it myself with continuosly pronounced aaaaa... uuuuuuu... ooooooo...) - my colleagues was nearby ready to call emergency for the doctor... 🙂

[F._Schubert]

I am joining Ben and Andrey in the big 'Thank you' and the demand for a lesson covering the full developement cycle of a product.

My point would be at least to create a document of detailed software requirements, such as 'Pause' and 'Reset' functionality, followed by a overall architecture (DAQ, Analysis, Presentation, Configuration, File I/O, ...) and a detailed architecture (Producer, Consumer, State Machine, AE, Plug-In)

Another thing I consider important is Error handling. In the prototype, the consumer looks good, but the producer is flawed. Any error in the DAQ chain is not propagated, so the VI would run on max CPU and the user would see nothing until he/she presses stop.

I consider this important, because at such a early developement stage, there is likely to have errors occuring (wrong parameters for the DAQ device). There is some saying, that code always needs minimum the same amount of code for error handling.

I think, that earing these rants from the community is a sign, that we need/want more such 'projects' (most of the posts are fix/improve one VI or showing nice little tricks and tweaks). Architectural design is a pretty joyful task, but gives you some hard working days (month's, years...) when done with to less foresight.

Felix