# The LCDuino-1 I/O processor



## amb

Last update: April 25, 2010

*News*

 - April 25, 2010: All future announcements and updates for the LCDuino-1 and related app modules (δ1 relay-based attenuator, δ2 relay-based input/output selector, and others) have moved to the new AMB DIY audio forum. We have an entire forum category dedicated to the LCDuino system, with separate sub-forums for each module. LinuxWorks and I will focus our support of these projects there. We welcome your continued interest and participation.
 - Mar 25, 2010: The δ2 (delta2) relay-based input/output selector application modules has been posted.
 - Mar 14, 2010: The δ1 (delta1) relay-based attenuator application module has been posted.

*Introduction*

 Ever since I built my β24 power amplfier, I've been wanting to build a high-end pre-amp to match. However, rather than using ordinary rotary switches for input/output selection, and a conventional potentiometer or stepped attenuator based on a mechanical switch for volume, I wanted to do something better.

 There are off-the-shelf solutions available for relay-based selectors, relay-based, chip-based or motorized pot volume controls, etc., but virtually all of them are designed for a singular purpose, some are operable with a remote control, some not. Some have a display for status, some don't. It would be nice to have all of those features, yet implement it in an _extensible_ manner such that more capabilities could be added without wholesale redesign, and to allow a builder to tailor the system to suit his/her exact needs.

 Many of you may have noticed the recent Arduino-based LCD driver circuits that linuxworks built on perfboards, controlling a myriad of devices such as the input/output selector and volume control for his β22, a S/PDIF input selector, and even an Espresso machine monitor/controller. Many months ago we began exploring the idea about turning the basic concept into a generic, extensible and modular _platform_, usable for many applications not only for audio, but other devices too.

 Arduino is attractive because of the rich set of tools, libraries, code and support available for firmware development. It uses the C programming language and the GNU C compiler (gcc) in a nice graphical integrated development environment. The environment runs on Linux, Windows and MacOS X. There is also a large and active Arduino programmer and user community where Open Source is _de rigeur_. In all it's a very exciting and dynamic scene and fits perfectly with the spirit of our project and goals.

*The LCDuino-1*

 The first result of this collaboration is the LCDuino-1 I/O processor, which will serve as the "heart" of the entire framework.

 LCDuino-1 is basically an LCD driver circuit based on a customized Arduino platform with some extra features. This board has two 6P pin headers which will mate up with matching receptacles on an industry-standard 2 row x 16 characters LCD module (80mm x 36mm, parallel interface, 5V DC, low-power backlighting). These LCD modules are available in various colors and backlighting, transmissive or transflective. Here are some examples of usable LCD modules. The LCDuino-1 has the same form-factor as the LCD module, with matching screw hole locations. When mated together, they become a two-board "sandwich" that is easily mounted to an enclosure's front panel. LCDuino-1's slim profile allows the assembly to fit in a 1U rack case. Off-the-shelf front bezels are available for these LCD modules.

 Depending on the nature of the application, the LCD display would show the current input/output selection, a volume control bargraph, the date and time (see below), or some other information as appropriate.

 It is worth noting that the LCD module is actually optional, LCDuino-1 could function without one. There may be applications where no display is required, yet LCDuino-1 could still serve as the control center.

 The main component on LCDuino-1 is the Atmel ATMEGA328P microcontroller. See the datasheet for chip features, you'll notice that amongst other features, this microcontroller offers many digital and analog I/O ports, I²C serial bus support and serial UART for program download, making it very versatile as a monitor and controller for devices. The microcontroller is clocked by a 16MHz ceramic resonator, and has an onboard pushbutton reset switch should the need arise.

 On the LCDuino-1, the I²C bus is connected to an onboard MCP23008 port expander chip, which gives us 8 more I/O ports. Six of these ports are used for controlling the LCD module. This means that we only consume 2 of the microcontroller's ports to operate the LCD module (plus one more port for the backlight). The I²C bus can be extended offboard to other devices (see "Application modules" below).

 An optional real-time clock chip DS1302 may be populated (clocked with a 32.768KHz crystal and could be backed up with an optional 0.022 Farad supercapacitor). This allows the LCD display to double as a date/time clock. The real-time clock option consumes three of the microcontroller's ports.

 A 3P pin header is provided to connect a Vishay TSOP34838 infrared receiver for remote control purposes. The infrared receiver's output uses up one microcontroller port. The module should be mounted on the enclosure's front panel.

 The remaining microcontroller ports are connected to three rows of pads with 0.1" spacing, which could then be connected (via pin headers and receptacles) to other devices.

 A 6P pin header allows a FTDI TTL-232R cable to be connected between a computer's USB port and the LCDuino-1 for program download purposes (see below). When installed in the target system, this connector is also where an offboard +5V DC power source would provide power to the LCDuino-1.

 There are two LEDs on the LCDuino-1 board, one for power, and another for digital port 13 activity (the latter is customary on Arduino boards). There is also a trimpot for LCD contrast adjustment.

 For versatility, a "prototyping area" consisting of an array of through-hole pads with 0.1" spacing allows custom added parts. Pads with +5V DC and GND are located nearby for convenience.

 The LCDuino-1 PCB has a low parts count, no SMD parts, and all parts are easy to find. Therefore it's easy and inexpensive to build.

*Application modules*

 The LCDuino-1 itself has enough I/O ports, both analog and digital, to implement simple control and monitoring functionalities. However, such features as input/output selectors, volume controls, etc., require extra hardware. We plan to introduce some or all of the following "application modules" in the future, which will inter-operate with the LCDuino-1:

 - Relay based input and output selector
 - Relay based volume control attenuator
 - PGA2310 based digital volume control
 - LDR (light-dependent resistor) based volume control attenuator
 - Motorized potentiometer volume control
 - X10 power line control
 - Possible others

 The LCDuino-1 platform and one or more of these "application modules" will be a new, versatile, high performance and extensible way to implement audio and non-audio control functionalities.

 In some cases, a separate audio application module allows optimized placement within the system enclosure. For example, the input/output selector and volume control may be installed at the rear, adjacent to the rear panel jacks to minimize audio signal wiring and reduce the opportunity of interference and capacitive-coupling related stereo crosstalk.

 I mentioned that LCDuino-1 does not require an LCD module to function, and the motorized potentiometer volume control may be a good candidate to be implemented with no LCD display at all.

 Since the firmware will be open source, others are invited and encouraged to use LCDuino-1 as a platform on which to implement their own custom functionality, including more application modules.

*Microcontroller programming*

 There are two steps to program the ATMEGA328P and make the LCDuino-1 functional:

 1. Initialize the bootloader
 2. Download the program (firmware) code

 Both of these require special hardware, the bootloader needs a special AVR programmer dongle and ZIF socket board, and the program code needs to be downloaded with a special FTDI TTL-232R cable. Both need to be connected to the computer's USB port running the Arduino development environment.

 I plan to offer pre-programmed microcontroller chips for some "canned" applications, so that builders need neither the special programming hardware nor the Arduino programming environment and firmware source code. Just plug and play.

 For those who wish to use LCDuino-1 in a customized manner, then the programming cables and tools will be necessary.

*Firmware progress*

 Linuxworks currently has separate versions of firmware code for each type of functionality that he has already prototyped on perfboard. The plan is to integrate them into a single source code base, add some application module auto-detect capability, and modularize the code to make it easier to understand and maintain.

 An integrated code base would also allow a single program to support multiple application modules, so that only one variant of pre-programmed microcontroller chip could support all "standard" application modules.

 Other work in progress is to improve the IR remote control support (learning capability, support more brands, etc.).

*Schematic diagram*

 Here is the current schematic diagram of LCDuino-1.







*PCB layout*

 Here is an image of the current PCB layout.






*PCB 3D rendering*

 Here are 3D renderings of the top and bottom sides of the PCB.











*Links*

 - AMB's LCDuino-1 page
 - linuxworks audio page

*Updates*

 All future announcements and updates for the LCDuino-1 and related app modules (δ1 relay-based attenuator, δ2 relay-based input/output selector, and others) have moved to the new AMB DIY audio forum. We have an entire forum category dedicated to the LCDuino system, with separate sub-forums for each module. LinuxWorks and I will focus our support of these projects there. We welcome your continued interest and participation.


----------



## amb

Here is the LCDuino-1 BOM.


----------



## sachu

Very cool Ti and linuxworks...Can already see many future DIY projects using this...making DIY more professional looking in addition to the coolness factor.


----------



## _atari_

Hi amb, hi linuxworks,

 nice to see that your LCDuino is announced. It is great and I personally think that you can allways need a bit more microcontrollers in your preamp.

 Due to my personal need I have started to design an input selector and volume control, which is intended to run with the LCDuino.

 I am happy to contribute it to your project. (see this thread).

 It is basically all balanced stuff - but if it helps you I am happy if it is of any use for anyone.

 Currently I am finishing the balanced input selector. Aim for this week is to get an volume control too.

 Marcus


----------



## TzeYang

Interesting, I just finished my MicroC project based on a 8051 chip for my university and I used LCDs too. I programmed everything using assembly language though 
	

	
	
		
		

		
		
	


	





 Would want to enter the prototyping team if not for my dreadful finals at this moment for 2 weeks. 
	

	
	
		
		

		
		
	


	





 I could use some PIC controller experience though


----------



## linuxworks

our project is now public 
	

	
	
		
		

		
		
	


	




 to keep myself occupied while the wait for the pre-production boards arrive, I took to modifying an M3 amp. here is a 'VOLUmastered' (lol) M3 with a proto-board LCDuino-1 and also a proto PGA vol control chip, mounted on a daughter card right where the volume pot would go:











 (the colors are a bit off since I shot this at night and didn't have the right lighting)


 on this build, I used a 'sparkfun' chip breakout board for the PGA chip and while its not optimal for trace layout, it does basically function. it takes 24v (dual rail) from the amp, itself; and needs only an additional 5v for its digital control side.

 this install of the PGA is mostly just a proof-of-concept. we plan to do a proper PGA board but in the meantime, I needed one to install into my M3 so I just built one up pt-to-pt style.

 also to come, we are planning on a relay-based attenuator (using latching relays), a version of the SPDIFmaster switch and some other goodies, too 
	

	
	
		
		

		
		
	


	




 in order to make the programming understandable, I am planning on some articles (HOWTOs) that will explain how you can take our code, bring it into the free software development GUI, make some changes and download the new version into your very own arduino board. I think (and hope) this will be a fun new adventure for many here.

 for a long time, controllers (and programming them) was a 'secret society' (lol) that was reserved only for those who had background and experience in this subject and the many tools it took to follow that process. we're hoping to make this a bit more accessible with a common platform (initially the LCDuino-1) and enough code examples and pre-written working applications to start from.

 some general arduino links to start off with:

 - the arduino page: Arduino - HomePage

 - the lady ada page (she does interesting and informative DIY arduino projects): Make stuff

 - the arduino 'playground', which has many simple examples of arduino programming: Arduino playground - HomePage

 - an announcement on the arduino forum for LCDuino-1: Arduino Forum - LCDuino-1 goes to pcb house


----------



## ROBSCIX

Great project.


----------



## liltehood

looks awesome!
 great work


----------



## n_maher

Very cool guys, great work. Can't wait to spend some quality time reading all the info and I'll most certainly be using this in the near future.


----------



## qusp

very col. i'm looking at building a tube buffer/pre-amp/headamp to use with my Buffalo32 and headphones/ powered monitors. and this looks like just the ticket to ease me into such an alien headspace for me. and if its too much for my little brain I can likely find one of your default modules and adapt it for this purpose ie. output selection and volume control. nice work guys!!


----------



## Beefy

I've been looking for a way to volume-control and input switch my planned MMM re-case and balancing act for a while now.

 DACT doesn't have enough steps.
 Khozmo is still an unknown quantity.
 Joshua Tree draws way too much juice.

 This is going to be *PERFECT*


----------



## linuxworks

just like when you do a build (or plan a build) you decide which components and parts you'll use, which boards you'll use and which features you offer the user.

 same with this kind of project. its an 'infrastructure' with options that you can pick and choose from, user interface elements, real-world control primitives; and then some sample code that shows how you make use of these things.

 the final part is the ability to take in the source code, mix and match how YOU want, then turn the crank and have it download your customized application. in the arduino world, there's one GUI that you download from the net (its free) and it runs on mac, linux, windows. its java based so it looks and feels the same way on all platforms. its the text editor and also it 'builds' the code from source and when you press the 'flash' button, it downloads the new code into the device (the amp you're working on).

 I think it will be a kick (lol) to have users be able to flash their stereo systems with their own firmware! get used to seeing a usb connector (or something equiv) to download code, in the back of audio gear, now 
	

	
	
		
		

		
		
	


	




 one of the frustrations I felt with non-extensible code is that you are stuck with the style that the developer picked for you. I bought a preamp with an IR remote and display but found one feature so annoying that it made the whole device unusable to me. it had a display that scrolled and blinked and changed. I hated that. I thought about ways to work around it, somehow. some kind of blanking routine that I could layer on top of this thing. I actually considered stuff like that, for a while 
	

	
	
		
		

		
		
	


	




 but when you have source code to the device, you now have the freedom to say 'no scrolling on MY box!' and disable or change or, well, fix, any routines that don't act the way you want them to. then reflash your device and you now have the UI behavior you like.

 in a way, I guess that 'binking screen' box I bought really pushed me over the edge and forced me to get into this microcontroller thing a bit more seriously. and once I found out how cheap and easy this arduino stuff was, I figured it would be a natural for DIY and audio. finally, people will be able to customize their UIs and not be stuck with what the manufacturer of the firmware decide. *you* are now the final manufacturer (if you want to be) of your own device. change the names, translate to local languages, even *add* blinking if you really want to. 
	

	
	
		
		

		
		
	


	




 the only real expense is a one time $20 cable which has a usb-to-serial chip inside and isn't at all a passive cable. that cable and the free software and free sample code is enough to get you up and running.

 if you have a standard hitachi 2x16 or 4x20 lcd display, that's what we are using and those are easy to find/buy.

 the port expander chip is in the dollar range and is pretty easy to find from the mailorder vendors.

 the clock chip is a fun frill but not strictly needed in order to run the main programs.

 I've been able to use any old IR receiver, even this crusty old radio shack 'pre war' (lol) metal shielded device:






 IR was chosen as the primary input method. everyone has some kind of handheld IR remote control at home and the arduino can learn your remote codes. you now have a large multibutton input device and you only have to wire up a 3-pin dollar-priced part and drill a round hole in the chassis! 
	

	
	
		
		

		
		
	


	




 it should be a pretty easy project to build and all the parts are cheap and easy to source. cutting the rectangle hole in the chassis is probably the hardest part of this kind of project, now


----------



## Beefy

Oh man, the more I think about this, the tighter my underpants feel.

 The possibilities are endless. And such an ambitious project as well! I'm so glad AMB and Linuxworks are at the core of this...... I don't know who else could pull it off, and get it to the masses so effectively.


----------



## m1abrams

Just to add ideas to the Flame. Add a network module so you can control the preamp via the network. This could be very handy to use a device like an iPhone or ipod Touch as a remote for it.

 Could also use it to display current track info if your source is a computer.


----------



## linuxworks

Quote:


  Originally Posted by *m1abrams* /img/forum/go_quote.gif 
_Just to add ideas to the Flame. Add a network module so you can control the preamp via the network. This could be very handy to use a device like an iPhone or ipod Touch as a remote for it.

 Could also use it to display current track info if your source is a computer._

 

done 
	

	
	
		
		

		
		
	


	














 its very crude and needs a LOT of more software work, but what is shown here is the arduino talking over wired 10/100 ethernet, speaking tcp/ip to a webserver and getting current song name and time from that server. that server is running apache webserver and that connects to the 'mpd' (music playback daemon) which really plays the songs. its 'sound card' is a usb/spdif box that sends spdif to my dac. the dac feeds its analog out to a PGA volume control chip (similar to the m3 photo). the arduino controls that chip, too.












 the neat integration part is that you see the volume level AND the song name/time info on the same screen. the arduino 'manages' both and does some web i/o for the song playback (and even pause, skip over the web, too); and also does local volume control in the analog domain. its a bit confusing since it has a few data paths (ethernet, usb, spdif, analog) and has 'control planes' (remote control and management) as well as 'data planes' (sound info).

 I've been using that as my main music playback system the past few months. its been fun 
	

	
	
		
		

		
		
	


	




 here's what the development environment looks like and I've highlighted where the arduino sends out a web request, 'please pause that song' to my music jukebox:






 the black region/window is the debug area and you can see a web style http header block followed by that green circled area. that's the business part we care about 
	

	
	
		
		

		
		
	


	




 that's the abbreviated 'song and time info' block returned from the MPD playback process. the arduino gets this 'pound delimited string' of stuff back, parses out the fields and writes the values to the lcd in 3 lines of text. the display only updates the parts that change, so when one song is over and the next one starts, only the song name and play duration areas on the lcd have to be updated.

 again, this is a very early proof-of-concept. a lot more work needs to be done to make this more of a finished application; but it shows some of the capability of what a simple 5v fanless cpu like the arduino can do, these days.


----------



## m1abrams

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


----------



## m1abrams

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

 Read/Display current PSU voltages.


----------



## linuxworks

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.


----------



## linuxworks

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.


----------



## TheRobbStory

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!


----------



## tomb

This looks exciting! Very cool work, guys!


----------



## glt

