Pages: [1] 2 
|
 |
|
|
Author
|
Topic: rotary encoders boucing (Read 4911 times)
|
|
pa3met
Neuling
 Offline
Posts: 3
Ich liebe dieses Forum!
|
 |
rotary encoders boucing
« 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?
|
|
 Logged
|
|
|
|
DL2GMI - Michael (H44MI)
alter Hase
Offline
Posts: 371
 
|
|
Re:rotary encoders boucing
« Reply #1 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.
|
|
Logged
|
UI 4, RF 4, Mods: UI-H-031,RF-05-H-001,RF-H-002,UI-H-003,UI-H-004,RF-H-005,UI-H-006,UI-H-008,RF-H-018,RF-H-023,UI-H-027,RF-H-029,UI-N-026,RF-N-009,RF-N-010,RF-N-011,RF-N-012,AG-N-013,RF-N-015,RF-N-016,UI-N-019,UI-N-025,RF-N-028,RF-N-030
|
|
|
|
|
SP3OSJ
Guest
|
|
Re:rotary encoders boucing
« Reply #3 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.
|
|
|
|
|
|
|
|
SP3OSJ
Guest
|
|
Re:rotary encoders boucing
« Reply #6 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
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:rotary encoders boucing
« Reply #7 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
|
|
Logged
|
|
|
|
Michael_K
Urgestein
Offline
Posts: 638
Ich liebe dieses Forum!
|
|
Re:rotary encoders boucing
« Reply #8 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
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:rotary encoders boucing
« Reply #9 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
|
|
Logged
|
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:rotary encoders boucing
« Reply #10 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
|
| « Last Edit: 28. May 2018, 07:47:28 by DF8OE » |
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:rotary encoders boucing
« Reply #11 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
|
|
Logged
|
|
|
|
|
|
SP9BSL
positron
alter Hase
Offline
Posts: 443
|
|
Re:rotary encoders boucing
« Reply #13 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.
|
|
Logged
|
73 Slawek
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:rotary encoders boucing
« Reply #14 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
|
|
Logged
|
|
|
|
Pages: [1] 2 
|
|
|
|
|
|
|
Of course if there are jumpers you can.
