Rotary encoder action

[Bill P.]

Hi all --  I've noticed that when I turn the rotary encoders clockwise their associated lights change in a counter-clockwise direction and vice-versa.  Is this the way a real PDP-11 worked as I found it to be somewhat counter intuitive?  At first I thought I might have mounted the encoders incorrectly, but then realized that was impossible given the 2/3 pin configuration.

--Bill

[Johnny Billquist]

No. The selections go around clockwise, just as the rotary.
On a real 11/70, the rotary selections also have a pointer, pointing to
which selection is current, in addition to the light showing what is
being displayed. (The selectors have 8 distinct positions they can be
in, and are not free running/rotating.)

This should be visible on the PiDP-11 as well, and should give you a
hint, even if there is no proper relationship between the selectors
position and what is being displayed.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/d32d7aac-ca25-4787-abbe-1942234a4ed0%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/d32d7aac-ca25-4787-abbe-1942234a4ed0%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Bill P.]

Thank, Johnny, that makes sense.  Can the panel code be changed to at least "fix" the clockwise action, or am I the only one seeing this?

--Bill

[Craig Ruff]

I see this also on mine. Definitely the direction of the lights is opposite that of the encoder knob for both knobs.

[oscarv]

Bill,

Oh dear - the 'reverse knob' bug is still in. Yes, I'll fix it (again, the fix dropped out apparently)! You indeed have to rotate that knob in the opposite direction...

Regards,

Oscar

[Bill P.]

Hi Oscar,

When you get a chance can you post your patch for this?  I started looking at the code, but decided not to reinvent the wheel if you fixed this before.

--Bill

[Gary Boone]

This bug appears to still be present in the current code. I just completed my PiDP11 using the latest downloads and noticed that the knobs moved the LEDs in "wrong" direction.

--Gary

[oscarv]

Fixed in the new version - see https://www3.ispnet.net/pidp11/PiDP-11%20Manual%20v0.2.odt for the install procedure.

[Gary Boone]

Success. Thanks!

[Bill P.]

Hi Oscar,

I downloaded the package from the link in the doc (https://www3.ispnet.net/pidp11/pidp11.tar.gz) and I am still seeing the reverse rotary switch action. Is there another source repository that I need to access?

--Bill

[Tom Lake]

I got mine from there, too and the encoders work fine. Are you sure the update went as planned?

Tom L

[oscarv]

Bill,

I agree with Tom - most likely you're not running the downloaded code. But let me know if I am wrong!

Kind regards,

Oscar.

[Bill P.]

I just downloaded the file again and extracted it to /opt/pidp11 and I'm still seeing the reversed rotary encoder action.  The file was obtained from https://www3.ispnet.net/pidp11/pidp11.tar.gz .  The old code was moved to a different directory and I am clearly running the new startup process since my switch settings match what is in the /opt/systems/selections file (which is different from the old code).  I'll grant that I may be doing something bone headed, but not sure what it would be.

--Bill

[oscarv]

Bill,

I will check next week when I am back home. The bone-headedness might be mine - the rotaries work fine here but it's not beyond me to mess things up. I will check & let you know :)

Kind regards,

Oscar.

[Dennis Williamson]

In my case, the data switch and lights rotate in the same direction. Only the address switch and lights rotate in opposite directions.

[Oscar Vermeulen]

Dennis,

On Wed, 3 Apr 2019 at 00:04, Dennis Williamson <dennistw...@gmail.com> wrote:

In my case, the data switch and lights rotate in the same direction. Only the address switch and lights rotate in opposite directions.

Ha! That points to where this rotating left/right malarkey is coming from: it *must* be hardware differences between rotary switches. I've been thinking that I somehow undid my rotation direction fix in the source code a few times, which was very confusing. But your case points to The Truth. There is no way other than hardware differences between your two switches to explain this behaviour. It must be a case where I ran out of the switches from box #1, and continued filling the parts bag from box #2. It is, in fact, true that there's lots of parameters to the rotary encoders internally.

OK, so now I know. And know how to deal with this in the code to solve it. Thanks (and sorry as well)!

Oscar.

[emt377]

Now you mention it, the upper rotary on my PiDP exhibits the "wrong way" behavior.  I never noticed before.

[Oscar Vermeulen]

On Sat, 6 Apr 2019 at 22:18, 'emt377' via [PiDP-11] <pid...@googlegroups.com> wrote:

Now you mention it, the upper rotary on my PiDP exhibits the "wrong way" behavior.  I never noticed before.

Yup - different batches with encoders that have a different internal setup. Tiny parameter, 180 degrees difference. They are all reorders from the same vendor, but... Now I know I can fix the rotational direction of the knob in software luckily.

Kind regards,

Oscar.

[emt377]

Same part number, different behavior?  Tut-tut, naughty supplier!

[Bill P.]

I feel vindicated :-)