(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?


----------



## linuxworks

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.


----------



## jezz

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.


----------



## linuxworks

Quote:


  Originally Posted by *jezz* /img/forum/go_quote.gif 
_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? _

 

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.

  Quote:


 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. 
 

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.

  Quote:


 Especially, if there are response time constraints that are sought, such as changing the volume within 10ms of receiving an input. 
 

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.


----------



## TimmyMac

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?


----------



## jezz

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.


----------



## Beefy

Quote:


  Originally Posted by *TimmyMac* /img/forum/go_quote.gif 
_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?_

 

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.


----------



## jnewman

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.


----------



## mojo

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.


----------



## manaox2

I can already tell this is going to be wicked. When I get a hold of a few of these, its going to be one of those things I never want stop tinkering with. I can't wait to play with one, must get all this other stuff done so that I can start playing.


----------



## linuxworks

Quote:


  Originally Posted by *Beefy* /img/forum/go_quote.gif 
_ For something like the Buffalo 32, it reportedly manages the digital volume control extremely well._

 

glt (posted here) has done some work in talking from his arduino to one of the TP dacs.

 I bet he could adapt his code to work with the lcd driver that we have. probably take an hour or two of work, if even that. then, that could be another software plugin to the system.

 is head-fi really ready to take on software projects? lol 
	

	
	
		
		

		
		
	


	




 but you know, it *is* rewarding to add new features and not even have to warm up the soldering iron to do it. and if you make a mistake in software, the parts don't give up their magic blue smoke like they sometimes do in hardware


----------



## linuxworks

Quote:


  Originally Posted by *jnewman* /img/forum/go_quote.gif 
_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. 
	

	
	
		
		

		
		
	


	


_

 

you could start with a 'worked out board and software', pick it apart, play with it, learn how it works and then create your own.

 I often find that starting with a known working system is a huge help in getting past the learning curve.


----------



## atothex

Cool beans! Nice work, amb and linuxworks.


----------



## Beefy

I have found the LCD displays easily enough at Mouser, but can't immediately find any nice bezel options. Any suggestions at this early stage?


----------



## dbfreak

I see my next project coming to light.


----------



## linuxworks

the lcd part that I like, these days, is this black background/amber foreground unit:

 NHD-0216K1Z-NSA-FBW-L

 (at mouser)

 I have not found good bezels yet. would love to find some dressing to put in front of the rough-cut rectangular hole, though! just a clear plastic front window and some frame around it; that would be all I'd need to clean up the mounting.

 perhaps even just a laser cut rectangle clear acrylic with 4 screw holes. that whole thing could be bolted to the front and make a sort of frame.


----------



## Beefy

I'm wondering whether you could just mount it at the back of a rectangular hole on a FPE panel.......?

 Though I suspect that the panel would need to be quite thin (or cutout at the back) such that the display comes far enough forward and isn't shadowed.


----------



## mojo

Me again.

 I am working on a project to create a universal joystick controller for video games. What does this have to do with this project, I hear you ask. Well, I have been thinking a lot about options for expansion.

 For example, you are going to target a 16x2 character LCD with direct support. That's cool, but what if someone wants to use a graphic LCD, or just some LEDs to indicate the selected source?

 What if someone wants to connect an MP3 player that can do ID3 tag reading, or add any number of other modules...

 Being open source they could I guess just add support themselves, but you have a limited number of I/O pins and connecting it all up could get tricky for the end user.

 What I decided to do is use a bus system. I have RS232 comms between modules, with the main controller as the bus master. It all works fine as long as modules don't try to talk at the same time, which is not a problem since there is only one bus master and modules only speak when spoken to.

 The advantage of this is that you get nearly unlimited expandability and anyone can create their own modules using whatever technology they want. It also keeps everything highly modular. People could even re-implement the main controller themselves and be compatible with existing modules.

 It's ambitious but very doable.


----------



## TeraHz

Nice project linuxworks and amb. This should be fun 
	

	
	
		
		

		
		
	


	




 I think it is much nicer to have the FTDI chip on the board and add a standard USB i/o, unless you want to preprogram the atmegas. I know the FTDI chip is on the expensive side but it might be worth it to not have to have an extra cable around if you want to program your amp (that sounds nice 
	

	
	
		
		

		
		
	


	




).


----------



## DoYouRight

sweet LinuxWorks you finally got this out there in the public! I was waiting to see more info than what you had told me! This is very exciting!


----------



## glt

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_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.

 ...

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

 ..._

 

I see. Somehow I had the impression that this was intended to be used with another (main) Arduino board. So if this is intended to be used standalone, why not include the usb device? to facilitate programming? That thing alone costs 10-20 bucks as a separate board.

 Also, I like 4x20 LCDs because I can't see the little numbers at a distance and with a 4 line LCD I can display numbers that are much larger (9X larger)


----------



## linuxworks

Quote:


  Originally Posted by *glt* /img/forum/go_quote.gif 
_I see. Somehow I had the impression that this was intended to be used with another (main) Arduino board. _

 

it depends on how complex the problem is that you are trying to solve. for some things, this single board can hold all the digital control stuff and the other functionality-boards (volume control or input selection, etc) perform their primary function and simply have some management interface (i2c bus, for example) for a cpu to control it over. 

 in other cases, it might make sense to have a 2nd local processor receive the i2c serial stream and convert commands meant for it into local bit-banging of some other chip or subsystem. I don't see this as the usual case, though, but its possible to do this and still stay inside the overall architecture.

  Quote:


 So if this is intended to be used standalone, why not include the usb device? to facilitate programming? That thing alone costs 10-20 bucks as a separate board. 
 

yes, its a $20 cable if you buy it in easy to use cable form. our interface follows the FTDI 6 pin 'standard' (reset on one end; 2 grounds on the other, vcc and tx/rx in the middle) and so this is one way to break down the 2 functions: 'programming' and 'using' 
	

	
	
		
		

		
		
	


	




 'using' happens much much more often than programming. I think it makes sense to optimize for the typical use case. I could forsee many installers that may be ok with 'off the shelf' applications pre-programmed in the chip and they simply install it and use it. in that case, they never need any host or computer/pc interface. why make them pay for things they don't need or want?

 for those that want to edit or change their apps, they can buy the 'download cable' and you buy that once, no matter how many devices you build that use arduino. once you 'flash' them with software that gets sent over that fancy cable, the code stays inside and if you're happy with the code, there's no reason to ever connect that port to a pc again.

 some people may want to have a 'ready to use' usb port on the back of their amps and systems. in that case, you can buy a small board that does what the magic cable does:

Arduino miniUSB: USB to TTL converter (FTDI) [v3] - $20.00 : Adafruit Industries, Unique & fun DIY electronics and kits

 Arduino "miniUSB": USB to TTL converter (FTDI)






 or one like it.

 mount that in the rear panel of the amp or dac (note, this is NOT a usb/spdif port, its a 'management port' and talks TO the box, not THRU the box; if you get what I'm saying).

 that becomes your management port for when you need to update the box's firmware.

 that little usb board just needs those 6 wires sent up front to the lcd area and you're done.

  Quote:


 Also, I like 4x20 LCDs because I can't see the little numbers at a distance and with a 4 line LCD I can display numbers that are much larger (9X larger) 
 

4x20 uses the same pinout as the 2x16 ones do. the only tricky part is that the mounting holes from the lcd to the daughter board (the LCDuino) won't line up. but its not the end of the world (that's not due for at least a few more years, lol) - the larger 4x20 lcd can mount onto the front panel on its own 4 screw holes and the backpack can 'hang' onto the lcd via the top 2 6pin header strips. there's actually a good amount of hold power in all those pins and header sockets. that may be enough for many people. the lcd mounting to the front bezel is the hard part; but the backpack module isn't in need of the same level of fastening.

 its also possible that another board, the same size as the 4x20, could be made using the same general idea as the LCDuino-1. maybe its the -2 version 
	

	
	
		
		

		
		
	


	




 think of all the extra proto hole room in THAT one 
	

	
	
		
		

		
		
	


	




 the nice thing about the 2x16 size is that its a good balance of 'real estate' on the lcd and small physical size. it can fit in a 1U rackmount and given that used pro audio boxes can sometimes be found cheaply, its nice to be able to come in under the 1U height.

 I've also used double sided foam tape to secure the 'dangling end' of a smaller backpack to the back of a larger display. the top pins holding it and the foam tape were enough for me. ymmv, of course.


----------



## mojo

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_some people may want to have a 'ready to use' usb port on the back of their amps and systems. in that case, you can buy a small board that does what the magic cable does:_

 

 Quote:


 4x20 uses the same pinout as the 2x16 ones do. the only tricky part is that the mounting holes from the lcd to the daughter board (the LCDuino) won't line up. 
 

Perhaps there is a solution to both these problems. Instead of using the LCDuino, just use a normal Arduino. Then supply a daughterboard for the LCD. You could use an ATmega8 which costs less than £1, and it would give you both an easy to use and intelligent LCD interface which could be adapted to any size or type of LCD with optional extra LEDs etc, and a USB interface using V-USB. The USB side could use the CDC mode to appear as a serial port on the PC, for remote control and firmware updates.

 The mega8 could also act as an I/O expander. You could even incorporate the IR and a button interface into it. You get all that from just two IO pins and can use any Arduino variant.

 BTW, I can recommend SeeedStudio for PCBs. They do a fantastic job of them and they are really cheap.


----------



## linuxworks

Quote:


  Originally Posted by *TeraHz* /img/forum/go_quote.gif 
_
 I think it is much nicer to have the FTDI chip on the board_

 

that chip, while not expensive, has a TINY lead pitch ;( I have an unsoldered brand new chip and board here (a lady ada board) and I have not had the courage to attempt soldering this by hand, yet.

 if there are pure software methods that are completely plug compatible with the standard development software, that would be great. so far, though, I have only been using the ftdi-enriched usb cable (lol) and it has worked just great as a download, debug and also as a simple power cable! 

 builders can decide what route they want to go. if they want a usb port on the back, at all times, they can install a board that has the ftdi (or similar) chip on it. if they simply want to program the chip at home, once, then not have to wire up usb inside their amp, the default install does not force any usb ports or chips on the target box. you just need to get 5v to the board and one easy way is the 'bottom' 3 pins of the 6pin software cable header (2 bottom pins are ground and the pin above it is 5v).


----------



## TeraHz

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_that chip, while not expensive, has a TINY lead pitch ;( I have an unsoldered brand new chip and board here (a lady ada board) and I have not had the courage to attempt soldering this by hand, yet._

 

You're right it's not the easiest chip to solder, but probably not any harder than the γ dacs. I just thing that with modular design it makes sense to allow for easy programming. Either way I'm sure you guys will make a great DIY project that I will follow closely.


----------



## linuxworks

the y1 and y2 don't have chips this dense, do they? the bantam dac does, though. or maybe the bantam chip is even easier.

 there's just NO WAY I'd want users even TRYING to hand solder the ftdi chip.

 for $20, its not worth it. more than $20 in frustration would be created in trying to 'save' money on this.

 in the PIC world, chip programmers tend to be $35 and up. $20 to program a chip isn't all that bad, comparatively


----------



## jnewman

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_you could start with a 'worked out board and software', pick it apart, play with it, learn how it works and then create your own.

 I often find that starting with a known working system is a huge help in getting past the learning curve._

 

That's true... the only reason I wouldn't go with your board is because I was thinking about getting one of the Arduino boards with 50+ i/o pins so that I wouldn't have to think as hard kludging everything together. 
	

	
	
		
		

		
		
	


	




 I've done a bit with BASIC Stamp and liked the microcontroller concept and stuff you could do but didn't like the chip itself or the programming environment. Arduino looks a lot better. This is very exciting. I'm tempted to try to join the prototype team, but I'm a ways off of actually building my preamp. I'll have to think about it. Nevertheless, it's very exciting, and congratulations to you both.


----------



## linuxworks

I did some basic stamp work, too; and it was fun and a rich environment with lots of internet examples out there. but the chips were TOO expensive and that just totally turned me off.

 the mega arduino boards look interesting with all their pins. for a very complex task, they might be the right thing to use.

 otoh, its not the common pinout or 'pin mapping' and so if you write code *assuming* the mega chip, then it won't run on the more common chips.

 also, the mega chip is only surface mount, isn't it?

 as a pre-made board its fine; but as DIY, it sounds impractical.


----------



## jnewman

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_otoh, its not the common pinout or 'pin mapping' and so if you write code *assuming* the mega chip, then it won't run on the more common chips.

 also, the mega chip is only surface mount, isn't it?

 as a pre-made board its fine; but as DIY, it sounds impractical._

 

I did not realize the pin mapping was different, although I guess it makes sense. I was just going to buy a board rather than put one together. 

 I imagine I'll end up with an LCDuino-1 at some point.


----------



## linuxworks

I have not followed the mega chip devel very much but its not just a 100% plugin for the other ard chips. I remember seeing some ethernet driver changes needed and so that made me wonder if this was at all a good idea or not!


----------



## lybbert

if it was not for me working on building my first heaphone amp i would be all for being a member of the development team. maybe ill get in on one of the next parts for it.

 -Lybbert


----------



## amb

A partial shipment of prototype boards arrived:


----------



## Henrik Nordberg

I always thought a DIY audio project, like the M3 or y1, should be brought out as a Make project, this goes the other way around but still brings those communities together. This is excellent.

 While volume and source indication is nice, showing data that is otherwise hidden would be even nicer. I am thinking of bit rate display in particular. Would it be possible to add that to a y2?


----------



## stwspoon

This looks very nice. A source for a less expensive "cable" for programming is
Modern Device Company $13

 Farther down on the page, if you have a serial port on your PC, are serial to rs232 adapters for $5.


----------



## linuxworks

let the soldering begin!


----------



## TeraHz

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_the y1 and y2 don't have chips this dense, do they?_

 

Sure they do - FT232RL on the y2 board 
	

	
	
		
		

		
		
	


	




 (not actually soldered, mind you):


----------



## amb

Quote:


  Originally Posted by *Henrik Nordberg* 
_While volume and source indication is nice, showing data that is otherwise hidden would be even nicer. I am thinking of bit rate display in particular. Would it be possible to add that to a y2?_

 

There is nothing on the y2 to provide this information. You'd have to come up with additional logic (probably snooping on the pre-ASRC I²S master clock and dividing that down).

  Quote:


  Originally Posted by *TeraHz* 
_Sure they do - FT232RL on the y2 board 
	

	
	
		
		

		
		
	


	




 (not actually soldered, mind you):_

 

Yup, they are both SSOP28, but we actually went out of our way to avoid SMD on the LCDuino-1 because through-hole alternatives exist, and would make the board appeal to a wider audience. Other FTDI USB -> RS232 converter boards are available, so there is no reason for us to re-invent the wheel and use up board space. As linuxworks already pointed out, not everyone needs it (IME, if we do everything right, most audio people who would use LCDuino-1 won't).


----------



## linuxworks

let the soldering conclude!






 (yes, it works. serial #0001 now installed, in-use and controlling my M3)


----------



## glt

Very nice!

 I guess this is a nice milestone for AMB. From now on all future designs will expose their s/w interface...


----------



## linuxworks

a demo build:

















 the blue electro cap is a bit taller than I wanted. next time I'll use a smaller one and the sandwich will fit a bit more snugly.

 the 3 color ribbon wire is going to my PGA chip board (chip-select, clock and data).


----------



## linuxworks

detail on how to mount the supercap (battery backup for clock chip):






 its soldered across ground and the trickle-charge pin. how nice that each pin is at diagonal ends of the chip and that the supercap fits just perfectly in place, there 
	

	
	
		
		

		
		
	


	




 if you don't care about having a clock or battery/cap backup, this can be omitted; but its really nice to be able to set your clock once and not worry about short-term power outages (I've seen it last for half a week on its own capacitor, so far.)

 its a .022F (farad) cap at 5.5v.


----------



## Dougie085

So can you put a bigger LCD on this? Or is that just that ethernet thing?


----------



## oneplustwo

Looks awesome linuxworks and Amb! Can't wait to see the final product!


----------



## amb

Quote:


  Originally Posted by *Dougie085* /img/forum/go_quote.gif 
_So can you put a bigger LCD on this? Or is that just that ethernet thing?_

 

Yes, a 4x20 LCD module will also be pin-compatible with LCDuino-1. The LCD will be larger than LCDuino-1, and the four mounting holes won't line-up, but it will work. Of course the firmware will need to "know" to take advantage of the extra width and rows.

 We are currently focused on the 2x16 LCD module to avoid taking the project in too many directions at the same time (and with all the planned "app modules" we really have to keep from spreading ourselves too thin). Also the 2x16 LCD module is sufficient for most uses, and will fit in slimmer/smaller cases.


----------



## linuxworks

Quote:


  Originally Posted by *Dougie085* /img/forum/go_quote.gif 
_So can you put a bigger LCD on this? Or is that just that ethernet thing?_

 

I can show a photo with that backpack board on a larger 4x20 style display.

 it works. I tested that, first, since I had one handy at the time 
	

	
	
		
		

		
		
	


	




 its just that it doesn't mount directly to the lcd via screw holes; it had to be held on *only* by the tension of the pins and headers. but for me, I'd be ok with that. the lcd unit, itself, has to be bolted to the front panel; but the backpack board can hang on by the pins and probably be fine in most cases on just that.

 software wise, you address each line by a magic constant and you have 'x' amount of chars to use before things go into no-man's land 
	

	
	
		
		

		
		
	


	




 I keep things simple, print at line 1 or 2 or 3 or 4 and on the larger displays, you have 20 chars per line. on the smaller ones, you have 16. when I create a program (or 'sketch' as the arduino guys like to call programs) I usually specify at the top what the display is going to be (16 or 20 chars). and the app I write will be very specific and designed with placements all setup for *that* kind of display.

 but, if something works on 16x2 displays (ie, the code is written for that) then it will also work as-is on the 20x4 ones. the reverse is not true, of course 
	

	
	
		
		

		
		
	


	




 I'll take a photo of the backpack on the 4x20 board later on. but they do work and you can address all 4 lines via software pretty easily.


----------



## ShinyFalcon

Coding for Rockbox's WPS was fun... this will be even more fun!!!

 Is there a software simulator to test code without having the actual hardware? (mainly to play with the LCD screen)


----------



## linuxworks

I have not used or found any simulator. have not searched for one, though, to be honest.

 to play around, you only need a base arduino board (many sources for that), the port expander chip and a standard hitachi style lcd. its breadboardable so simulators really don't make sense to me, with such simple hardware.

 there is nothing timing critical about the lcd and cpu path. so even if your resonator is mounted on breadboard, I bet things will still work ok. wiring is not really critical here, from what I've seen.

 if you can breadboard the thing in an evening, why even bother with a simulator?


----------



## _atari_

cool stuff. Respect for that!

 Linuxworks & AMB have done great work. Welcome AMB in the world of microcontroller!

 BTW: @linuxworks - I think it is time to feature this on MAKE.


----------



## linuxworks

Quote:


  Originally Posted by *_atari_* /img/forum/go_quote.gif 
_BTW: @linuxworks - I think it is time to feature this on MAKE._

 

agreed 
	

	
	
		
		

		
		
	


	




 it has been there, on the 'blog' section:

Make: Online : DIY Arduino LCD backpack

 but didn't feel it was ready until it had a PCB and some more testing.

 perhaps after beta test would be a good time to do a MAKE mag. submission?

 the SPDIFmaster switch was also in hack-a-day (grin) and that used the same basic backpack, as well.

 I probably have 4 or 5 of those backpacks around the house doing various things. some audio, some coffee, some neither 
	

	
	
		
		

		
		
	


	




 it seems a very useful combination of things to have on a single board and I'm glad I won't have to rely on the perfboards for too much longer


----------



## _atari_

Note to self: DO NOT POST BEFORE READING YOUR RSS!


----------



## amb

Quote:


  Originally Posted by *_atari_* /img/forum/go_quote.gif 
_Welcome AMB in the world of microcontroller_

 

Thanks! 
	

	
	
		
		

		
		
	


	



 I didn't get into the microcontroller thing just for the sake of it, but because it offers opportunities for better audio. It also lets me branch out into new areas of development that happens to be exciting and 
	

	
	
		
		

		
		
	


	




.


----------



## _atari_

Quote:


  Originally Posted by *amb* /img/forum/go_quote.gif 
_Thanks! 
	

	
	
		
		

		
		
	


	



 I didn't get into the microcontroller thing just for the sake of it, but because it offers opportunities for better audio. It also lets me branch out into new areas of development that happens to be exciting and 
	

	
	
		
		

		
		
	


	




._

 

Yes, it is nice to create physical objects with complex behaviour. Microcontrollers are very haptic for me.

 Let's see how my remote control will work out.

 The timing of your project is perfect. Since my amp at home failed and now I need a DAC, preamp and amp - but you have probably seen my other thread already.


----------



## linuxworks

here's what a 4x20 larger display looks like when mounted to the LCDuino-1:











 there, its doing coffee duty on my espresso machine (PID temperature control).


----------



## Grahame

Kudos to all involved in this.


----------



## The Monkey

jeez louise. nice.


----------



## linuxworks

detail on how to mount the watch crystal (on the reverse side of the board):







 a small loop of wire-wrap wire (or equiv) holds the crystal in place and also to ground. solder both ends of the loop on the opposite side (component side) of the board.

 note: you have to do this BEFORE you install the 8pin socket for the clock, chip, itself.

 there aren't too many things that have to be done in order; but this is one of them 
	

	
	
		
		

		
		
	


	




 once this is in place, THEN you can solder the supercap on top of this (if you want a 'battery backup' of the clock).


----------



## amb

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_detail on how to mount the watch crystal (on the reverse side of the board):
 ...
 a small loop of wire-wrap wire (or equiv) holds the crystal in place and also to ground. solder both ends of the loop on the opposite side (component side) of the board._

 

I used a thin resistor lead clipping (from the 1/8W miniature resistors), mounted it as shown in linuxworks' photo, but simply soldered it onto the "pads" instead of forming a loop on the other side.

 Btw, my LCDuino-1 is also up and running.


----------



## John E Woven

just wondering, what's the point of having all those holes on the side of the board?


----------



## mattcalf

Quote:


  Originally Posted by *John E Woven* /img/forum/go_quote.gif 
_just wondering, what's the point of having all those holes on the side of the board?_

 

From AMBs webpage:[size=small]
[/size]
  Quote:


 Prototype through-plated pads area on 0.1" grid for custom applications


----------



## linuxworks

the proto holes are for when you need to add 1 or 2 chips or some other small circuit that is part of the application you are building.

 for example, in the motorized pot case, you need an h-bridge. one can fit nicely on the proto holes.

 maybe you want some relays. some small ones can go there.

 molex connectors for offboard wiring. you can run some thin wires from the breakout pads (_D* and _A* holes) to the proto area and then have the molex offboard connectors solder in there.

 I mounted a 7805 voltage reg chip on the proto holes for one app. I'll probably add a piezeo buzzer (tell me when to stop pulling the espresso shot, lol).

 maybe you need more ram, so you can install an i2c eeprom chip and save lots of data in there (webservers need lots of string data, for example).

 I'm sure people can think of other small additions that could fit on the proto holes area.


----------



## nattonrice

Holy wow I totally missed this!
 Guys this is seriously awesome work o(^-^)o

 I love the AMB Labs / LinuxWorks Labs on the silkscreen! Pure class =]


----------



## linuxworks

some detail on soldering and shrink-tubing seal on the vishay IR receiver module.

 I've decided to have the TSOP (ir device) end soldered to the wire; and the other end of this cable will terminate in a keyed 3pin molex plug.

 these TSOP modules do NOT like to be hooked up wrong. I blew up at least 2 or 3 of them over the past few months (semi lol). so I think its a good idea to make them connector-keyed.

 you can also mount the IR module on a very small piece of perf board and then have a molex keyed plug/socket on that.
















 many ways to skin this cat; and this is just one of them 
	

	
	
		
		

		
		
	


	




 for doc purposes: pin ordering on those vishay TSOP modules are, left to right: signal-out, ground, +5v. I like green or black for ground and something like red or orange or yellow (depending on where you cut your 3 wire ribbon from, lol) as +5v.

 again, its really easy to blow these parts if you hook them up wrong. so the extra effort to pick colors and be sure about what goes where, that pays off, here


----------



## aloksatoor

impressive 
	

	
	
		
		

		
		
	


	




 let the coding begin 
	

	
	
		
		

		
		
	


	




 already ordered an educational kit from hacktronics


----------



## linuxworks

someone asked (today, in fact) for a temperature display.

 done. 
	

	
	
		
		

		
		
	


	









 using an lm34 linear temp sensor (outputs direct voltage for F or C degrees; lm34=F and lm35=C) on the small perf board going to analog-in-0 on the arduino.

 every clock second it 'smooth value' reads the analog-in port, scales the value and displays the current temperature next to the time 
	

	
	
		
		

		
		
	


	




 the temp sensor could be clamped to a transistor heatsink (to monitor your bias) or just placed inside the chassis to show 'internal chassis temp'. you could even have a 3 pin jack on the back of the box and run this cable externally to get 'ambient room temperature'.


----------



## mattcalf

Awesome stuff Linuxworks + AMB.

 All this information that the LCDuino is capable of gathering, do you plan for it to be displayed on one 'home' screen or will there be a capability of creating a button on the front panel to take us to the (for example) temperature screen?

 Cheers,
 Matt.


----------



## linuxworks

any kind of control you want. there are spare 'logical pins' (pins with a name and function and relate 1:1 to actual physical chip pins) on the arduino. you can use one of those for a front panel button or buttons. if you start to run out of 'pins' on the cpu, you then move on to using a 'port expander' like the one that is vertically oriented on the pc board, that MCP chip. that takes in 'i2c serial' and puts out 8 bits of controllable i/o lines. you can then use a mix/match of input and output on those pins and then call routines to get and set values to them. if that makes sense..

 the software is meant to be editable and there will be many examples that show what routines do what. its then a case of you, the user, doing some light (or heavy) mods to the software, downloading into the device, trying it and going back again until satisfied 
	

	
	
		
		

		
		
	


	




 that's what I had in mind; not so much any 'final' software but a framework, a set of examples, some canned demo apps (might be called end-user apps) and from there you can take any/all of that and run with it 
	

	
	
		
		

		
		
	


	




 some things you may change, while the system is installed and running, via menu pages. but major changes in how the thing works would mean you go into the source editor (text editor), move/edit some blocks of text around, add your own stuff if you want, then build/download/test. and if it works, publish it back so others can use it 
	

	
	
		
		

		
		
	


	




 in terms of the temperature thing, I happened to have a spare lm34 hanging around (..) and also had a spare analog-in port, so it was easy to just use that.

 but if I wanted to monitor, say, EACH of the heatsinks (yeah), then you'd need a more software addressable way of getting to each one of them. for that, there is OneWire (heh) and also i2c. i2c chips seems cheap (50cents each). I may try them and see if they work. if they 'play well' in the i2c bus along with our lcd port expander chip, then we get to use *lots* of temperature sensors. haven't tried yet, but its on the to-do list


----------



## linuxworks

Quote:


  Originally Posted by *mattcalf* /img/forum/go_quote.gif 
_All this information that the LCDuino is capable of gathering, do you plan for it to be displayed on one 'home' screen_

 

that reminds me, one possible thing to do with 'gathered information' is to send it to a pc, somewhere. suppose you wanted to get a graph of simultaneous (ie, time matched) sensor readings of rail voltage, bias voltage, heatsink temperature, powerOn-time and maybe even volume level. those are a bunch of collected 'data points'. the ard can't keep all that locally (for long) and so if you are into data collection or need to watch things for debugging, you want that up on some host or pc.

 a wireless link is kind of neat 
	

	
	
		
		

		
		
	


	




 there are these xbee modules that have arduino drivers. you can create a pt-pt tunnel between arduinos and other arduinos or even pc's. if one endpoint is the pc, then it can store the logged data. import into a spreadsheet and go nuts


----------



## Wilf

Very, very interesting.

 I know the sabre32 chip is under an NDA, but would that prevent grabbing the bit depth/sample rate information from the buffalo 32, and displaying it on this unit? Not interested in volco myself, but displaying this information would be interesting for me.


----------



## Lifthanger

what did you do? my wallett is in tears...

 I'm happy about this project though 
	

	
	
		
		

		
		
	


	




. Thanks alot!


----------



## komi

Quote:


  Originally Posted by *amb* /img/forum/go_quote.gif 
_Here is the LCDuino-1 BOM. 
	

	
	
		
		

		
			








_

 

Put me on the list for proto boards please ...


----------



## GeWa

I'm also kinda interested in one of those.

 Regards


----------



## Grahame

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_that reminds me, one possible thing to do with 'gathered information' is to send it to a pc, somewhere. suppose you wanted to get a graph of simultaneous (ie, time matched) sensor readings of rail voltage, bias voltage, heatsink temperature, powerOn-time and maybe even volume level. those are a bunch of collected 'data points'. the ard can't keep all that locally (for long) and so if you are into data collection or need to watch things for debugging, you want that up on some host or pc.

 a wireless link is kind of neat 
	

	
	
		
		

		
		
	


	




 there are these xbee modules that have arduino drivers. you can create a pt-pt tunnel between arduinos and other arduinos or even pc's. if one endpoint is the pc, then it can store the logged data. import into a spreadsheet and go nuts 
	

	
	
		
		

		
		
	


	


_

 

On the "enterprise class monitoring" side of things, I hope there is the ability to have some meta data, so that these things, the sensors/actuators can become self describing.

 e.g. query for attributes that give, say, name, type, range?, and operations/methods - something like the java bean api, for example.

 That way you could have a generic web/java/c# app for *any* device that implemented the API/Protocol, and as you add new capabilities to the device, the client app could recognize them, *with no additional work required* 
	

	
	
		
		

		
		
	


	




 You can still write custom apps using the API to some up with a "pretty" remote UI for the device (from an iPhone, nokia770 or other browser, say),

 Sample attributes to display on historical trend graphs. Alert on out of band/range values. etc etc

 All this can be done external to the device, as long as there is some generic way of getting the data out of the device, on request ( getValue(AttributeName) , say) , or setting an attribute value, or performing an operation remotely.

 What say you?

 This is the sort of thing I'd be interested in, and would be willing to help with.

 *edit* - *Aha!*

 Define the API/Protocol, then you can write adapters to the component model of you choice ...

 e.g. write an adapter (only needs to be done once) to make the device appear as a JMX/java bean, then you can monitor/control it by jconsole out of the box, or plug it into any bean aware framework ...

 Same approach works for any other component based framework ..., JMX, SNMP, etc

 REST based web interface, etc etc


----------



## linuxworks

next he'll be asking for SNMP support.


----------



## Beefy

POP3/SMTP. I want my DAC to be able to send and receive emails.


----------



## Grahame

Quote:


  Originally Posted by *Beefy* /img/forum/go_quote.gif 
_POP3/SMTP. I want my DAC to be able to send and receive emails._

 

 *Oh No* given the availability of the right email / sms gateway, your DAC could auto twitter to what you are listening to, at what volume level.

 *Edit* or just use the twitter API ...

 *Help*. I've just created a monster!


----------



## jtostenr

This is really cool stuff. Gonna have to rethink my Beta 22 project.....

 Good thing it's going at a snail's pace 
	

	
	
		
		

		
		
	


	




 I love the idea of being able to monitor critical voltages, temps, etc. and setting up alarms and logging the data. I wonder though, could you monitor things like the bias without affecting it, and potentially the sound quality? I love this stuff, but sound quality remains my top priority.

 Jeff


----------



## linuxworks

HOW the measurement is done - that's probably not my expertise. I can suggest some a/d chips but I'm not sure how to make the measurements and not be 'kosher' with audiophiles due to measurement wires running from test points to data collection points.

 then there's the muxing issue; assuming you have 1 voltage a/d you can poll, you'll still have to connect it (probably 2 points but maybe all can be wrt ground) to each place via some 'roving relay' contact or something.

 it would not be affordable to have precision a/d chips for each and every measurement point!

 there are only 4 spare a/d (10bit, 0-5v) channels on the arduino so you run out of those, fast, too.

 so, if the muxing can be done so that you can select, via some 2 or 3 bit address, which point you are going to measure, then yes, it can watch many bias points and stuff like that.

 maybe an analog cmos switch would be enough just to allow sampling of key voltage test points?

 needs more research. but I do think its a desireable feature, someday, to be able to monitor lots of key internal values. maybe even servo logic to keep them in check, as well!


----------



## jtostenr

It would be great to have a switchable input attenuator as an option as well, just in case you didn't have enough suggestions yet 
	

	
	
		
		

		
		
	


	




 I.E. - http://www.head-fi.org/forums/f6/rol...9/index58.html

 Jeff


----------



## linuxworks

not only switchable input atten but on amps that allow it, switchable GAIN settings.

 the m3 and PPA series can be gain-programmed with just a simple R per channel. locate some relays near those points and its simple enough. uln2003 style chip to drive the relays or just use transistors.


----------



## jtostenr

You can even add a touchscreen interface to the front of your amp - 

Liquidware : TouchShield Slide











 Seems like there a thousands of different applications for this platform. I can't wait to see the finished product.

 So when are you guys going to start taking pre-orders? 
	

	
	
		
		

		
		
	


	




 Jeff


----------



## mattcalf

Quote:


  Originally Posted by *jtostenr* /img/forum/go_quote.gif 
_You can even add a touchscreen interface to the front of your amp - 

Liquidware : TouchShield Slide











 Seems like there a thousands of different applications for this platform. I can't wait to see the finished product.

 So when are you guys going to start taking pre-orders? 
	

	
	
		
		

		
		
	


	




 Jeff_

 

That is so ridiculously badass! 
	

	
	
		
		

		
		
	


	



 Pardon my language.


----------



## linuxworks

Quote:


  Originally Posted by *jtostenr* /img/forum/go_quote.gif 
_You can even add a touchscreen interface to the front of your amp - _

 

better yet, why have it on the front panel; put that cool touch pad thing on a handheld (diy) remote and link them with RF.

 do-able, in theory.


----------



## DoYouRight

that is calling me must snag a touchscreen for myself.


----------



## aloksatoor

Liquidware : InputShield.... using a joystick mounted on the front panel to power on and cntrl the input relays and the volume pots (or a rudimentary UI).... would mean a minimalist front panel with only a control stick and a headphone out n lcd


----------



## linuxworks

I wonder how *usable* a cheap joystick will be.

 then again, that's far from cheap, at that price 
	

	
	
		
		

		
			





 for input selection, I guess I'm a bit old fashioned and that I'd want either a single button that cycles between the inputs OR individual buttons, one for each input port.

 fiddly things like joysticks always sound good on paper but I never liked them in actual operation.


----------



## DoYouRight

could itouch be used to control this?


----------



## linuxworks

I'm thinking that IP (web) is one way to try to control it. its a neutral 'standard' (not vendor specific).

 wireless handheld that speaks IP and can 'browse the web' might be a good remote idea. it would have a touch pad, some kind of graphics ability and all that. and once you enable a webserver inside the gear, you get 'management' via handheld remote things as well as proper desk pc's running, say, firefox 
	

	
	
		
		

		
		
	


	




 IR would be the simplest and cheapest and most obvious way into the box. xbee (zigbee) wireless RF 'chips' are another semi-easy arduino standard way. bluetooth could be another (I have not even looked at what arduinos can do with BT but I bet there's a good amount out there).

 lots of possible ways to remotely 'touch 'devices, once you put a cpu inside


----------



## johnwmclean

Very Cool... Holy Cow!


----------



## linuxworks

slight status update: I pulled out the 'sony only' (lol) IR receiver code and integrated a multibrand receiver code base.

 from here:

Arc Language Blog: An Arduino universal remote: record and playback IR signals

 it seems to receive sony, nec (a LOT of controls speak nec language) and philps rc5 and rc6 (two varieties). more work is needed on philips since they don't always send the same code for the same key (odd how that works, for them).

 a nice plus is that the IR code base also includes ir SENDING as well! I have not even tried this yet but it might be interesting to play with it some other time. use case: if your input selector goes to 'tv' then it could send out an IR burst to turn the tv, itself, on. switch back to a diff analog input and it might turn the tv off. or to that effect.

 ir blasters are not the best way to control devices but sometimes its all you have. my tv has no serial control input or anything like that, so if I want the tube off, it has to be IR for me.

 anyway, I'm still working on testing this new code out. with that will come some way for users to run a 'learn script' and associate the internal functions (vol_up, mute, etc) with user assigned IR remote keypresses.


----------



## _atari_

Thats cool news.

 I think you cannot overestimate the effort to do this. I think you will create a major contribution to the arduino world!


----------



## linuxworks

when I converted the code from the sony non-interrupt based IR decoder to the new codebase (which uses interrupts and hardware 'timer2' in the arduino) I found that the IR driver was...

 TOO FAST!

 lol.

 such a problem to have, something being 'too fast' 
	

	
	
		
		

		
		
	


	







 some code restructuring to stop the repeated keys was needed. now it seems to work ok. I think (lol).


----------



## _atari_

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_some code restructuring to stop the repeated keys was needed. now it seems to work ok. I think (lol)._

 

last commit-message: should compile


----------



## linuxworks

some fun, just for the heck of it. I ported over a game to get more experience in the IR library and LCD libs:
















 heh 
	

	
	
		
		

		
		
	


	




 software development isn't all fun and games. but sometimes it can be (lol).


----------



## glt

linuxworks,

 There is something better than your programming skills: your photography skills. Superb photos....


----------



## amb

Status update: We now have a prototype team and I hope to ship the boards out to the team sometime within the next week.


----------



## MoxMonkey

i might have missed it in this thread but what are we looking at for price to build one of these?


----------



## amb

The LCDuino-1 PCB board cost is yet undetermined until we go to production, but the parts to populate it is about $35-40 including the LCD module. It doesn't take into account any additional hardware ("application modules") that may be needed to make it do real work.


----------



## linuxworks

rough cost of the key parts:

 lcd: about $10-$15
 cpu chip: about $5
 clock chip: also about $5
 port exp chip: about $1
 6pin connectors: about $1 ea (3 needed)
 pin header: about $1
 trimmer pot: about $1
 resonator: less than $1

 for those that want to do any kind of editing of the program code, figure in another $20 for a serial/usb download cable (has FTDI chip in the cable).

 so, the cable (optional but highly recommended so you can roll your own code) and the lcd are the largest 'ticket' items that I can think of. the cable is something you buy one of (regardless of how many LCDuinos you build and program). the amber-on-black lcd's that I use are $10 at mouser.

 so that should give a rough idea of the key parts cost.


----------



## mattcalf

Very cool! Thanks Linuxworks and AMB for developing such an obviously wanted piece of kit in DIY audio and thanks for keeping it cheap!


----------



## rds

I like playing around with the code for these kind of things, but this would be too much of a distraction during school ...I'll have to wait till winter break =)

 It would be nice to have an on board regulator so that power could be easily tapped from an amp's power supply.


----------



## linuxworks

Quote:


  Originally Posted by *rds* /img/forum/go_quote.gif 
_It would be nice to have an on board regulator so that power could be easily tapped from an amp's power supply._

 

that's one application for the proto holes. we made sure they were big enough to fit 7805 style flat leads thru.

 example:







 that was 9vdc in and after the 7805, it went right to the +5v line on the board.

 not everyone needs it but if you do, the proto holes are your friend 
	

	
	
		
		

		
		
	


	




 on that photo, the orange electrolytic is over analog-0 input. that LCDuino board was controlling my espresso machine and the sensor comes via an LM35 temperature chip. that line gets smoothed by the cap and so I don't have to worry about multi-reading the value to smooth it out, the cap does that for me. there was *just* enough room to fit the cap in between the analog pin and a nearby ground pad


----------



## Gross

I am very interested in this project...


----------



## linuxworks

some more software progress: some early success with a universal learning receive mode, for IR. there's even a 'gui' where you can go thru the functional keys, one by one, and assign YOUR own ir codes to them. the results are saved in eeprom and used at each power-up.

 to get into this mode, you press a special soft-reset button at power-on time or any time the welcome logo appears. then it cycles you thru the various buttons (keypad keys, arrow keys, etc) and asks you to press the key that is displayed on the lcd. you press them, it asks the next until they are all assigned. that's it; then it takes you out of setup and into 'use' mode. you can re-do setup at any time (power-up and hold the soft-reset button or invoke the welcome banner and hit soft-reset button).

 until now, you had to edit the source code to define keys. now, there's a GUI in the LCDuino code, itself.


----------



## adamus

This has really got my interest. I am envisaging an input selector, vol control, and bias meter for my new tube amp i am working on. Good work chaps.


----------



## ShinyFalcon

Hmm a bias meter... Very interesting, but can it be reasonably accurate down to small adjustments? Maybe using a motorized trimpot rotator? hehe. Or are we simply talking about simple DC measurement? I wouldn't want the meter constantly measuring the bias however.


----------



## adamus

I was thinking just to monitor, not active bias. 

 What sort of resolution do we have? I use 10ohm 'test' resistors in the cathodes of my el34 amp, so only need accuracy down to 1E^-2 or so. 

 Just thinking out looud really. I will probably buy one and have a play.


----------



## linuxworks

the internal a/d's have 10bit (1024) resolution, from 0-5v.

 you'd want to front-end the ard cpu with a buffer of SOME kind, I would think.

 what would be really cool is to get hold of some DMM chips that read voltage (well) and output an i2c stream or even serial. I have some old DMMs that have rs232 serial out on any of their measure ranges.


----------



## elliot42

This looks like an awesome project and coincides nicely with my desire to create a similar device. I got an Arduino board a few weeks ago and have been playing with it, getting familiar with the environment. I like it a lot.

 What I'd like to do is make a preamplifier, controlled with the Arduino via buttons and eventually a remote. I'll be starting some prototyping this afternoon and have some shift registers (595 for output, 4021 for input) and 3-wire LCD using the LCD3Wire library and 4094 shift register.

 My goal is to have:
 - 4 inputs - 1 analog, 3 digital - as inputs to the preamp, the digital inputs going through a DAC (external at the moment, through my LD DAC_1, but eventually through an internal or external Opus DAC). Digital inputs would be USB (with USB > SPDIF), coax, optical (with TOS > SPDIF), input selector would switch between the SPDIF inputs and send that through to the DAC which sends back the analog signal via a 'loop input'.
 - PGA volume control with a rotary encoder, with the Arduino saving volume level / mute state in eeprom.
 - Multiple outputs (2 or 3) with the option to bypass the PGA and have line level output on each output.
 - e24 (or similar) power control that has mains output to plug amps into so that I can power off the preamp (by button or remote) and power is cut to the amps as well.

 Is any of the code you have been working on available? It would really help me and I could contribute what improvements I can as well.
 I could also help with prototyping if you need extra boards built and tested.


----------



## amb

elliot42, the current firmware is still being massaged for the prototype team, we will make the source available. The prototype team is already full, we have no more boards at this time. Please wait for the production version,


----------



## glt

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_some more software progress: some early success with a universal learning receive mode, for IR. there's even a 'gui' where you can go thru the functional keys, one by one, and assign YOUR own ir codes to them. the results are saved in eeprom and used at each power-up.

 to get into this mode, you press a special soft-reset button at power-on time or any time the welcome logo appears. then it cycles you thru the various buttons (keypad keys, arrow keys, etc) and asks you to press the key that is displayed on the lcd. you press them, it asks the next until they are all assigned. that's it; then it takes you out of setup and into 'use' mode. you can re-do setup at any time (power-up and hold the soft-reset button or invoke the welcome banner and hit soft-reset button).

 until now, you had to edit the source code to define keys. now, there's a GUI in the LCDuino code, itself._

 

That's pretty impressive. I thinks this is a first for Arduino S/W. How much memory does this code take?


----------



## DoYouRight

Could J.River MC's remote work with an arduino? Media Center Remote - JRiverWiki


----------



## linuxworks

if that IR transmitter is like most of the others, I think it would work.

 there's no RF receive on the arduino, but that remote you listed seem to have either a local or remote ir blaster.

 NEC and sony style protocols (a lot use NEC) are working well. philips rc5/rc6 still needs more work but should run eventually (they're tricker than the other types since they don't send the same keycode on every press of the same key. that complicates things).


----------



## mugdecoffee

You know, with the code you're writing it sounds like it wouldn't be all that hard to make a the LCDuino into a universal remote with a screen like the fancy logitech ones.


----------



## Ynis Avalach

First things first, I want to thank Ti and LinuxWorks sincerely for taking on this project, it makes this hobby soooo much more interesting than it already is!

 Secondly I wanted to ask if it could be done, and if how, to install a LCDuino into a chassis with a Sigma22 and messure like 4 rails of voltages and output them on a 16x2 or a 20x4 LCD.

 Greetz Ava and the most of luck with the LCDuino!


----------



## amb

Quote:


  Originally Posted by *Ynis Avalach* /img/forum/go_quote.gif 
_Secondly I wanted to ask if it could be done, and if how, to install a LCDuino into a chassis with a Sigma22 and messure like 4 rails of voltages and output them on a 16x2 or a 20x4 LCD._

 

You'll need to scale the voltages down (with resistor dividers) so it's within the Atmel chip's A/D input range of 0-5V. The negative rail voltages need to have their polarity inverted to a positive voltage (an inverting unity-gain opamp stage, powered by a dual-rail supply, would work for each of these). The "prototype pads" area of the LCDuino-1 board is ideal for mounting the opamps and extra parts.

 There are several A/D input ports, marked _A_n_ in the schematic. Connect the "normalized" rail voltages to these ports and modify the firmware to read them and display the values on the LCD. The A/D ports have a resolution of 10 bits (1024).

 Obviously, this is not a "plug and play" proposition, requiring some extra hardware and firmware hacking, but is entirely possible.


----------



## Ynis Avalach

Is there a good source or way to start into arduino programming, I started with a C++ book which I will read now.
 Because I have no knowledge of programming yet. I know, but it's part of my studies anyway, why don't start there, where their's a big community. It won't be that the LCDuino board will lie on my desk tomorrow. So I thought that that will be a truly awarding project, if I'll get it to work the way I plan it to work in the end.
 Greetz and thanks again! Ava


----------



## _atari_

Quote:


  Originally Posted by *Ynis Avalach* /img/forum/go_quote.gif 
_Is there a good source or way to start into arduino programming, I started with a C++ book which I will read now.
 Because I have no knowledge of programming yet. I know, but it's part of my studies anyway, why don't start there, where their's a big community. It won't be that the LCDuino board will lie on my desk tomorrow. So I thought that that will be a truly awarding project, if I'll get it to work the way I plan it to work in the end.
 Greetz and thanks again! Ava_

 

I really dig 'Making Things Talk: Practical Methods for Connecting Physical Objects' - ISBN-13: 978-0596510510. It is a very nice introduction to arduino from a 'How do I do this' persepctive. 

 'Getting Started with Arduino (Make: Projects)' is also a recommendation. But I heard from some friends it does not contain more than Making Things talk.


----------



## linuxworks

I came across this link while looking for IR senders and receivers:

Buffalo Round Micro IR Sensor - IR-350 - Smarthome







 looks like a nice idea for mounting the ir receiver/sensor. but a bit expensive considering that the active part is only a dollar ;(

 maybe this will get some creative ideas going? anyone have ideas on how to do something like this on-the-cheap in a DIY sense?


----------



## linuxworks

update:

 just yesterday, I added support for using a linear single-gang analog pot as an input device, for controlling the volume. it has the advantage of being cheap, easy to find, takes up little space, has good feel and it points to absolute values (when you turn the knob to 12 oclock, you get the volume as halfway, etc).

 I 'burned' one analog-in pin for this but I think its worth it 
	

	
	
		
		

		
		
	


	




 and it works well with the IR arrow-key style input, too. you can use both, and alternate between them if you want. if you turn the pot to some level, the volume goes to that level; then if you bump it up/down with the IR remote, it uses the last value 'seen' and operates on that. and again, the user is free to 'touch up' the knob at any point and it will take priority over the arrow keys.

 the 'knob' also takes note of the min volume level and max volume level, as set by the user in the GUI. so even if you grab the vol knob and crank it to max, the system won't blast you out of your room, it will honor the user's max-vol level and never go outside the min/max range.

 we're closing in on getting the beta code ready to ship and admittedly this was a last minute addition but I have to admit I like this feature quite a lot, so its going into the beta-test code base.

 there is also provision for separate control of input selectors AND output selectors. if you choose name lengths of 8 chars or less, you can show the input selector device name on the top left of the display and output sel name on the top right of the display. IR buttons are assigned for direct access to the inputs and outputs.

 (note, we're almost at the 6000 lines of C code-point. this stuff really adds up but there's a lot of functionality in this system)


----------



## glt

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_update:

 ...
 and it works well with the IR arrow-key style input, too. you can use both, and alternate between them if you want. if you turn the pot to some level, the volume goes to that level; then if you bump it up/down with the IR remote, it uses the last value 'seen' and operates on that. and again, the user is free to 'touch up' the knob at any point and it will take priority over the arrow keys.
 ..._

 

Hi linuxworks, what is the behaviour if you do more than "touch up"? Suppose I turn on the device and the pot is at min, then I use the remote to increase the volume to say mid-vol. If I start turning the pot, does it not increase the vol until pass the mid point?... thanks. Looking forward to looking at your code.


----------



## _atari_

Quote:


  Originally Posted by *glt* /img/forum/go_quote.gif 
_Hi linuxworks, what is the behaviour if you do more than "touch up"? Suppose I turn on the device and the pot is at min, then I use the remote to increase the volume to say mid-vol. If I start turning the pot, does it not increase the vol until pass the mid point?... thanks. Looking forward to looking at your code._

 

I personally think rotary encoders are easier for this task - because you would have to have an motor pot to keep it in sync with the real volume - which would be nice too.

 So many possibilities


----------



## linuxworks

Quote:


  Originally Posted by *glt* /img/forum/go_quote.gif 
_Hi linuxworks, what is the behaviour if you do more than "touch up"? Suppose I turn on the device and the pot is at min_

 

the way the logic works, today, is that only CHANGES in the pot cause the vol to change. powerup uses the last saved vol setting (that could have been gotton to via the knob or IR). if you don't touch the knob, it restores the last used value and does not 'scan' the pot unless the knob moves.

  Quote:


 , then I use the remote to increase the volume to say mid-vol. If I start turning the pot, does it not increase the vol until pass the mid point?... thanks. Looking forward to looking at your code. 
 

scene: you power on and you had left the vol setting at, say, 3/4 fullscale, and so it ramps up from zero to 3/4 setting and stays there. as soon as you turn the pot, it essentially throws away any last-value and NOW takes its value directly from the percentage of the pot. so, if you had left the pot at near zero (say) and you touched it just a little, it would read the new value (still near zero, say) and then set the volume based on that.

 ie, the pot always over-rides any 'increment / decrement' that the IR arrow keys previous asked for. the pot does not 'offset' or 'add' to that value, it *replaces* that value.

 that's how it is now. as a first pass, unless there are better ways.


----------



## _atari_

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_update:



 (note, we're almost at the 6000 lines of C code-point. this stuff really adds up but there's a lot of functionality in this system) 
	

	
	
		
		

		
		
	


	


_

 


 Is it possible to introduce 'Feature defines' since I can assume that not very much space for custom code is left?

 How big is the program (in kByte)?


----------



## linuxworks

Quote:


  Originally Posted by *_atari_* /img/forum/go_quote.gif 
_I personally think rotary encoders are easier for this task - because you would have to have an motor pot to keep it in sync with the real volume - which would be nice too.

 So many possibilities 
	

	
	
		
		

		
		
	


	


_

 

I do plan to have a servo thing going with a motor pot and feedback on the actual position. so, with motors, you can let the pot TRACK and keep up with whatever the current number is on the lcd display. I'm envisioning some way where the user can grab the motor pot, twist it and it won't 'fight' the user, it will take its new value from that and update the display. then you go back to the IR, tweak the value up or down a bit and then *watch* the pot keep up via motor action. that stuff is still yet to be done but its planned.

 rotary encoders are also supportable but I did like the idea of an absolute-reading valuator and pots do that really nicely. they are also easier to read as the code is less tricky (I've seen 'twitchy' rot encoders before and I don't like that 'feel').


----------



## linuxworks

Quote:


  Originally Posted by *_atari_* /img/forum/go_quote.gif 
_Is it possible to introduce 'Feature defines' since I can assume that not very much space for custom code is left?

 How big is the program (in kByte)?_

 

I have a bunch of #defines at the top and for now, that's how you turn on/off various feature subsets. you can make the unit input-selector only, output-only, both, and so on.

 at some point, we want to have a single codebase (if possible!) and have the options be hardware settable (resistor programming on a spare a/d pin?) or at least via the lcd GUI.

 code space is about halfway used; but one issue I'm running into is RAM usage! the learning remote eats up a lot of array space since hex key codes are stored in longwords and arrays-of-long could eat up your ram/heap space if you are not careful (I've already run into this where the code would build but not quite download or run properly and shows a mystery set of bugs due to running out of ram).

 soon, I'm going to have to start optimizing the code and memory usage, which I have been putting off for quite a while, now


----------



## _atari_

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_
 code space is about halfway used; but one issue I'm running into is RAM usage! the learning remote eats up a lot of array space since hex key codes are stored in longwords and arrays-of-long could eat up your ram/heap space if you are not careful (I've already run into this where the code would build but not quite download or run properly and shows a mystery set of bugs due to running out of ram).

 soon, I'm going to have to start optimizing the code and memory usage, which I have been putting off for quite a while, now 
	

	
	
		
		

		
		
	


	


_

 

Good to hear.

 Perhaps it is possible to store the IR keys in EEPROM.
 <computer-science-stuff>
 Why don you build some kind of tree map, so that you can walk it down to find the required action.
 By that you can get it from EEPROM very fast (reading only out twice the bytes as used in the remote code - pure estimate - code + pointer).
 setting up & writing the tree map will be an challenge.
 </computer-science-stuff>

 But I positively opt for one codebase. Anything else would bring you in codespace hell.

 But reducing RAM footprint is essential from my point of view - since others using the LCDuino will be not so experienced in debuggin (aka guessing whats wrong) the stuff than you.

 waiting eagerly for the prototype & code beta


----------



## linuxworks

Quote:


  Originally Posted by *_atari_* /img/forum/go_quote.gif 
_Good to hear.

 Perhaps it is possible to store the IR keys in EEPROM._

 

I am. after the learn-sequence is complete, the array of codes is saved in eeprom. I'm using working ram to save temp values and only syncing to eeprom if the user FULLY completes learn-mode. if he bails out in the middle or lets the system time-out, no changes are made (as a safety).

 I could not do that if I wrote to eeprom 'always'.

  Quote:


 <computer-science-stuff>
 Why don you build some kind of tree map, so that you can walk it down to find the required action.
 By that you can get it from EEPROM very fast (reading only out twice the bytes as used in the remote code - pure estimate - code + pointer).
 setting up & writing the tree map will be an challenge.
 </computer-science-stuff> 
 

for speed, I'm using simple arrays, so that the system can quickly match the incoming hex code (longword) with one in the array.

 I'm not sure I want to get too fancy in data structs, b-trees or hashes or linked lists. this is a controller and not a full cpu, afterall 
	

	
	
		
		

		
		
	


	




  Quote:


 But I positively opt for one codebase. Anything else would bring you in codespace hell. 
 

its a good goal but as you add more features, it pushes out the 'generic code base' bit by bit. something creative with overlays (?) might be nice.

 one first start is to move away from static arrays and malloc them based on the feature set the user programmed. that way you don't waste storage space (in real ram) on things you'll never use or run.

 another trick is to use PROGMEM to store data in flash instead of eeprom; if I start to run out of eeprom space.

  Quote:


 But reducing RAM footprint is essential from my point of view - since others using the LCDuino will be not so experienced in debuggin (aka guessing whats wrong) the stuff than you. 
 

agreed; the mystery 'it wont run!' will confuse a lot of people if they start editing the code and adding things, not realizing this isn't a pentium with a gig of ram at its disposal. and the debug tools on the arduino don't tell you a lot about how much ram you have left, running out of stack space, etc.


----------



## _atari_

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_I am. after the learn-sequence is complete, the array of codes is saved in eeprom. I'm using working ram to save temp values and only syncing to eeprom if the user FULLY completes learn-mode. if he bails out in the middle or lets the system time-out, no changes are made (as a safety).

 I could not do that if I wrote to eeprom 'always'.

 for speed, I'm using simple arrays, so that the system can quickly match the incoming hex code (longword) with one in the array.

 I'm not sure I want to get too fancy in data structs, b-trees or hashes or linked lists. this is a controller and not a full cpu, afterall 
	

	
	
		
		

		
		
	


	


_

 

Yes, but if you assume, you can create a data structure in which you can compare incoming byte by bite until you reach an answer you can easily compare the incoming 'live' IR signal to the EEPROM.
 I personally think tha you have not pentium at readout time, but you can take as long as you want at write time - this will not be easy. 
 Let's have a closer look at the code after the prototype is soldered up.

  Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_its a good goal but as you add more features, it pushes out the 'generic code base' bit by bit. something creative with overlays (?) might be nice.

 one first start is to move away from static arrays and malloc them based on the feature set the user programmed. that way you don't waste storage space (in real ram) on things you'll never use or run.

 another trick is to use PROGMEM to store data in flash instead of eeprom; if I start to run out of eeprom space.

 agreed; the mystery 'it wont run!' will confuse a lot of people if they start editing the code and adding things, not realizing this isn't a pentium with a gig of ram at its disposal. and the debug tools on the arduino don't tell you a lot about how much ram you have left, running out of stack space, etc._

 

If I remember correctly, you can write it only after reboot. No matter - I think there is enough non volatile memory at hand - volatile memory is the problem.

 I think the idea of getting memory with malloc is a good idea - since if you cannot malloc enough memery you still can create an error message instead of dumbly crashing.

 Let the code mature by some people. It will be hard at the beginning - but there will be a good solution


----------



## amb

Update: LCDuino-1 prototype boards and parts, as well as pre-programmed microcontrollers are being shipped to the prototype team.


----------



## linuxworks

I've started doing some development on using motor pots as 'zoomable valuators'. what that means is that you'll be able to use a motorized single-gang linear pot as an input 'valuator' (level setter), grab the knob and turn it and the digitally controlled volume engine (PGA or whatever) will follow the user's hand. turn the knob and the volume goes up, etc.

 the hard part that I'm still working on is having the motor 'catch up' if you now try to use the IR remote. that part is mostly working in my alpha test code but sometimes the motor fights you as you try to turn the pot and IT wants control over the pot. some tuning is needed but its mostly working right now.

 its an evolution of the non-motor pot valuator code I wrote a few days ago. for those that want to use a regular linear non-motor pot for input-only, that works fine right now. for those that want to use MOTOR pots as input and output valuators, its almost ready.

 note that I'm not really planning on using the pot to DO volume leveling; no analog signals will run thru the pot; the pot is there just for control purposes and to give the cpu another i/o device to show the current or desired volume level.

 the tricky part was to try to detect when the user twisted the pot and not the system twisting its own pot (lol). for now, I settled on a mutex style arrangement where, if the pot is in motion due to the cpu itself moving it, the user is not allowed to grab it since the system is still 'in control'. however, once the pot has come to rest, control goes back to the user and he can grab and twist the pot and the system will 'listen' to that and not fight it. the new value from the manual pot twist is updated on the display and the new volume is 'set' and used.

 then, if the user updates the value via the IR remote (a nudge up or down with the arrow keys) the system knows that the last input was via IR and not a 'twist' and so the system takes control again and zooms the pot over to that exact spot and then leaves it there. as you use the arrow keys and leave the knob alone, the knob zooms back and forth as the arrows are pressed up and down. even when you go into mute, the pot zooms down to zero. and as you switch inputs or outputs, it restores the last-used level for that input and the pot zooms to THAT location, too 
	

	
	
		
		

		
			





 this is a very experimental and very optional part of the LCDuino system but if you can get hold of a single gang linear motorized pot, it could be fun to play with and try to fine tune the code so that it works well enough to be production quality. for those that want a valuator input but don't need or care about the motor-pot part, the code is still in a state that it can use a non-motor single gang linear pot just as well.

 I wasn't sure this idea was worth doing, but I now think it is 
	

	
	
		
		

		
		
	


	




 its kind of cute to have the physical pot always stay in step with the lcd bargraph display. and since the pot is just 'advice' to the cpu and not a real actual attenuator, even if it takes the pot a while to zoom over to the new location, the volume engine has no lag and it goes right to the user's vol setting even if the pot is a bit laggy in getting there 
	

	
	
		
		

		
		
	


	




 anyway, another progress update. the thing is becoming more and more usable with each week that goes by, even if I do say so myself 
	

	
	
		
		

		
		
	


	










 the chip hanging on the small perf board is the l293d h-bridge chip for motor control.




 update: I added a short video-capture of the device, in motion:

http://www.netstuff.org/demo_vid/mot...r/P1000389.mp4

 (from a pocket digicam in video mode; .mov converted to .mpeg4 format)

 I'm using the IR remote to select between 2 output devices and each one has a 'last used' value that is stored. each output change causes the volume to be changed and this, in turn, causes the motor pot to 'catch up' or chase the value around. I also click up and down a little bit on the arrow keys to bump the volume up and down. the motor pot chases that value, too.


----------



## Gross

I am planning on using this or something like it to put together a preamp, or essentially a fancy switcher box. I actually have a few ATMEGA8-16s and some 2x24 HD44780A00 based LCDs sitting around, so until you guys are ready let go of a few of these, I think I am going to play around with my own version. I appears the ATMEGA8-16 is pin compatible with the ATMEGA328. I am closely following this thread


----------



## manaox2

I enjoyed seeing that video immensely, very cool.


----------



## TimmyMac

This is actually the best volume control implementation I've seen for DIY projects. I don't need remote control or fancy switching or anything for my headphone rig, but I'm definitely putting something like this in my loudspeaker rig. When will it be ready?


----------



## amb

Quote:


  Originally Posted by *TimmyMac* /img/forum/go_quote.gif 
_...
 When will it be ready?_

 

There is no ETA. Development will take as long as it takes.


----------



## Ynis Avalach

If I wanted to meassure the 30 volts of my Sigma22 (positive rail) would a simple voltage divieder with these (picture) values work? (maybe a noobie dumb questing but I'd really like to get on that, am working with arduino duemilanove atm)




 Thanks for any help.
 Just at addressing a 16x2 LCD with temps
 Greetz Ava


----------



## linuxworks

what I would wonder about is if sharing grounds is a good idea.

 my gut feeling is that the digital stuff should avoid ANY ground sharing with analog gear.

 if you could sense the voltage via an indirect means (maybe again those LDR devices could be useful?) that would be a better isolated design.


----------



## GeWa

Any new developments here?

 Regards


----------



## amb

We are in prototype phase. Members of the prototype team are just beginning to get started, and since this project involves both hardware and firmware, and there are so many possible applications, the development and prototyping phases go in parallel and will take much longer than traditional audio circuits.

 Stay tuned, we will post any new info or announcements when we have them.


----------



## GeWa

Thanks Ti.
 Didn't want to rush things, just pure curiosity. 
	

	
	
		
		

		
		
	


	




 Regards


----------



## linuxworks

the LCDuino platform (the display, IR, cpu and code) is mostly stable, at least feature-wise. what is on-going is the 'apps'. the value of the controller is really the applications (and its integration). one independant project:

http://www.head-fi.org/forums/f6/ard...ontrol-445551/

 can be one 'app' that the controller could talk to.

 vol control chips are being looked at and some work is done (proof of concept) but the details still need more work in order to get something production quality. lots of angles still left to explore before a final design appears.

 relay based attenuators are also being looked at (I'm updating a design and trying a new software/hardware variation right now, in fact).

 there's also some work on trying to standardize on i2c as an interconnect bus. this means moving some of the spi-based devices (like the PGA chip) off the local 'spi bus' on the arduino and hiding it behind an i2c port expander. if this works then we can free up more local pins and make things like 'volume control' and 'input selection' be i2c functions with well defined public interfaces.

 I'm also in the middle of some code restructuring so that we can try for a single codebase and either build-time or run-time selection of which features get enabled.

 and the motor-pot stuff was just too interesting and fun and that distracted me from a lot of the (above). I've updated my main listening system to use the motor-pot hardware and software and so far, it seems to work. the last part that needs to be developed is 'user grab detection' (for lack of better terms, lol) where, if the motor is currently in motion and the user grabs it, the system should detect that (early) and halt the motors and give control back to the user. that part I still have not gotton working. once that is done, I'll merge it back into the main devel tree and consider this a supported feature. I'm currently trying this semi-cheap part:

RK16812MG099 ALPS Potentiometers






 its linear, so its easy to read with the CPU and seems to work well enough as a user i/o knob. the software can motor it over to the correct spot for any given dB setting and so no matter how a dB setting got changed, the motor zooms over to stay in sync with the new value. for $8 for the pot and about $4 for the motor control chip, its a cheap and fun upgrade. ok, it costs more than that: you also have to justify 2 digital output lines (rotate-l and rotate-r) and 1 analog-in line (to sense the pot wiper value). so there are dollar costs and 'pin costs' to consider 
	

	
	
		
		

		
		
	


	




 I'll post more pics later.


----------



## luvdunhill

Linuxworks:

 I'd like to pick up a USB AVR programmer. Any opinions on these two:

USB ISP Programmer for ATMEL AVR (ATMega/ATTiny...) - eBay (item 160328616926 end time Nov-11-09 13:01:03 PST)

USBtinyISP AVR Programmer Kit (USB SpokePOV Dongle) [v2.0] - $22.00 : Adafruit Industries, Unique & fun DIY electronics and kits

 Thanks!


----------



## linuxworks

neither of those 2. what you want (what I recommend, at least) is the ftdi 6pin usb/serial cable, such as this one:

USB TTL-232 cable [TTL-232R 3.3V] - $20.00 : Adafruit Industries, Unique & fun DIY electronics and kits

 mouser also carries it but people often order the wrong one ;( adafruit only carries 1 type of ftdi cable so that's the easier order, imho.

 the programmers you listed can program the atmel chips but the 'arduino system' prefers that ftdi cable. it just makes things a LOT easier to use that standard ftdi one since the gui has 'drivers' all setup for it and most people do use the ftdi one.


----------



## luvdunhill

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_neither of those 2. what you want (what I recommend, at least) is the ftdi 6pin usb/serial cable, such as this one:_

 

Well, I should have been a little clearer. I'm looking for something to use as AVR-ISP... perhaps you have a recommendation for a way (or shield) to turn an Arduino into a AVR-ISP?


----------



## linuxworks

the usb-tiny device works great for init'ing the chips and adding a bootloader to it. but once a bootloader is written, you don't use this device anymore and instead use the ftdi one (usually). that's for the arduino environment.

 if you are talking about non-arduino stuff; just pure avr atmel chip programming, I can't help much as I'm sticking entirely to the arduino system (for ease, really).

 the usb-tiny-isp does support the dual inline 6pin ISP header. but I've only used that to create bootloaders and that's my only experience with that device.

 sorry, but I have not yet gone 'beyond' the walled garden of arduino-land and so I can only comment on the bootloader style of software uploading; and in that case, I don't believe the tiny isp device will help with that.


----------



## amb

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_neither of those 2. what you want (what I recommend, at least) is the ftdi 6pin usb/serial cable, such as this one:

USB TTL-232 cable [TTL-232R 3.3V] - $20.00 : Adafruit Industries, Unique & fun DIY electronics and kits

 mouser also carries it but people often order the wrong one ;( adafruit only carries 1 type of ftdi cable so that's the easier order, imho._

 

Actually, Mouser, Digi-Key, Farnell and RS Components all have it:

Mouser 895-TTL-232R-3V3
Digi-key 768-1015-ND
Farnell 1329311
RS 429-307

 These are links to the correct one with the 6P SIP receptacle. The official FTDI part number is "TTL-232R-3V3", but if you search on that, you'll also find other variants (additional suffix on the part number, with different connectors or bare wires). Most arduino folks use the linked one with no additional suffix. Here is the datasheet for the cable and its variants:

http://www.ftdichip.com/Documents/Da...ABLES_V201.pdf


----------



## glt

Here is a $3 option: Arduino Forum - Using a cell phone cable as a cheap ($3) USB TTL


----------



## linuxworks

in fact, I tried to locate some of those cheap phone cables 
	

	
	
		
		

		
			





 I did find a usb-serial cable that uses the prolific brand chipset; but the chip is buried in thick molded plastic and you have to cut it away to bypass the level converter. too much effort given that the cable is $10 and I'd put way more than $10 of effort into it and still not get the ftdi chip, itself.

 also, you'd want to have the auto-reset feature if at all possible and not all cellphone cables have the line needed for that.

 it was a neat idea but too hacky for me, personally. the $20 cable is a one-time purchase and that's quite cheap as far as development environments go.

 my first controller was a BASIC stamp (bs1) and that chip, just by itself, was way more than the $20 I paid for the arduino ftdi cable


----------



## stwspoon

I have had good luck with the Modern Device  USB BUB Board USB to TTL serial board for $12 and you can configure it for 5V or 3.3V. For an additional $1.50 they throw in a 3' A to Mini B cable. It is all assembled except for the connector so that you can customize it. The std pinout is the same as the FTDI cable for the Arduino.

 Not affiliated, just a satisfied customer. 

 I can't wait to get my hands on a LCDuino. When is the next round of boards scheduled?


----------



## amb

Quote:


  Originally Posted by *stwspoon* /img/forum/go_quote.gif 
_I can't wait to get my hands on a LCDuino. When is the next round of boards scheduled?_

 

Unknown. I might order more prototype boards if there is a good reason for it, but at the moment I am waiting for the existing prototype team to really get rolling, so I could incorporate all feedback and changes for the eventual production board.


----------



## luvdunhill

Thanks everyone for the suggestions. Goodies have been ordered.

 One more thing I'm looking for is a cheap way to program SOIC microcontrollers. I figure I could clamp them to a protoboard or something, but I remember seeing some nice ZIF sockets that PIC programmers use for this back in the day... any recommendations for this type of gadget?


----------



## stwspoon

I have used a SOIC chip clip in the past. something like this though the sockets are much nicer but also $$. If you only have a few the clip may do it. If you have not ordered the chips yet, some companies will program them for you.


----------



## luvdunhill

That looks nice, but doesn't that require the device to be soldered? Can you use it "free air"? As for the pre-programming, who offers that sort of service in small quantities?


----------



## stwspoon

I have had reasonable luck in putting the SOIC down on an antistatic surface and clipping the clip down over the SOIC. The clip grabs the SOIC body and contacts the leads as they come out of the body and bend down. You just have to be prepared for the SOIC to go flying off somewhere if you don't get the clip on right 
	

	
	
		
		

		
		
	


	




. Digikey and Arrow electronics will program chips ordered from them, according to  this PicList thread. At the bottom of the thread is someone offering programming services. Other threads indicate that Microchip Direct offers a programming service. A ZIF SOIC socket is about $140 
	

	
	
		
		

		
		
	


	




 at Digikey.


----------



## linuxworks

some devel news: today I have the PGA volume control chip (pga23xx series) working across i2c via a port expander chip. I'm using a phliips PCFxxx series chip (for variety) and can remotely send {chipselect, clock, data} over i2c via a 'bit bang' at the i2c message level 
	

	
	
		
		

		
		
	


	




 ie, for each of the 16 bits that are needed (8 for left, 8 for right) you send the (cs, clock, data) but toggle clock and cycle around the data bit until done with all 16.

 so far, it seems to work. this offloads 3 'valuable' digital i/o pins from the arduino cpu, itself, and allows the volume control system to be truly an i2c slave device on the i2c bus. less wiring to the main lcduino board, too 
	

	
	
		
		

		
		
	


	




 I've been using i2c to control a relay attenuator bank but this is the first time I've used i2c to control the burr brown PGA chip via this bridged big-bang method. I also modified my SPDiFmaster so that it, also uses a port expander over i2c and selects the input spdif port via a 2bit binary enum that is simply sent to the 'well known' spdif selector i2c address.

 so far, the idea of 'putting everything non-analog on i2c' seems to be working. of course the motorized linear-taper pot can't come in via a PE, it has to 'burn' a true analog-in port on the lcduino. the rotate control bits, though (move_left and move_right) could be on 2 unused PE bits somewhere.


----------



## linuxworks

2 more updates and a question:

 update1: new feature 'IR key aliasing'. the beta code now allows you to define more than 1 IR key code for any given internal function. suppose you have 2 nice handheld remotes that you like and use often and maybe they both have vol up/down buttons. it would be nice if EITHER of those 2 remotes would trigger the same 'vol up' function in VoluMaster, for example. and that's what I did: created a way to allow extra keys (from the same or different remote, even different brand and protocol) to map to the same internal function. my use-case was wanting to be able to use the vol up/down keys on my slimdevices squeezebox remote and have them actually control my PGA vol control chip. the native vol control on the slimdevices box is disabled in spdif-out so it works just fine with no overlap.

 update2: half-db steps on up/down are now allowed. you can set a global mode with an IR key to switch to half-db mode or full-db mode. all volume adjustments increment or decrement by the right db amount and the display changes to show "42.5" instead of "42dB", when in half-db mode. the volume range now goes 0..255 instead of 0..127 as it did before, using all 8 bits. when in full-db mode, volume is bumped up 2 counts each time, so that the 0..255 range is still maintained.

 and now the question: does anyone have any recommendation on a 4 pin *very small* keyed (polarized) connector? what I'm looking for is something to carry i2c signals, which are {clock, data, vcc, gnd}. I wonder if there are things like the mini-usb connectors but with .1 spacing so that they work out on perf and pc boards? something about the size of mini-usb, too; but I also need easy ways to make cables and mini-usb is not very user-friendly when it comes to making your own headers and jumpers.

 does anyone have any good ideas for small molex (?) keyed 4 pin connectors (headers and plugs) for this application? I think a lot of 'application boards' will have an i2c input and i2c passthru points on it and so I can see a lot of use for chaining i2c functions and needing a connector/plug/socket standard.


----------



## luvdunhill

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_and now the question: does anyone have any recommendation on a 4 pin *very small* keyed (polarized) connector?_

 

cat5?


----------



## m1abrams

Why not just a 4 pin KK molex? .1 spacing, cheap, pretty easy to work with even without the crimp tool. Any smaller than that and it becomes a pain to make cables IMHO.


----------



## m1abrams

Just saw the cat5 suggestion, that is not a bad idea either. However if it is meant for just inter-board connections and not intercase I think it would be a little bulky.


----------



## linuxworks

Quote:


  Originally Posted by *m1abrams* /img/forum/go_quote.gif 
_Why not just a 4 pin KK molex? .1 spacing, cheap, pretty easy to work with even without the crimp tool. Any smaller than that and it becomes a pain to make cables IMHO._

 

those are inline, which takes up more room than I was hoping for. they are keyed (good) and easy/cheap (good) but I was imagining something line 4 pins in a 2x2 layout with some index key or shape key somewhere.

 but a 4pin KK is a good standby to have if nothing else becomes the obvious choice.


----------



## linuxworks

Quote:


  Originally Posted by *luvdunhill* /img/forum/go_quote.gif 
_cat5?_

 

too bulky. even rj11 (4 pin is all you need) is too large. this is board-to-board not chassis-to-chassis.

 for the chassis case, THAT would be a good use! but I want a small connector that can take me from a board that is the size of a small lcd to another small board in the chassis (might be a relay board or PGA board or even 'managed power supply' board with controller logic there.


----------



## m1abrams

87833-0441 Molex Headers

 whole page of em
http://www.mouser.com/Interconnects/...z0wxnw&FS=True


----------



## linuxworks

maybe something like this:

Digi-Key - WM1796-ND (Manufacturer - 43045-0414)


----------



## m1abrams

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_maybe something like this:

Digi-Key - WM1796-ND (Manufacturer - 43045-0414)




_

 

I like it. I also am partial to right angle versions too for low profile.


----------



## glt

JST 2.54mm 3-pin through hole connector pack


----------



## luvdunhill

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_too bulky. even rj11 (4 pin is all you need) is too large. this is board-to-board not chassis-to-chassis.

 for the chassis case, THAT would be a good use! but I want a small connector that can take me from a board that is the size of a small lcd to another small board in the chassis (might be a relay board or PGA board or even 'managed power supply' board with controller logic there._

 

ah, I was assuming this was an external connector. For internal, I like the connectors that FCI makes. Check Digikey, Newark, Mouser etc. About as low profile as you can get.


----------



## linuxworks

Quote:


  Originally Posted by *glt* /img/forum/go_quote.gif 
_JST 2.54mm 3-pin through hole connector pack_

 

need 4 pins, not 3. they got any ones with 4?


----------



## glt

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_need 4 pins, not 3. they got any ones with 4? 
	

	
	
		
		

		
		
	


	


_

 

I Don't know. That is a good shop though and very responsive with email.


----------



## linuxworks

new feature for today - lm75a support 
	

	
	
		
		

		
		
	


	









 just some hand soldering directly to the chip with ribbon cable 
	

	
	
		
		

		
		
	


	




 connect in to i2c pins (28 and 27 on the ard chip), run some code such as:


 Wire.beginTransmission(my_dev_addr);
 Wire.send(0x00); // 0 = 'temperature register' 
 Wire.endTransmission();

 Wire.requestFrom((uint8_t)my_dev_addr, (uint8_t)2); // read 2 bytes
 while (Wire.available() < 2) { } // note the null loop!

 val = (Wire.receive() << 8); // MSB
 val |= Wire.receive(); // LSB

 // now, deal with the funky lm75a bit-shifting
 shifted = (val >> 5);
 val_f = (float)shifted * 0.125;

 return val_f;


 and that's it. you get direct digital-reading degrees in C.

 with 3 bits of addressing for this chip series, you can have 8 of these on the common i2c bus and poll them all you want.

 one per heatsink? perhaps! lol 
	

	
	
		
		

		
		
	


	





 ...anyway, one more 'driver' ready for the volumaster code base.


----------



## srserl

I would like dc offset protection for my preamp...is the arduino fast enough at detecting and switching output? If not, would it be possible to have it work with an epsilon-12-like circuit and allow the arduino to override the e-12 if there is no dc (and switch off the output), but not allow it to override (and switch on the output) if the e-12 has switched off output due to dc offset?


----------



## amb

While arduino is "fast enough", you won't save any circuitry by involving it for DC offset sensing. You'll still need the LPF, and since DC offset could be either polarity, you'd either need to use an "absolute value" circuit to feed an arduino's a/d input, or use the existing ε12-style output to toggle a digital input on the arduino...


----------



## srserl

Hmmmm,
 Using the ε12 output to trigger the arduino might be a good way...just set an interrupt on the state change of the pin and use that to trigger a dc offset state. Then, just make sure that the dc offset state is always used when setting the state of the relay.
 The only reason for me to do it this way is to avoid an extra relay in the signal path as there will be enough relays as it is.


 Wi


----------



## amb

Yep. Since we are planning a relay-based output selector app, it'd be a simple matter to make it disconnect all outputs based on an external trigger. I'm not even sure the arduino would need to be involved in this at all, just some logic on that board. OTOH, it might be cute to have the LCD display this condition...


----------



## linuxworks

my take on it is that there is room (in my vision) for a 'management module' that also includes environmental monitoring (like the big boy routers and switches do). it could check for dc offset, bias (where it makes sense), voltage rail levels and temperature of key points. if any of those 'look' like trouble could be happening, a fast disconnect (power off and relay tripping to disconnect spkrs/phones) would be in order.

 I could see the cpu making some decisions that would be way beyond simple analog electronics to be able to do.

 its not in my near-term plans but it is part of The Vision(tm)


----------



## amb

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_...
 its not in my near-term plans but it is part of The Vision(tm) 
	

	
	
		
		

		
		
	


	


_

 

While I think that's all very cool, and coming from a background of fault-tolerant computers where even seconds of system downtime could mean millions of dollars lost, I lived and breathed that stuff, I could certainly understand the attraction. But the audio purist in me also says that some of this goes far beyond what's necessary, and gets into the realm of complexity for complexity's sake. Afterall, a stereo is _not_ a mission-critical computing platform, oftentimes the simpler solutions are the most reliable.

 The LCDuino-1, in my mind, allows us to get around the limitations of antiquated items like volume pots, cleaning up signal wiring, and while we're at it, provide the convenience of remote control and simplified front panel. But it is also an opportunity for wretched excess... Just because there is a CPU doesn't mean that it has to be in the middle of everything.

 I am not opposed to the concept of CPU control where it makes sense, but as we go down this path of possibilities, we should not forget the K.I.S.S. principle.


----------



## Nebby

The one feature I'd like to implement in my built-sometime-in-the-future amp would be a power LED that changes color to reflect the warm-up state. With the temp probe ability, it sure sounds like it will be do-able


----------



## linuxworks

if you use an rgb led, you can 'burn' 3 PWM lines on the arduino and get exact color (within 255 pwm-based levels of r,g,b) and intensity 
	

	
	
		
		

		
		
	


	




 sure, its do-able.


----------



## pixeljedi

Slightly off-topic / slightly related* 
	

	
	
		
		

		
		
	


	




 If anyone wants to try their hand with Arduino programming, Sparkfun Electronics is having a free day on Jan 7th. A good opportunity if you've been holding off due to lack of fundage.

 (*related in the sense that if more people on the forum can program Arduino's, more people can contribute)


----------



## manaox2

Quote:


  Originally Posted by *pixeljedi* /img/forum/go_quote.gif 
_Slightly off-topic / slightly related* 
	

	
	
		
		

		
		
	


	




 If anyone wants to try their hand with Arduino programming, Sparkfun Electronics is having a free day on Jan 7th. A good opportunity if you've been holding off due to lack of fundage.

 (*related in the sense that if more people on the forum can program Arduino's, more people can contribute)_

 

Seriously great opportunity, thanks! I'm going to pick up a pint glass while I'm at it. http://www.sparkfun.com/commerce/pro...oducts_id=8405


----------



## ShinyFalcon

This is awesome! Something to do over the holidays. Though I'm not sure what to look for there... I guess I'll take a look around. 

 Arduino is C/C++ centered, yes? All I have worked on is Java, but I suppose it won't take me long to adapt to C++.


----------



## linuxworks

its c/c++ based.

 not a huge amount of c++ (thankfully). I'm converting a lot of chunks of code over to c++ 'classes' but that's about all the c++ I use.

 if you know java, you'll be able to follow along well enough.

 the compiler (error line # stuff) is useless, though. it points you to wild places that aren't even close. solution: don't write code that won't compile (lol).


----------



## m1abrams

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_if you know java, you'll be able to follow along well enough._

 

Except if you have never dealt with pointers and dereferencing, and pass by reference versus by value. Those items tend to give most Java guys the hardest time (that and the many symbols required for it).

 On the plus side you can overwrite your operators


----------



## pixeljedi

Quote:


  Originally Posted by *m1abrams* /img/forum/go_quote.gif 
_Except if you have never dealt with pointers and dereferencing, and pass by reference versus by value. Those items tend to give most Java guys the hardest time (that and the many symbols required for it).

 On the plus side you can overwrite your operators 
	

	
	
		
		

		
		
	


	


_

 

I'm just glad it's not assembly! Anything based off C is fine by me


----------



## linuxworks

assembly turns me off. I started with it, some 30+ yrs ago but I'm MUCH happier with a higher level language like C.

 with the several thousand lines of C in volumaster, for example, there's no way I could write this much if I had to do it only in assembler!

 getting away from the low level programming languages let you concentrate on the apps functionality, itself, where your time is better spent, anyway.


----------



## GeWa

Awfully quiet here?

 Regards


----------



## linuxworks

the software (firmware) continues to improve and I'm modularizing a lot of it so that the main routines are smaller and contain mostly just the parts that make them special (if its an spdif switch or analog switch or vol control or MPD controller or even espresso machine controller) 
	

	
	
		
		

		
		
	


	




 by moving a lot of the other parts into 'class libraries' it keeps the main parts smaller and easier to read. so, I'm working on that, in the background - some software re-org and cleanup.

 also, turning my attention to relay attenuation control circuits. I have a sample that I built on perf board; but the first version had some issues that needed a redesign to fix them. I hacked my perf board for the redesign and its almost ready for me to test with. after that, the code needs another major update (talking to a bunch of latching relays is quite quite different than talking to a solid state PGA vol control chip, for example). with the PGA case, you talk to the chip and you get what you want pretty much immediately. with relays, I have to setup a 'work queue' and pulse some relays on and off at various times and do that at various time during the whole main polling loop. its a very different model than the PGA chip case. and add to that a motorized pot that keeps trying to play catch-up with the almost instantaneous lcd display and you get some interesting timing loops going on 
	

	
	
		
		

		
		
	


	




 so, some work on the lcd unit, itself, but more work actually on the functional modules or 'things that the lcduino controls'. we're thinking that the relay attenuator (for vol control) and an input/output selector (spdif for digital and relay based for analog) would be the first 2 'personality modules' that would follow the lcduino-1.


----------



## GeWa

Thanks for the update.
 I'm really impressed with al the work you are doing here.

 Regards


----------



## TimmyMac

Would this thing be able to control a soft-start circuit for high power amps too? I'm thinking of having a small transformer to run the brains of my amp, and then using that to open/close relays so that it would first connect the big transformer through a resistor and then a few hundred ms later remove the resistor. Sort of a 'standby', where only the low-power stuff is on, vs 'on' mode, where going to 'on' activates the soft start routine. Possible?


----------



## linuxworks

controllers are a nice alternative to discrete logic. it may be cheaper (time and parts) to write software to do some jobs than to hard-connect gates, etc 
	

	
	
		
		

		
		
	


	




 what you are asking is time-based, right? or do you want to measure something and trigger the relay closure on *that* ? you could - you would not have to play 'guess the time constant' games, then. that also helps if you turn things off then on again - the processor could do something smart then, that discretes might not be able to easily do.

 another thing to think about (maybe) is a SSR instead of mech relay. they don't go down to zero but they are softer than a 'harsh' relay closure (maybe).


----------



## TimmyMac

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_controllers are a nice alternative to discrete logic. it may be cheaper (time and parts) to write software to do some jobs than to hard-connect gates, etc 
	

	
	
		
		

		
		
	


	




 what you are asking is time-based, right? or do you want to measure something and trigger the relay closure on *that* ? you could - you would not have to play 'guess the time constant' games, then. that also helps if you turn things off then on again - the processor could do something smart then, that discretes might not be able to easily do.

 another thing to think about (maybe) is a SSR instead of mech relay. they don't go down to zero but they are softer than a 'harsh' relay closure (maybe)._

 

Time-based should be fine - I just need something to stop the lights from dimming when I turn the amp on. I mostly want an alternative to this:





 Something like this:
 press on button (remote or physical button)
 controller closes relay to connect power through 50R resistor
 wait (200ms or so) to charge a good fraction of a farad of power caps
 controller closes relay to connect power directly, bypassing resistor
 opens both relays when you press off button


----------



## linuxworks

some LCD-less LCDuino-1 work, here:






















 underside:







 what I did here was to build a partial LCDuino-1 and leave out the clock chip, crystal for RTC and pin headers for the LCD module.

 this base config can be used as a 'cpu engine' to power simple projects. in this case, I wanted a display-less motor pot IR controller. just real, real simple - an IR receiver that uses 4 volume control buttons (same fast/up, slow/up, etc style) and controls a motorized pot. for now, that's it and that's all I want for this application (its going inside a b22 amp build).

 what's new is that I populated the data pins (analog and digital) with headers and created a lower 'motherboard' for the cpu module to sit on. I was going to add screws to the bottom of the board but the tension of all those pins, really just self-hold the thing in place. I added hex spacers just to keep the module a little more stable.

 the cpu module feeds thru the 'useful pins' to the motherboard, below. there, the dirty work is done (bwahaha...) 
	

	
	
		
		

		
		
	


	




 this is where I would plan to have 'application specific' stuff; in my case, a motor-pot controller chip (h-bridge). that's all the 'application' that I need for now but if I needed some relays or push button interfaces, I could make use of the port expander (PE) chip that's sitting on the main green board and meant to be the LCD interface but now can be used as 8 bits of i/o (leds, buttons, buzzers, whatever is a 1 or 0 state).

 to program the module, just lift it out of its motherboard and connect the magic $20 cable (lol) to the 6 pins on the LCDuino-1. same as you would if it was bolted to the back of the LCD. I decided not to run 'programming wires' to the back of the chassis for software upgrades since this app won't need upgrading very often. when it does, I'll pop the cover, remove the module and upgrade software out of the box then replace the module and put the cover back on. it will clean up the interior wiring and make a cleaner build, I think.

 3 connectors are neede: power-in, IR-in, motor-out. that's it in my simplistic application. power comes in at the top/left and motor wires simply go from the bottom right molex (near the L293D chip) to the motor on the pot.

 I need to add a soft 'config' button (like the reset button that is on the green board) to be used to trigger 'learn mode'. even though there's no LCD module, I still plan to support some kind of simple learn mode with even just a single led as the 'ok, go on to next button' indicator. primitive but I want to have some kind of support for learning the vol up/down remotes and not demand that an LCD be installed.

 so, this is a demo of using the LCDuino-1 board in a non-lcd way and also how you can feed thru the important pins to a motherboard, below, for the real app-specific work. this way you make the module on top very generic and even replaceable if it goes bad.


----------



## ujamerstand

Good to see that this thread is still alive and kicking! One of the things I can see myself doing with this is to use it as a stand-by module, where it can serve as a rather expansive clock while the amp is off, and when IR detects the ON signal, it'll turn the amp on. And its been a while since prototyping started, so I wanna ask: Prototypers, how's the progress? 
	

	
	
		
		

		
		
	


	




 and how's the relay attenuator going?


----------



## TimmyMac

Someday I've gotta build a softbox. Do you have a macro ring flash too?


----------



## linuxworks

Quote:


  Originally Posted by *TimmyMac* /img/forum/go_quote.gif 
_Someday I've gotta build a softbox. Do you have a macro ring flash too?_

 

no, I don't use those. those are direct light and direct light often creates shadows that you don't *want*.

 I just use a 12" cube made of frosted plexiglass and have lights shine on the outside, creating a diffused light inside.

 update on progress: after some hardware debugging I finally found my circuit bug in the relay attenuator (I was not giving 5v to one of the 2 PE chips; missed running that wire on my proto board). I now have a 2 chip version (each PE is now individually addressible) and that will let me work on the new algorithm (staggered writes to each of the bits on each side of the relay; then 'relax' the bits after the relay has clicked in). it seems to basically work right now but needs some tuning. at least I found my hardware error and this lets me progress in the firmware direction (finally) 
	

	
	
		
		

		
		
	


	




 here's a snapshot of the unit in operation with one PE chip showing 'vol' and the other showing '~vol' (binary complement). look close and you'll see there is motion blur in the volume pot knob; this is real. the motor was 'catching up' to the value that was loaded into the lcd display and the camera shutter was set on a slightly longer duration.


----------



## linuxworks

also what has been keeping me busy is finishing up my 3ch b22 build. this was the first time I tried to integrate some digital control stuff in an amp like this. I have the MVC version (motor vol control) of the LCDuino on the bottom/left corner of the photo (slightly hidden by the chassis):






 it has an IR receiver that sits inside the red bezel on the chassis (that came from an incandescent light that I gutted and just kept the red jewel) 
	

	
	
		
		

		
		
	


	




 that controls the motor pot and all the digital stuff stays entirely out of the way of the analog things. I haven't heard any 'cpu noise' in this arrangement.


----------



## glt

What is the topology of the relay-based attenuator?


----------



## linuxworks

the topology is the same that many use, r/2r. it is a common config.

 what is not as common is using latching relays and that requires more timing and on/off steps in software. but the gain is that once 'runup' finishes, all current can be removed and the relay bank retains its settings thru power cycles even with no cpu help.

 I'm playing with the idea of strobing the bits in the 8bit byte and timing each relay to keep it biased long enough to latch stably but not longer than it needs (thus freeing up a current sink). just like you can strobe the segments in a 7seg led display (those old things, lol) you can do the same kind of thing with relays if they are latchers.

 one PE chip would have 8 bits going to one 'side' of the relay bank and the complementary PE chip would manage the remaining pins on that relay bank. that way you can send a 00 or 11 to them and have them 'do nothing' but you can send 10 and 01 to them to get them to latch in A or B states. you can even high-Z the lines after you are 'done'.

 this is the kind of thing I'm experimenting with at the moment.


----------



## glt

R/2R, yes, common implementation. The non-latching relays is an excellent improvement. Are you optimizing by minimizing the number of resistors used in any one level or strictly adhering to the db level?


----------



## linuxworks

not trying to keep R count down. I honestly don't think that's an area that's worth splitting hairs over.

 keeping power down (and heat) is a goal, though.


----------



## glt

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_not trying to keep R count down. I honestly don't think that's an area that's worth splitting hairs over.

 keeping power down (and heat) is a goal, though._

 

I remember I worked out the attenuation for all the possible combinations of resistors in a spreadsheet and if one goes about picking the resistor configuration for the desired -db levels, one could see that near the target attenuation level there were close enough values where the number of resistors was smallest. Can't argue if there is sonic differences though


----------



## linuxworks

its very possible to 'carefully pick' the R and # of relays you want. then have the software do tricky stuff to get whatever db levels and steps (even if non-linear) you want.

 I don't care about those details. yet. 
	

	
	
		
		

		
		
	


	




 what I care about is the ability to get 'at' the relays and control their latching behavior on a per-relay (bit) level. if you can do that, the rest is just software magic that can be figured out later (lol).

 its a lot more chips to have 2 PE channels (PE chip and relay driver chip) but I think the extra control it gives you -may- pay back. maybe not but I'd rather have it and learn I don't need it than the other way around


----------



## ujamerstand

Hey Linuxworks, if one would like to go all out, and attach as many devices to the LCDuino as possible; how many devices can a single ATMEGA328P support before performance starts to degrade?
	

	
	
		
		

		
		
	


	




 Might it have enough processing power to handle three MCP23008 (1 for input select, 2 for balanced relay attenuator), one of these, a rotary encoder, IR receiver, and possibly more?

 On a side note, where did you get your flat cable wires from? It's hard to find them in small amounts.


----------



## linuxworks

Quote:


  Originally Posted by *ujamerstand* /img/forum/go_quote.gif 
_Hey Linuxworks, if one would like to go all out, and attach as many devices to the LCDuino as possible; how many devices can a single ATMEGA328P support before performance starts to degrade?
	

	
	
		
		

		
		
	


	




 Might it have enough processing power to handle three MCP23008 (1 for input select, 2 for balanced relay attenuator), one of these, a rotary encoder, IR receiver, and possibly more?_

 

I have not tried more than 2 PE chips at once but the limit would be a combo of a few things. addressing is one issue; each chip family has a base i2c address (that you can't change) and then usually 2 or 3 user bits that you can set. that gives up to 8 (for 3 bits) devices *of that chip family* on the same i2c bus before you run out of addr's for that family. you can also pick other chip vendors and you get a new bank of addresses you can use when talking to *those* chips. so addressing is not a huge problem but one to be aware of.

 you can also mux the control lines so that you create the illusion of having multiple source i2c control buses. don't know if you'd ever need to do that, but its possible (like adding a 2nd serial port, same kind of soft-serial hack but for i2c).

 it will also depend on how much time you spend with the device. some devices take 2 bytes to write to their outputs and some take a single 'write-a-byte' style commands. I would think that, at the same speed, the write 1 byte PE chips are going to take less bus time than the 2 byte PE chips (the mcp style you refered to needs 2 bytes at a time to write).

 another issue is 'what are you DOING in the big control polling loop?'. I'm scanning the IR receiver and picking apart actual 38khz waves and making 1's and 0's from them and storing that in an IR-rx buffer. that needs quick turn-around time. if you are also polling and writing to many PE chips, you now could take longer to ID an IR keypress or even miss one, entirely. I don't know how many things you can poll and still do 'IR in software' like the arduino does, today.

 if things get more and more complex, I would look to defer processing or concentrate it in some other subsection and send 'summary and interrupts' to the main cpu. a webserver or client could be an example where a single arduino can't really do web i/o AND other things at the same time, well. so going multiple cpu may be the only effective way to go. and then you have to have the cpu's talk to each other and that's yet another comms bus 
	

	
	
		
		

		
		
	


	




 (what was the question, again?)

 lol 
	

	
	
		
		

		
		
	


	





  Quote:


 On a side note, where did you get your flat cable wires from? It's hard to find them in small amounts. 
 

I think digikey had some in spools. I occasionally find it at my local surplus store but only on rare occasions. and I've never found good teflon or non-melt insulated ribbon cable ;(


----------



## ujamerstand

So the performance depends on the number of devices fighting for the access to I2S bus, where the potential bottleneck might occur? Also, it depends on the processing time on the input devices, decoding an IR signal and Interpreting user input from the rotary encoder both takes a lot of CPU cycles (lots of loops); where IR decoding takes the most CPU cycles out of all the activities that one might do with an LCDuino-based preamp. 

I honestly don't think the I2S bus should be a problem, unless one starts to feed audio signals through it. I am stupid. I am only thinking in terms of what I want to do. (Who knows, one might feed audio signals through it and control LEDs based on the beats or something.) But for an average user of LCDuino, I can only imagine a source controller, one attenuator board or two, and LCD output. When user input is being polled, I2S bus will be used by no more than 3 devices, ie, 1 LCD screen, and 1 or 2 attenuator device for SE or balanced operation, or 1 LCD screen and 1 source selector. If LCDuino executes command like attenuator1 -> attenuator2 -> LCD -> repeat. I don't think there would be any visible lag in the output.

 On the other hand, I never thought about how processor intensive a task might be. One might want to reevaluate the priorities of different devices based on how CPU intensive it is.

  Quote:


 (what was the question, again?) 
 

No worries, your answer is exactly what I need. 
	

	
	
		
		

		
		
	


	




 I guess somebody just has to try them all out until they get start to see laggy screen display or stuttering volume turning... Can't wait till LCDuino is in production! Please don't make me wait long enough to build my own on perfboards.


----------



## ShaneP

i2s is only used for audio afaik. i2c is a separate bus and is used for commands and other i/o.


----------



## ujamerstand

Quote:


  Originally Posted by *ShaneP* /img/forum/go_quote.gif 
_i2s is only used for audio afaik. i2c is a separate bus and is used for commands and other i/o._

 

I see. Thanks for telling me! Now you see what a newb I am, and how much more research I must do...


----------



## GeWa

Is this still going anywhere?

 Regards


----------



## amb

Yes, in fact. While the thread had been quiet, linuxworks and I have worked on this quite a bit. He is focused on the firmware while I have been working on the schematic for the relay attenuator and relay input/output selector modules. We hope to show more in this thread soon.


----------



## GeWa

Thanks for the update Ti.

 Regards


----------



## linuxworks

yes, as amb has said, stuff has been going on, just mostly r/d stuff. I took a detour to try out a digital pot and see if it was usable directly in the audio path. turns out it wasn't. oh well. but wouldn't know that until I tried. also got some experience which will pay back later, I hope.

 on the attenuator front, just yesterday I finally got the first version of code working. latching relays are tricky and it took some thinking to find a successful strategy on how to 'click them', not consume huge amounts of current at once and also to minimize audible clicks in the path. it was only about 100 lines of code but still, it was all brand new code that I had to develop from scratch, along with the strategy.

 good news is that the proto IS working, we have a schematic and are working toward pcb layouts. I always like to have at least 1 working proto before moving forward and now we can really do this.


----------



## MASantos

This is great news. While there are good relay att and source selectors out there, the way AMB (and you linuxworks) documents and supports his projects is much better.

 Looking forward to this!

 Manuel



  Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_yes, as amb has said, stuff has been going on, just mostly r/d stuff. I took a detour to try out a digital pot and see if it was usable directly in the audio path. turns out it wasn't. oh well. but wouldn't know that until I tried. also got some experience which will pay back later, I hope.

 on the attenuator front, just yesterday I finally got the first version of code working. latching relays are tricky and it took some thinking to find a successful strategy on how to 'click them', not consume huge amounts of current at once and also to minimize audible clicks in the path. it was only about 100 lines of code but still, it was all brand new code that I had to develop from scratch, along with the strategy.

 good news is that the proto IS working, we have a schematic and are working toward pcb layouts. I always like to have at least 1 working proto before moving forward and now we can really do this._


----------



## ujamerstand

Very Nice. Which relays will the pcb support? Are we going to see a dedicated supply of latching relays at Ti's audio shop? Both Mouser and Digikey are a little low in supply for these things...


----------



## Olli1324

Oo-er, posted in the wrong thread :/

 As I am here, though, I may as well say I'm particularly excited about this new project.


----------



## vixr

this is going to be fabulous...I cant wait to play with this stuff...


----------



## jtostenr

ok, I have a noob question...

 I know the LCDuino requires it's own 5V power source, but what about the input selector and speaker/headphone switch? Will they draw power from the LCDuino, or do they require their own power source?

 Jeff


----------



## linuxworks

the lcduino does not draw that much power on its own. I have a sigma25 (7805) powering one of mine with about 7vac going into it and it barely gets warm to the touch.

 it would depend on what the downstream things need. the relay module is designed NOT to eat current (we took extra pains to do this). the relays are 'strobed' a few at a time (configurable) and are only clicked for a few ms before they are 'relaxed'. this keeps the peak current down, as well. the relay board needs only 5v and so far, with my proto, its drawing off the same s25 as the lcduino1.

 other 'client' boards may need special power. the PGA chip proto I built needed dual 12v or possibly dual5 (if the DIP version was used). it also needed a logic 5v and that could come from the lcd1 but for isolation reasons, I would give it its own clean 5v.

 input selector follows the same latching relay scheme as the attenuator, so that can very easily use the same s25 supply as the lcduino1.

 output selector MIGHT be different as it would benefit from a higher current (contact) relay. if we can find a 5v dc latching relay that 'carries current' that would be great. else, that relay may have to be driven by a transistor or equiv and most 'heavy duty' relays I've seen are 12v for cars (nice heavy duty ones easily found) or 24v. some even higher voltage. so the output selector might be the only non-latcher here and that means it takes current when its in its 'down' position. when I made my output relay module, I picked the normally-open contacts to be for the phones and NC contacts for spkrs since I tend to use my b22 (which has the relay in it) for spkrs more than phones. if you use it the other way, you may want to define the NC contacts for phones.


----------



## jtostenr

Thanks Linuxworks, that helps alot. Do you know what the approximate sizes of the attenuator, input and output selector pcbs are going to be yet? Just looking for an estimate so I can work on my layout.

 Jeff


----------



## amb

I am working on the PCB layouts but I don't have a firm size to report yet. Sorry.


----------



## Listen2this1

Is it going to fit in an Altoids tin?


----------



## amb

Not likely.


----------



## Juaquin

Just wanted to say I am very excited for the relay volume board in particular - I'm building a GainClone and using my own Arduino solution for other things, but relay volume control will be the final touch.


----------



## jtostenr

Hmmm...strange, I thought I had posted this already, but now it's gone.

 Anyway, how difficult would it be to incorporate a switchable input attenuator into the LCDuino? I suppose it would take adding a few resistors, a relay and some code, right? Maybe something that could be done on the perfboard section of the LCDuino.


----------



## amb

The relay-based volume attenuator will have 256 steps which should remove any need for an additional attenuator...


----------



## jtostenr

Do you mean there would be no need for one of these?


  Quote:


  Originally Posted by *amb* /img/forum/go_quote.gif 
_If you're using a source that is "too hot", then you might want to add an input attenuator at the amp. Here is a schematic of a switchable attenuator. It is drawn for an unbalanced (2 or 3 channel) amp, for a 4-channel balanced amp you'll need to double everything for the negative signal, and use either a 4PDT switch, or two DPDT switches.






 If you use the same value for all the resistors, then the attenuator will drop the effective gain of the amp by one half (-6dB). A good value to use is anywhere from 10K to 47K._


----------



## amb

Yes, with conventional pots, when you get near the bottom of its adjustment range, channel tracking is usually at its worst. Ordinary stepped attenuators don't suffer from this, but the steps are usually too big near the bottom. These factors make the volume control less than useful when you're using really sensitive low-Z headphones and the amp has high gain. However, with the relay volume stepper we're designing, we'll have 256 steps of adjustment with excellent channel tracking. This means that you should not need to pre-attenuate.


----------



## jtostenr

Great! Thanks Amb


----------



## linuxworks

we're planning on 8 relays or 8 bits. but you can, if you wish, depopulate any # of bits and save on relay cost and relay 'clatter' noise if you are happy with a 0-127 range of steps (for 7 bits) and 0-63 for 6 relays. you can edit the software and tell it you only have 6 relays installed and that you want the steps to be X dB, etc. being open-source, you can do anything you want to customize it for your install.

 you can compute the value of the R's when you decide on the # of bits, output Z that is desired, step size (per increment of volume) and so on. the max is 8 relays since chips and machine-bytes prefer things in multiples of 8 
	

	
	
		
		

		
		
	


	




 but realize that you are free to pick a lower number if you want. as long as you update the software (examples will be given) and make it match the hardware you built, it will work.

 my proto was 7 relays and I used 1dB as the step size. I've been using that for a while and I like this config. it saves on 1 relay and some relay noise and I, personally, don't see the need for half dB steps (even though the software allows for single dB and half dB steps) and a single click-up or down gets me a single dB and that works pretty well in the real world. and the range of 0dB (straight thru) to 127dB (near total mute) is more than enough for me!

 you COULD build yours to go from 0dB to 255dB in 1dB steps but I'm not sure you'll find much use below 90 or 100dB of atten, in real world use. but you COULD build this to run in that range. no problem. maybe you want a lab grade atten (this passes DC, of course) and you really do want to atten that low (for non audio use). this module can do that. you have 8 bits to play with and you can map the native 0..255 range of those 8 bits of anything you want. if you want 0..255 to be 0-127dB in half db steps, that 'fits' in 8 bits also, so that is a valid configj, as well.


----------



## Beefy

How do you find the relay solution compares to your PGA 23** solution? Sound quality, difficulty to implement, any perspective would be great......


----------



## luvdunhill

Quote:


  Originally Posted by *Beefy* /img/forum/go_quote.gif 
_How do you find the relay solution compares to your PGA 23** solution? Sound quality, difficulty to implement, any perspective would be great...... 
	

	
	
		
		

		
		
	


	


_

 

I believe LinuxWorks "abandoned" the PGA approach.. I think it's mentioned somewhere above in this thread, or in another thread


----------



## Beefy

Quote:


  Originally Posted by *luvdunhill* /img/forum/go_quote.gif 
_I believe LinuxWorks "abandoned" the PGA approach.. I think it's mentioned somewhere above in this thread, or in another thread 
	

	
	
		
		

		
		
	


	


_

 

I didn't see that. I thought the two approaches were being developed in parallel.


----------



## luvdunhill

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_I took a detour to try out a digital pot and see if it was usable directly in the audio path. turns out it wasn't. oh well. but wouldn't know that until I tried. also got some experience which will pay back later, I hope_

 

.


----------



## Beefy

Huh, well there you go then. Lucky that I got my digital volume control somewhere else then......


----------



## linuxworks

Quote:


  Originally Posted by *Beefy* /img/forum/go_quote.gif 
_How do you find the relay solution compares to your PGA 23** solution? Sound quality, difficulty to implement, any perspective would be great...... 
	

	
	
		
		

		
		
	


	


_

 

the pga solution was good in some ways and more troublesome in others. I have not at all abandoned it but the first prio was for relays. I think the beta group (email list) also seemed to feel that the relay atten was the better one to implement first.

 I've built at least 3 air-wired or perf board pga volume control engines and some worked very well and some not. there are a lot of variables to iron on to get this perfected and we didn't think it was worth the development time to *perfect* the pga style board when the relay board was an easier (and technically) better 'win'.

 the long-term architecture, as I see it, is to be engine-agnostic as much as possible and allow for the lcd1 to control relay banks and/or pga style chips and/or LDR style devices. (one neat thing about ldr's is that it could be used in the feedback loop of an op-amp and effectively be a smooth true-gain control, in addition to an input attenuator also being present).

 so, first supported 'client' would be a relay board but that's not to the exclusion of others. just an ordering of what makes sense to hit and develop, first.


----------



## linuxworks

Quote:


  Originally Posted by *luvdunhill* /img/forum/go_quote.gif 
_._

 

my own words:

 "I took a detour to try out a digital pot and see if it was usable directly in the audio path. turns out it wasn't. oh well. but wouldn't know that until I tried. also got some experience which will pay back later, I hope."


 and so I tried a real simple digital pot in the audio path and it didn't work out. I still have other plans for that digital pot (...) and so it was never wasted work.

 this was not intended to be a PGA replacement, btw. the PGA is still a good 'mid-fi' chip as there are times when having that 31dB of gain is very useful! I've said this before, but when watching a DD5.1 movie that is downmixed to 2.0 (for spdif use) my source cuts things by at least 10dB and the content is often buried under that, as well, to allow for headroom. as a result, even setting the atten at 0dB and letting my dac run full-force is not enough to be able to hear the movie dialog. in those situations, you really do want/need gain and its nice to have that available. its also nice to have smooth volume swings between adjustments and that's possible with the solid state volume engines; not so much with chattery relay banks.

 on a home theater setup, I could even envision a hybrid of relays and PGA style. especially when you have 6 (5.1) channels or even more to have to manage and vary at the same time. I'd hate to hear that many relay banks going on and off at each volume twist!


----------



## linuxworks

Quote:


  Originally Posted by *Beefy* /img/forum/go_quote.gif 
_I didn't see that. I thought the two approaches were being developed in parallel._

 

more than two 
	

	
	
		
		

		
		
	


	




 one thing that benefits from concurrent multiple 'client' development is that you get to generalize the control aspect and get the code 'right' earlier than if you had to adopt some new style of client and 'merge that in'.

 quite a bit of code (and assumptions) had to change when I straddled the line between talking to relays and pga chips. it was a good exercise and very useful in coming up with the abstraction needed to make this work.

 don't forget, this is a research and design project; so rushing things isn't really helpful. I know people are eager to get hold of these things but rushing a design this complex too soon is not what anyone really wants to see happen.

 and just to give some numbers to the software size and complexity, for grins, here's some numbers:

 % wc -l *
 751 IRremote.cpp
 92 IRremote.h
 122 IRremoteInt.h
 646 LCDi2c4bit.cpp
 168 LCDi2c4bit.h
 102 config.h
 292 ds1302.cpp
 110 ds1302.h
 102 lm35.cpp
 56 lm35.h
 104 lm75a.cpp
 54 lm75a.h
 118 mcp23xx.cpp
 73 mcp23xx.h
 320 pga23xx.cpp
 94 pga23xx.h
 4885 volumaster_2_31.pde
 146 x10.cpp
 36 x10.h
 8271 total

 roughly 8000 lines of C code in this project, so far. not exactly a small project. the UI has many advanced features and we want the whole system to work and have future expansion ability without re-doing a lot of the code.

 we do believe that the feature set and architecture offered will be worth the wait


----------



## linuxworks

Quote:


  Originally Posted by *Beefy* /img/forum/go_quote.gif 
_How do you find the relay solution compares to your PGA 23** solution? Sound quality, difficulty to implement, any perspective would be great...... 
	

	
	
		
		

		
			



_

 

I brought one of my PGA air-wire test setups over to amb's place and we ran an rmaa on it. I believe at that time, it was essentially at the noise floor level of the test equip (we likely used the m-audio RME box). whatever the rme was at, the PGA was just about at that level, too. ie, it was very very good and surprised us both, to be honest.

 once the relays board is laid out and the testers have them in their hands, then the pga stuff can be revisited. for my own 5.1 use, I really want to have 3 of those pga's and so I'm personally interested in this chip/series, to be sure


----------



## linuxworks

Quote:


  Originally Posted by *luvdunhill* /img/forum/go_quote.gif 
_I believe LinuxWorks "abandoned" the PGA approach.. I think it's mentioned somewhere above in this thread, or in another thread 
	

	
	
		
		

		
		
	


	


_

 

please don't speak for me. as I've written in a few posts, today, this is just not the case.

 thanks.


----------



## luvdunhill

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_please don't speak for me. as I've written in a few posts, today, this is just not the case.

 thanks._

 

I'm not sure what you're deal is. Beefy asked a question and I referred him to a post that answered it.


----------



## linuxworks

my 'deal' is that you were speaking for me and I didn't appreciate it. I never once said pga was shelved or abandoned. its not your place to speak for me, that's all I'm saying.


----------



## swt61

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_please don't speak for me. as I've written in a few posts, today, this is just not the case.

 thanks._

 

If he's referring someone to something that you had previously posted, he's not speaking for you, you did that all on your own.

 That's all I'm saying.


----------



## luvdunhill

I couldn't remember the exact words... "shelved"? "abandoned"? whatever.. I summarized it from my memory instead of finding the exact post... yes, i put the word in quotes as it was my addition. Perhaps I should have used [sic] as well?

 Then, i found the exact post and quoted it to clear things up.


----------



## linuxworks

I'm trying to understand where this is coming from.

 looking back at what I posted, I see on page12:

 "some devel news: today I have the PGA volume control chip (pga23xx series) working across i2c via a port expander chip. I'm using a phliips PCFxxx series chip (for variety) and can remotely send {chipselect, clock, data} over i2c via a 'bit bang' at the i2c message level "

 so in november, I was experimenting with 'remoting' the pga across an i2c chip and bit-banging it. that worked and I used that in my m3 amp for a few months.

 then on page14, I say:

 "also, turning my attention to relay attenuation control circuits."

 and so that means, to me, that I've added more things to the project, not removed any.

 sorry if that was not clear.


----------



## luvdunhill

Quote:


 I took a detour to try out a digital pot and see if it was usable directly in the audio path. turns out it wasn't 
 

I think the above statement is the source. Personally, if I said something wasn't usable directly in the audio path, that would imply that it was no longer being worked on and a release wasn't being planned. Am I the only one who read things that way?


----------



## amb

Regardless of what was posted or interpreted, the fact is we have not abandoned anything. Relay-based attenuator and input/output selector modules are what we're going to release first, but we plan to add other modules in the future.


----------



## Beefy

No need to fight gentlemen, I'm not worth it!


----------



## Pars

Would there be any possibility of using the input select board or controller with a different I/O board? I am looking at making a board which would have 4 bal. and SE inputs, bal and SE monitor outs and bal and SE outputs, with a muting relay on the output. All inputs would have on-board relays.


----------



## linuxworks

Quote:


  Originally Posted by *Pars* /img/forum/go_quote.gif 
_Would there be any possibility of using the input select board or controller with a different I/O board? I am looking at making a board which would have 4 bal. and SE inputs, bal and SE monitor outs and bal and SE outputs, with a muting relay on the output. All inputs would have on-board relays._

 

if I understand you correctly, you want to use the lcduino1 as the controller but have it talk to your own board?

 its open-source and so yes, you should be able to 'software glue' your board to the lcduino1. if you use i2c it might be easier (as there will be examples to follow, to speed your customization).

 what you would do is to find the action routines (when the user presses 'input button 1', say) and then call your routine instead of the built-in one. like that.


----------



## luvdunhill

Chris, I'd expect that you'd need more circuity on your board that what you mentioned. (Perhaps you didn't give an exhaustive list?) For example, do you plan on having relay driver on the board and control mechanism as well?


----------



## Juaquin

Quote:


  Originally Posted by *luvdunhill* /img/forum/go_quote.gif 
_I think the above statement is the source. Personally, if I said something wasn't usable directly in the audio path, that would imply that it was no longer being worked on and a release wasn't being planned. Am I the only one who read things that way?_

 

Digital Pot =/= PGA volume chip

 I believe that is the source of your confusion. He abandoned the digital pot because it was hard to implement because of the input constraints. The PGA chip, on the other hand, had great results but requires a dual supply and is a little harder to implement, so I believe it was decided that the relay board would be the quicker and "cleaner" implementation for now, but the PGA is still on the table. Someone correct me if I'm wrong, I don't mean to put words in anyone's mouth.


----------



## linuxworks

Juaquin got my intention 100%. thanks, mate.

 and that digital pot IS going to show up again. "its not dead, yet" 
	

	
	
		
		

		
		
	


	




 but in the audio path is not what its meant for, at least that particular model. but can be good for other control things.


----------



## ujamerstand

Voltage sensing and auto/manual biasing tool anyone? You'll never have to open up your casing again. This is starting to look like the most versatile project ever!


----------



## linuxworks

that idea has been raised a few times 
	

	
	
		
		

		
			





 I personally like it. when I've had to tweak pots and watch meters, I thought to myself 'shouldn't a robot be doing this instead, and perhaps even monitoring it and allowing front-panel control of it?'

 servos do this without 'processing' but what if the circuit is not already designed to support this and you want some 'tuning module' as an option or accessory?

 yes, I think its a neat idea and good application of a control platform.


----------



## luvdunhill

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_Juaquin got my intention 100%. thanks, mate._

 

ahhh. i see... heh.

 Back in the good old days we didn't have microcontrollers and used these things called "servos" to do this type of stuff


----------



## linuxworks

like I said, servos are the conventional way. but what if you wanted to build in some rules or do fancy things that might need software assist? it might be nice to control time constants or even follow different rules for letting something warm up and then step into a different 'curve' for keeping it at some bias point. with a software component, you can at least try different things out and not have to solder or buy new parts 
	

	
	
		
		

		
		
	


	




 perhaps the controller can make use of multiple kinds of input: the current rail voltage or temperature or other variables and use that in making its decision. normal servos can't be that smart but controllers can.

 I wouldn't dismiss controllers are being 'overkill'. we like that here in DIY, don't we?


----------



## Pars

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_if I understand you correctly, you want to use the lcduino1 as the controller but have it talk to your own board?

 its open-source and so yes, you should be able to 'software glue' your board to the lcduino1. if you use i2c it might be easier (as there will be examples to follow, to speed your customization).

 what you would do is to find the action routines (when the user presses 'input button 1', say) and then call your routine instead of the built-in one. like that._

 

Basically.

  Quote:


  Originally Posted by *luvdunhill* /img/forum/go_quote.gif 
_Chris, I'd expect that you'd need more circuity on your board that what you mentioned. (Perhaps you didn't give an exhaustive list?) For example, do you plan on having relay driver on the board and control mechanism as well?_

 

I am just starting to determine whether this is a path I want to go down or not, so no, I haven't defined what is on the board beyond the jacks and relays. Since it will be a vertical back panel-mounted board, I don't have a ton of real estate to work with, so it may have to interface another board to interface to the controller.

 Is there any website with more detail on the this project? I have done machine language/assembly language programming before, but haven't played around with anything for several years now


----------



## luvdunhill

Quote:


  Originally Posted by *Pars* /img/forum/go_quote.gif 
_I don't have a ton of real estate to work with, so it may have to interface another board to interface to the controller_

 

Perhaps this is derailing this thread a bit, but I think you might at minimum want a relay driver. I have used a QFN package for this that is quite compact and I'd look at some of these type packages personally.Perhaps LinuxWorks has some recommendations as well. You might also want to talk with Jacob, as I think he's done a layout for something like this as well (vertical, etc.), and found that 4-layer board simplified things greatly.


----------



## linuxworks

I would suggest having an i2c decoder on your board and bit-mapping the relays. its just an array of relays; what they do doesn't matter as much. the 'handover' from the arduino controller to your board would be, I would think, i2c and you just have to define the 'application protocol' so that the controller and the i2c slave will speak the same semantics. ie, when the controller turns on bit 3, say, of the 8bit byte, what does bit 3 mean when you receive it on the target board side? it might mean to mute the main muting relay or it might mean turn on input 2 to the 'audio bus'.

 you'd define an interface (like a .h file) and then those defines would be used in both your hardware (so to speak, via pc traces) and on the controller side via custom 'driver' software.

 the glue comes in where you 'bind' the keypress (button X on a remote) to the abstract event you want to happen on the target board (latch bit 3, whatever that does on the hardware) and like that.

 that's kind of the broad overview of how I'd approach it. bit-map the 8 available bits (assuming you can fit all your 'states' into 8 bits) to some native board function and then flip those bits under software control when user events occur (button presses on remotes or front panels).

 if you use non-latching relays, its a lot easier and you just resend the 8 bits each time any one of them changes (i2c means you can't send just a bit or two; you are committed to 8 bits for each 'message' to the target board).

 the mcp controller that we used for the lcd interface could be used and you could use the lcduino1 schematic for the mcp connections. give your mcp chip a new 3bit address and put that chip on your board. connect your board to the common i2c bus and be sure to reference the right i2c address when sending byte mask (relay mask) updates.


----------



## linuxworks

progress on the relay controller side of things:













 it consists of 2 port expanders (i2c serial), 2 relay driver chips (ULN2803), 2 resistor SIPs (for relay 'bias' and led current limit) and 2 LED bargraph 'debug' displays.

 I also wrote a short C program that will calculate the R values needed for the R-2R ladder attenuator. here's a first version:

Index of /audio/r_2r_calc

 a sample run:


 % make
 cc -c r2r.c
 cc -o r2r r2r.o -lm

 % ./r2r 8 0.5 25000
 using bits=[8] stepsize=[0.5] z=[25000]
 max_atten=[127.5]
 bit 0 db -0.5 Rs=[1398.5] Rp=[421914.4] 
 bit 1 db -1.0 Rs=[2718.7] Rp=[204887.0] 
 bit 2 db -2.0 Rs=[5141.8] Rp=[96552.9] 
 bit 3 db -4.0 Rs=[9226.1] Rp=[42742.8] 
 bit 4 db -8.0 Rs=[15047.3] Rp=[16535.6] 
 bit 5 db -16.0 Rs=[21037.8] Rp=[4708.5] 
 bit 6 db -32.0 Rs=[24372.0] Rp=[644.2] 
 bit 7 db -64.0 Rs=[24984.2] Rp=[15.8] 

 I gave it 8 bits (8 relays), 25k as an output-z and 1/2dB as the native step-size. Rs is the series R and Rp is the parallel (shunt) R.

 the new volumaster LCDuino1 firmware will be able to take, from the user, the 2 key parms (# of relays installed, step size) and it will 'do the right thing' when talking to the relay controller.

 so, in theory, you could populate the 8-relay board with just 6 relays (if you wanted to) and space them .1 dB apart, such as this:

 % ./r2r 6 0.1 25000
 using bits=[6] stepsize=[0.1] z=[25000]
 max_atten=[6.3]
 bit 0 db -0.1 Rs=[286.2] Rp=[2158996.4] 
 bit 1 db -0.2 Rs=[569.1] Rp=[1073284.2] 
 bit 2 db -0.4 Rs=[1125.2] Rp=[530464.0] 
 bit 3 db -0.8 Rs=[2199.7] Rp=[259125.9] 
 bit 4 db -1.6 Rs=[4205.9] Rp=[123600.6] 
 bit 5 db -3.2 Rs=[7704.2] Rp=[56124.3] 

 and that would be the 6 R value pairs to use and you'd get just over 6dB of atten but down to the 0.1db level. if you wanted... 
	

	
	
		
		

		
		
	


	




 as long as the board matches the software (you enter those things to the software on the LCDuino1) then it will work.

 most people will probably go for 8 bits and .5db as the spacing, but you CAN do whatever you want, here.


----------



## fishski13

linuxworks,
 thanks for the post. very helpful 
	

	
	
		
		

		
		
	


	




.


----------



## linuxworks

Quote:


  Originally Posted by *jtostenr* /img/forum/go_quote.gif 
_Are the bargraph leds there only for development, or are they going to be on the production board as well?_

 

yes, we're planning on having board space there (and resistor networks) for people to populate. there are many sources for these bargraph chips (isolated non-bused led segments) and they're cheap and useful to debug things. so we're planning to have them on the production board.

 the firmware will have some 'demo' modes so you can see the firing sequence and also some true debug modes that will let you latch on and off each of the relays, so you can see if any of them are stuck or broken (initially or even over time). being able to see the lights could be useful in that pursuit.

 there will be a jumper (hard jumper or switch) to electrically disconnect them at will and stop the light show 
	

	
	
		
		

		
		
	


	




 normally they're off, anyway; on end is sitting close to + and the other end gets temporarily shorted to gnd to 'signal' a pulse to one side of the relay or the other. if side A, then that bank of leds will have lights turn on; and if side B of the relay wire, then the flash comes from the other bargraph chip. the pulse time is very short and so the lights will look like they're off most of the time and only when you turn the knob or use the IR remote will there be a short burst of 'run-up' and some light activity, then they will all look off again after run-up is over. its only when you run it in 1/100 speed (or like that) that you'll see the individual leds fire.


----------



## Juaquin

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_there will be a jumper (hard jumper or switch) to electrically disconnect them at will and stop the light show 
	

	
	
		
		

		
		
	


	


_

 

What if I want a light show? I'm mounting mine on the front panel baby!


----------



## linuxworks

during normal operation, the lights won't even be visible to get much of a show. the flashing would be over in mere milliseconds.

 if you run debug mode and stretch the timing your volume control events are blocked until all the bits are clocked out to the i2c serial bus. it could take a few seconds to display all the led flashes and no one would want to wait that long before being able to click up or down to the next volume level.

 the leds directly show the voltage pulses to the relays; so when you run in debug mode, you are holding voltage high for 'that long' while you display and pause on the led. just something to realize when you are playing around; and that these relays are meant to have current sent thru them, then STOPPED very shortly afterwards.


----------



## Juaquin

Yeah, I know. I just thought it would be fun to dream. If I really wanted the light show I'd hook the bargraphs up separately to a shift register and throw some bits at it with the Arduino.


----------



## linuxworks

these LEDs would not be good for a 'non debug' show.

 but nothing says you could not use the very same idea and give it a new i2c addr, then update the firmware to send pretty patterns or VU simulated levels (?) to such displays. as long as you don't take too much of a time slice (inside the big do-loop); things are kept simple, right now, and almost nothing is interrupt driven. if any one task takes too much time, the others are blocked until it gets around to them.


----------



## linuxworks

a heads-up for the home theater guys here. there's an hdmi switch (3 ports) on sale today for $15: 

Meritline.com - HDMI v1.3 + HDCP 3 Ports Mini Switch, intelligent Auto Switch and 3 pcs of 6 Feet HDMI v1.3 Male to Male Digital A/V Cable, 30 AWG Cable, Category 2 Certified, Support 1080P HD Resolution






 what caught my interest was that it has a remote IR input for picking the hdmi port that gets selected. IR is just TTL signaling and the arduino can easily learn and repeat IR commands. this means that, in theory, we could have this hdmi switch 'slave' to whatever spdif channel the user selects via the lcduino. this box would sit in the back of your a/v shelf and the hdmi cables would run to this; then a single cable would run from the hdmi box to your spdif/lcduino box. you'd setup the association of which spdif port goes with which hdmi port.

 for this price, I'll give this hdmi switch a try and see if its as remote-able as I think it may be.


----------



## amb

Introducing δ1 (delta1), the first of a series of application modules for the LCDuino-1.

 I will add more info here, but for now here is a 3D render "teaser" of the PCB:







 More info is found in this post.


----------



## jtostenr

Cool 
	

	
	
		
		

		
		
	


	




 Eagerly awaiting further developments...


----------



## Lil' Knight

That's awesome, Ti!
 How many steps does it have?


----------



## linuxworks

up to 8 relays, assignable to any step size you want (read my last few posts)

 install less if you want, then tell the controller about it.


----------



## amb

When fully-populated with 8 relays, you will have 256 steps.


----------



## aloksatoor

AWESOME!!! does it have a pot controller or only with buttons/IR?


----------



## amb

We designed it to be operable with IR remote or pot, or both. When using a motorized pot, you will be able to have the pot "track" the changes from the IR remote.


----------



## linuxworks

Quote:


  Originally Posted by *aloksatoor* /img/forum/go_quote.gif 
_AWESOME!!! does it have a pot controller or only with buttons/IR?_

 

the input control is via various means.

 you can use up/down buttons (actually, the firmware is fancier than that; it allows TWO up and TWO down buttons; one fast and one slow).

 you can use a pot (analog linear tracking pot; not needing 2 stereo tracks since its not passing audio directly). you can use a MOTOR POT, too (as you vary the volume on the IR remote, the motor will 'keep up' and the pot will always show the absolute current value).

 see this post (and its video link) for a demo of how that pot and motor will work:

http://www.head-fi.org/forums/f6/lcd...ml#post6109992

 as I press the button on the front (or remote, in this case), it recalls the last volume for that input and 'zooms over' to the right degree of arc that would indicate that volume level. press the button to go back to the previous input channel (then lookup its last volume value) and zoom over to that one. that demos the motor 'servo' action.


 you can use rotary encoders but those are less preferred (imho). we're encouraging linear pots and linear motor pots if you want a 'knob'.

 when I get time, I also plan to add direct input from an IR remote keypad so you could enter '1 4' to set the db level to 14. I find this style of UI least useful but it will be included, for completeness, once the prio-1 things are done.


----------



## Billyk

Oh boy!
 Go away for a few months....
 I'm gonna have to get me onea these!!
 Boy It looks great, nice work you guys!!!
 Thanks!!!!


----------



## ujamerstand

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_...you can use rotary encoders but those are less preferred (imho). we're encouraging linear pots and linear motor pots if you want a 'knob'...._

 

Why not? I was hoping to use one with a built in push button so that I could use it as a selection mechanism as well. It also bypass the need for a motorized pot if I want to use a IR remote.


----------



## linuxworks

Quote:


  Originally Posted by *ujamerstand* /img/forum/go_quote.gif 
_Why not? I was hoping to use one with a built in push button so that I could use it as a selection mechanism as well. It also bypass the need for a motorized pot if I want to use a IR remote._

 

the code currently supports normal non-motor linear pots (as input 'valuators') and you don't HAVE to use motors. if you build the code and turn motor-pots off (a flag) then it won't try to move what is not there 
	

	
	
		
		

		
		
	


	




 it also won't 'wait' for the pot to adjust itself and follows a different firmware code path. not a problem.

 but its a user interface 'problem' that I never liked. once you have out-of-band ways to adjust an entity, if you don't keep those in sync they become confusing to the user. since we can adjust volume via the handheld IR remotes, that's now 'out of band' compared to the front panel knob. if you changed the volume via the remote, the front knob is no longer 'true' anymore. but with a motor, this is solvable and the out-of-band controls still cause the others to sync-up.

 with rotary encoders, they also don't show absolute values. they're good at relative-values but suck at absolute positioning. they are also a lot more 'touchy' to use and even program for. some people are ok with how RE's feel but a lot (myself included) don't like them. if you like them, you are free to add code modules for them. there are even 'simple' ones that just click up and down on private spst pulse switches, so those don't require any code changes at all; they can wire directly in where the up/down buttons would go.

 the code is open-source and you can add whatever user-interface elements you want. but I have not spent much time on RE's since the motor pots are more novel (I think) and solve the problem better. and they're more fun (gotta admit that, too)


----------



## ujamerstand

I agree. I think its a matter of choice. I wanted to use a rotary encoder because I was searching for a minimalistic interface. A rotary encoder with a built in push button will allow me to loose all the buttons that will be needed when all the applications modules gets attached. I will be able to use just the rotary switch to command everything from source control to volume control. Any changes can be displayed by the lcd. So people who wants a pot as an absolute indicator can use a motorized pot. People who wants an all purpose control interface can go with the rotary encoder. Besides, who says both cannot be used at the same time? 
	

	
	
		
		

		
		
	


	




  Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_... since the motor pots are more novel (I think) and solve the problem better. and they're more fun (gotta admit that, too) 
	

	
	
		
		

		
		
	


	


_

 

Yes! I quite enjoy that video you posted. Any chance an acceleration and deceleration motion will be added to the movement procedure?


----------



## linuxworks

I tried using pwm to slow down the motors but I have not played enough with it.

 at first, I wanted it to work and work simply. then, I see a 2nd pass to make things more efficient; and replacing a logical PID algorithm with a true varying analog style PID (really varying the proportional part, at least) would be part of that. it can take a whole developer 'a while' to get that part really right and so I deferred that for another pass (or another developer!)

 there's also a limit to how fast that pot can spin. the video shows it moving at its full speed, which isn't very fast at all. I wonder if slowing it down as it gets near its destination is actually worth the extra code complexity? it needs to be evaluated.

 another part of the code that I have been deferring is 'grab detection' as I call it 
	

	
	
		
		

		
		
	


	




 if the motor pot is speeding along (someone unmuted it, say) and the operator grabs it; it would be nice for the system to notice that where it should be, its not. that would mean a person grabbed the knob and that we should immediately stop the motors! that part of the code also still needs to be developed.

 if I was going to use a rotary encoder, I would also look into some of the dedicated chips that can watch the encoder and report back 'summaries' to the host cpu. that will save a lot of interrupts and let the host cpu (arduino) do its many other things on its polling loop. having to watch for RE events AND be very fast with it - that's actually hard to do if you are doing many other things, as well. to get a really responsive RE, I'd like to see some front-end chip work done. want to do that for us?


----------



## ujamerstand

If only I am qualified. 
	

	
	
		
		

		
		
	


	




 But I guess I can read up on how I2C protocol works, and play around with an ATtiny85-20PU or something. It could be a fun summer project. haha


----------



## linuxworks

don't spend time on i2c. all you need to know is: you send a byte to an address and it gets there. that's it. not much more to it than that.

 i2c is used to send byte values to the relays (0..255, max, for the 8 relays) but that does not have anything to do with the pot stuff. the pot has 2 wires for CW and CCW rotate (those can be pwm-able) and there's 1 analog in pin used for the wiper of the pot (both ends of the pot are at vcc,gnd). analogRead() is done on the pot wiper pin and you get a 0..1023 absolute value back.

 and so the cpu is taking 0..1023 from the wiper, sending CW or CCW (or both, as a brake) to the motor and each poll it checks if its 'gotton there' or if it needs to continue CW or even reverse to CCW. maybe the user twisted the knob and now it should be going the other way. each poll, this gets checked and the _current_ direction is then sent to the h-bridge (for the motor).

 so its not even i2c stuff at all. the PID algorithm just reads the 0..1023 value and figures out where the volume should be (native is 0..255) and tries to get it there until its 'close enough' (delta is less than some percent).


----------



## Juaquin

I'd be interested in putting together a Rotary Encoder implementation of some sort, if no one else would like to, because I'm interested in using one. If you use a knob without a mark on it, you don't have those out of sync problems - turn clockwise for more volume, counter-clockwise for less. Combined with an LCD for feedback as to where you are on the scale, it's just as precise as using up/down buttons or IR control. I'll take a look over spring break.


----------



## linuxworks

if your knob has no pointer or marking, its true that absolute positioning is not useful. you can grab and turn any time you want, then 
	

	
	
		
		

		
			





 I was never able to get one of the regular encoders to run smoothly enough for me. I was always able to outrun it. always. even in a very (unrealistic) tight polling loop I could outrun it with a fast twist. I didn't like that and gave up trying to scan it with 'host time'. so, if there is a chip that will front-end this and just interrupt the host when it has an event (parsed) that would really help.

 the nice thing about the analog reading pot is that there is no guesswork in sampling its position. and 'debouncing' is done with any spare cap from the wiper to gnd. this gives a good fast way to vary the position and it does not waste a lot of host cycles.


----------



## ujamerstand

If I understand you correctly, all the dedicated controller does is to determine the actual direction of the RE from wiper readings, this is then sent to either the CW or CCW pin on the lcduino? Is the readings from RE that bad to need a dedicated controller specifically for this purpose?


----------



## linuxworks

Quote:


  Originally Posted by *ujamerstand* /img/forum/go_quote.gif 
_If I understand you correctly, all the dedicated controller does is to determine the actual direction of the RE from wiper readings_

 

RE and wiper? are you mixing the rotary encoder and pot?

  Quote:


 this is then sent to either the CW or CCW pin on the lcduino? Is the readings from RE that bad to need a dedicated controller specifically for this purpose? 
 

CW and CCW are signals *from* the controller to the motor (from the arduino to the l293d h-bridge chip and the chip then turns the motor one way or the other).

 so the feedback loop is: the cpu reads the analog voltage from the pot, across wiper and gnd. it gets a 0-1023 value and comes up with a percent of fullscale; it then uses that to scale the native volume level and sends that value to the volume engine part (relay, pga, whatever).

 the way the code works right now is that the analog value from the pot is sensed at every poll loop and if the value changes from the last stable value, we detect a 'user knob operation' and we take that value and scale the 0..255 (say) value for volume and immediately update the volume engine. that volume change takes effect right away; and if you turn the knob, the engine tracks that.

 the motor stuff is done via sticky bits 
	

	
	
		
		

		
		
	


	




 at the top of the big polling loop, the controller checks the wiper position and compares it against where it should be, given the current 'volume' byte value. if the compared value is not right, it figures if it should turn the motor one way or the other. it starts that operation and it STICKS, all the while, the code is free to continue its big polling loop and service other tasks. the big polling loop comes up to the top again and checks that pot/volume relationship again. if they are close it sends a 'stop' message to the motor (another sticky/latched message) and the polling loop continues on down. if the motor needs to be reversed, a 'stop, change direction' is sent and the pollling loop, again, continues. this achieves the effect of a background motor 'catch-up' with immediate foreground volume change events. the user interface never feels laggy or slow; even if the motor is still playing catch-up


----------



## luvdunhill

Just curious, what is the maximum (and minimum I suppose for completeness) number of resistors in the series and shunt in your implementation (i.e. in the signal path)?

 I've found that encoders can work very well, but you have to plan for a few things. Try keep the cpr of the device high enough so that you only rotate it once to reach the maximum and store the last value so that it can survive the device being turned off. In this case, a knob with a detent can work well, as long as the knob isn't turned when the device is off.


----------



## linuxworks

the user can install as many as 8 relays or as little as 1, I guess. each relay is 1 stage of attenuation and you either have a bypass or you have an 'attenuation' stage. each relay is its own stage.

 the result is a series of 'bypasses' and 'shunt/series' stages. so it depends on the binary value you plug in.

 if you have a 7 (0111) for example, that's 3 bits that are in the 'process' or attenuate state and 1 bit in the 'no effect' or bypass state. but as soon as you jump up to 8 (1000) that's now only 1 stage 'active' and 3 other ones are now in byass (passthru). its a binary thing like that. and it can be seen as you run the code in slow mode (demo mode) and see the lights flash on the led segments and see 1 relay turn off and 3 of them turn on (but pulsed, since they are latchers).


----------



## ujamerstand

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_RE and wiper? are you mixing the rotary encoder and pot?_

 

Eh? I thought you were talking about the Rotary encoder, and making an analogy between the motor and the lcduino, since you mentioned that RE might need a dedicated controller. 
	

	
	
		
		

		
		
	


	




 I didn't think that RE with detents would have such bad performance hit on the lcduino to require a dedicated controller. Since I thought that each interrupt would be significant. Perhaps I should leave it off for you guys to take care of it.


----------



## linuxworks

I have not tried the detented ones other than the spst pulse style (not a true encoder). but detent or not, it seems that they can be over-run or spun faster than the computer can track them. those become lost pulses and its not a smooth user interface. its hard to implement a rotary encoder well and I've seen plenty of commercial versions (cars, home stereos, even test gear) have a bounce-like effect when it hits a boundary condition. I never liked that aspect of rotary encoders.

 since the arduino has the luxury of an 'ok' a/d onboard, using a pot as a valuator makes good sense.

 another UI plus is that the value can roughly be seen from far away; even if the lcd values are too small to read, you can often still see the knob and its pointer and get an idea of where it is on the absolute scale. with a RE that has no pointer marking, you lose this user interface cue. its a useful cue to have, too. and to be able to look at it and know how much more 'twist' there is, that's also a useful UI cue.

 I'd suggest trying it over some time to see if its a UI style you like. perhaps you'll find that you don't want the RE style after you try this one


----------



## cobaltmute

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_I have not tried the detented ones other than the spst pulse style (not a true encoder). but detent or not, it seems that they can be over-run or spun faster than the computer can track them. those become lost pulses and its not a smooth user interface. its hard to implement a rotary encoder well and I've seen plenty of commercial versions (cars, home stereos, even test gear) have a bounce-like effect when it hits a boundary condition. I never liked that aspect of rotary encoders._

 

Detented encoders can get ugly.

 I've got my own working Arduino code that drives a PGA2311 from a rotary encoder on interrupts. I used a 24 PPR, 24 detent encoder as my first test. The problem is that if you actually look at the maps, 1 pulse != 1 detent. Over 1 detent on that encoder, 1 would be getting 4 interrupts using both encoder channels. I've made it work so that one detent equals 1 step, but the code drops alot of readings. Working with interrupts, there was no way I could can spin the encoder fast enough that the Arduino couldn't keep up.

 Now that was a $2 mechanical encoder. It works well enough, but there is a nice 32 detent, 8 PPR optical encoder at Mouser for $20 that I'm going to order for when my PCBs come in. The datasheet shows that it should not have that issue.


----------



## linuxworks

my code has put the IR decoding into interrupts but nothing else goes there. that seems to be a balance on what is really time critical (ir decoding certainly is) and what can wait (sensing pot value twists).

 if you are not doing IR decoding and not updating an lcd at regular intervals (are you?) then you can service RE events a lot faster.

 the option is quite open to support RE's but I don't find them as nice to use, on a daily basis, as the analog motor pot is. but that's not to stop anyone from using any valuator style they want. simply call your own routine to get value inputs instead of the read_analog_pot() kind of routine that is included in the code base.

 if you wanted to disable IR entirely and use your own interrupt routine, you could do that, too. that's the beauty of open source.


----------



## Juaquin

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_I was never able to get one of the regular encoders to run smoothly enough for me. I was always able to outrun it. always. even in a very (unrealistic) tight polling loop I could outrun it with a fast twist. I didn't like that and gave up trying to scan it with 'host time'. so, if there is a chip that will front-end this and just interrupt the host when it has an event (parsed) that would really help._

 

Yeah, I'm not sure about the smoothness or how fast it'll move, but I'm thinking an ATTiny2313 (for the two interrupts) with a little bit of software, just enough for interrupt handling and throwing some data at the main processor. Hopefully that'll catch most of the turns, especially without the abstraction layer of the Arduino library. If anyone has suggestions for good encoders I'm all ears. I mostly like the idea because you don't have to worry about mismatch between the IR input and the state of the pot, or use a motorized pot.

 To be clear, I'm mostly doing this for myself so although I'll make the design available for all (if I can come up with a good one), I don't expect it to be an "official" part of the LCDuino project. Don't listen to anything I say because I'm probably wrong


----------



## linuxworks

Quote:


  Originally Posted by *cobaltmute* /img/forum/go_quote.gif 
_ there was no way I could can spin the encoder fast enough that the Arduino couldn't keep up._

 

are you updating an lcd with graphics when you detect knob twists? that's also a 'burden' that the lcd1 has. the bargraph display on the lcd isn't free and it takes some cycles to compute and print.

 what would be really neat idea is to have an i2c slave that, anytime you query it, would give its absolute value or a relative one since the last i2c query. that would offload the main processor from the mundane 'tracking the RE' task. I could like that kind of design 
	

	
	
		
		

		
		
	


	




 but I'm not excited about having to track the RE and also do a bunch of other computation, as well.


----------



## linuxworks

if you come up with a tiny (heh) chip that pre-processes this and makes it 'synchronous friendly' so that the lcd1 can poll this chip and get an immediate answer (even if a RE event is locally being processed) then that's a useful addition and I'm sure a lot of people will want to try it out.

 that level of hardware/software is a good mix. if the hardware can free up the cpu, that's always good. I'd like to leave enough 'slack' room in the design so that more tasks can be added to the poll loop and still have decent response time.


----------



## luvdunhill

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_the result is a series of 'bypasses' and 'shunt/series' stages. so it depends on the binary value you plug in._

 

right, so with 8 DPDT relays, so how many series resistors at the maximum? 

 Also, what does the input and output impedance look like over the range of possible values? Are there cases where a buffer might be helpful?

 edit: just saw your reply above, that would be a rather cool approach.


----------



## amb

Quote:


  Originally Posted by *luvdunhill* /img/forum/go_quote.gif 
_right, so with 8 DPDT relays, so how many series resistors at the maximum?_

 

Eight resistors maximum at highest attenuation.

  Quote:


 Also, what does the input and output impedance look like over the range of possible values? Are there cases where a buffer might be helpful? 
 

You choose what you want the impedance to be, and we provide a calculator to display the resistor values necessary to implement it.

 A buffer is a good idea if the output of the attenuator and the next active stage (i.e., amp) will be far away. I recommend putting the attenuator as close to the input of the next active stage as possible.


----------



## linuxworks

the output z is kept constant, by design. for my table run, I picked 25k and with e96 resistors the output z stayed very close. I'm updating that 'table computer' software so that it shows the variation in true output z when you enter the actual R values you were able to buy and install.

 as for series R's, that would be 8 if 8 relays are installed, would it not? the R is in series or its shorted out; and the shunt is similarly in parallel or its 'opened up' and effectively removed from the equation. so worst case if all 8 R's are in play for max atten, its 8 R's in series. but as you get closer and closer to 0, the 'far end' resistors never come into play (their relays or bits stay at the 0 state) and so as you get closer to 0, you go thru 'lesser and lesser' series R's.

 I do think a buffer stage is a good idea; or to install this very close to the input of the actual amp. this is basically a passive preamp in its raw state and should be treated as such. buffer or put close to the next gain stage.


----------



## luvdunhill

ah, ok now I see how it works.. I assumed correctly at the beginning, and then managed to confuse myself. very cool stuff.

 So, then what is the maximum attenuation? Is the attenuation curve linear?


----------



## linuxworks

you should really just download my source code and read it 
	

	
	
		
		

		
			





 there is no max atten. the user decides:

 - # of bits (ie, relays)
 - spacing between steps (half db, full db, tenth db, etc)
 - output Z

 you plug those things into the calc and it gives you the R values to use as well as showing the max atten.

 simple case: 255 steps and each step is a db, then that's 255 db max atten.

 if you make the steps half a db but stay with 8 relays, then your max atten is now half, so that's 127.5db.

 read the source for more insight 
	

	
	
		
		

		
		
	


	




 and yes, its linear in a logarithmic kind of sense. each step is the same size and so you can dial in any db value, in native step-size increments and if you count up or down by just 1 click, you get the same level of atten difference. the step sizes are all the same; its not a variable one, if that's what you are asking.


----------



## Juaquin

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_if you come up with a tiny (heh) chip that pre-processes this and makes it 'synchronous friendly' so that the lcd1 can poll this chip and get an immediate answer
 ...
 that level of hardware/software is a good mix. if the hardware can free up the cpu, that's always good._

 

Yeah that's the idea, the Arduino only has two interrupts so using a RE would make it so you couldn't even use a pushbutton on/off switch, or any other interrupt-driven process. It may be overkill to use a whole extra chip for the RE but it's necessary, and it guarantees that the RE has all the cycles it wants so hopefully you don't miss any steps. At least, that's what I'm hoping.


----------



## cobaltmute

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_my code has put the IR decoding into interrupts but nothing else goes there. that seems to be a balance on what is really time critical (ir decoding certainly is) and what can wait (sensing pot value twists).

 if you are not doing IR decoding and not updating an lcd at regular intervals (are you?) then you can service RE events a lot faster._

 

 Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_are you updating an lcd with graphics when you detect knob twists? that's also a 'burden' that the lcd1 has. the bargraph display on the lcd isn't free and it takes some cycles to compute and print._

 

I'm using one of Sparkfun's serial controlled LCD's so my control of the LCD is a little simpler. I'm only reporting the volume as text, but I'm doing a touch of math to catch the 0.5db steps using INT math. I do have to watch my update rate as the code can write to the SerLCD module and LCD too fast and lock the display.

 My basic code loop is like:
  Code:


```
[left]do every millisecond watch for debounced encoder button push if button-pushed mute or un mute update LCD = true if current vol != encoder position current vol++ or current vol -- updated-lcd = true Update LCD if required end do loop interrupt code encoder_pos++ or encoder_pos-- based on grey code.[/left]
```

There is some inspiration here from luvdunhill's project. 
	

	
	
		
		

		
		
	


	




 There is another twist going on, but that's a secret until it is fully implemented/debugged.

  Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_if you come up with a tiny (heh) chip that pre-processes this and makes it 'synchronous friendly' so that the lcd1 can poll this chip and get an immediate answer (even if a RE event is locally being processed) then that's a useful addition and I'm sure a lot of people will want to try it out.

 that level of hardware/software is a good mix. if the hardware can free up the cpu, that's always good. I'd like to leave enough 'slack' room in the design so that more tasks can be added to the poll loop and still have decent response time._

 

It is interesting to imagine what could be done taking two projects and smashing them together. The board I've just finished laying out includes an Arduino and two PGAs. It has also been designed so you can stack the boards so you can control a stack of PGAs at once. Between pins used for hardware jumpers (4), LED indication (2) and LCD control (1) there is a few places you could hack my code/board to integrate.


----------



## bou

I have used the LSI/CSI RE interface. They have different model, they have some that gives you a pulse up and pulse down, but they also have some with an internal counter. So the chip takes cares of the actual count and the arduino just have to question the interface to know at what count it is.

 I used the second version (the LS7566r) in a project and they work quite nicely.


----------



## linuxworks

that sounds kind of interesting.

 distributed processing makes sense as you add more and more things that have to be done. if you start to get fancy on the lcd (or even get into graphics) then there just is no time to be 'eventful' on something like a RE.

 but if some smaller chip can spend 100% of its time watching the wheel go round (lol) and then report back to a caller (i2c would be really nice and universal) what the current value is, that would be a nice hardware interface to a useful and much used function.

 combining functional blocks IS what its all about, I think. that's one of the reasons the hw and sw are both open. if people want to do some merge and adopt this UI element or that control function, they should be able to. they won't have to start from scratch and they should be able to re-glue various parts to their liking.

 if you have an arduino and pga's together, that could be considered a callable system on its own. if you run i2c slave code in your cpu, you can 'act' like a delta 1 relay bank and the lcduino1 controller could talk to it and control it.

 the delta1 controller doesn't have a cpu onboard, just port expanders so the only way to talk to this board is on its own terms 
	

	
	
		
		

		
		
	


	




 but its simply 0..255 on one i2c addr and 0..255 on the other. and any byte pattern you write should be a kind of complement to the one on the other side since its a latcher and you want to write opposite patterns to pulse a + or - direction and then unpulse shortly after. all of that logic is done on the main controller, so if you wanted to talk to the delta1 relay board, you'd have to adopt that drive code into your controller.

 it does seem do-able and if all the code is in the same platform (arduino) that makes integration much easier of a task


----------



## linuxworks

Quote:


  Originally Posted by *bou* /img/forum/go_quote.gif 
_I have used the LSI/CSI RE interface. They have different model, they have some that gives you a pulse up and pulse down, but they also have some with an internal counter. So the chip takes cares of the actual count and the arduino just have to question the interface to know at what count it is.

 I used the second version (the LS7566r) in a project and they work quite nicely._

 

that's what I'm talking about 
	

	
	
		
		

		
		
	


	




 I think I did come across some chips to do this (specialty) but I never got anything to try.

 the internal counter model is very close to the analog pot model, so the code would not have to change much at all. and, it makes things real simple if the remote device maintains 'state'. it also means that other masters (controllers, possibly concurrently) can also query this thing and gets its counter value. pushing the info down into the 'managed element' itself is a good model; having it be more and more remote from itself is less and less good


----------



## luvdunhill

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_and yes, its linear in a logarithmic kind of sense. each step is the same size and so you can dial in any db value, in native step-size increments and if you count up or down by just 1 click, you get the same level of atten difference. the step sizes are all the same; its not a variable one, if that's what you are asking._

 

very cool. I think it would be nice to give the user the ability to make the thing feel like a stepped attenuator from a curve standpoint. I guess that's the beauty here, someone could code this. I cannot imagine with -255dB attenuation and 1dB steps the fact that you have so many steps to really be all that worthwhile from a usability standpoint. I'd rather have a few large steps and then in the commonly used range go down to 0.25dB or something.
 I've implemented this, and it seems to work really well... another idea is to have a switch that can be used to alter the step size. I used the switch built into the encoder for this and it's a pretty cool feature. Lots of things to play with, so this should be a fun project for those so inclined!


----------



## linuxworks

when you say alter the step size, do you mean the actual attenuator network or just display/counting games?

 the way I'm seeing it, the native engine has a characteristic step size, based on how its designed. the pga has a native (lowest) of .5db. the user can configure the delta-1 relay array to be whatever step-size they want and that will be the base resolution in how to count up or down.

 now, that's the native engine. the display, otoh, can show different things. if the user wants to click up and down in single db amounts, and yet the native engine might be half db's, this just means that each up-arrow press bumps the native volume value up twice as fast (or left shift by 1 bit, for speed). this way the user gets to move up and down faster or slower (not have to count based on native step size) and yet you need no changes to the engine to support this. its all a 'display and counting trick' so to speak.

 if you have a native engine that gives lots of resolution (say down to half db) then you can 'imply' any curve you want on that, if it makes you happy. you can layer a user curve and translate (map) one to another. as the user turns the pot, you can map that degree of arc to a y-value on some curve and then send that adjusted or scaled value to the engine. this is what's nice about software vs hardware brute-force techniques; you can change the 'curve of the pot' any time you want and in any way. even have discrete plotted values for the translation table if you don't want a math style curve 
	

	
	
		
		

		
		
	


	




 I actually don't find the need for it, though, in the real world. having single db steps or even half db is more than you need to do volume control for real world use. this isn't some 24 or 48 step switchbox; this is 127 and 255 steps of atten that you can set to pretty fine spacing. with that much res, I'm not so sure you need to project alternate curves on this.

 the system I've been living with has 'only' 1db steps and goes from 127 to 0db. I have my long-jump set to count in 4db steps and the short-jump to count in 1's. I find this to be a good set of values to use; the long-jump lets you speed up and down to a value, quickly; and the single 1db up/down's let you fine tune the level once you've sped to the general target volume level. splitting down to the half db level seems overkill to me, but its allowed if you really want to split db's like that


----------



## linuxworks

working on a web CGI to do the maths for you:







 alternate line-wrapped version:






 when the code is finished, we'll post a URL so that you can plug in and calculate your own values.


----------



## mugdecoffee

What would make the resistor calculator absolutely amazing would be if it could generate a mouser or digikey BOM too.


----------



## linuxworks

planned!

 its allowed for, already, in the code:

 typedef struct evalues {
 double std_val;
 char *vendor1_partnum;
 char *vendor2_partnum;
 } _evalues;

 _evalues e96_table[] = {
 { 01.00, "", "" }, 
 { 01.02, "", "" }, 
 { 01.05, "", "" }, 
 { 01.07, "", "" }, 
 { 01.10, "", "" }, 
 { 01.13, "", "" }, 

 just need someone to fill in the vendor1 and vendor2 string parts (and maintain it!) and we should be in business. I did only code a single decade (0..10) and I scale the values in powers of 10 to normalize before I search. so there needs to be some way to take the part numbers and 'scale' them, too. hopefully its not too hard and that vendors used some rhyme/reason to partnumber their parts.


 I've coded the e6, e12, e24, e48, e96 and e192 resistor tables so it can find the 'nearest' real value from the theoretical one.


----------



## nattonrice

If you listed rn55d and standard xircon parts it would be virtually maintenance free =)


----------



## amb

The board will have pads for resistors with 5mm, 10mm and 12.5mm spacings. You could also use a combination of these pads to fit additional intermediate sizes. This means it can support RN50, RN55, RN60 and other sizes too, including the Vishay-Dale PTF series. Or if you want to get really fancy, the Vishay S104 foil resistors (that is, if you could find them and don't mind the price).


----------



## srserl

When I was looking at rotary encoders awhile back, I stumbled upon laser mouse sensors which seem very powerful and adaptable to many tasks, including rotary encoding. I would like to revisit that idea sometime, but too busy right now.


----------



## MASantos

Quote:


  Originally Posted by *amb* /img/forum/go_quote.gif 
_The board will have pads for resistors with 5mm, 10mm and 12.5mm spacings. You could also use a combination of these pads to fit additional intermediate sizes. This means it can support RN50, RN55, RN60 and other sizes too, including the Vishay-Dale PTF series. Or if you want to get really fancy, the Vishay S104 foil resistors (that is, if you could find them and don't mind the price). 
	

	
	
		
		

		
			



_

 

Will it support SMD resistors?


----------



## jtostenr

Quote:


  Originally Posted by *amb* /img/forum/go_quote.gif 
_The board will have pads for resistors with 5mm, 10mm and 12.5mm spacings. You could also use a combination of these pads to fit additional intermediate sizes. This means it can support RN50, RN55, RN60 and other sizes too, including the Vishay-Dale PTF series. Or if you want to get really fancy, the Vishay S104 foil resistors (that is, if you could find them and don't mind the price). 
	

	
	
		
		

		
		
	


	


_

 

I looked around and didn't see the S-series anywhere, but after seeing the prices for the PTF series, I'm not going to bother looking anymore lol. For a 1/8W, .01% PTF resistor, you are looking at $5.95 each 
	

	
	
		
		

		
		
	


	




 How many of these would we need? Looks like 34 per board in the pic. So, 68 for a balanced config? That's over $400 just for resistors.....If that's correct, I think I'll stick with the RN series 
	

	
	
		
		

		
		
	


	




 Edit: Turns out Mouser does carry a few of the S series...$32 a piece lol.

http://www.mouser.com/ProductDetail/...0kmFDO9y0sI%3d


----------



## cobaltmute

S series are available here:

Texas Components - Precision Resistor & Microelectronics

 I believe qusp has ordered from them


----------



## linuxworks

another peek at the CGI, in progress:






 this was a silly example but it shows that you can plug in fractional values and it will still work.

 its still in C code (it took almost 2000 lines of C code to get that to run, live) but will be converted to perl when we get a chance and then hosted on a public server so that people can get at it.


----------



## jtostenr

Quote:


  Originally Posted by *cobaltmute* /img/forum/go_quote.gif 
_S series are available here:

Texas Components - Precision Resistor & Microelectronics

 I believe qusp has ordered from them_

 

Very interesting, if you have a need for super-high precision stuff. They even have "Z" series resistors if S aren't good enough. Of course they are *$51 each*! (from Mouser anyway).


----------



## linuxworks

$51 each??

 are they, at least, _directional?_ and marked for which way the current goes best?

 (yes, I'm kidding. really.)


----------



## Juaquin

I've seen $50 caps. Why not resistors?


----------



## amb

Quote:


  Originally Posted by *MASantos* /img/forum/go_quote.gif 
_Will it support SMD resistors?_

 

No, there are no SMD parts anywhere on this board, and there are plenty of excellent through-hole resistors to choose from.


----------



## Beefy

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_this was a silly example but it shows that you can plug in fractional values and it will still work._

 

I know that the TPA Joshua tree has a fixed output impedance, and variable input impedance. How does this attenuator work in that respect?


----------



## linuxworks

Quote:


  Originally Posted by *Beefy* /img/forum/go_quote.gif 
_I know that the TPA Joshua tree has a fixed output impedance, and variable input impedance. How does this attenuator work in that respect?_

 

I think its the opposite way, isn't it? the TPA is constant on the input side whereas this is constant on the output side.


----------



## Beefy

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_I think its the opposite way, isn't it? the TPA is constant on the input side whereas this is constant on the output side._

 

"The kit's input impedance varies between 2.2K and 10K, with a fixed output impedance of 750R."

 From here.


----------



## linuxworks

I had in and out reversed in my mind, I think 
	

	
	
		
		

		
		
	


	




 (go get coffee BEFORE you post first thing in the AM, lol).


 here's an expanded run of the CLI tool that now shows effective dB stage attenuation (based on actual resistor values; not ideal ones) as well as the actual calculated input z. so yes, its input z that is kept constant:

 ./r2r_cli 8 .5 25000
 using bits=[8] stepsize=[0.5] z=[25000]
 max_atten=[127.5]
 bit 0 dB -0.5 Rs=[1400] Rp=[422000] acutal dB=[-0.500523] actual Zin=[25001.8]
 bit 1 dB -1 Rs=[2740] Rp=[205000] acutal dB=[-1.00733] actual Zin=[25022.6]
 bit 2 dB -2 Rs=[5110] Rp=[95900] acutal dB=[-1.99144] actual Zin=[24940.4]
 bit 3 dB -4 Rs=[9310] Rp=[43200] acutal dB=[-4.01651] actual Zin=[25145.8]
 bit 4 dB -8 Rs=[15000] Rp=[16500] acutal dB=[-7.99033] actual Zin=[24939.8]
 bit 5 dB -16 Rs=[21000] Rp=[4750] acutal dB=[-15.9329] actual Zin=[24991.6]
 bit 6 dB -32 Rs=[24300] Rp=[649] acutal dB=[-31.9131] actual Zin=[24932.6]
 bit 7 dB -64 Rs=[24900] Rp=[15.8] acutal dB=[-63.9618] actual Zin=[24915.8]


 this is my semi standard run using 8 bits, half db steps and 25k target Z. the last 2 columns show the effect of using e96 resistors.

 to constrast, if we used ideal resistors and not standards-based values, the run shows this:

 ./r2r_cli 8 .5 25000
 using bits=[8] stepsize=[0.5] z=[25000]
 max_atten=[127.5]
 bit 0 dB -0.5 Rs=[1398.48] Rp=[421914] acutal dB=[-0.5] actual Zin=[25000]
 bit 1 dB -1 Rs=[2718.73] Rp=[204887] acutal dB=[-1] actual Zin=[25000]
 bit 2 dB -2 Rs=[5141.79] Rp=[96552.9] acutal dB=[-2] actual Zin=[25000]
 bit 3 dB -4 Rs=[9226.07] Rp=[42742.8] acutal dB=[-4] actual Zin=[25000]
 bit 4 dB -8 Rs=[15047.3] Rp=[16535.6] acutal dB=[-8] actual Zin=[25000]
 bit 5 dB -16 Rs=[21037.8] Rp=[4708.48] acutal dB=[-16] actual Zin=[25000]
 bit 6 dB -32 Rs=[24372] Rp=[644.152] acutal dB=[-32] actual Zin=[25000]
 bit 7 dB -64 Rs=[24984.2] Rp=[15.7839] acutal dB=[-64] actual Zin=[25000]

 and for those that want to check me, here's the logic:


 Rp = ( pow(10, (db/20)) * output_z / (1 - pow(10, (db/20)) ) );

 Rs = ( output_z - (1 / ( (1/Rp) + (1/output_z))) );

 actual_db = 20 * log10(output_z * computed_Rp / (output_z + computed_Rp) / (computed_Rs + output_z * computed_Rp / (output_z + computed_Rp) ));

 actual_z = computed_Rs + ( output_z * computed_Rp) / (output_z + computed_Rp);


 ...for those that care


----------



## amb

As promised, here are more details about the δ1 relay-based stepped attenuator.

 First, a 3D render update to show the latest version (v0.6).






 Here is the PCB layout, for a larger version click here:






 Here is the schematic diagram:










 The board has two sections, a "Driver" section and an "Attenuator" section. Each section is on a separate page of the schematic diagram shown above.

 The two sections will come as one board, but it will be grooved so that you can optionally snap it apart to mount the two sections separately. A ribbon cable with IDC dual-row sockets on each end can be used to connect the two sections (J4 and J5).

 These boards are designed to be stackable. One board supports two channels (stereo), two boards support four-channel balanced. You can stack even more boards if desired, up to a limit imposed by the number of available I2C addresses (see below).

*Attenuator section*

 The attenuator section contains the relays and resistors for the resistive ladder, as well as input/output Molex connectors for each channel (J6 and J7). There are separate analog double ground planes for each channel. There are also positions for optional ground loop breaker resistors and caps, which could be populated if your build needs this. Two of the attenuator section mounting holes can be used as a contact to the chassis through metal standoffs and screws. If you do not populate the ground loop breaker parts, then the onboard analog signal grounds are left floating.

 As discussed before, up to 8 relays are supported, giving us up to 256 steps of control. You may configure the last relay (K8) as a "mute" relay by installing wire jumpers across RS8 and RP8, which will reduce the number of steps by half. When all relays are used as attenuators (rather than having the last one serve as "mute"), and choosing 0.5dB steps, you will still be able to reach -127.5dB of attenuation, which is "mute" for all practical purposes.

 You can also choose to populate less than 8 relays, one less relay results in halving the number of steps. Also as mentioned, the step size (number of dB per step) and attenuation range will also be configurable, so you could build an attenuator for specialize applications. A special web-based calculator will be available to help you select the optimum resistor values for your requirements.

 The board supports through-hole resistors of 200, 400 and 500 mils lead-spacing (5mm, 10mm and 12.5mm). Other intermediate sizes are also possible by using the pads between those three sets. This lets δ1 accommodate a wide range of resistor types, including RN50, RN55, RN60 and PTF types from Vishay-Dale.

 The relays are latching type, which means that the driver circuit only needs to send the coil a pulse to set the state, and then no more coil current is needed to maintain that state. To change states, a reverse polarity pulse is applied. This means that the relays will draw no current when the volume is not being changed, and will maintain their states even when power is turned off.

*Driver section*

 The driver section has a 6P Molex connector (J1) that serves as the "Interface" connector to the LCDuino-1's I2C bus as well as for +5V power supply and digital/logic ground. There is also an ALT_POWER pin which may optionally be used to connect a separate power supply for the relay coils, rather than using the "regular" +5V supply (this is jumper-configurable with JP2). ALT_POWER can be something other than 5V, if you use this then choose your relay coil voltage specs accordingly.

 If more than one driver section boards are stacked together, 6P headers and receptacles (J2 and J3) on the board may be added to propagate the I2C bus signals, power and ground to all stacked boards without the need for separate wiring from the LCDuino-1 or the power supply. There are pads for two such "stacking" connectors, so that you may, for instance, populate a male header in J2 on the component side of the 1st (bottom) board, and a female receptacle in J2 on the solder side of the 2nd board. If you need to stack more boards, then populate a male header in J3 on the component side of 2nd board and a female receptacle in J3 on the solder side of the 3rd board. And this could be repeated in J2 for the 4th board, etc.

 The driver section board has holes for "normal" chassis mounting, but also has holes for mounting behind the LCDuino-1. It is taller than the LCDuino-1, so this method would only be feasible if there is sufficient height in the case.

 Each driver section contains two PCF8574 I2C port expander chips which gives us 8 bits each (to drive up to 8 relays). Since the relays are single-coil latching type, they need coil voltage polarity reversal to change states, so we use two port expander chips, which allows the firmware full control of the relay coils. Each PCF8574 port expander chip must occupy a unique I2C address, which is configured by JP1 and JP2, respectively. There are 3 bits each, so there are 8 possible addresses to choose from. Since each board uses two addresses, that means only up to four boards are possible. However, there is a PCF8574A chip (note the A suffix) that will give us a different address space, so there could be up to eight δ1s on the bus (not counting any other I2C devices that may be sharing the address space, of course).

 Two ULN2803 darlington array chips provide the actual "drive" of each end of the relay coils. Two 10-segment LED arrays can be populated to display the state of the relay coil drive, and a spare LED on each one of these serve as the power indicator. There are two remaining unused LEDs, one on each array (TST0 and TST1), which are pulled up by the resistor network R1+ and R1- and can be optionally used to provide some other state indication if you want. All LEDs can be disabled or enabled with a jumper (JP3).

*Current status*

 We will be prototyping δ1 very soon, updates will be posted here.


----------



## glt

Quote:


  Originally Posted by *Juaquin* /img/forum/go_quote.gif 
_I'd be interested in putting together a Rotary Encoder implementation of some sort, if no one else would like to, because I'm interested in using one. If you use a knob without a mark on it, you don't have those out of sync problems - turn clockwise for more volume, counter-clockwise for less. Combined with an LCD for feedback as to where you are on the scale, it's just as precise as using up/down buttons or IR control. I'll take a look over spring break._

 

I've implemented some very simple code and used capacitors for debouncing. Works 100% reliable for me. H I F I D U I N O: Arduino Code for Rotary Encoder


----------



## glt

Quote:


  Originally Posted by *cobaltmute* /img/forum/go_quote.gif 
_Detented encoders can get ugly.

 I've got my own working Arduino code that drives a PGA2311 from a rotary encoder on interrupts. I used a 24 PPR, 24 detent encoder as my first test. The problem is that if you actually look at the maps, 1 pulse != 1 detent. Over 1 detent on that encoder, 1 would be getting 4 interrupts using both encoder channels. I've made it work so that one detent equals 1 step, but the code drops alot of readings. Working with interrupts, there was no way I could can spin the encoder fast enough that the Arduino couldn't keep up.

 Now that was a $2 mechanical encoder. It works well enough, but there is a nice 32 detent, 8 PPR optical encoder at Mouser for $20 that I'm going to order for when my PCBs come in. The datasheet shows that it should not have that issue._

 

If you set the interrupt to detect only rising of one channel then you only read one interrupt per detent.


----------



## glt

Quote:


  Originally Posted by *Juaquin* /img/forum/go_quote.gif 
_Yeah, I'm not sure about the smoothness or how fast it'll move, but I'm thinking an ATTiny2313 (for the two interrupts) with a little bit of software, just enough for interrupt handling and throwing some data at the main processor. Hopefully that'll catch most of the turns, especially without the abstraction layer of the Arduino library. If anyone has suggestions for good encoders I'm all ears. I mostly like the idea because you don't have to worry about mismatch between the IR input and the state of the pot, or use a motorized pot.

 To be clear, I'm mostly doing this for myself so although I'll make the design available for all (if I can come up with a good one), I don't expect it to be an "official" part of the LCDuino project. Don't listen to anything I say because I'm probably wrong 
	

	
	
		
		

		
			



_

 

I think this chip is designed to do that http://www.lsicsi.com/pdfs/Data_Shee...183_LS7184.pdf


----------



## jtostenr

Very nice work!

 What are the dimensions of the board?




			
				amb;6477792 said:
			
		

> As promised, here are more details about the δ1 relay-based stepped attenuator.
> 
> First, a 3D render update to show the latest version (v0.6).
> 
> ...


----------



## Juaquin

Quote:


  Originally Posted by *glt* /img/forum/go_quote.gif 
_I think this chip is designed to do that http://www.lsicsi.com/pdfs/Data_Shee...183_LS7184.pdf_

 

Looks good, but do you have a source where these could be found consistently and in quantity? I found a couple one-offs here and there, but unless Mouser/Digikey/Newark/etc sell them consistently it wouldn't help much to design something around it.

 The ATTiny2313 might not be built specifically for the job, but it's cheaper (than the LS7183's I can find), easily available, and easily hacked/reprogrammed.


----------



## linuxworks

using a general purpose and small sized cpu would be a good idea, I think. the code could be extended and adapted to the purpose, as designs change. adaptability is worth something.

 if that chip could be an i2c player (slave) and have enough internal buffering so that it might 'compress events' and burst that summary up to the host upon i2c query, that would be cool as hell and a nice way to offload the UI details of RE's.

 if there are any existing (good) protocols (between host and the RE subcontroller chip) it would be good to consider reusing one rather than inventing a new one.


 edit: I just looked at that pdf. it does not have an i2c interface, it does not have any kind of buffering (that I could find), it does not compress events and its mostly a realtime converter of quadrature to 'pulses'. that may be useful in *decoding* it but I'm not sure that it offers enough of an acceleration to make it useful. slightly, but we can do better with a custom and small cpu, I think.


----------



## Juaquin

Quote:


  Originally Posted by *linuxworks* /img/forum/go_quote.gif 
_using a general purpose and small sized cpu would be a good idea, I think. the code could be extended and adapted to the purpose, as designs change. adaptability is worth something.

 if that chip could be an i2c player (slave) and have enough internal buffering so that it might 'compress events' and burst that summary up to the host upon i2c query, that would be cool as hell and a nice way to offload the UI details of RE's._

 

i2c would be easy because libraries already exist for the Arduino and ATTiny's. Then just send an update every 20ms or so with the counter (positive or negative) of all the RE inputs during that 20ms. That'll take the load off the Arduino, especially with respect to interrupts, while still allowing good volume control, I think. I'll breadboard it together over spring break and see what happens.


----------



## amb

Quote:


  Originally Posted by *jtostenr* /img/forum/go_quote.gif 
_What are the dimensions of the board?_

 

Currently the δ1 board driver section is 3.2" wide and the attenuator section is 4.8" wide. Both are 2.6" deep. This is not cast in stone, and may change in future revisions.


----------



## vixr

crap... I was hoping to put this on my B22...its quickly getting waaay over my head. sigh...


----------



## linuxworks

there will be standard firmware and it I believe you will be able to get chips preprogrammed with the code on it. so its simply a matter of hooking up 5v, running some cables as documented and that's it.

 we will compile a few sample BOM listings for common configs (8 relays, half db steps; 7 relays, 1 db steps, etc) and this will make picking your resistor sets easier. you can create your own but you don't have to; you can use one of the standard ones.

 use of the device will be simple and will work similar to other ones.

 but if you want to customize things, that's where all this extra stuff comes into play. but its entirely optional; the system is designed to be simple to install and use, by default. its still just a fancy volume control with line-in connectors and line-out connectors


----------



## amb

Quote:


  Originally Posted by *vixr* /img/forum/go_quote.gif 
_crap... I was hoping to put this on my B22...its quickly getting waaay over my head. sigh..._

 

Vixr, there has been a lot of talk here about the "what-if"s, like rotary encoders and other possibilities that would require you to do some engineering of your own, including firmware.

 However don't let that talk confuse you. Getting this all to work in a standard manner won't be much more complex than using a regular stepped attenuator. It will be just the matter of stuffing the LCDuino-1 and δ1 boards (the arduino chip will be available pre-programmed) and connecting power, ground and some other wires.


----------



## Olli1324

Will remote control operated volume be supported upon release? (i.e parts requirements, firmware changes if necessary)


----------



## amb

Quote:


  Originally Posted by *Olli1324* /img/forum/go_quote.gif 
_Will remote control operated volume be supported upon release? (i.e parts requirements, firmware changes if necessary)_

 

Yes.


----------



## Olli1324

Too cool, too cool.

 Really looking forward to it 
	

	
	
		
		

		
		
	


	




 It's going to go great with my Bijou.


----------



## linuxworks

Quote:


  Originally Posted by *Olli1324* /img/forum/go_quote.gif 
_Will remote control operated volume be supported upon release? (i.e parts requirements, firmware changes if necessary)_

 

the system is designed around the 'learning-receiver' method; this means that it should work with most existing remotes and you go thru a guided learn dialog when you first configure the system and teach it which buttons on YOUR remote you want to be volume-up, down and so on.

 so, that's one less part you have to order or worry about 
	

	
	
		
		

		
		
	


	




 as for firmware, we'll have some standard releases and, like any software, there will be interim updates or bugfixes as needed. as a user, you are free to use the as-shipped firmware or try newer versions as they come out. at any time, you can also roll-back to older versions, safely, if you wish. the controller chips are in the $5 range (give or take) and one strategy is to keep one chip with 'as shipped' firmware and another as a playground. that way you can always bump the playground chip's version up and test it out; but not have to wipe it and reflash it to revert. I sometimes have older firmware 'saved' in a spare chip since its pretty quick to just swap chips and mark one as 'production' and one as 'latest beta'.


----------



## vixr

Quote:


  Originally Posted by *amb* /img/forum/go_quote.gif 
_Vixr, there has been a lot of talk here about the "what-if"s, like rotary encoders and other possibilities that would require you to do some engineering of your own, including firmware.

 However don't let that talk confuse you. Getting this all to work in a standard manner won't be much more complex than using a regular stepped attenuator. It will be just the matter of stuffing the LCDuino-1 and δ1 boards (the arduino chip will be available pre-programmed) and connecting power, ground and some other wires._

 

sweet! I have a pretty good AMB labs collection going and this is real tip of the spear stuff...I'm gonna buy one and give it a shot.


----------



## Billyk

Yeah, that's the beauty part about this project! Plug and play if you want or you can play with programming...add different bits, whatever! The sky's the limit.


----------



## jtostenr

I'm sure this was mentioned somewhere before, but I can't seem to find it. What is the depth of the LCDuino? How much space behind the front panel does it require?

 Jeff


----------



## srserl

Quote:


  Originally Posted by *jtostenr* /img/forum/go_quote.gif 
_I'm sure this was mentioned somewhere before, but I can't seem to find it. What is the depth of the LCDuino? How much space behind the front panel does it require?
 Jeff_

 

With the connectors I have used for attaching the momentary switch, and the connector for the programming cable, mine is about 1.25 inches from the front of the pcb to where the wires come out of the connectors on the back. The lcd sticks out about 5/16ths inch from the pcb. 
 How you choose to mount it, and how much space you need behind it will depend on the thickness of your front panel, and how you shim or hollow out the front panel to have the front of the lcd where you want it.


----------



## amb

Hot on the heels of the δ1 attenuator, here is the second application module for the LCDuino-1 "system": the δ2 (delta2), a relay-based input/output selector board.

 δ2 supports two channels per board, and up to eight ports per channel. Each port can be configured to be either an input port or output port by setting two jumpers. Also, not every port need to be populated. Thus, you can have an arbitrary number of input or output ports, as long as the total number of ports per channel does not exceed eight. This makes the δ2 very flexible, and could be used in a variety of pre-amplifier or headphone amplifier applications.

 Similar to the δ1 attenuator, the δ2 board contains a "driver" section and a "selector" section which may optionally be snapped apart and mounted separately. In fact, the "driver" section of the δ1 and δ2 boards is identical.

 The δ2 board is also the same size as the δ1, with the same mounting hole and interface/stacking connector locations, so they could all be stacked together and share the I2C bus, power supply and ground connections.

 Here is a 3D rendering of the PCB:







 The PCB layout (for a larger version click here):






 The schematic diagram is spread over four pages. The first two pages shows the Driver and Selector sections, respectively. The third page shows an I/O port and its configuration jumpers for unbalanced and balanced applications. The fourth page is a functional block diagram showing how the δ2 might be used in a pre-amp or headphone amp.


















*Driver section*

 δ2's driver section is identical to δ1's driver section, you can read about it in this post.

*Selector section*

 As mentioned above, there are up to eight ports per channel (Molex connectors IO0L-IO7L and IO0R-IO7R, which go to rear panel of front panel jacks). Each set of (left/right) ports can be configured as input or output by setting the JPS_n_ and JPG_n_ jumpers. Then, during "initial setup" of the LCDuino-1, you "tell" the firmware about the configuration.

 You can configure the board to be an input selector ony (i.e., all eight ports are for input), output selector only (i.e., all eight ports are for output), or a mix of inputs and outputs. You can also populate less than 8 relays, their associated Molex jacks and parts if you don't need a total of eight ports.

 The ports configured as "input" goes to their associated relays, the firmware implements a 1-of-N switching scheme (i.e., only one left/right input pair is enabled at a time). The selected input is then connected to the "input bus" (available at the Molex connectors labeled "IBUS"). In a typical preamp/headphone amp, the signal here is then "Sent" to the volume control and the active line stage/buffer or headphone amp (see page 4 of schematic above).

 The ports configured as "output" also goes to their associated relays. But the firmware implements a M-of-N switching scheme for these ports (i.e., anywhere between _none_ to _all_ of the left/right output pairs may be enabled simultaneously). The outputs are fed from an "output bus" (via Molex connector "OBUS"). The signal here is usually "Received" from the output of the active line stage/buffer or headphone amp described above (again, see schematic page 4).

 Since there is the capability to disconnect all outputs, the LCDuino-1 firmware can implement power-up delay muting (and instantaneous power-off muting) without the need for any additional hardware.

 Another example δ2 application (not shown in the diagram) is a simple N-to-1-to-M signal router, where no volume control or line stage is used. The "input bus" is connected to the "output bus" (Send -> Recv), so you may choose an input to be connected to one or more outputs.

 For any input port, the RT_n_ resistor provides a load to the source when the port is not enabled. Usually a high-value resistor (10K-100K ohms) is used here to keep the source's output coupling capacitor discharged to minimize any switching "thump".

 For any output port, the RT_n_ resistor provides a low-resistance shunt to ground (as seen by the next stage, such as the input of a power amplifier). A low-value resistor (0-1K ohms) is usually appropriate here to prevent the next stage input from floating, which would act as an antenna to pick up noise. This resistor may be omitted for any port that will drive a passive load, such as headphones.

 Since RT_n_ are only "in the circuit" for disabled inputs or outputs, there is no need to use fancy resistor types for these. Due to the crowded board, there is only room for 5mm lead-spacing resistors (such as Vishay-Dale RN50, or the miniature Panasonic or Xicon 1/8W metal film resistors).

 The ROUT resistors are on the output bus, and serve as optional shunt resistors for the active line stage/buffer or headphone amp output (if used). This provides a load to the line stage or headphone amp so its output will not float even when no output port is enabled. For a line stage or headphone amp with output coupling capacitor, this helps to prevent a "thump" when the output ports are switched. Depending on the design of the line stage or headphone amp, the appropriate value of this resistor can be anywhere from less than 100 ohms to tens of Kohms).

 ROUT can support resistor lead spacing from 5mm-12.5mm with several intermediate sizes.

 The relays are latching type, which means that the driver circuit only needs to send the coil a pulse to set the state, and then no more coil current is needed to maintain that state. To change states, a reverse polarity pulse is applied. This means that the relays will draw no current when not changing state, and will maintain their states even when power is turned off.

 Note that these relays are the same type as those on the δ1, which makes them good for low-signal applications (e.g., preamp, headphone amp), but not adequate for medium or high-power speaker-level switching.

*Regarding the Input/Output Configuration Jumpers*

 As noted above, each port has two 3P jumpers for input/output configuration. As shown on page 2 and 3 of the schematic diagram above, one of these (JPS_n_) is for the signal line, and routes the selected port to either the input or output bus. This jumper is what sets a port to be "input" (jumper set to 1-2) or "output" (jumper set to 2-3).

 The other jumper (JPG_n_) sets the port's ground reference to either the input ground (IG) or the output ground (OG).

 In the schematic diagram page 4 example above, it is assumed that the active line stage or headphone amp is a conventional passive-ground based design. By setting the input ports to be referenced to IG and the output ports to be referenced to OG, the two grounds connect to each other through the volume control and line stage/headphone amp, and that would work just fine.

 However, when the line stage or headphone amp has an actively-driven output "ground", then care must be taken regarding which ground reference to use for each output port. For example, if a 3-channel active-ground β22 or M³ is being used as the basis for the line stage/headphone amp, the preamp-outs should be referenced to IG while the headphone-outs should be referenced to OG. See "β22 as a pre-amplifier" or "M³ as a pre-amplifier" in the "Other options" sections of their respective websites. To do so on the δ2, the JPG_n_ jumpers for the preamp-out ports should be jumpered 1-2 (referenced to IG) while the headphone-out ports should be jumpered 2-3 (referenced to OG).


----------



## jtostenr

Cool 
	

	
	
		
		

		
		
	


	




 Another very nice product from the AMB/Linuxworks team. However, I was disappointed to see the last sentence...

 What would be the best way to adapt/incorpate speaker output switching if I was using this module?


----------



## sachu

Ti, are you looking for anymore folk to prototype this? I would surely be interested.


----------



## amb

Quote:


  Originally Posted by *jtostenr* /img/forum/go_quote.gif 
_Cool 
	

	
	
		
		

		
		
	


	




 Another very nice product from the AMB/Linuxworks team. However, I was disappointed to see the last sentence...

 What would be the best way to adapt/incorpate speaker output switching if I was using this module?_

 

Rather than using the onboard relays to switch speaker-level signals directly, you can use them to activate the coils of high-current offboard relays to do that.

  Quote:


  Originally Posted by *sachu* 
_Ti, are you looking for anymore folk to prototype this? I would surely be interested._

 

At the moment, no. But I will announce any changes if/when it happens.


----------



## jtostenr

Ahh, I see. Seems easy enough to do. Can't wait until you guys start selling all this LCDuino stuff


----------



## amb

Added some more text to Post #364 above.


----------



## jtostenr

If you were to stack 4 of these (2 Delta-1s & 2 Delta-2s) what would be the height? Would there be any reason you would not recommend stacking 4 of these? (Assuming you do all the inital config and tweaking before they are stacked.)


----------



## Ob3ron

Hey amb/linuxworks, will it be possible to make a CD player based on the LCDuino and modules? What's involved?


----------



## linuxworks

a first build: production board # 0001 
	

	
	
		
		

		
		
	


	









 8-bit build (256 steps) in half-dB increments, going from -127.5dB to 0dB.

 took a good 4 hours to solder all that. maybe more than 4 hours.


----------



## amb

Quote:


  Originally Posted by *jtostenr* /img/forum/go_quote.gif 
_If you were to stack 4 of these (2 Delta-1s & 2 Delta-2s) what would be the height? Would there be any reason you would not recommend stacking 4 of these? (Assuming you do all the inital config and tweaking before they are stacked.)_

 

You'll need about 12-14mm spacing between each board for the pin/socket connections and to provide enough clearance for the parts. You can stack 4 boards just fine.


----------



## amb

Quote:


  Originally Posted by *Ob3ron* /img/forum/go_quote.gif 
_Hey amb/linuxworks, will it be possible to make a CD player based on the LCDuino and modules? What's involved?_

 

You'd need to spin your own firmware and application module.


----------



## linuxworks

Quote:


  Originally Posted by *Ob3ron* /img/forum/go_quote.gif 
_Hey amb/linuxworks, will it be possible to make a CD player based on the LCDuino and modules? What's involved?_

 

do you really mean cd player or networked music player?

 I have a very pre-alpha bit of code that does a network (web based) audio controller but its far from production quality. it just remotely talks to a linux MPD task and that, in turn, talks to a usb audio card ON that webserver that finally outputs audio.

 that's the only work I've done on anything like this. and its not really an initial part of the project, it was just 'advanced r/d' stuff that I was toying with to get a feel of the ethernet card on the arduino platform.

 audio *playback* control, while possible, isn't an initial focus of this project. at least initially.


----------



## jtostenr

Quote:


  Originally Posted by *amb* /img/forum/go_quote.gif 
_You'll need about 12-14mm spacing between each board for the pin/socket connections and to provide enough clearance for the parts. You can stack 4 boards just fine._

 

Great. I was hoping I could stack 4 of these in my 3" tall enclosure in order to save space.


----------



## steven2992

Quote:


  Originally Posted by *Ob3ron* /img/forum/go_quote.gif 
_Hey amb/linuxworks, will it be possible to make a CD player based on the LCDuino and modules? What's involved?_

 

If you use a philips cd-pro2 or whatever is the most recent version you get s/pdif out and you only have to make a controller consisting of an interface board between the arduino and the cd-pro and some code to make it work. or maybe even just code if you use a dedicated LCDuino. you might be able to wire the arduino directly to the cd-pro

 edit: CD-PRO2LF is the most recent version

Philips CDM12 / CD-Pro / CD-Pro2 / CD-ProM / CD-Pro2LF - Marantzphilips.nl


----------



## vilts

CD player is so last year 
	

	
	
		
		

		
			





 What I would like to see is music player with VS1053 playing FLAC files from SD card.


----------



## Pageygeeza

Found this, it may only play MP3, but I still think it's pretty awesome!


----------



## linuxworks

I stopped using cd/dvd players many years ago. all my stuff is now computer-selected and in various formats (many of which a typical cd player will not understand).

 add the fact that networked players allow faster shuffling between tracks and disks and that, once you've done a RIP, you are no longer doing a realtime 'extraction' as you play; so the file is already pre-read and already setup for you.

 I would not be at all motivated to work on a cdplayer interface or code base; but I would be more interested in networked player interfaces (probably web-based since its more interoperable).


----------



## linuxworks

Quote:


  Originally Posted by *Pageygeeza* /img/forum/go_quote.gif 
_Found this, it may only play MP3, but I still think it's pretty awesome!_

 

I used to be very much into mp3 (and even bought a semi-expensive commercial encoder) but these days, I can hear the diff between mp3 and flac pretty easily. I think my 'mp3 by choice' days are mostly over and its going to be flac-based, for me, for now on.

 what might be interesting is to take a 'plastic firewall/router' kind of box (like the asus wifi router) and run a small linux distro on it, use its usb port as an spdif output and consider that system to be your fanless diskless networked audio player. it would have a web front end and the arduino would send web GET requests to it over normal tcp/ip for status display and play/pause/skip kinds of control features.

 look very early in this thread and you'll see some pics of a proto that did this very thing. you'd need an 'ethernet shield' and some wiring to connect it to the lcduino (or use an old style proper arduino 'italy' board, that directly takes 'shield' form factor boards) and that would be a start on the web-client embedded arduino system.

 the last time I tried ethernet, though, there were some stability bugs in the arudino libraries. its been months since I've looked but I did want things to stabilize (in their libraries) before really taking another look at this direction.


----------



## Juaquin

While we're on the subject, any recommendations for a good network player to incorporate into an amp (reading flac files off a network drive)? It would be even better if you could somehow hook it up to an Arduino / LCDuino to do control.


----------



## linuxworks

have you tried the mpd system, yet? 'music playback daemon' which runs on most unix systems (I don't know if it runs on windows or not). 

 its a distributed architecture and you can place functions almost where you like. its very flexible and can have a simple (or complex) web interface. I used a simple-simple (lol) web interface and did have the arduino do http GETs to control pause/play/next/prev stuff, as well as time time duration/remain and song name. but that's where I stopped and went back to the volume control stuff 
	

	
	
		
		

		
		
	


	




 give mpd a look. I used the ncurses (text terminal) version for a client interface. its what I used to create playlists, pause things, play/skip, etc. when I wanted to just do quick stuff, you'd telnet/ssh to the mpd box, run 'ncmpc', then quit and logout. it was very lightweight and just used VT100 style 'light graphics'. pretty much all the functionality you'd need, too.

 the server, 'mpd' itself, is the thing that talks to the sound card and that sound card (spdif out) is what you'd send to your dac/amp. the audio does come from the same system the 'mpd' daemon runs on, yet the control can be done locally or remotely via the web/http.

 the arduino part, the way I tried it, was to have the ethernet shield run the tcp/ip/sockets stack and the arduino would just issue web GETs and pend on their responses, parse them and display a formated version to the local lcd display. also accept IR commands and use those (FF, REW, PAUSE) to send the corresponding GET requests. something like that.


----------



## Juaquin

I do have an Arduino ethernet shield, but my server is running 2008. Control would be nice, but I'm mostly interested in a network player that will play files off any drive on the network, like a Sonos but not as expensive and more DIY to integrate into my amp.


----------



## linuxworks

Quote:


  Originally Posted by *Juaquin* /img/forum/go_quote.gif 
_I do have an Arduino ethernet shield, but my server is running 2008. Control would be nice, but I'm mostly interested in a network player that will play files off any drive on the network, like a Sonos but not as expensive and more DIY to integrate into my amp._

 

this could be done. if your files are network accessible (your mp3, flac, etc) then mpd is running on a unix box and it can mount pretty much any nfs/smb filesystem you're likely to find. once it mounts that remote drive, it access the files same as if they were local.

 you could also connect your drives directly to the mpd unix box and mount them locally. no need to go over the network if its an external drive (usb, fw, sata, whatever).

 all the heavy lifting still needs to be on the pc side. the arduino is really only a controller. it will NOT route audio thru it, if that was your intention.


----------



## Juaquin

I was hoping for a hardware device that would replace the PC that could be integrated directly into the amp (like a Sonos), because I don't have a PC close to where the amp would go. So it would connect to a network drive over ethernet, stream the flac file, and then locally (inside the amp) convert to analog and play it. A network DAC, I guess. I didn't expect the Arduino to do it, but I was hoping there was some other simple network player solution.


----------



## amb

Quote:


  Originally Posted by *Juaquin* /img/forum/go_quote.gif 
_I was hoping for a hardware device that would replace the PC that could be integrated directly into the amp (like a Sonos), because I don't have a PC close to where the amp would go. So it would connect to a network drive over ethernet, stream the flac file, and then locally (inside the amp) convert to analog and play it. A network DAC, I guess. I didn't expect the Arduino to do it, but I was hoping there was some other simple network player solution._

 

It's called the Squeezebox.


----------



## Juaquin

Quote:


  Originally Posted by *amb* /img/forum/go_quote.gif 
_It's called the Squeezebox. 
	

	
	
		
		

		
		
	


	


_

 

Yeah I've been looking into them. Hopefully I can find a way to integrate it into the amp nicely. I don't want to derail the thread with this segue - thanks for the ideas!


----------



## amb

Just wanted to let everyone know that all future announcements and updates for the LCDuino-1 and related app modules (δ1 relay-based attenuator, δ2 relay-based input/output selector, and others) have moved to the new AMB DIY audio forum. We have an entire forum category dedicated to the LCDuino system, with separate sub-forums for each module. LinuxWorks and I will focus our support of these projects there.


----------



## Zorlac

I would like to see someone integrate this into a DAC and have the display show S/PDIF info like bit rate, sample rate, bit depth, number of channels, etc.


----------



## amb

I plan to do that with my future desktop DAC.


----------



## linuxworks

Quote: 





zorlac said:


> I would like to see someone integrate this into a DAC and have the display show S/PDIF info like bit rate, sample rate, bit depth, number of channels, etc.


 

 this isn't typical dac info, though.  I've looked into this and you either have to talk to the dac chip at a very low level (most don't even give you this info via its 'mgmt interface') OR you have to spy on the bits, directly, and glean it from the spdif stream (a circuit I used to build about 15 yrs ago had a hardware GAL chip that would pick out the subcode bits and show things that dacs, today, still don't show).
   
  samplerate is not too hard and its even possible to hack it based on a freq-to-voltage conversion (roughly).  bit depth is often just 'said' to be 24 from the dac even if the native stream is not 24.  channels is not directly viewable via dacs (especially multichannel things like dd5.1 and dts).  dacs tend to say its PCM or perhaps DD or DTS but it won't go deeper than that (2ch stereo dacs, that is).  multichannel home theater dacs tend not to be diy friendly (at all).
   
  one idea is to have a pc side 'beside' the dac and listen in on the stream and then have IT break out the spdif protocol.  not a very clean solution though.
   
  I do want to have at least a samplerate display so I can see when 44.1 comes out vs 48.  that much I plan to do via the frequency measure hack.  the rest is not so easily do-able with standard dac chips.


----------



## dgbiker1

Very cool! I used an Arduino w/ LCD a couple years ago when I built my Opus DAC for switching inputs/outputs and controlling the lighting. Used a blackberry trackball for navigation.


----------



## TheShaman

[Removed - cross-posted accidentaly]


----------



## particleman14

Hey guys check this out...
   
  The alpha-10 is getting close to completion.  it has been a long time coming.. These are going to be available soon...


----------



## ujamerstand

I like how there is just one random tube lying around with all the digital electronics.


----------



## chryses

Has anyone used one of the 2x16 Newhaven OLED character displays (e.g., Mouser Part No: 763-NHD-0216KZW-AY5)?  Anyone know if these are "plug-and-play" compatible with the LCDuino?


----------



## ShinyFalcon

Looks good. The OLED displays has some unused pins (contrast, backlight), and uses about 10mA more current. I might try one out...


----------



## linuxworks

there does not seem to be any contrast adjustment (that won't hurt and actually its a good thing you don't need it anymore). there is not any pin 15,16 which is used for backlight (brightness) control. but unlike the vfd compatible displays, there does not seem to be a message-type you can send the display to vary its brightness.
   
  vfd's have 4 levels of brightness and you vary them via a message you send to the vfd. lcd's vary their brightness via analog voltage on the 15,16 pins. but the oled module *seems* like it has a fixed brightness. and even worse, the spec sheet talks about burn-in and so you have to be careful you don't leave the pattern on the screen!
   
  the current shipping lcduino code is 'vfd-friendly' in that if you select auto-off display mode, it will completely darken the display after inactivity; not just turn the backlight off but literally erasing the screen after the delay. if you used this mode, you could avoid the burn-in problem. I might order one of these to try it, but not real happy about the price premium they charge.
   
  also, there are r/g/b lcd displays that use rgb leds with 4 wires as the backlight. with those, you can choose your exact color. I've played with those and it can be fun to pick your exact foreground color that way. the lcduino only has support for 1 pwm line (stock) but you could tap into 2 more on the board and write custom firmware to vary the r/g/b values on their own and color-mix your own display. even change colors based on some state or mode that the device is in.


----------



## chryses

Yeah, I'm not terribly excited about the price either.  But the display does look extremely crisp, so I probably will give it try.  Have to build my LCDuino first, but will report back.


----------



## ShinyFalcon

If the OLED is similar to the ones used in the Sansa clip, the background will be pitch black. All you'll see in the dark is the colored text, hopefully no light bleeding. Should be a joy to use, but the firmware will need to be updated to include code to blank out the screen.


----------



## linuxworks

Quote: 





chryses said:


> Yeah, I'm not terribly excited about the price either.  But the display does look extremely crisp, so I probably will give it try.  Have to build my LCDuino first, but will report back.


 

 make sure it has the same hole pattern size (75mm or something like that) and that the 14 or so pins at the top are the same spacing as normal 16x2 lcd's.  there is at least 1 model that looks like a perfect drop-in.
   
  I will probably try one to see what its all about.  I have some VFD's that work pretty well (high current though; need a separate 5v for them) and of course most lcd's work just fine.


----------



## linuxworks

Quote: 





shinyfalcon said:


> If the OLED is similar to the ones used in the Sansa clip, the background will be pitch black. All you'll see in the dark is the colored text, hopefully no light bleeding. Should be a joy to use, but the firmware will need to be updated to include code to blank out the screen.


 


  no, that code is there fine in the shipping v1.0 lcduinos.  there are 3 modes of backlight: full-on, auto-fade from hi to low; auto-shutoff.
   
  in auto-shutoff, it turns the backlight off (which does nothing to this oled) but it also DOES erase every char on the display (writes space chars out to whole display).  when a user event happens and if its in this black-out mode, it repaints the whole screen and resets the timer for screen blanking.  it all works fine.  it was added to support VFD's and so the same thing is here for OLEDs, too.  think of it as an anti-screen burn setting.
   
  note that if you picked that middle mode (auto-fade) it won't appear to do anything on vfd's or oled's.  you'll get full brightness no matter what.


----------

