Proposed change to main page channel display

More
12 Mar 2015 02:21 #29582 by hexfet
This change fixes the problem described in this post . The current proposed diff is here , but may be further changes based on this discussion. Three items to consider...

This change has a side effect that seems beneficial to me but would like to know if the current behavior has a reason. Currently values of the real output channels (CH1-CHxx) displayed on the main page in boxes and bars are taken from the mixer output, but with only the safety limit applied (and scale for percentages). Why is this? These values may not be the same as the values used by the protocols, so don't necessarily reflect what's being sent to the aircraft. The proposed change displays the values used by the protocols, which have all limits applied.

Second, the mixer output (subject only to safety limit) is also used in timer.c, the safety dialog, and the safety check in protocol.c. Also for these cases it seems to me better to use the final channel values. I propose changing the calls to MIXER_GetChannel to MIXER_GetFinalChannel in these cases also (which eliminates all uses of GetChannel so it could be removed). Would there be any issues with that? For example, with this change if the student's PPM signal violates the safety check the safety dialog would be displayed.

Finally, MIXER_GetChannel calls MIXER_ApplyLimits, which has the side effect of updating channels with non-zero Speed settings. I think this is a bug because the code looks like it should only run every 5 msec. Updating with the main page refresh would introduce about 5% error for every place the channel is displayed (if I read the code right). Removing the call to MIXER_ApplyLimits eliminates this issue.

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 02:52 #29585 by PhracturedBlue
Replied by PhracturedBlue on topic Proposed change to main page channel display

hexfet wrote: This change has a side effect that seems beneficial to me but would like to know if the current behavior has a reason. Currently values of the real output channels (CH1-CHxx) displayed on the main page in boxes and bars are taken from the mixer output, but with only the safety limit applied (and scale for percentages). Why is this?

because thepurpose of the trims is to null-out servo offset, and so they don't represent intent (I set my rudder at 0 but there is a bit of left to it, so I trim it out and now the box shows -5 which isn't the intent).
You don't have to agree that this is a good solution, but you asked why, and now you know.

Second, the mixer output (subject only to safety limit) is also used in timer.c, the safety dialog, and the safety check in protocol.c.

The rationale is basically the same as above.

Finally, MIXER_GetChannel calls MIXER_ApplyLimits, which has the side effect of updating channels with non-zero Speed settings. I think this is a bug because the code looks like it should only run every 5 msec. Updating with the main page refresh would introduce about 5% error for every place the channel is displayed (if I read the code right). Removing the call to MIXER_ApplyLimits eliminates this issue.

That sounds like a bug (certainly the speed shouldn't be adjusted). I'm not sure what side-effects (if any) there would be to this change though. the flags passed to MIXER_GetChannel may not be the same in all contexts. Probably it would be safer to just move the speed check to update on a regular cadence instead.

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 03:30 #29586 by hexfet
No, perfect...now I understand. Makes sense to me. I ask because I haven't been in RC long enough to know.

Do you think the behavior described in the post (main screen channel values are not updated when PPM In is set to Channel) is worth fixing? GetChannel could replace the mixer output with ppmChannels like CalcChannels does, but not sure how that would affect its use for timers and safety. Would be nice if the instructor could see students values, but this is pretty expert set up and would probably be tested on the model anyway.

With your pointer on flags I looked more closely and there is no bug. The speed update only happens at the appropriate time.

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 04:11 #29588 by PhracturedBlue
Replied by PhracturedBlue on topic Proposed change to main page channel display

hexfet wrote: Do you think the behavior described in the post (main screen channel values are not updated when PPM In is set to Channel) is worth fixing?

Yes it seems like the main page should show the value passed through PPMIn if enabled

MIXER_GetChannel appears to be used in the following locations:
timer code for enabling the timer based on channel value
safety-check on startup
datalog reporting and datalog enable trigger
main-page display


the timer code, main-page, and datalog should each use the PPMIn value for their triggers. I guess the safety should too since the entire point is tomake sure you aren't sending a dangerous value to the model on startup.

That implies that the PPMIn application could be moved to GetChannel, and the '//5th step: apply limits' code could then call MIXER_GetChannel() to avoid code duplication.

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 15:52 #29601 by cmpang

hexfet wrote:
...Currently values of the real output channels (CH1-CHxx) displayed on the main page in boxes and bars are taken from the mixer output, but with only the safety limit applied (and scale for percentages). Why is this? These values may not be the same as the values used by the protocols, so don't necessarily reflect what's being sent to the aircraft. The proposed change displays the values used by the protocols, which have all limits applied.

...


I have been saying this for many many times in the past years and didn't get any response. It would be great if this silly display information can be corrected at last...

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 17:03 #29608 by PhracturedBlue
Replied by PhracturedBlue on topic Proposed change to main page channel display
That is because I don't think it is broken. That doesn't mean I'm right, but there are 2 sides to the question, and I haven't seen consensus on an answer.

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 17:12 #29611 by FDR
I think it is fine to see "normalized" values in all places in the tx except the actual output monitor.
The scaling (and trims) should only kick in at the very end before sending out the value.
Otherwise if you change the scale of an input, you would need to change all the mixing, the safety values, the failsafe values, etc...

Please Log in or Create an account to join the conversation.

More
12 Mar 2015 23:26 #29616 by hexfet
I've made the change suggested by PB. Pull request here .

Current behavior is unchanged except when PPM In is set to Channel and the trainer switch is ON. In this case the PPM input value will be used for:
  • main page display channel values
  • startup safety check
  • safety dialog display value
  • datalog enable
  • value logged in datalog
  • timer switch
  • timer reset switch

Please Log in or Create an account to join the conversation.

More
13 Mar 2015 01:15 #29620 by PhracturedBlue
Replied by PhracturedBlue on topic Proposed change to main page channel display
looks good. I merged it

Please Log in or Create an account to join the conversation.

Time to create page: 0.050 seconds
Powered by Kunena Forum