[Alan Meyer]

I'm certainly experiencing the counter rotation issue as well.  So for those of us with this issue, do we need to make a configuration change? 

[Bill P.]

Hi Oscar,

Now that we've discovered that there are actually two different versions of the rotary switches that ended up in the kit, can we get the code changes necessary to reverse the rotation direction?  Thanks!

--Bill

[oscarv]

Bill,

I'm away from home but if your rotary knob dials the wrong way around, then this is the fix:

in \src\11_pidp_server\pidp11\gpio.c

line 344 is

            knobValue[i]++;    //bugfix 20181225
change to

            knobValue[i]--;    //reverse direction

line 352 is

            knobValue[i]--;    // bugfix 20181225
change to

            knobValue[i]++;    // reverse direction

and recompile

        cd /opt/pidp11/src

        sudo ./makeserver.sh

That's it...

Kind regards,

Oscar.

[Bill P.]

Thanks, Oscar!

[osuvman]

On Saturday, May 11, 2019 at 2:31:49 PM UTC-4, oscarv wrote:

Bill,

I'm away from home but if your rotary knob dials the wrong way around, then this is the fix:

Dennis Williamson said only one of his switches was operating backwards, I don't think this fix will work for him.

[oscarv]

On Sunday, May 12, 2019 at 2:42:35 AM UTC+2, osuvman wrote:

Dennis Williamson said only one of his switches was operating backwards, I don't think this fix will work for him.

Indeed - that will need an if statement to treat each switch differently.

Kind regards,

Oscar.

[emt377]

As a bemused software guy, I ask: are there data sheets for these specific devices, explaining (a) what they say to software, and (b) the differences between the two models?

[osuvman]

I wondered the same thing. It's a pretty standard part, though, so there are plenty of tutorials on the web about how to program them. I did find one datasheet, but all it had on it was a phase diagram like is on the Wikipedia page:
https://upload.wikimedia.org/wikipedia/commons/thumb/6/68/Quadrature_Diagram.svg/220px-Quadrature_Diagram.svg.png

[Stephen Casner]

I wonder the same. It seems unlikely to me that there would be two
variations of a part with the same numer. It does not make sense.
Instead there must be some other variable that we have not realized.
Is the behavior of a particular unit always the same, or might the
direction change from time to time? Is there some subtle variation in
signal timing that varies between different models of Pi? Is there
something that might vary as a result of construction technique?

-- Steve

[Oscar Vermeulen]

Steve et all,

On Sun, 12 May 2019 at 18:19, Stephen Casner <cas...@acm.org> wrote:

On Sun, 12 May 2019, 'emt377' via [PiDP-11] wrote:

> As a bemused software guy, I ask: are there data sheets for these specific
> devices, explaining (a) what they say to software, and (b) the differences
> between the two models?

I wonder the same. 

Of course there are proper data sheets! The question is whether there was a proper buyer (no, it was me).

This is my punishment for buying from a bulk seller on Alibaba that apparently did not realise a subtle difference between two batches...

Not to blame him though, he's always delivered good quality for a good price. Without sellers like him the kit would be more expensive. It might even be that if I used the normal algorithm for rotation detection, they would all behave the same. But my simple code is less CPU intensive (it's run constantly!), so the i++ / i-- software fix will solve the problem.

Kind regards,

Oscar.

[Oscar Vermeulen]

Compare your quadrature diagram with the one from the attached datasheet of (an earlier version of) the rotary switch that I use - there's a shift in the A and B patterns! I suspect this is what was at play.

Kind regards,

Oscar.

[Johnny Billquist]

I haven't looked at this at all, but is it possible to mount the switch
in two ways, which might make it "appear" to work one way or the other?

I mean, the obvious thing is if it just indicates the direction with two
lines, then if those two lines are swapped, it will appear to rotate in
the opposite direction.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Johnny Billquist]

