Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using gVar as offset wrong scaling (x7 radio) #4582

Closed
lshems opened this issue Mar 9, 2017 · 20 comments

Comments

Projects
None yet
4 participants
@lshems
Copy link

commented Mar 9, 2017

When using a Gvar as offset on a mixer line, the actual effect is only 10 % of the Gvar setting.

So on a mixer line, source max, weight 0, offset gVar1 with gVar set to -100, the output is -10.

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 9, 2017

So, only when using -gVar as offset this is not working correct.

gVar as offset with a negative value of gVar is working correct.

So must be in the - part of the gVar thing.

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 10, 2017

It was late yesterday. Correct issue:

Gvar 100

Source Max, weight 0, offset -gvar
Result -10 instead if -100

Source Max, weight 0, offset gvar
Result 100, as expected.

@3djc

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2017

image

image

I don't seem to be able to replicate, could you let me have your otx ?

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 10, 2017

Ah, you'r on RC11, I had returned to RC10, because the RC11 had some other issues bothering me. Forgot to test on RC11 as well.

So, it seems that it is fixed on RC11.

Thanks.

@kilrah kilrah closed this Mar 10, 2017

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 10, 2017

Could we reopen: tested on RC11, and got a similar result.

test otx attached.

just change the offset from -gv1 to gv1 and see the difference
2017-03-10 1
2017-03-10

testerror.zip

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 10, 2017

tested on taranis 2.2RC11, same issue. I have no clue what happens, since a new model with the same settings doesn't exhibit this behaviour; Only the attached OTX does this.

@kilrah

This comment has been minimized.

Copy link
Member

commented Mar 10, 2017

Weirdo... actually I'm sure I could reproduce your initial issue last night, but I was tired too, and this morning I couldn't.

Maybe improper init somewhere if it's "random"...

@kilrah kilrah reopened this Mar 10, 2017

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 10, 2017

Indeed.

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 10, 2017

remark that the gvar screen is showing only zero's !?

@kilrah

This comment has been minimized.

Copy link
Member

commented Mar 10, 2017

Hmm not here?`What flight mode do you have selected?

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 10, 2017

the screenshot does, no?

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 10, 2017

2017-03-10 2

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 10, 2017

2017-03-10 3

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 10, 2017

perhaps that screen is not functional yet, I don't know.

@kilrah

This comment has been minimized.

Copy link
Member

commented Mar 10, 2017

Indeed, didn't see it...

Open companion, open file, click simulate (on document) - values are shown correctly (but output is bad). Close simu, click simulate again, they're all 0.

@mpaperno, help? haven't followed storage evolution close enough, but seems like it could be related?

@mpaperno

This comment has been minimized.

Copy link
Member

commented Mar 11, 2017

Indeed, the Simulator Radio Outputs gvars not updating was a bug (fixed @ 0a5732b). Thanks for noticing :)

No clue on the problem of the actual gvars calculations in firmware... I can't keep track of the import/conversion routines either, if that's what you mean Andre. I guess first step is consistent repro case. Maybe @bsongis has some clues for us.

@kilrah

This comment has been minimized.

Copy link
Member

commented Mar 11, 2017

No I just meant the bug you fixed :)

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 14, 2017

Ok, found a reproducable action triggering the issue. It doesn't make sense at all:

in the attached file, there are two models, both having input1 with SA as source, gVAR1 having a value of 50, and mixer line 1 having source Max, weight 0 and offset GVAR1. mixer line 2 having source Max, weight 0 and offset -GVAR1.

When no switch warnings are active, the second mixer line produces -5, where it should have produced -50.
When activating switch warning for SB, the second mixer line is correctly showing -50.

Tell me whats happening ???

testerror (2).zip
2017-03-14 1
2017-03-14

@3djc 3djc self-assigned this Mar 15, 2017

@3djc 3djc added this to the OpenTX 2.2.0 milestone Mar 15, 2017

@3djc

This comment has been minimized.

Copy link
Contributor

commented Mar 15, 2017

I can reproduce that, will be looking at that today

@lshems

This comment has been minimized.

Copy link
Author

commented Mar 15, 2017

Thanks. It is a plane crashing one for my models after conversion from X9, if I wouldn't test properly before using it :).

3djc added a commit that referenced this issue Mar 15, 2017

bsongis added a commit that referenced this issue Mar 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.