Title: rotary encoders boucing
Post by: pa3met on 14. May 2018, 12:08:21
hi,
I am finishing off the mcHF v0.6 -- currenty RX only. Works fine, except for that I found that both the RF gain and RIT
knob showed some bouncing.... like turning left right not always increasing/decreasing stuff.
I ordered fres rotary encoders and replaced thm, ... to find myself in the same situaltion.
I did check the UHSDR pages for mods but bounce nor rotary gave me results that brings me how to
fix this behaviour.
anyone else who sees the rotary encoders bouncing or sometimes not working?
|
Title: Re:rotary encoders boucing
Post by: DL2GMI - Michael (H44MI) on 14. May 2018, 16:43:33
I have the same problem, this is present over all Firmware Versions at my mcHF 0.4.
I installed the encoders which are listed in the BOM.
|
Title: Re:rotary encoders boucing
Post by: DF8OE on 14. May 2018, 18:39:26
It is not a firmware problem - it is a quality problem of encoders...
vy 73
Andreas |
Title: Re:rotary encoders boucing
Post by: SP3OSJ on 27. May 2018, 08:27:30
This is not a problem of encoder quality.
There are encoders with offset 90 and offset 270
That is why it is good to accept my solution
To draft a pcb with the possibility of rotation correction.
or do it programmatically. |
Title: Re:rotary encoders boucing
Post by: peter_77 on 27. May 2018, 08:34:27
I used those classical ones from ALPS:
https://www.reichelt.de/Drehimpulsgeber/STEC12E08/3/index.html?ACTION=3&LA=2&ARTICLE=73923&GROUPID=3714&artnr=STEC12E08&trstct=pol_0 (https://www.reichelt.de/Drehimpulsgeber/STEC12E08/3/index.html?ACTION=3&LA=2&ARTICLE=73923&GROUPID=3714&artnr=STEC12E08&trstct=pol_0)
and have never ever seen any issues like described.
|
Title: Re:rotary encoders boucing
Post by: DF8OE on 27. May 2018, 09:10:47
If it is a problem of firmware it must be reproduceable on ALL devices using the samte firmware revision. But it is not. I have build 5 mcHFs and ~150 OVI40 and I cannot confirm it is a firmware problem. Additionally I do not have one single PCB that has heavy bouncing encoders. Sometimes in menu there is a direction error - that can be a firmware problem (timeslot is cut by interrupt). But under normal working conditions I enver have had any issue. And I do not want to use encoders with different direction ::) Of course if there are jumpers you can.
vy 73
Andreas |
Title: Re:rotary encoders boucing
Post by: SP3OSJ on 27. May 2018, 10:50:02
This is not a software problem!
An additional function can be made in the menu:
Encoders -> left/right
The menu has a similar function:
Menu Inverse Scrolling -> OFF/ON
Only that it only applies to the menu
|
Title: Re:rotary encoders boucing
Post by: DB4PLE on 27. May 2018, 11:57:50
Hi,
you are mixing two problems it seems:
1)
Original poster wrote that sometimes the value is not changing in the direction of turn but goes backwards, this usually happens when turning slowly and only a tiny amount. This is an encoder hardware bouncing problem, where the STM32F4 simply says the gray code going backwards due to bouncing. Quality encoders have less of an issue here. With proper HW debouncing or better encoders this can be reduced/eliminated. Optical encoders should not suffer from that problem at all, btw.
I can see that on my boards as well, but is just a little annoying but not critical. If someone would care to experiment with the debounce capacitor value (which is 1nF AFAIR), we could probably eliminate this to a very large extent.
2)
What Artur discusses (at least this is what I guess), is that some encoders result consistently in opposite turns as usual. Due to the reversed order of the gray codes in the encoder. What he proposes is a layout which permits to switch the direction by using solder bridges in a clever way. And yes, this could be done ins software easily with extra solder bridges. However, current software does not support this.
The opposite direction option for menus results from the fact that on the mcHF 0.7 due to the changed encoder location, the original direction of scrolling was considered counterintuitive by some. If turn on, the change is in the menu navigation only. So this is a completely different thing.
But yes, the encoder direction interpretation could be changed in the firmware, but I personally see no reason for that. If using the normal encoders, all works as it should (with the exception of issue of the original poster, as discussed).
73
Danilo
|
Title: Re:rotary encoders boucing
Post by: Michael_K on 28. May 2018, 05:48:34
Hallo,
mich "erwischt" das Problem hin und wieder beim Encoder E1 nach dem Einschalten (sowohl ui_V0.5, als auch ui_V1.7)
@Danilo. meinst Du die beiden C's an den Kontakten A und B?
In welche Richtung sollten die geändert werden (größer/kleiner)?
Habe nächste Woche Zeit und würde mal probieren
vy 73 aus Erfurt
Michael_K |
Title: Re:rotary encoders boucing
Post by: DB4PLE on 28. May 2018, 05:58:09
Hallo Michael,
Hallo,
mich "erwischt" das Problem hin und wieder beim Encoder E1 nach dem Einschalten (sowohl ui_V0.5, als auch ui_V1.7)
@Danilo. meinst Du die beiden C's an den Kontakten A und B?
In welche Richtung sollten die geändert werden (größer/kleiner)?
Habe nächste Woche Zeit und würde mal probieren
vy 73 aus Erfurt
Michael_K
|
|
Gute Frage, ich habe schon versucht, die STM32 Unterlagen zu sichten, ob da was steht. In jedem Fall habe ich Beispiele gesehen (nicht ausprobiert!), bei denen mit 10k Pull-Up Widerstand und 100nF gearbeitet wurde (Lowpass 150Hz). Da wir den internen Pull-Up verwenden (der hat typisch 40k), würde ich mal denken man sollte mal probieren, schrittweise (!) in Richtung 22nF gehen (Lowpass 180 Hz). Höhere Kondensatorwerte -> geringere maximale Rotationsgeschwindigkeit.
73
Danilo
|
Title: Re:rotary encoders boucing
Post by: DF8OE on 28. May 2018, 07:42:58
Ich habe da so einen fixen Gedanken für einen Workaround - kann aber auch völlig falsch liegen...
Kann es sein, dass die Stellung, von der aus man dreht, nicht korrekt erkannt wird, weil ja erst beim Wechsel von dieser Stellung an von der Firmware "gesnifft" wird? Wie wird überhaupt erkannt, ob an einem Encoder gedreht wurde - in unserer Schleife oder per Interrupt? Wenn in der Schleife: wäre es nicht vielleicht besser, einen Interrupt zu nehmen, der ausgelöst wird, wenn sich an einem der beiden Anschlüsse der Signalpegel ändert (egal in welche Richtung)? Denn wenn man bei so einer Pegeländerung per Interrupt aufgeweckt wird muss der "Startpegel" folglich der "inverse aktuelle" des auslösenden Signals gewesen sein. Es würde ja ausreichen, wenn in dem Interrupt einfach ein Flag gesetzt wird, dass auf eine megakurze Tabelle zeigt, in der aufgeführt ist, welcher Signalpegel den Interrupt ausgelöst hat und wie der beim Auslösen war. Die weitere Verarbeitung könnte dann innerhalb unserer "normalen Schleie" erfolgen - dort wird dann auch das Flag gelöscht undder Interrupt für alle Encoder solange disabled bis sie sagen wir 0.5 Sekunden nicht mehr angefasst wurden. Nach dieser Zeit muss der Interrupt wieder "scharfgemacht werden".
Bei mir tritt das Problem nur am "Drehanfang" auf. Niemals mittendrin beim Drehen, Das macht schon etwas stutzig.
vy 73
Andreas |
Title: Re:rotary encoders boucing
Post by: DB4PLE on 28. May 2018, 16:30:06
Hello,
to clarify:
All decoding of the encoder is completely handled in hardware by the STM32 timers which have a quadrature encoder mode. The only thing we do is to read the counted steps. No interrupts, nothing. Just reading a single register from the timer is all we do to figure out if there is a changed in the encoder position.
In the BFML (big fat main loop) we read the encoder positions from these register.
It is not clear to me why we get wrong direction from the encoders. There is only little information on how the encoder mode of the timers work, this does not make it easier.
The encoder reading code in ui_rotary.c is doing some strange things which I don't full understand why it is doing what it does. However, I can't see how it could cause "backward" motion. What I will look into is what happens when then counter wraps around (reach maximum value and then continue from zero.
73
Danilo
|
Title: Re:rotary encoders boucing
Post by: DF8OE on 28. May 2018, 16:43:21
Hi Danilo,
I do not fully understand working of decoding, too. It would be helpful if someone can add a logic analyzer (or a dual trace scope) to encoder output and tries to log what happens if diretion at start is correct or is not correct.
It never was something that bothers me - it is a "cosmetic issue" in my view. But it is present - no doubt.
vy 73
Andreas |
Title: Re:rotary encoders boucing
Post by: SP9BSL on 29. May 2018, 07:08:11
Hi,
i saw this problem too, it is annoying especially in Menu options navigation/modification. I did not observe this for frequency dial becuse i use DIY magnetic encoder (i promised to publish STL files and pcbs for it and will do it). For three knobs on the left i use ALPS encoders (exactly the ones from BOM) and all show problems as described. It doesn't matter the UI board, same behaviour on OVI40 UI and mcHF 0.4 UI.
@Andreas: It is hard to catch this moment but doable. In spare time will try to do that.
@Danilo: I found some bugs in libraries provided by ST's MCD team (EEPROM simulator, RTC clock/calendar), so i would not be suprised that there is another issue with encoder functionality of timer (althought i did'n look to this code yet). I never used it in this way because when i integrate encoder in project, i always use the interrupt way.
Summary: it will be investigated because it is annoying in my opinion. |
Title: Re:rotary encoders boucing
Post by: DB4PLE on 29. May 2018, 07:18:04
Hi Slawek,
the whole encoder code is from "us", i.e. from Clint or Chris from the early ages, a little bit streamlined by me but not changed in its algorithms. No STM library involved, just the timer setup code is generated by CubeMX.
I think it is most likely an interaction between "poor" hardware and possibly wrongly configured timer interface.
73
Danilo
|
Title: Re:rotary encoders bouncing
Post by: peter_77 on 29. May 2018, 14:15:39
Slawek is right here. In the configuration menue this is reproducable either on the mcHF or I40-UI.
Not the way that its not functioning at all but the right left behaviour is somehow "shaky".
EDIT
corrected typo in thread title |
Title: Re:rotary encoders boucing
Post by: DF8OE on 29. May 2018, 16:23:53
I think like Danilo. It is a combination of hardware problem and "simple firmware interpretation".
If you want to code a debouncing filter this would cause more delay in firmware processing, more code and probably new configuration for different encoders.
So best is to add a RC lowpass between encoder contacts and GPIOs. You need three parts: one resistor as pullup (already present built-in STM), a capacitor to GND (already present) and a serial resistor between contact and GPIO/capacitor (missing). So you can cut the track and insert it. I never have had tried but I thin 1K...3.3K will do the job. But pay attention! Screwing up resistor will cause lower maximum pulses ( ==> you cannot turn very fast). I would think hardware lowpass is sufficient for volume, AGC and RIT but not for VFO.
vy 73
Andreas |
Title: Re:rotary encoders boucing
Post by: OE3HKC on 29. May 2018, 19:55:48
Hallo Allerseits,
und auf "deutsch" würde ich sagen...
prellende Kontakte können so manches verursachen...
ich habe in meinem MiniTRX die Encoder-Kontakte über pullup 4k7, dann Serien-Widerstand 100 Ohm und Ko von 1n gegen 0V "entprellt"...
diese Probleme mit "falscher" Drehrichtung habe ich bisher noch nicht festgestellt.
Ich verwende auch die preisgünstigen Encoder von ALPS...
Schaltbild dazu unter
https://www.amateurfunk-sulingen.de/forum/attachments/MINIMCU.PDF
MiniMCU.pdf
vy 73, Helmut |
Title: Re:rotary encoders boucing
Post by: peter_77 on 31. May 2018, 08:27:33
As a conclusion following Helmuts advice would would mean to simply cut the encoder lines and add a 100Ohm resistor.
Thats a quick fix.
Looks like Helmut has done here too much as he has not taken into account that the STM CPU has an internal pullup resistor on chip and the 1nF capacitor is there anyway either on mcHF and I40-UI. |
Title: Re:rotary encoders boucing
Post by: S53DZ on 31. May 2018, 11:07:01
Hi there,
I did some LTspice simple simulations of contact bouncing.
I have used an optocoupler for that.
It seems that a lower value pull-down resistor makes a difference.
Perhaps the slope of end pulse could be important here for FW level-decision.
Just guessing.
Beside that, my experience is: don't use the cheapest encoders.
73 Bojan
|
Title: Re:rotary encoders boucing
Post by: SP9BSL on 31. May 2018, 16:31:23
Hi Bojan,
as Danilo said, the problem lies somewhere between the hardware and firmware. I always use ALPS encoders wchich are known as good ones, and i met this issue in mcHF/OVI40. From other side, i replaced few unknown encoders in stuff like Hameg/Rigol oscilloscopes/spectrum analyzers, and the new ones from ALPS works much better and longer than those mounted in factory.
Increase of capacitance and/or series resistance may cause problems with slope as mentioned. This issue doesn't occur with magnetic encoder chip (AS5040, AS5601) I use, so I think that this leads to conclusion that we have slope problem. |
Title: Re:rotary encoders boucing
Post by: SP9BSL on 03. June 2018, 18:03:49
Hi,
Beside the slope, there is also zero crossing counter issue for sure. Anyway: workin' on it... |
Title: Re:rotary encoders boucing
Post by: SP9BSL on 04. June 2018, 06:41:32
Hi,
Please test the new 2.9.34 version. It contains fixup for encoder boundary crossing and hardware filter usage (internal STM settings) for encoder sampling. Hope this will work better. For my mcHF, after this fixup, the issue is no longer reproduceable. |
Title: Re:rotary encoders boucing
Post by: peter_77 on 04. June 2018, 14:03:11
Tested and works perfectly fine now. The hangers are not reproducable anymore. Either on mcHF or I40.
Good job Slawek !
|
Title: Re:rotary encoders boucing
Post by: SP9BSL on 04. June 2018, 16:09:02
Hi Peter,
thank you for the report. This part of code is very old and still needs some cleanup.
I'm curious of reports from others who changed the encoder capacitors to bigger than in schematics. |
Title: Re:rotary encoders boucing
Post by: DF8OE on 04. June 2018, 16:51:36
You should ask in Yahoo group because of changing capacitors is mainly mentioned to 0.7 boards whichs layout is not rf resistent ::)
vy 73
Andreas |
Title: Re:rotary encoders boucing
Post by: SP9BSL on 04. June 2018, 18:51:56
Title: Re:rotary encoders boucing
Post by: OE3HKC on 04. June 2018, 19:08:00
TNX Slawek for your great work,
I also tested the new version with my MiniTRX..
sometimes there were little boucings, only some few, perhaps because of the small pullup of 4k7...
but now there is no more issue from the encoders and I think it is not necessary to change it for a magnetic type...
73, Helmut |
Diskussions- und Newsboard des DARC-Ortsverbandes I40 | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|