And the obvious answer if this is somewhat random from one panel to the
next is to have a configuration command or file, telling for each rotary
in which direction it goes. And then it will work for any kit, as soon
as the configuration file/command have been applied. And then you can
have it different for each of the rotaries as well (they really should
be handled separately anyway).

[osuvman]

On Sunday, May 12, 2019 at 1:15:42 PM UTC-4, Johnny Billquist wrote:

I haven't looked at this at all, but is it possible to mount the switch
in two ways, which might make it "appear" to work one way or the other?

I mean, the obvious thing is if it just indicates the direction with two
lines, then if those two lines are swapped, it will appear to rotate in
the opposite direction.

The part has 5 pins (3 for the rotary encoder, 2 for the push button), you can't mount it wrong without a whole lot of effort.

[osuvman]

On Sunday, May 12, 2019 at 1:19:17 PM UTC-4, Johnny Billquist wrote:

And the obvious answer if this is somewhat random from one panel to the
next is to have a configuration command or file, telling for each rotary
in which direction it goes.

I  was planning on doing that anyway. I updated gpio_param.c to support inverting
the rotary direction the same way it can invert switches. See the reference to
panel_driver002.zip that uploaded to my google drive.

---

panel_driver_002.zip

[emt377]

Ha.. somewhere I turned from a "bemused software guy" to:

| As a mediated software guy

Machine translation!

[David Richards]

I have received and built a new pidp11 this week. Everything worked first time, the only minor problem is that both encoders are working backwards. No problem I'll apply the patch if it gets too annoying.

The pi keeps various configuration settings on the boot disk in a text file, perhaps this would be a suitable place to override the default encoder action. Alternatively an environment variable could be used.

Hth David.

[oscarv]

David,

Indeed - the patch I published is the fix for now, it'll be a config item in the next software version!

Kind regards,

Oscar.

[David Griffith]

Is this fix in the currently available software version?  If so, how do I change the setting?

[Steven A. Falco]

The fix is earlier in this thread. Quoting Oscar from 5/11/19:

I'm away from home but if your rotary knob dials the wrong way around, then this is the fix:

in \src\11_pidp_server\pidp11\gpio.c

line 344 is
knobValue[i]++; //bugfix 20181225
change to
knobValue[i]--; //reverse direction

line 352 is
knobValue[i]--; // bugfix 20181225
change to
knobValue[i]++; // reverse direction

and recompile
cd /opt/pidp11/src
sudo ./makeserver.sh

> --
> You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/5726a52f-91aa-4177-ad94-2a53b86abeaa%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/5726a52f-91aa-4177-ad94-2a53b86abeaa%40googlegroups.com?utm_medium=email&utm_source=footer>.

[David Conners]

Bumping this old topic, just curious if there is a "real" fix coming down the line?

Not super urgent - swapping the direction in the code and recompiling is not a big deal; but if it is not going to be addressed it might be useful to update the build manual with the information.

Cheers

David

[Johnny Billquist]

What defines a "real fix"? The problem is that apparently the hardware
varies, with no way of telling that anyone have figured out yet.

As such, maybe we could do with a configuration file that people can put
into which way the encoding is on his hardware.

Beyond that, I can't see what could be done.

Johnny

> <https://groups.google.com/d/msgid/pidp-11/5726a52f-91aa-4177-ad94-2a53b86abeaa%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/pidp-11/5726a52f-91aa-4177-ad94-2a53b86abeaa%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/fd210256-ce80-4c23-8335-6c8a1cd41430n%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/fd210256-ce80-4c23-8335-6c8a1cd41430n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[David Conners]

It would seem that having the user setting in a separate config file rather than in a separate code fork is desirable.

In any case, the build doc should be updated to reflect the possibility that the encoders are not aligned with the code/configuration

Something like

Encoder Polarity

The rotary encoders can ship with one of two polarities, and unfortunately there is no way to detect in the PiDP software which version you have. It does however affect which direction the PiDP software thinks you are rotating the encoder. If there is a mismatch between the encoder polarity and the software you will see the LED's controlled by the encoder rotate in the opposite direction to the encoder. For example, if the top knob LED is reading "CONS PHY" and you rotate the knob clockwise, it should advance to "KERNEL D", but if it instead goes to "PROG PHY" you have a software/encoder polarity mismatch.

If this doesn't bug you, it can be left as is, no functionality of the PiDP is impacted.

