The LCDuino-1 I/O processor - Page 2

Well I am very excited about this project. I will finish my M3 first though!

Linuxworks I think you have done this one too but not sure.

Read/Display current PSU voltages.

I have not integrated it, but its a cool function to have. it could be an optional module (software module and hardware sensor) for those that want it.

the arduino has several analog input pins. the resolution isn't great (0.1023 as the normalized value range) and its with respect to the 'AREF' (analog ref) pin in the arduino, or its via the internal ref). you can set the AREF to some reasonable value (up to but not MORE than 5v!) and then your 0..1023 return value is a percent of scale, of that. it may be enough for the application. 2 of the 6 analog pins on the arduino are taken by the i2c function so that leaves 4 spares (a0..a3).

but also there are nice high precision a/d converters that have arduino code written for them. I have not tried this one yet but I have the chip in my parts bin, ready to be used someday here's the link:

Lab3 - Laboratory for Experimental Computer Science

that chip seems to have more than enough resolution to be able to do various measurement tasks. imagine having a switchable input as a front end to this chip; and suppose that front-end could tap into various voltage 'test points' that people use to set bias, dc offset and things like that in their amps. suppose you could even set alarms so that if any of those test point values vary by X amount over some safety window, that an alert will be generated and/or logged. maybe even emailed or twittered (did I really say that?)

one of the key differences between consumer home networking gear and 'enterprise' class gear is that the enterprise class stuff is 'manageable'. you can get voltage points, temperature points, error/event/status log info, fan speed rpm value, all kinds of neat environmental (as its called) measurements.

suppose that thinking is now brought to DIY audio gear web-enabled amps, preamps, input selectors, output selectors. queryable 'boxes' that could report their voltages or heatsink temperatures when asked. boxes that work together in a network and when the one in control says 'its sleep shutdown time now' they all power off in their own way, in the right sequence. when the master box says 'user wants to switch from headphone amp to speaker amp' all the right boxes do their proper things, such as a volume slow fade to zero, then mute, then power off. the other box will power on, delay a bit, then rise the volume up to its last set value. that kind of distributed 'script' is now possible with this kind of infrastructure.

and yes, I really do have sleep-timer implemented and working at the end of an hour, it slowly fades down the volume, then sends an x10 'power down' command to the amplifier and finally shuts off all the lcd light (backlight) and goes into standby mode.

another idea for a 'personality module': caller-id device that interfaces to this system.

use-case: you're listening to the stereo and a call comes in. the caller-id arduino looks up the name and number that it gets from some caller-id (modem?) interface and if its in the 'interrupt the user' list, it could flash the data on the lcd screen and perhaps even soft mute the music.

someone suggested that to me a few months ago and I never found any good caller-id interface box, but its a cool idea and very do-able if that interface can be found and hacked into.

and then, there are xbee wireless modules that are popular with the arduino community:





those are very tiny things and allow 'peers' to talk to each other over short distances (up to a few hundred feet, I think). one end could be on a pc and the other could be connected to the LCDuino, somehow, and that might be a non-IP way to wirelessly link things. xbees have onboard a/d ports, too, I believe.

I'm way into it.

I think this will be the kick-in-the-pants I need to get my M3 cased up as a proper preamp.

Great work, guys!

This looks exciting! Very cool work, guys!

(Let me say first that I think very highly of the projects from AMB and linuxworks)

But having done an Arduino project myself, I'm curious to know how this implementation is advantageous over an off-the-shelf standard arduino board and a serial/I2C LCD?

one of the design goals was to integrate, on 1 board, some common functions and pre-wire it to make it easy to get that functionality working.

I have not seen many (any?) other arduino clones that are actually *on* the backpack board; usually the backpack is just a serial or i2c way to talk to the lcd. here, we've put the arduino chip, itself; a realtime clock and battery backup (supercap style); and also a standard port expander prewired for the lcd, all on the base board. and all in the same exact form factor as the 16x2 display module, itself. the idea was that this backpack board should fit in any box that can also take the bare lcd module (in terms of front panel size).

so, its mostly a convenience in integration and also establishes a base config that some common software can be run on.

the idea of an 'lcd backpack' has been around a long time. this is yet another take on that, but with slightly more integration than most have had.

