Logical Swtiches - 'Edge' and 'Sticky'?!? (V2.0.8)

[Spainman]

Hi,
could anybody please explain the parameters of Edge and Sticky?
They seem to be undocumented and Google didn't help either in finding a correct and comprehensive function and parameter description.

(Which is quite frustrating by the way. Is there a way to contribute to the documentation? Even some short but complete and correct notes in the manual are better than nothing.)

Well - back to the actual question. Tests made in simulator:

Edge:
- Ln seems to go TRUE for 'Duration' when the 'V1' is TRUE for a duration specified in 'V2' as an time interval, right?
- What does 'Delay' do? I can't figure it out.
EDIT: Bug in Companion - transmitter shows N/A for delay


Sticky:
- Ln goes to TRUE when 'V1' transitions from FALSE->TRUE
- Ln goes to FALSE when 'V2' transitions from FALSE->TRUE
- Ln goes to FALSE after 'Duration', 'Duration' starts when Ln goes to TRUE

- 'Duration' has a higher priority than 'V2', if 'Duration' hasn't passed, 'V2' will not set Ln to FALSE
=> In my opinion the precedence is the wrong way around. What is the idea behind it? E.g. when 'V2' is a physical input the user would expect to be able to abort what ever was triggered by 'V1' immediately using 'V2', regardless of the duration. I can think of situations where this behavior could be dangerous.

- if 'Duration' is set !=0 then 'V1' does not trigger Ln, even when Ln is currently FALSE (or in simpler words: if Ln was switched off by the duration timer, it needs to be turned off by 'V2' once more before it can be turned on by 'V1' the next time)
=> Unexpected. Not useful in my opinion. When a switch is off, it is off and should allow to be turned on again, no matter if it was turned off by the 'duration' or 'V2'. What is the idea here or is it a bug?

- 'Delay' can't be selected. Why?
EDIT: Bug in Companion - transmitter allows entering delay

It would be great if someone with the needed insight could clarify and elaborate a bit. Please don't ask what I'm trying to do. I'm just checking out what functions are available and how they behave in detail before making use of them.

Thank you.

[dinamich]

The duration and delay are independent of actual logical switch function and are applied onto the logical switch output after the condition processing. More on how duration works here https://github.com/opentx/opentx/issues ... t-43725312

A short explanation of sticky and edge on http://rc-soar.blogspot.com/2014/04/ope ... -beta.html

And Companion delay enabled/disabled is a bug, thanks. I already corrected it in https://github.com/opentx/opentx/commit ... 3cdc22c302

Everything you described works as designed, I see no real problems.

[Helle]

Hy

I think Sticky and Edge are not good terms, notations

Sticky is a SR-FlipFlop, a Set-Reset FlipFlop, opentx-German SRFF
at V1 Set Parameter
at V2 Reset Parameter
if V1 and V2 same Parameter then its a Toggle FlipFlop (On, Off, On, Off ...)

Edge is a short Impuls, (about 10ms), opentx-German Puls
V1 Parameter
V2 Timing

1,0 infinte V1 at least 1sec be on then a short Puls is one time aktiv
0,0 0,8 V1 less then 0,8 sec on then a short Puls is one time aktiv
0,5 2,0 V1 betwean 0,5 an 2,0 sec on then a short Puls is one time aktiv


the AND-Switch is a enable-funktion
duration has a priority
delay has not

For Germans:
Take the German Manual about 290pages
viewtopic.php?f=92&t=3563&p=85090&hilit ... ual#p85090
at the end

Helle

[davx]

Yes I agree, FlipFlop and Pulse would be really more explanatory.

[Spainman]

Thank you guys!

@Dinamich:
I know the description at rc-soar - not complete and even misleading for 'edge' in my opinion. Good to know that the priorities are intentionally the way they are.
How can I get the fixed 2.0.8 Version (matching the tx fw. version) of Companion? Do I need to compile it myself from the source ? Is there a branch for 2.0.8 including fixes like this one or are fixes accumulated till the next release? I saw a post regarding nightly builds but don't know if that is for the current status of the next release only. It might be a stupid question but I'm quite new to the project...

@Helle:
Is the german documentation more complete?

