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