Hi Paul - I only made this suggestion because I assumed it would be easy
to apply the same mechanism that you're using to limit TRAC requests to
one-per-500ms. If there's more to it than that then I'm not even
convinced that one-increment-per-click is needed, so maybe it's not
worth the effort. The volume control already works nicely, and I doubt
people will notice a difference between one increment and two in general
use.
However, if you do investigate this, a few thoughts:
1) One increment per click might be a bit slow. My own encoder has 30
clicks per full revolution. So to go from 0 to 100 would take over
three complete turns of the encoder. Perhaps this could be a
user-configurable value. For example, for my volume buttons I use an
increment of 5 (["mixer","volume","+5"]) because I found that made them
more responsive than the built-in ["button","volup"] command.
2) I captured some -z output, to see what's going on. I can see various
types of behaviour.
Sometimes there's only one interrupt:
Code:
--------------------
1566370933.5778 7 control.c,242: Interrupt: encoder value: 23 change: 1
1566370933.6074 6 control.c,337: Encoder on GPIO 21, 20 value change: 1
1566370933.6075 6 servercomm.c,74: Send Command:0,
Fragment:["mixer","volume","+1"]
--------------------
Sometimes there are two interrupts with exactly the same timestamp, with
the second one showing no change to the encoder value. The result is an
increment of one:
Code:
--------------------
1566370933.6358 7 control.c,242: Interrupt: encoder value: 24 change: 1
1566370933.6358 7 control.c,242: Interrupt: encoder value: 24 change: 0
1566370933.7111 6 control.c,337: Encoder on GPIO 21, 20 value change: 1
1566370933.7112 6 servercomm.c,74: Send Command:0,
Fragment:["mixer","volume","+1"]
1566370936.0457 7 control.c,242: Interrupt: encoder value: 28 change: 1
1566370936.0457 7 control.c,242: Interrupt: encoder value: 28 change: 0
1566370936.1254 6 control.c,337: Encoder on GPIO 21, 20 value change: 1
1566370936.1254 6 servercomm.c,74: Send Command:0,
Fragment:["mixer","volume","+1"]
--------------------
Sometimes there are two interrupts in short succession, resulting in a
total change of two:
Code:
--------------------
1566370932.8865 7 control.c,242: Interrupt: encoder value: 21 change: 1
1566370932.8917 7 control.c,242: Interrupt: encoder value: 22 change: 1
1566370932.9034 6 control.c,337: Encoder on GPIO 21, 20 value change: 2
1566370932.9034 6 servercomm.c,74: Send Command:0,
Fragment:["mixer","volume","+2"]
1566370934.4686 7 control.c,242: Interrupt: encoder value: 25 change: 1
1566370934.4787 7 control.c,242: Interrupt: encoder value: 26 change: 1
1566370934.5153 6 control.c,337: Encoder on GPIO 21, 20 value change: 2
1566370934.5153 6 servercomm.c,74: Send Command:0,
Fragment:["mixer","volume","+2"]
1566370936.5703 7 control.c,242: Interrupt: encoder value: 29 change: 1
1566370936.5827 7 control.c,242: Interrupt: encoder value: 30 change: 1
1566370936.6293 6 control.c,337: Encoder on GPIO 21, 20 value change: 2
1566370936.6294 6 servercomm.c,74: Send Command:0,
Fragment:["mixer","volume","+2"]
--------------------
In those last three examples, the time intervals between the double
interrupts are 11.7ms, 10.1ms and 12.4ms respectively. So at first
sight, if you were to limit the VOLU interrupt rate to one every 20ms
(instead of the 500ms used with TRAC), then those double interrupts
would be prevented from causing two increments - they could be treated
as one event, which could be programmed to send whatever volume
increment the user had chosen. 20ms would correspond to 50 possible
events per second, which feels like it should still be fast enough - I
couldn't physically turn my 30-increment encoder through 1.67
revolutions in 1 second. But maybe the 20ms could be a
user-configurable parameter too.
Can I just check a previous detail? I'm pretty sure you're aware of
this, but just in case we've got crossed wires and you thought I was
referring to the original sbpd. The pigpio version currently sends the
command associated with the first button in the list whenever I press
any programmed button. You explained the difference in the way the pin
is identified, but your explanation implied it would be simpler to know
which button has been pressed under pigpio, so it seems odd that the
wrong commands are being sent. Apologies if you're aware of this - I
know that version was only a proof of concept etc.
------------------------------------------------------------------------
chill's Profile: http://forums.slimdevices.com/member.php?userid=10839
View this thread: http://forums.slimdevices.com/showthread.php?t=107001
_______________________________________________
diy mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/diy