I actually prefer English for technical stuff but in case of OpenTx I'm struggling to find documentation at all when things go into details. For example Lua _function scripts_: the other types are documented but function scripts are only mentioned without details on restrictions and input/output, entry points etc. Instead of detailing all functions on a minimum, essential depth certain aspects are documented beyond full extend and others are simply unmentioned. The documentation seems pretty mainstream-targeted. An additional reference sheet with short, complete and accurate notes would be great (similar to an API-documentation).

I'm really not complaining - I love the project and will just download the source sooner or later to answer my own question based on the implementation details. Just take it as an impression from a new user that really wants to explore the available features in detail.

Regarding 'edge' I assume it is named this way based on the input and not the output. The input needs to transition from 1 to 0, after the initial 0 to 1 change within the specified time interval. So the 1->0 edge of V1 triggers LN constrained by the V2 interval. The case where the interval is [t0; infinity] seems to be special - in this case LN is triggered when V1 is 1 for a minimum time t0, as soon as t0-time has passed and not on the 1->0 edge. I would have expected that triggers on the V1 1->0 transition if V1 was 1 for a minimum time amount of t0.
Special case or a bug? Infinity is just another number, why is it treated differently?


EDIT regarding sticky once again:
V1 doesn't set the sr-flipflop if it was reset by 'Duration'.
- so LN has actually three states: FALSE, TRUE and FALSE_BY_DURATION
- V1/set is ignored in the _invisible_ FALSE_BY_DURATION state
- additionally there is the 'AND' field that acts as a third reset but leaves LN in the setable FALSE state

This seems _really_ crooked! Only a reset by 'Duration' causes the strange behaviour. Please confirm that this is really, really, really (+ 100x really) the intended behaviour.
If it is, I would really appreciate if you could help me understand what the purpose of this behaviour is.
A fliplop whose 'set-ability' is dependent on the reset-reason and not on it's current value goes beyond my imagination of possible use cases.

[Kilrah]

are fixes accumulated till the next release?

That.
https://github.com/opentx/opentx/issues ... +is%3Aopen
2.0.10 will be released when those are closed. Nightly builds were only available during the beta test phase of the version 2.0.

For example Lua _function scripts_: the other types are documented but function scripts are only mentioned without details on restrictions and input/output, entry points etc.

Function scripts were added after other types, and after the existing documentation was written. The doc as usual lags behind, and simply hasn't been updated yet.

Regarding 'edge' I assume it is named this way based on the input and not the output.

The idea between the name was that a matching input condition would create a "rising edge" on the output. Was mainly chosen via "find me a 4-character name for that function in 2 minutes".
It's "if input is ON for a duration that is in the specified interval, create an ON state that only lasts a single cycle".

This seems _really_ crooked! Only a reset by 'Duration' causes the strange behaviour. Please confirm that this is really, really, really (+ 100x really) the intended behaviour.

Yes. Duration is "minimum time the output is ON". It only acts on the ON state.

Duration/delay is a separate block AFTER the LS, and always works the same way regardless of the type of LS. It has no idea what is upstream.

[Spainman]

....

Thank you for all the details!

Yes. Duration is "minimum time the output is ON". It only acts on the ON state.
Duration/delay is a separate block AFTER the LS, and always works the same way regardless of the type of LS. It has no idea what is upstream.

Sorry for going into a discussion, but you only described why the 'duration' block isn't responsible for the behaviour. I agree with that, but still I consider it a bug in 'sticky' and not a feature or normal behaviour:
When the state is OFF the trigger V1 should cause a transition to ON, no matter what. The sticky block operates on the LS value but doesn't seem to evaluate the SET/RESET (V1/V2) signals based on the LS value but on something else.

I assume that 'sticky'
- stops listening to V1 and starts listening to V2 when it detects V1, and
- stops listening to V2 and starts listening to V1 when it detects V2.
So it ignores that there are external influences that can manipulate its value.
It should always listen to V1 and V2, evaluate its current value in combination with the received signal and flip accordingly.

Really, think of it as a user and not as one of the developers - What is a possible use case that could make use of the current behaviour?

[Kilrah]

As said the LS "logic" and the "duration" blocks are independent and are not aware of each other. So if duration quenches the output low, then the logic doesn't know about it and the signal between the 2 stays ON, and needs to be turned OFF before the "duration" block will accept a transition again.