If you do want to align the rotation directions you will have to modify one of the PiDP source files and recompile

First edit the file /opt/pidp11/src/11_pidp_server/pidp11/gpio.c

Search for the two lines that increment and decrement knobValue[i] and reverse them

e.g.

knobValue[i]++; //bugfix 20181225

change to
knobValue[i]--; //reverse direction

knobValue[i]--; // bugfix 20181225
change to
knobValue[i]++; // reverse direction

Save the file and recompile the software

cd /opt/pidp11/src
sudo ./makeserver.sh

Note that if one encoder is correct and one isn't, making this change will just flip which is correct and which isn't. Handling that case is beyond the scope of this note.

[Stephen Casner]

I have trouble believing that there are two hardware versions of the
encoder switches that are specified to operate differently. Rather, I
expect that the software driving the encoder is susceptible to tiny
variations in the switch bounce timing. As I recall, long ago in this
conversation Oscar made a post in which he admitted that the method he
used to read the encoder was something of a shortcut (I don't remember
his exact phrase). If my expectation is accurate, then PiDP11 owners
may find that the behavior of their encoder switches changes over time
as the bounce timing changes with switch use and age.

I have not hooked up a scope to the switches or instrumented the
software to verify this conjecture.

-- Steve

[Johnny Billquist]

We have since actually looked with scopes and they do indeed seem to
encode in different ways. That in itself is not a big issue. But there
don't seem to be any difference in the product identification for the
encoders, which is very surprising.

But feel free to continue investigating. The encoders are using gray
codes, by the way, so bouncing actually is not a problem. It just cause
movement back and forth between the two adjacent states. Eventually you
will end up on the correct state. And sample rates pretty much don't
affect it either, unless we get to very low sample rates, and very high
speed of the encoder changes.

Johnny

[Michael Katzmann]

The encoders have two quadrature channels (so not a grey code in the usual sense). That is, one is leading/lagging by 90 degrees. This is how the program can distinguish direction.

I've noticed that it's easy to go faster than the processor is sampling the signal and thus miss counts (so that the led lags the switch position) 

[Johnny Billquist]

On 2022-02-01 00:28, Michael Katzmann wrote:
> The encoders have two quadrature channels (so not a grey code in the
> usual sense). That is, one is leading/lagging by 90 degrees. This is how
> the program can distinguish direction.
> I've noticed that it's easy to go faster than the processor is sampling
> the signal and thus miss counts (so that the led lags the switch position)

That is what grey code is. Only one channel changes at a time. With two
bits:

00 -> 01 -> 11 -> 10 -> 00

Which with a rotary encoder is done by having two 180 degree fields, 90
degrees apart.

Classic grey code.


If sampling can't keep up, it's not that you start lagging. What happens
is that you'd get things in the wrong order. You'd skip one or two
positions. With one skipped, you just get to an impossible state from
the previous one, and with two skipped, it looks like you moved in the
other direction.

Johnny

>
> On Mon, Jan 31, 2022 at 5:06 PM Johnny Billquist <b...@softjar.se
> <mailto:b...@softjar.se>> wrote:
>
> We have since actually looked with scopes and they do indeed seem to
> encode in different ways. That in itself is not a big issue. But there
> don't seem to be any difference in the product identification for the
> encoders, which is very surprising.
>
> But feel free to continue investigating. The encoders are using gray
> codes, by the way, so bouncing actually is not a problem. It just cause
> movement back and forth between the two adjacent states. Eventually you
> will end up on the correct state. And sample rates pretty much don't
> affect it either, unless we get to very low sample rates, and very high
> speed of the encoder changes.
>

[David Conners]

so I am very new to the PiDP-11 stuff, is there a repo where Oscar maintains the code that we can contribute to?

I figure if I am going to bring something up as an issue I should make a good faith attempt to fix it :-)

I've got what appears to be a relatively simple approach, a new command line argument (-k) to the server11 process that will flip the direction of one or both of the knobs

That way, only the /opt/pidp11/bin/pidp11.sh script needs to be edited to specify the rotation of the encoders.

The code does a bitwise and on the argument supplied and flips the rotation of the ADDR encoder if the 0x1 bit is set, and the DATA encoder if the 0x2 bit is set.

e.g. to flip both encoders you would change your pidp11.sh to have

        echo "*** Start client/server ***"
        sudo ./server11 -k 3 &