The LCDuino-1 I/O processor

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