|
lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
|
I am interested to know where you placed the capacitors. Can you show a drawing perhaps?
Scotty
On Sun, Feb 25, 2024, 3:18 PM barry halterman < kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
|
Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ?
toggle quoted message
Show quoted text
From: Scotty RSent: Sunday, February 25, 2024 6:45 PM To: [email protected]Subject: Re: [BITX20] sbitx encoder contact bounce ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
|
The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time.
On Mon, Feb 26, 2024, 6:14 AM barry halterman < kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
|
TU Ashhar, but it was easier and quicker for me to do it via hardware. 73 Barry ? Sent from for Windows ?
toggle quoted message
Show quoted text
From: Ashhar FarhanSent: Monday, February 26, 2024 7:23 AM To: [email protected]Subject: Re: [BITX20] sbitx encoder contact bounce ? The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time. ? On Mon, Feb 26, 2024, 6:14 AM barry halterman <kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
|
The whole idea was to get you to fire up the soldering iron. - f
On Mon, Feb 26, 2024, 6:05 PM barry halterman < kthreebo@...> wrote: TU Ashhar, but it was easier and quicker for me to do it via hardware. 73 Barry ? Sent from for Windows ? ? The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time. ? On Mon, Feb 26, 2024, 6:14 AM barry halterman <kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
|
I would rather do it with a soldering iron then fumble ?through the code. Soldering Irons I can handle, code not so much. ? 73 Barry ? Sent from for Windows ?
toggle quoted message
Show quoted text
From: Ashhar FarhanSent: Monday, February 26, 2024 7:37 AM To: [email protected]Subject: Re: [BITX20] sbitx encoder contact bounce ? The whole idea was to get you to fire up the soldering iron. ? On Mon, Feb 26, 2024, 6:05 PM barry halterman <kthreebo@...> wrote: TU Ashhar, but it was easier and quicker for me to do it via hardware. 73 Barry ? Sent from for Windows ? ? The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time. ? On Mon, Feb 26, 2024, 6:14 AM barry halterman <kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
|
What did you name that file? I would like to look at it.
Scotty
|
Hi Scotty,
I believe that the encoder input is in sbitx_gtk.c line 3439:
int enc_read(struct encoder *e) {
73
Evan
AC9TU
|
|
|
My experience is that debouncing in software can vary from encoder to encoder. I would suggest creating symbolic constants for each encoder (e.g., tune, volume, etc). Usually, the delay is between 40 and 100 milliseconds:
#define TUNE_ENCODER_DELAY??????????? ???? 50??????? // debounce delay in ms #define VOLUME_ENCODER_DELAY??????????? 40
and then look where to place them in the code. Many programmers use the standard delay() function call:
delay(TUNE_ENCODER_DELAY); ?????????? ????
However, the delay() function is a "blocking" function, which means that it turns off interrupts for the delay period. Given that debounce functions have relatively short delays, this probably isn't a problem in this code body. However, perhaps some functions [e.g., MyHairsOnFire()] shouldn't be blocked. In that case, I would suggest:
/ ? Purpose: to cause a delay in program execution ? Parameter list: ? ? unsigned long millisWait ? ?// the number of millseconds to wait ? Return value: ? ? void / void MyDelay(unsigned long millisWait) { ? unsigned long now = millis(); ? while (millis() - now < millisWait) ? ? ; ?????????????????????????????????// Twiddle thumbs until delay ends... } The millis() standard Arduino function is non-blocking, otherwise it acts the same as delay(). I try to use the style shown above. I use a starting capital letter for the function name and Polish notation because most standard and function library names in the Arduino IDE start with a lowercase letter. That way, I know in advance whether I wrote the code or it comes from a library I didn't write.?
Also, the details about the function always falls in the function header between the "/" and the "/" followed immediately by the function signature (e.g., void MyDelay(unsigned long millisWait) and a newline character). By rigidly following the function format, I wrote a program that looked for the "/" lead-in and then used the __FILE__ and __DATE__ standard macros to create a user document that detailed all of the function calls we wrote for the project. When I had my own software company, I gently convinced all of my programmers to follow this format. Anyone who used a different format had to buy beer and pizza for the programmers the following Friday. I don't remember anyone buying lunch more than once, which kept the project documentation for the code up-to-date.
Sorry for the long answer, but conventions can make projects with multiple coders easier to use.
Jack, W8TEE
On Monday, February 26, 2024 at 07:23:58 AM EST, Ashhar Farhan <farhanbox@...> wrote:
The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time.
On Mon, Feb 26, 2024, 6:14 AM barry halterman < kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
--
Jack, W8TEE
|
Jack, In the sbitx, the encoders fire interrupts and measure the time through millis(), it is a wrapper around utime() - f
My experience is that debouncing in software can vary from encoder to encoder. I would suggest creating symbolic constants for each encoder (e.g., tune, volume, etc). Usually, the delay is between 40 and 100 milliseconds:
#define TUNE_ENCODER_DELAY??????????? ???? 50??????? // debounce delay in ms #define VOLUME_ENCODER_DELAY??????????? 40
and then look where to place them in the code. Many programmers use the standard delay() function call:
delay(TUNE_ENCODER_DELAY); ?????????? ????
However, the delay() function is a "blocking" function, which means that it turns off interrupts for the delay period. Given that debounce functions have relatively short delays, this probably isn't a problem in this code body. However, perhaps some functions [e.g., MyHairsOnFire()] shouldn't be blocked. In that case, I would suggest:
/ ? Purpose: to cause a delay in program execution ? Parameter list: ? ? unsigned long millisWait ? ?// the number of millseconds to wait ? Return value: ? ? void / void MyDelay(unsigned long millisWait) { ? unsigned long now = millis(); ? while (millis() - now < millisWait) ? ? ; ?????????????????????????????????// Twiddle thumbs until delay ends... } The millis() standard Arduino function is non-blocking, otherwise it acts the same as delay(). I try to use the style shown above. I use a starting capital letter for the function name and Polish notation because most standard and function library names in the Arduino IDE start with a lowercase letter. That way, I know in advance whether I wrote the code or it comes from a library I didn't write.?
Also, the details about the function always falls in the function header between the "/" and the "/" followed immediately by the function signature (e.g., void MyDelay(unsigned long millisWait) and a newline character). By rigidly following the function format, I wrote a program that looked for the "/" lead-in and then used the __FILE__ and __DATE__ standard macros to create a user document that detailed all of the function calls we wrote for the project. When I had my own software company, I gently convinced all of my programmers to follow this format. Anyone who used a different format had to buy beer and pizza for the programmers the following Friday. I don't remember anyone buying lunch more than once, which kept the project documentation for the code up-to-date.
Sorry for the long answer, but conventions can make projects with multiple coders easier to use.
Jack, W8TEE
On Monday, February 26, 2024 at 07:23:58 AM EST, Ashhar Farhan < farhanbox@...> wrote:
The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time. On Mon, Feb 26, 2024, 6:14 AM barry halterman < kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
--
Jack, W8TEE
|
Farhan, In reviewing the tuning encoder, I found the function tuning_isr(void):
static int tuning_ticks = 0;
void tuning_isr(void){
int tuning = enc_read(&enc_b);
if (tuning < 0)
tuning_ticks++;
if (tuning > 0)
tuning_ticks--;
}When the interrupt is received, the following is called :
int enc_read(struct encoder *e) {
? int result = 0;?
? int newState;
??
? newState = enc_state(e); // Get current state??
? ??
? if (newState != e->prev_state)
? ? ?delay (1);
??
? if (enc_state(e) != newState || newState == e->prev_state)
? ? return 0;?
?
? //these transitions point to the encoder being rotated anti-clockwise
? if ((e->prev_state == 0 && newState == 2) ||?
? ? (e->prev_state == 2 && newState == 3) ||?
? ? (e->prev_state == 3 && newState == 1) ||?
? ? (e->prev_state == 1 && newState == 0)){
? ? ? e->history--;
? ? ? //result = -1;
? ? }
? //these transitions point to the enccoder being rotated clockwise
? if ((e->prev_state == 0 && newState == 1) ||?
? ? (e->prev_state == 1 && newState == 3) ||?
? ? (e->prev_state == 3 && newState == 2) ||?
? ? (e->prev_state == 2 && newState == 0)){
? ? ? e->history++;
? ? }
? e->prev_state = newState; // Record state for next pulse interpretation
? if (e->history > e->speed){
? ? result = 1;
? ? e->history = 0;
? }
? if (e->history < -e->speed){
? ? result = -1;
? ? e->history = 0;
? }
? return result;
}The only delay function is the?
?if (newState != e->prev_state)
? ? ?delay (1);
That is using delay and not the same as what Jack has suggested.? Still, the delay is active for only one millisecond.? If this would need to be increased, it would be better to use the construct that Jack has suggested.? Other delays in the code do use the millis() function.?
Please let me know if I have missed something so I can understand the code better.
73
Evan
AC9TU
|
Hi Evan:
What is the interpretation of the call to enc_read(&enc_b)? Most encoder ISR's return either 0 or 1. If that's the case, the ISR could be simplified to:
void tuning_isr(void) {
?? int tuning += enc_read(&enc_b); }
However, if the encoders always return 0 or 1, the complex if statement blocks in enc_read() check for values 2 and 3, too. What's the interpretation of those values?
Also, the fragment:
newState = enc_state(e); // Get current state??
? ??
? if (newState != e->prev_state)
? ? ?delay (1);
??
? if (enc_state(e) != newState || newState == e->prev_state)
? ? return 0;?
Can newState ever be different than e->prev_state? If not, is the check even necessary?
Jack, W8TEE
On Monday, February 26, 2024 at 11:30:33 AM EST, Evan Hand <elhandjr@...> wrote:
Farhan, In reviewing the tuning encoder, I found the function tuning_isr(void):
static int tuning_ticks = 0;
void tuning_isr(void){
int tuning = enc_read(&enc_b);
if (tuning < 0)
tuning_ticks++;
if (tuning > 0)
tuning_ticks--;
}When the interrupt is received, the following is called :
int enc_read(struct encoder *e) {
? int result = 0;?
? int newState;
??
? newState = enc_state(e); // Get current state??
? ??
? if (newState != e->prev_state)
? ? ?delay (1);
??
? if (enc_state(e) != newState || newState == e->prev_state)
? ? return 0;?
?
? //these transitions point to the encoder being rotated anti-clockwise
? if ((e->prev_state == 0 && newState == 2) ||?
? ? (e->prev_state == 2 && newState == 3) ||?
? ? (e->prev_state == 3 && newState == 1) ||?
? ? (e->prev_state == 1 && newState == 0)){
? ? ? e->history--;
? ? ? //result = -1;
? ? }
? //these transitions point to the enccoder being rotated clockwise
? if ((e->prev_state == 0 && newState == 1) ||?
? ? (e->prev_state == 1 && newState == 3) ||?
? ? (e->prev_state == 3 && newState == 2) ||?
? ? (e->prev_state == 2 && newState == 0)){
? ? ? e->history++;
? ? }
? e->prev_state = newState; // Record state for next pulse interpretation
? if (e->history > e->speed){
? ? result = 1;
? ? e->history = 0;
? }
? if (e->history < -e->speed){
? ? result = -1;
? ? e->history = 0;
? }
? return result;
}The only delay function is the?
?if (newState != e->prev_state)
? ? ?delay (1);
That is using delay and not the same as what Jack has suggested.? Still, the delay is active for only one millisecond.? If this would need to be increased, it would be better to use the construct that Jack has suggested.? Other delays in the code do use the millis() function.?
Please let me know if I have missed something so I can understand the code better.
73
Evan
AC9TU
-- Jack, W8TEE
|
I understand now.
Jack, W8TEE
On Monday, February 26, 2024 at 10:37:26 AM EST, Ashhar Farhan <farhanbox@...> wrote:
Jack, In the sbitx, the encoders fire interrupts and measure the time through millis(), it is a wrapper around utime() - f
My experience is that debouncing in software can vary from encoder to encoder. I would suggest creating symbolic constants for each encoder (e.g., tune, volume, etc). Usually, the delay is between 40 and 100 milliseconds:
#define TUNE_ENCODER_DELAY??????????? ???? 50??????? // debounce delay in ms #define VOLUME_ENCODER_DELAY??????????? 40
and then look where to place them in the code. Many programmers use the standard delay() function call:
delay(TUNE_ENCODER_DELAY); ?????????? ????
However, the delay() function is a "blocking" function, which means that it turns off interrupts for the delay period. Given that debounce functions have relatively short delays, this probably isn't a problem in this code body. However, perhaps some functions [e.g., MyHairsOnFire()] shouldn't be blocked. In that case, I would suggest:
/ ? Purpose: to cause a delay in program execution ? Parameter list: ? ? unsigned long millisWait ? ?// the number of millseconds to wait ? Return value: ? ? void / void MyDelay(unsigned long millisWait) { ? unsigned long now = millis(); ? while (millis() - now < millisWait) ? ? ; ?????????????????????????????????// Twiddle thumbs until delay ends... } The millis() standard Arduino function is non-blocking, otherwise it acts the same as delay(). I try to use the style shown above. I use a starting capital letter for the function name and Polish notation because most standard and function library names in the Arduino IDE start with a lowercase letter. That way, I know in advance whether I wrote the code or it comes from a library I didn't write.?
Also, the details about the function always falls in the function header between the "/" and the "/" followed immediately by the function signature (e.g., void MyDelay(unsigned long millisWait) and a newline character). By rigidly following the function format, I wrote a program that looked for the "/" lead-in and then used the __FILE__ and __DATE__ standard macros to create a user document that detailed all of the function calls we wrote for the project. When I had my own software company, I gently convinced all of my programmers to follow this format. Anyone who used a different format had to buy beer and pizza for the programmers the following Friday. I don't remember anyone buying lunch more than once, which kept the project documentation for the code up-to-date.
Sorry for the long answer, but conventions can make projects with multiple coders easier to use.
Jack, W8TEE
On Monday, February 26, 2024 at 07:23:58 AM EST, Ashhar Farhan < farhanbox@...> wrote:
The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time. On Mon, Feb 26, 2024, 6:14 AM barry halterman < kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
--
Jack, W8TEE
--
Jack, W8TEE
|
Two 0.1 uf capacitors on the encoder board are WAY much simpler! Barry ? ? Sent from for Windows ?
toggle quoted message
Show quoted text
From: Jack, W8TEE via groups.ioSent: Monday, February 26, 2024 1:44 PM To: [email protected]Subject: Re: [BITX20] sbitx encoder contact bounce ? On Monday, February 26, 2024 at 10:37:26 AM EST, Ashhar Farhan <farhanbox@...> wrote: Jack, In the sbitx, the encoders fire interrupts and measure the time through millis(), it is a wrapper around utime() ? My experience is that debouncing in software can vary from encoder to encoder. I would suggest creating symbolic constants for each encoder (e.g., tune, volume, etc). Usually, the delay is between 40 and 100 milliseconds: #define TUNE_ENCODER_DELAY??????????? ???? 50??????? // debounce delay in ms #define VOLUME_ENCODER_DELAY??????????? 40 and then look where to place them in the code. Many programmers use the standard delay() function call: delay(TUNE_ENCODER_DELAY); ?????????? ???? However, the delay() function is a "blocking" function, which means that it turns off interrupts for the delay period. Given that debounce functions have relatively short delays, this probably isn't a problem in this code body. However, perhaps some functions [e.g., MyHairsOnFire()] shouldn't be blocked. In that case, I would suggest: ? Purpose: to cause a delay in program execution ? ? ? unsigned long millisWait ? ?// the number of millseconds to wait ? void MyDelay(unsigned long millisWait) ? unsigned long now = millis(); ? ? while (millis() - now < millisWait) ? ? ; ?????????????????????????????????// Twiddle thumbs until delay ends... ? The millis() standard Arduino function is non-blocking, otherwise it acts the same as delay(). I try to use the style shown above. I use a starting capital letter for the function name and Polish notation because most standard and function library names in the Arduino IDE start with a lowercase letter. That way, I know in advance whether I wrote the code or it comes from a library I didn't write.? Also, the details about the function always falls in the function header between the "/" and the "/" followed immediately by the function signature (e.g., void MyDelay(unsigned long millisWait) and a newline character). By rigidly following the function format, I wrote a program that looked for the "/" lead-in and then used the __FILE__ and __DATE__ standard macros to create a user document that detailed all of the function calls we wrote for the project. When I had my own software company, I gently convinced all of my programmers to follow this format. Anyone who used a different format had to buy beer and pizza for the programmers the following Friday. I don't remember anyone buying lunch more than once, which kept the project documentation for the code up-to-date. Sorry for the long answer, but conventions can make projects with multiple coders easier to use. On Monday, February 26, 2024 at 07:23:58 AM EST, Ashhar Farhan <farhanbox@...> wrote: The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time. ? On Mon, Feb 26, 2024, 6:14 AM barry halterman <kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
--
Jack, W8TEE
--
Jack, W8TEE
|
Barry, They are simpler fix for you. But if we roll in this interesting change, then, all the hundreds of radios can have better debouncing without touching their soldering irons. We are homebrewing in C as well, now.
On Tue, Feb 27, 2024, 3:04 AM barry halterman < kthreebo@...> wrote: Two 0.1 uf capacitors on the encoder board are WAY much simpler! Barry ? ? Sent from for Windows ? ? On Monday, February 26, 2024 at 10:37:26 AM EST, Ashhar Farhan <farhanbox@...> wrote: Jack, In the sbitx, the encoders fire interrupts and measure the time through millis(), it is a wrapper around utime() ? My experience is that debouncing in software can vary from encoder to encoder. I would suggest creating symbolic constants for each encoder (e.g., tune, volume, etc). Usually, the delay is between 40 and 100 milliseconds: #define TUNE_ENCODER_DELAY??????????? ???? 50??????? // debounce delay in ms #define VOLUME_ENCODER_DELAY??????????? 40 and then look where to place them in the code. Many programmers use the standard delay() function call: delay(TUNE_ENCODER_DELAY); ?????????? ???? However, the delay() function is a "blocking" function, which means that it turns off interrupts for the delay period. Given that debounce functions have relatively short delays, this probably isn't a problem in this code body. However, perhaps some functions [e.g., MyHairsOnFire()] shouldn't be blocked. In that case, I would suggest: ? Purpose: to cause a delay in program execution ? ? ? unsigned long millisWait ? ?// the number of millseconds to wait ? void MyDelay(unsigned long millisWait) ? unsigned long now = millis(); ? ? while (millis() - now < millisWait) ? ? ; ?????????????????????????????????// Twiddle thumbs until delay ends... ? The millis() standard Arduino function is non-blocking, otherwise it acts the same as delay(). I try to use the style shown above. I use a starting capital letter for the function name and Polish notation because most standard and function library names in the Arduino IDE start with a lowercase letter. That way, I know in advance whether I wrote the code or it comes from a library I didn't write.? Also, the details about the function always falls in the function header between the "/" and the "/" followed immediately by the function signature (e.g., void MyDelay(unsigned long millisWait) and a newline character). By rigidly following the function format, I wrote a program that looked for the "/" lead-in and then used the __FILE__ and __DATE__ standard macros to create a user document that detailed all of the function calls we wrote for the project. When I had my own software company, I gently convinced all of my programmers to follow this format. Anyone who used a different format had to buy beer and pizza for the programmers the following Friday. I don't remember anyone buying lunch more than once, which kept the project documentation for the code up-to-date. Sorry for the long answer, but conventions can make projects with multiple coders easier to use. On Monday, February 26, 2024 at 07:23:58 AM EST, Ashhar Farhan <farhanbox@...> wrote: The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time. ? On Mon, Feb 26, 2024, 6:14 AM barry halterman <kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
--
Jack, W8TEE
--
Jack, W8TEE
|
Farhan:
I agree. If the only tool you have is a hammer, every problem looks like a nail. If you can, it's always nice to add a new tool to the belt.
Jack, W8TEE
On Monday, February 26, 2024 at 09:03:05 PM EST, Ashhar Farhan <farhanbox@...> wrote:
Barry, They are simpler fix for you. But if we roll in this interesting change, then, all the hundreds of radios can have better debouncing without touching their soldering irons. We are homebrewing in C as well, now.
On Tue, Feb 27, 2024, 3:04 AM barry halterman < kthreebo@...> wrote: Two 0.1 uf capacitors on the encoder board are WAY much simpler! Barry ? ? Sent from for Windows ? ? On Monday, February 26, 2024 at 10:37:26 AM EST, Ashhar Farhan <farhanbox@...> wrote: Jack, In the sbitx, the encoders fire interrupts and measure the time through millis(), it is a wrapper around utime() ? My experience is that debouncing in software can vary from encoder to encoder. I would suggest creating symbolic constants for each encoder (e.g., tune, volume, etc). Usually, the delay is between 40 and 100 milliseconds: #define TUNE_ENCODER_DELAY??????????? ???? 50??????? // debounce delay in ms #define VOLUME_ENCODER_DELAY??????????? 40 and then look where to place them in the code. Many programmers use the standard delay() function call: delay(TUNE_ENCODER_DELAY); ?????????? ???? However, the delay() function is a "blocking" function, which means that it turns off interrupts for the delay period. Given that debounce functions have relatively short delays, this probably isn't a problem in this code body. However, perhaps some functions [e.g., MyHairsOnFire()] shouldn't be blocked. In that case, I would suggest: ? Purpose: to cause a delay in program execution ? ? ? unsigned long millisWait ? ?// the number of millseconds to wait ? void MyDelay(unsigned long millisWait) ? unsigned long now = millis(); ? ? while (millis() - now < millisWait) ? ? ; ?????????????????????????????????// Twiddle thumbs until delay ends... ? The millis() standard Arduino function is non-blocking, otherwise it acts the same as delay(). I try to use the style shown above. I use a starting capital letter for the function name and Polish notation because most standard and function library names in the Arduino IDE start with a lowercase letter. That way, I know in advance whether I wrote the code or it comes from a library I didn't write.? Also, the details about the function always falls in the function header between the "/" and the "/" followed immediately by the function signature (e.g., void MyDelay(unsigned long millisWait) and a newline character). By rigidly following the function format, I wrote a program that looked for the "/" lead-in and then used the __FILE__ and __DATE__ standard macros to create a user document that detailed all of the function calls we wrote for the project. When I had my own software company, I gently convinced all of my programmers to follow this format. Anyone who used a different format had to buy beer and pizza for the programmers the following Friday. I don't remember anyone buying lunch more than once, which kept the project documentation for the code up-to-date. Sorry for the long answer, but conventions can make projects with multiple coders easier to use. On Monday, February 26, 2024 at 07:23:58 AM EST, Ashhar Farhan <farhanbox@...> wrote: The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time. ? On Mon, Feb 26, 2024, 6:14 AM barry halterman <kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
--
Jack, W8TEE
--
Jack, W8TEE
--
Jack, W8TEE
|
Gentlemen, I will not argue the fact that software might be the proper method, IF you know the syntax of the language and have a good understanding of programming structure and can make it work. ?I for one, have neither and getting a LED to blink is a major task. My hat is off to you folks who can program. Yes, I am envious. 73 Barry K3BO ? Sent from for Windows ?
toggle quoted message
Show quoted text
From: Jack, W8TEE via groups.ioSent: Monday, February 26, 2024 9:46 PM To: [email protected]Subject: Re: [BITX20] sbitx encoder contact bounce ? I agree. If the only tool you have is a hammer, every problem looks like a nail. If you can, it's always nice to add a new tool to the belt. On Monday, February 26, 2024 at 09:03:05 PM EST, Ashhar Farhan <farhanbox@...> wrote: Barry, They are simpler fix for you. But if we roll in this interesting change, then, all the hundreds of radios can have better debouncing without touching their soldering irons. We are homebrewing in C as well, now. ? On Tue, Feb 27, 2024, 3:04 AM barry halterman <kthreebo@...> wrote: Two 0.1 uf capacitors on the encoder board are WAY much simpler! Barry ? ? Sent from for Windows ? ? On Monday, February 26, 2024 at 10:37:26 AM EST, Ashhar Farhan <farhanbox@...> wrote: Jack, In the sbitx, the encoders fire interrupts and measure the time through millis(), it is a wrapper around utime() ? My experience is that debouncing in software can vary from encoder to encoder. I would suggest creating symbolic constants for each encoder (e.g., tune, volume, etc). Usually, the delay is between 40 and 100 milliseconds: #define TUNE_ENCODER_DELAY??????????? ???? 50??????? // debounce delay in ms #define VOLUME_ENCODER_DELAY??????????? 40 and then look where to place them in the code. Many programmers use the standard delay() function call: delay(TUNE_ENCODER_DELAY); ?????????? ???? However, the delay() function is a "blocking" function, which means that it turns off interrupts for the delay period. Given that debounce functions have relatively short delays, this probably isn't a problem in this code body. However, perhaps some functions [e.g., MyHairsOnFire()] shouldn't be blocked. In that case, I would suggest: ? Purpose: to cause a delay in program execution ? ? ? unsigned long millisWait ? ?// the number of millseconds to wait ? void MyDelay(unsigned long millisWait) ? unsigned long now = millis(); ? ? while (millis() - now < millisWait) ? ? ; ?????????????????????????????????// Twiddle thumbs until delay ends... ? The millis() standard Arduino function is non-blocking, otherwise it acts the same as delay(). I try to use the style shown above. I use a starting capital letter for the function name and Polish notation because most standard and function library names in the Arduino IDE start with a lowercase letter. That way, I know in advance whether I wrote the code or it comes from a library I didn't write.? Also, the details about the function always falls in the function header between the "/" and the "/" followed immediately by the function signature (e.g., void MyDelay(unsigned long millisWait) and a newline character). By rigidly following the function format, I wrote a program that looked for the "/" lead-in and then used the __FILE__ and __DATE__ standard macros to create a user document that detailed all of the function calls we wrote for the project. When I had my own software company, I gently convinced all of my programmers to follow this format. Anyone who used a different format had to buy beer and pizza for the programmers the following Friday. I don't remember anyone buying lunch more than once, which kept the project documentation for the code up-to-date. Sorry for the long answer, but conventions can make projects with multiple coders easier to use. On Monday, February 26, 2024 at 07:23:58 AM EST, Ashhar Farhan <farhanbox@...> wrote: The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time. ? On Mon, Feb 26, 2024, 6:14 AM barry halterman <kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
--
Jack, W8TEE
--
Jack, W8TEE
--
Jack, W8TEE
|
I know a book on C that might be useful... 
Jack, W8TEE
On Tuesday, February 27, 2024 at 09:43:41 AM EST, barry halterman <kthreebo@...> wrote:
Gentlemen, I will not argue the fact that software might be the proper method, IF you know the syntax of the language and have a good understanding of programming structure and can make it work. ?I for one, have neither and getting a LED to blink is a major task. My hat is off to you folks who can program. Yes, I am envious. 73 Barry K3BO ? Sent from for Windows ?
From: Jack, W8TEE via groups.ioSent: Monday, February 26, 2024 9:46 PM To: [email protected]Subject: Re: [BITX20] sbitx encoder contact bounce ? I agree. If the only tool you have is a hammer, every problem looks like a nail. If you can, it's always nice to add a new tool to the belt. On Monday, February 26, 2024 at 09:03:05 PM EST, Ashhar Farhan <farhanbox@...> wrote: Barry, They are simpler fix for you. But if we roll in this interesting change, then, all the hundreds of radios can have better debouncing without touching their soldering irons. We are homebrewing in C as well, now. ? On Tue, Feb 27, 2024, 3:04 AM barry halterman <kthreebo@...> wrote: Two 0.1 uf capacitors on the encoder board are WAY much simpler! Barry ? ? Sent from for Windows ? ? On Monday, February 26, 2024 at 10:37:26 AM EST, Ashhar Farhan <farhanbox@...> wrote: Jack, In the sbitx, the encoders fire interrupts and measure the time through millis(), it is a wrapper around utime() ? My experience is that debouncing in software can vary from encoder to encoder. I would suggest creating symbolic constants for each encoder (e.g., tune, volume, etc). Usually, the delay is between 40 and 100 milliseconds: #define TUNE_ENCODER_DELAY??????????? ???? 50??????? // debounce delay in ms #define VOLUME_ENCODER_DELAY??????????? 40 and then look where to place them in the code. Many programmers use the standard delay() function call: delay(TUNE_ENCODER_DELAY); ?????????? ???? However, the delay() function is a "blocking" function, which means that it turns off interrupts for the delay period. Given that debounce functions have relatively short delays, this probably isn't a problem in this code body. However, perhaps some functions [e.g., MyHairsOnFire()] shouldn't be blocked. In that case, I would suggest: ? Purpose: to cause a delay in program execution ? ? ? unsigned long millisWait ? ?// the number of millseconds to wait ? void MyDelay(unsigned long millisWait) ? unsigned long now = millis(); ? ? while (millis() - now < millisWait) ? ? ; ?????????????????????????????????// Twiddle thumbs until delay ends... ? The millis() standard Arduino function is non-blocking, otherwise it acts the same as delay(). I try to use the style shown above. I use a starting capital letter for the function name and Polish notation because most standard and function library names in the Arduino IDE start with a lowercase letter. That way, I know in advance whether I wrote the code or it comes from a library I didn't write.? Also, the details about the function always falls in the function header between the "/" and the "/" followed immediately by the function signature (e.g., void MyDelay(unsigned long millisWait) and a newline character). By rigidly following the function format, I wrote a program that looked for the "/" lead-in and then used the __FILE__ and __DATE__ standard macros to create a user document that detailed all of the function calls we wrote for the project. When I had my own software company, I gently convinced all of my programmers to follow this format. Anyone who used a different format had to buy beer and pizza for the programmers the following Friday. I don't remember anyone buying lunch more than once, which kept the project documentation for the code up-to-date. Sorry for the long answer, but conventions can make projects with multiple coders easier to use. On Monday, February 26, 2024 at 07:23:58 AM EST, Ashhar Farhan <farhanbox@...> wrote: The debouncing of the encoders is done in software, not hardware. This is the first time I have heard of a bounce problem anyway.? Take a look at the encoder code you could tweak it to increase the debounce time. ? On Mon, Feb 26, 2024, 6:14 AM barry halterman <kthreebo@...> wrote: Hi, I put the capacitors on the underside of the encoder board. Each capacitor (.1uf) goes from? the phase A and B pin, to the encoder housing grounding trace. Plenty of room to incorporate these. Barry ? Sent from for Windows ? ? I am interested to know where you placed the capacitors. Can you show a drawing perhaps? ? On Sun, Feb 25, 2024, 3:18 PM barry halterman <kthreebo@...> wrote: lately I have noticed some contact bouncing with the main encoder when tuning my sbitx. My display frequency would bounce back and forth. I noticed, on the schematic, that there are no capacitors to clean up the noise from the rotary encoder. I installed two .1uf caps on the encoder board and that took care of my issue. Have not noticed any problems with the multi function encoder though.
73
Barry?
--
Jack, W8TEE
--
Jack, W8TEE
--
Jack, W8TEE
-- Jack, W8TEE
|
Scotty R