This is not necessarily an intended behavior, but simply a result of how things have always been way before Edge and Sticky were added.
Nobody has reported that to be a problem so far, and I doubt using Sticky with a duration actually has many real-world uses in the first place. So there were 2 ways to do it, both making sense in terms of logic depending on how you considered them, but no envisioned application... so just implement it the simplest way.

Give us a real world example where you want to use this and it doesn't work as required, and we may change things... But without that keeping current behavior in order not to break existing setups has priority.

[Spainman]

...I doubt using Sticky with a duration actually has many real-world uses in the first place...

Considering that the duration period can't be interrupted, I agree. Maybe duration shouldn't be available with sticky anyway like the n/a delay on edge.

I might have been overestimating the consistency of the provided functions. From a users stand point an LS has one line with options, including duration, so it is perceived as one object and not as several independent blocks that don't cooperate and can leave each other in an inconsistent state.

To me it was an rs-flipflop with one set input option 'V1' and three reset inputs 'V2', 'AND' and 'Duration'. Still using the last reset option did break the flipflop. Not so great... but at least I know why it happens now.

Thank you for taking your time for the clarifications!!!

[Kilrah]

Same with AND, it's like an AND gate AFTER the LS.

Sent via mobile

[Spainman]

Same with AND, it's like an AND gate AFTER the LS.

Nope! When AND goes 0 the LS turns 0 and can be set with V1 again without a V2 signal in between. Just tested on 2.0.8 on the transmitter to be sure.... only 'Duration' leads to the inconsistent state

[Kilrah]

Then something is wrong - but to me it's the AND handling.

[Spainman]

Well... doesn't seem to make much sense to continue discussing this. Dead end...
Take care

Edit:
I tried reading the documentation on logical switches again to make my own notes summing up your information, my results and what is written in the document. The documentation is really confusing and even plain wrong in parts (page 20):

"...Duration parameter (the minimum time a custom switch will be active for even if its conditions become false instantly)..."
- Missleading and incomplete, it's also the maximum time the switch will stay on. LS turns off by itself when duration has passed.

"...and a delay parameter (that affects both activation and deactivation)..."
- Wrong, only activation is delayed, deactivation happens immediately when the Operation returns false


"An extra AND condition (if selected, must be on for the custom switch to become active)"
- Unclear and misleading, "must be on to become active" sounds as if the AND condition is only checked during activation. Your information is that it is an additional condition on top of the operation result. In case off sticky it is something in between because it affects the operation....

So is the documentation correct and just incomplete or is the implementation wrong? To me this is all a mess and it does not really build confidence in using these functionalities for anything beyond a paper plane....

What is the evaluation order by the way? I assume strictly top down. So can LSn depend on LSn-1, or is that a false assumption?

[Spainman]

I doubt using Sticky with a duration actually has many real-world uses in the first place.

Me again - sorry
I'm creating a startup sequence for an esc (bl-heli firmware in gorvernor arm mode) and 'sticky' is used with 'duration'. It's not a synthetic use case but real. I can detail the whole sequence if needed but basically one of the things I use is a delayed pulse with a defined length that is triggered itself by another LS that is implemented with 'edge'.

L1, Edge, SH_down, [1.3, 1.7], !L3, --, --
- triggers the startup sequence when SH is held for round about 1.5s and then released

....other Ls....

L4, Stcky, L1, synthetic_reset_as_workaround, --, 0.5, 0.5
- generates a pulse of 0.5s length after a delay of 0.5s length

Of course L4 works only every second time if not reset manually. I work around that but it's ugly to have to.

I think:
- 'AND' should never (like you said yourself) have an influence beyond the evaluation. If the the sticky switch was triggered once and then AND changes between 0 and 1 the result should change the same between 0 and 1. It should not act similar to V2. At least AND should be fixed. This is clearly not in line with the way AND works on the other available functions.

- Having 'Duration' alter the state of the flipflop would be useful for example for the timed pulse explained above. I think it would be reasonable to have a timed self deactivation without impeding the next activation. It would add usefulness and open possibilities without having to work around the strange reset-twice effect, but I know that we two disagree on this...

[Kilrah]

So is the documentation correct and just incomplete or is the implementation wrong?

