Fullscreen HTML5Med Res (??MB)HTML4

SILICON SILIC CHIP www.siliconchip.com.au Publisher & Editor-in-Chief Leo Simpson, B.Bus., FAICD Production Manager Greg Swain, B.Sc. (Hons.) Technical Editor John Clarke, B.E.(Elec.) Technical Staff Ross Tester Jim Rowe, B.A., B.Sc Nicholas Vinen Photography Ross Tester Reader Services Ann Morris Advertising Enquiries Glyn Smith Phone (02) 9939 3295 Mobile 0431 792 293 glyn<at>siliconchip.com.au Regular Contributors Brendan Akhurst Rodney Champness, VK3UG Kevin Poulter Stan Swan Dave Thompson SILICON CHIP is published 12 times a year by Silicon Chip Publications Pty Ltd. ACN 003 205 490. ABN 49 003 205 490. All material is copyright ©. No part of this publication may be reproduced without the written consent of the publisher. Printing: Hannanprint, Noble Park, Victoria. Distribution: Network Distribution Company. Subscription rates: $105.00 per year in Australia. For overseas rates, see our website or the subscriptions page in this issue. Editorial office: Unit 1, 234 Harbord Rd, Brookvale, NSW 2100. Postal address: PO Box 139, Collaroy Beach, NSW 2097. Phone (02) 9939 3295. Fax (02) 9939 2648. E-mail: silicon<at>siliconchip.com.au ISSN 1030-2662 Recommended and maximum price only. 2  Silicon Chip Publisher’s Letter Do microcontroller projects have too many features? One of the advantages of products with microprocessors is that it is often very easy for the designer to incorporate additional features with little or no increase in circuit complexity. And so it has been with SILICON CHIP projects. Invariably there is a temptation on the part of the designer to add this or that feature to make it more attractive to the end user. However, as the hard-nosed Publisher of the magazine, I often wish that they simply wouldn’t do it. First, it adds options and choices and that, to me, is “bad”. Every choice and option means that there is the chance that it will confuse the project builder and that means we get emails from readers seeking clarification. Second, adding options means more programming time involved in developing the product. And invariably that means that more bugs have to be found and fixed. Moreover, more operating features inevitably mean that we have to take up more space to describe them in the magazine. You can see where I am coming from. In theory, we subscribe to the KISS principle (Keep it Simple, Stupid); in practice, we often don’t. And so it has been with our new DAC project which we have featured over four issues, this issue being the last. This is a classic microprocessor-controlled project; lots of features in a relatively simple circuit. It is all in the programming, you see. In fact, it wasn’t until Nicholas Vinen had finished writing this last article that some of the more abstruse features were revealed. So when I was reading the article, one side of me was saying “This is more complicated than it needs to be and Nicholas has really got the bit in his teeth this time” while the other side was saying “That’s really clever etc”. I won’t tell which side was dominant . . . So the DAC project is not just a DAC. For a start, it is a playback device in its own right and it will decode WAV files, with various sampling rates, stored on an SD card. It also incorporates a headphone amplifier with its own front-panel volume control. Both of these were included in the long list of features in the first article. Somewhat less obvious in that same list of features was digital tone control and headphone cross-feed. Not mentioned at all, was digital volume control via the infrared remote control and to top it off, loudness compensation to the ISO specification. Now digital volume control with the infrared remote I regard as highly desirable, if only for its convenience. I also regard it as the best method from a sound quality point-of-view, even though some audiophiles regard digital volume control as undesirable because it involves reducing “bit depth” in the audio data stream. But loudness compensation is somewhat more debatable. On the one hand, it is a worthwhile feature because it does compensate for loss of hearing sensitivity at the frequency extremes when overall playback sound levels are reduced. On the other hand, if you choose to enable the loudness compensation, it is always going to be a rough approximation, because you don’t know the level at which the program was originally recorded and how that equates with the maximum signal level that can be reproduced in your listening situation. It is a “bit of fudge” in other words, although undoubtedly far superior to the loudness control often featured in hifi amplifiers of yesteryear. At least, the user has the choice of whether or not to use any or all of the digital control features of our new DAC. Certainly a great deal of design and programming has gone into this project but I tend to feel that we may have included too many options which many people will simply never use (and it has taken a lot of time to program all this stuff . . . Grrr). What do you think? Should we incorporate lots of features in our microprocessorcontrolled projects or should we keep them simple? Leo Simpson siliconchip.com.au