[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.