I don't know what documentation you looked at, but if it's the official OpenTX doc it has not been updated for 2.0 yet, so Edge, Sticky and sequence-governed types in general did not exist, LSs were always "straight" and no such issue existed. So it is correct, for the version it applies to.

2.0 is still not considered "stable", if you want to use it you're still pretty much on your own, you basically have to find out about things yourself, and as it's still a moving target things you find out might still change.

I have called for a developer review of how this works to see if everything was intended or not, don't remember all of it. But I doubt anything will change simply because now there are too many 2.0 users out there for whom we'd like to avoid changes. People have now had 6 months to comment on it and nobody has, they've adopted it as it is. Or never used it. But it had never been considered "wrong" yet.

[bertrand35]

I just commented this issue, I vote for 2 changes. Please review the comments here:
https://github.com/opentx/opentx/issues/1646

[Spainman]

I don't know what documentation you looked at, but if it's the official OpenTX doc it has not been updated for 2.0 yet, so Edge, Sticky and sequence-governed types in general did not exist, LSs were always "straight" and no such issue existed. So it is correct, for the version it applies to.

The things I pointed out regarding the documentation are independent of Edge and Sticky. It is about Duration, Delay and AND in general - please see my post again.
I referred to the english version of the OpenTx for Taranis (http://www.open-tx.org/2013/08/22/opent ... -manual-en). The "Differences Between OpenTX r2470 and 2.0"-Document doesn't list any changes on these parameters, so I assume that the behaviour did not change and that the documentation is not accurate.

As said before - I would be willing to help in straightening this part of the documentation if the descriptions are really wrong.

I'm sorry if I stepped on anybodys feet by saying that this or that is 'wrong'. Not my intention! It's just the way it looks to me if something is documented to do 'this' and instead does 'that' and even your personal explanations on how some things are supposed to work don't match with what the transmitter is doing. Really no offence meant!!!

I just commented this issue, I vote for 2 changes. Please review the comments here:
https://github.com/opentx/opentx/issues/1646

Thank you guys for looking at it! You don't mention the effect of 'AND' parameter on 'Sticky'. It would be great if you could discuss that too:

From Kilrahs explanations AND should behave for all operation types as

LS_value = operation(V1,V2) && AND_value

for sticky it does instead

LS_value = (sticky (V1, V2) &&= AND_value)

so it actually resets the flipflop when AND is 0 instead of just returning the and-combination.

[Kilrah]

I referred to the english version of the OpenTx for Taranis (http://www.open-tx.org/2013/08/22/opent ... -manual-en). The "Differences Between OpenTX r2470 and 2.0"-Document doesn't list any changes on these parameters, so I assume that the behaviour did not change

The "Differences Between OpenTX r2470 and 2.0" Document was never finished and never went further than where it's at now in the order of the screens.

BTW, you might want to answer on the github issue, Bertrand probably won't see your posts here.

[Spainman]

So does that mean that the effect of Duration, AND and Delay actually has changed in 2.0? Then I misunderstood you. Thought that the functionality of these parameters was cast in stone long before.

I looked at github, I thought that commenting is restricted to the members of the project. Will do. Thank you.

[dinamich]

So does that mean that the effect of Duration, AND and Delay actually has changed in 2.0? Then I misunderstood you. Thought that the functionality of these parameters was cast in stone long before.

Yes it changed, here is a link to the issue https://github.com/opentx/opentx/issues ... t-43725312 (again)

[Spainman]

Yes it changed, here is a link to the issue https://github.com/opentx/opentx/issues ... t-43725312 (again)

Right, sorry - missed noticing the link you provided previously.

[Spainman]

Just in case somebody stumbles across this thread looking for information on edge and sticky:
Tested the current nightly build of 2.0.10. It adds functionality and consistency to edge and aligns the behaviour of sticky in combination with Duration and AND. (Thank you Bertrand!)

Details are commented here at https://github.com/opentx/opentx/issues/1646

[Awap]

Thanks for poining out.
I noticed changed Edge behavior.
I'll have to review and correct my models, no big thing.

Just in case somebody stumbles across this thread looking for information on edge and sticky:
Tested the current nightly build of 2.0.10. It adds functionality and consistency to edge and aligns the behaviour of sticky in combination with Duration and AND. (Thank you Bertrand!)

Details are commented here at https://github.com/opentx/opentx/issues/1646