What inspired the use of the Arduino over something with an ARM7 or ARM9 core? It sounds like you guys aren't leveraging too much code from the existing Arduino code out there, so that merit may be a bit lost? I've always found the Arduino to be an exceptionally capable platform, but more often than not as the task becomes more and more complex, the ability for the Arduino [any 8-bit AVR] to meet the task's needs diminishes. Especially, if there are response time constraints that are sought, such as changing the volume within 10ms of receiving an input.

The ARM7, on the other hand (TI's, NXP's, etc.) can run something like FreeRTOS, where much of the scheduling and other mundane or difficult tasks are handled by the OS. The notion of the ARM7 hosting a webserver isn't insane, and it's not like the ARM7 is much more expensive than the Arduino. Conceivably, with the more advanced microcontrollers, it would be possible for the bootloader either load code into memory or execute code directly from an SD/MMC card, making it easier and cheaper for people who don't already own some form of Atmel ISP. Even further, an ARM7 (moreso an ARM9) could deliver i2s to a DAC, decoding the data from the aforementioned SD card. You do lose the through-hole ease of the Arduino, but given that the y2 DAC contains several SMT parts, I'm not sure that was part of the initial consideration?

It strikes me that the Arduino is very limited in comparison to some of the existing components out there, and that the open source merits of the Arduino are lost when not using the interchangeable shields or the existing modules.

What made me think of this was the this gadget, linked from this hackaday story.

MOST of the code was leveraged from various online examples for the arduino.

ARM is more powerful but we have not found the arduino to be lacking in the cpu department, for the tasks its supposed to be doing. it meet the needs of small, cheap, easily accessible, free development software, multiplatform (and same UI for them all) and LOTS of community support. the chips are cheap and all parts are easy to get (and can be found in thruhole styles, as well).

this is not to say other controllers couldn't be used; but the arduino seemed as good as any and it does have a lot of momentum in the open source community.

all platforms run out of steam if you push them beyond what they are meant for.

how much cpu power does one need to scan for IR remote codes and talk to leds, buttons and lcd's? not a lot. and if you start running into scaling problems, its always possible (and often advantageous) to break the problem into sub-problems and let individual chips work on those smaller tasks.

I've not found input to be at all laggy; when I press and hold the IR button, it ramps up and down pretty fast. when I press mute, it mutes right away. for the 99% use cases, the arduino has more than enough cpu power to do these basic tasks.

I'm trying to decide if I'd rather have control over an external relay-based attenuator or control the volume control in the digital domain through the DAC. I guess an attenuator would be more versatile when I finally buy/build a record player. I'm assuming both are possible / not too difficult with this controller?

Good to hear then! I apologize if I seemed presumptuous. I just tend to worry about the maker/DIY community on a whole all going after one 8-bit microcontroller.

And yes! Admittedly, I do tend to stress out the various chips I'm stuck with (a few ATmega88's, a dwindling few ATmega8's). Without going too OT, a lot of what I do is very timing-related and often requires the use of V-USB, which leads me to fill up a lot of the cycles and have a biased opinion towards AVR on the whole.

Actually, if you haven't heard of it/thought of it already, you could always use V-USB to control your system from the PC.

The way I look at it, is that it is very uncommon for an amp to lack a volume control; those that do probably still need a dedicated pre-amp. Might be fine for your customised setup, but could potentially kill resale value.

And it depends VERY heavily on the quality of the digital volume control in the DAC. Some DACs start losing bits very quickly which IMHO is probably worse than most decent analogue volume control options. For something like the Buffalo 32, it reportedly manages the digital volume control extremely well.

This is very exciting... I've been wanting to build a fancypants microcontroller control for a preamp myself... now I just have to decide if I'm dumb enough to try to cobble together my own rather than using you guys' fine design.

I built a V-USB based volume control using the PGA. I wrote a little WinAMP plugin too which automatically set the volume according to ReplayGain data in the file tags.

Basically analogue ReplayGain which sounds an awful lot better than when it's done digitally.

I don't think it's compatible with the Arduino though. FTDI is probably the best bet for maximum compatibility, as it leaves open the possibility of other devices communicating via RS232.