Yet another Volume controlers and source selections

Thanks for the help
In schematic is shown that pin1 of encoder is connected at Interrupt pin, while pin3 in Port D.0. In encoders, switch A change state before switch B (close its contact before switch B in CW direction) so usually used as the interrupt source, while switch B is checked to determine the direction of encoder turn. So, your encoder should be connected in the right way on pcb, pin1 left (SwA), pin2 (Com) center, pin3 (SwB) right. No pin inversion.
Have you tried to turn slowly the encoder? Is working in this way?
Fotis
 
Boban, encoders without detents by 99% can run any of the A and B switch waveform pattern. If the encoder works correctly in slow speed - be it so for a while - that means its connection to the microcontroller ports should also be correct. Then i can think only one thing: inaccurate code of interrupt handler. Are you sure that this project is working? Who has confirmed you for this? :Pinoc: ?
In my career, i have seen hundreds supposedly super-duper projects based on incomplete program code.
 
Last edited:
I know few things about Atmel micros, i am in the PIC side but i know that both companies offer similar abilities. Just now i looked on datasheet of Atmega16 due to the debounce (anti-chattering) circuitry around encoder that i can see on the schematic. I don't use this R-C circuit around encoder, is a waste of parts, pcb space etc. Instead this, i have always enabled the internal weak pull-ups of PIC micro Port B. So, the common pin of encoder is tied at 0V node, while A and B terminals are connected directly to PortB inputs. The chattering of encoder is eliminated by the internal Schmitt-Trigger of PIC. I have tried this connection lot of times without problem. To my big surprise, in Atmega16 datasheet i saw that all of its Ports have internal pull-ups!!! Which can be enabled individually! Therefore, C9-C10-C11 and R28 - R29 (forming an anti-chattering filter around encoder) are useless.
Hmmm... This Atmel is really generous compared to Microchip. I think is time to try some Atmega micros. :)
 
Last edited:

Wait till I reach home and I will provide you with a .bin or .hex for you to test again (it is another variant of firmware than posted on thread) .
Did you write the fusebits necessary ?
The project have been / is in use in more than 250 pieces and is working perfectly , so you made something wrong .
Please check schematics and interconnection as this is a simple project .
I will come again later and i will support you how I can.
Fotios : for sure the project is working !
 
Last edited:
Hi Dunzup, thanks for help. I will check connections later.

Yes, i write the fusebits:

CKSEL 0 = selected
CKSEL 1 = selected
CKSEL 2 = not selected
CKSEL 3 = selected
- Jtag disable
- Internal 8Mhz RC oscillator

- Jtag disable
- Internal 8Mhz RC oscillator (Cksel = 0100 , Sut = 10)
is ok .
I have read your pm and i have seen the video , i will try to think what is wrong there .
I will be back .
-----------------------
Back : it seems you have some type of short circuit between some lines of uC on port where encoder is connected !!!
Pls check ( 3 years ago one user from romanian forum where i have posted first time this firmware
had the same problems and we discover connection in short circuit ) or maybe try programming again as one year ago an user from Germany have some problems that gone after second programming and never reappear .
Either way I will post a new variant for this firmware when I will reach my home (last revision).
 
Last edited:
OK, 'll check when i got home.

I use a AVR-ISP program that has two places to check:

SUT0 Programmed
SUT1 Programmed

SUT0 is deafult. Should i have to check SUT1?

ps: Is it possible to post firmware revision for ATmega32 also? I have few ATmega32 and i would like to verify that they work. Thanks.
 
Last edited:
OK, 'll check when i got home.

I use a AVR-ISP program that has two places to check:

SUT0 Programmed
SUT1 Programmed

SUT0 is deafult. Should i have to check SUT1?

SUT is the start-up time after applied power ie +5V to uC .
It is not important if the uC starts in 0ms , 4ms or 64ms from power up as I always use (64ms ) .
But hey you can do use the 64ms time for uC start up time .
 
Last edited:
Thx Dunzup. Right now i have try firmware that u posted, but i have the same problems :(
OK, the problem is either the encoder or to me :). Tomorrow I'll get two more encoders for the test.
I have to check the control PCB. Can you post valid scheme for this project, a reference to check my PCB? Is this the right sch: http://vicol-audio.ro/img/volume-controller/VC_R2R&Shunt_2010.pdf
Thanks in advance.
 
Hi Boban
As i told you, your BOURNS encoder without detents, it has no problem to run any A - B switch waveform pattern. Also, its pins seems to be in correct sequence. At the time that common pin is at the middle place and by looking on your PCB, by sure is connected at 0V (Gnd). If pins A and B were inversely connected at PCB, the only problem would be decrement of numbers during CW rotation and increment during CCW rotation. Nothing more. I also believe that danzup code is correct and i suppose that your programmer works fine. In your PCB plan, i can't see any short circuit and that is designed exactly as shown in schematic. Try to remove the debounce filter around encoder: C9-C10-C11 -R27-R28.
Then check again if encoder works this time.
 
Last edited:
Thx Dunzup. Right now i have try firmware that u posted, but i have the same problems :(
OK, the problem is either the encoder or to me :). Tomorrow I'll get two more encoders for the test.
I have to check the control PCB. Can you post valid scheme for this project, a reference to check my PCB? Is this the right sch: http://vicol-audio.ro/img/volume-controller/VC_R2R&Shunt_2010.pdf
Thanks in advance.

Yes that schematic is the good one.
I will write now for you a test firmware that print on LCD the name of switch pressed and direction of encoder when rotate cw or ccw and if sees multiple pressing on the same time will tell on LCD .
I will post this later .
OK ?
 
Thanks to all, We solve the problem :)
I remove debounce filter from control PCB close to encoder and it work! Right now i will try it with ATmega32...

edit: oh my... i think that with ATmega32 working faster :D

Bravo Boban. That is nice to you. Just one thing: keep R27 - R28 (i am looking on your PCB) in their place, because the inputs of Atmega are triggered during HI to LO transitions of encoder. Unless danzup has already enabled the internal pull-ups of Atmega. Then the 2 resistors are useless.
Fotis
 
Last edited:
Bravo Boban. That is nice to you. Just one thing: keep R27 - R28 (i am looking on your PCB) in their place, because the inputs of Atmega are triggered during HI to LO transitions of encoder. Unless danzup has already enabled the internal pull-ups of Atmega. Then the 2 resistors are useless.
Fotis
In firmware that pull ups resistor are enabled but there are so many type of encoder and when I try there are some cheap Chinese encoders that require more current on ,so that is the mystery about that .
So that work even with resistors removed , but not recommended for some type of encoder .
Of course that debounce filter work ok only with cheap encoder , that filter must/can be removed for good and expensive encoders. As majority of users use cheap and buggy encoders at the time I was testing a lot of encoders ,that debounce filter was helping a lot .
Also 2 years ago in romanian forum there was a user who do this project and for his encoder he must use 0.47uF capacitors instead 0.1uF , as he experienced a lot of in-controlled bounce with his encoder....
I am glad you make it !!!!
Congrats .
There is no difference between Atmega16 and Atmega32 in speed only more memory available , for adding more feature if you want and you know to write firmware for Atmel uC.
Also you cannot modify the speed of uC as a lot of routines rely on timing specifically tailored for 8Mhz (including subroutine that decode RC5 Remote code)!
(As the firmware works at high speed there are a lot of waiting out for user to do things ...... )
 
Last edited: