All Switches and Channels on display

[GoogleCodeExporter]

It will be very helpful to have on LCD display some screen with all switches 
state (on/off). Especially the SW1-C and Feature switches.

Secondly when we are making mixes on upper channels (ch9-16) it will be helpful 
to have also LCD screen with channel bars.

Thanks.

Original issue reported on code.google.com by gbir...@gmail.com on 7 Dec 2011 at 3:19

[GoogleCodeExporter]

Switches are available on main view. On 3 alternate screens accessible via 
left/right key

Original comment by bson...@gmail.com on 8 Dec 2011 at 2:07

• Changed state: Accepted

[GoogleCodeExporter]

Yes alternate switches screens are working in open9x. Unfortunately not in G9x.
BTW: some explanation of differences, ideas between Open9x, Gruvin9x 
trunk/branches, will be helpful to chose favorite firmware?

Original comment by gbir...@gmail.com on 8 Dec 2011 at 4:10

[GoogleCodeExporter]

There is very little difference between gruvin9x (trunk) and open9x. You will 
find in open9x the features that Bryan doesn't want in gruvin9x, and which I 
need or want on my own radio. I keep trying minimizing these differences which 
today are:
- unstable bandgap (which unfortunately my radio returns): different averaging 
for no flicker on the main voltage display
- telemetry with FrSky: I prefer offsets and max values using the unit (Volts / 
Amp / km/h) of the telemetry output, not the maxV thing which at the field has 
no sense to me

I suggest you fly with the gruvin9x-frsky branch, not open9x, not 
gruvin9x-trunk, which keep changing everyday and as a consequence are not 
stable!

Original comment by bson...@gmail.com on 8 Dec 2011 at 4:24

[GoogleCodeExporter]

Now SW1-SWC are correctly displayed in alternate views on both trunk and frsky 
branches.

For function switches and CH9-CH16, yes I think it's a very good idea, I add it 
on my plate, but it will be only in trunk (new feature).

Original comment by bson...@gmail.com on 8 Dec 2011 at 6:52

• Changed state: Started
• Added labels: Milestone-darktrain

[GoogleCodeExporter]

I need an idea here for CH9-CH16: how is it possible to know which channels we 
are watching?

Original comment by bson...@gmail.com on 2 Jan 2012 at 11:06

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

maybe on screen for SW1-SW6 eight bars like for P1-P3, to have new different 
look for ch9-16. and also switch ID0-2
the information about sticks and pot positions are irrelevant on three screens.

Original comment by gbir...@gmail.com on 2 Jan 2012 at 11:45

Attachments:

• screenshot-5.png

[GoogleCodeExporter]

Yes, vertically, it seems to me a good idea for virtual channels. But in this 
case it means that we will have 1 screen for physical inputs (sticks, pots, 
switches) and 2 screens for virtual inputs (virtual switches, virtual channels).

But at the moment I would prefer that ID0-ID2 is in the physical inputs screen. 
Perhaps in place of "TRN", we could write "ID0" or "ID1" or "ID2", and it is 
writen in white on black when TRN is pressed.

Or perhaps another screen for physical inputs with ID0, ID1, ID2 in the left 
column and trims numeric values in the remaining space?

Original comment by bson...@gmail.com on 2 Jan 2012 at 1:54

[GoogleCodeExporter]

I agree with two screen idea, first physical with ID012/TRN and second virtual 
with CH9-16 and SW1-C

for space reduction it is possible to use virtual Switches like this:
SW147A
SW258B and CH9-16 bars
SW369C  

nice idea physical/virtual screens :) and it will be only on two screens!

Original comment by gbir...@gmail.com on 2 Jan 2012 at 3:52

[GoogleCodeExporter]

Sounds good to me. Carry on. :-D

Original comment by gru...@gmail.com on 3 Jan 2012 at 5:13

[GoogleCodeExporter]

What about this screen?

Original comment by bson...@gmail.com on 3 Jan 2012 at 6:27

Attachments:

• screenshot-1.png

[GoogleCodeExporter]

Original comment by bson...@gmail.com on 3 Jan 2012 at 6:41

• Changed state: Fixed

[GoogleCodeExporter]

fantastic !!!

Original comment by gbir...@gmail.com on 3 Jan 2012 at 7:06

[GoogleCodeExporter]

Sorry for this comment which I wrote too fast:

- telemetry with FrSky: I prefer offsets and max values using the unit (Volts / 
Amp / km/h) of the telemetry output, not the maxV thing which at the field has 
no sense to me

It DOES make sense to me. I understand it perfectly and I am convinced that it 
will work. But I prefer the way I designed it originally in er9x, using a MAX 
and an OFFSET which are defined using the chosen unit (km/h, Amp, RPMs...).

Bertrand.

Original comment by bson...@gmail.com on 6 Jan 2012 at 10:42

[GoogleCodeExporter]

I'm so sorry. But you do not appear to understand it at all, based on your last 
commnent.

Where is your method -- your mechanism -- for calibration? Completely absent, 
so far as I can see.

Original comment by gru...@gmail.com on 8 Jan 2012 at 3:40

[GoogleCodeExporter]

Yes, there is a calibration. As soon as you have 2 points (given here by OFS 
and MAX) it's possible to draw any linear curve. 

Original comment by bson...@gmail.com on 8 Jan 2012 at 8:53

[GoogleCodeExporter]

Eh?? OK .. I'll give you a a real life example and you tell me how to calibrate 
it.

You have an air speed sensor that output a voltage from 0V to 3.30V over the 
range of velocities 0 Km/h to 25.5 Km/h, where 3.30V output from the sensor = 
25.5Km/h air speed.

You connect this to the D8R receiver's A1 port. 

Now, the internal reference voltage inside the D8R's ADC circuitry is supposed 
to be 3.30V. But it isn't. It's some other value, in the range 2.25 to 3.36V -- 
but you have no way to measure that voltage.

So then, how do you calibrate the firmware to display the correct Km/h, even 
though he voltage reference is incorrect by some unknown amount.

There is an added restriction, which is that you have no wind tunnel or 
physical equipment to measure air-speed other than the sensor supplied. You can 
only trust that the voltages it supplies are what were stated. (This is the 
most likely real-world scenario.)

So HOW?

Original comment by gru...@gmail.com on 8 Jan 2012 at 10:16

[GoogleCodeExporter]

Ok I will play this game as soon as possible :)
I can't promise today though.

Original comment by bson...@gmail.com on 9 Jan 2012 at 8:55

[GoogleCodeExporter]

Bryan, does it exist any solution to your question? We only know that 
everything is incorrect and we have no way to calibrate it!

The simple answer from the "average joe" I am would be: if you want to 
calibrate volts, you need a voltmeter, if you want to calibrate RPMs, you need 
a tachimeter, if you want to calibrate a speed, you need the special gun we 
have at the field.

Am I straight in my head?

Original comment by bson...@gmail.com on 9 Jan 2012 at 10:24

[GoogleCodeExporter]

May I play this game too ? (as I already played it)
I have calibrated my eagletree Pitot tube using my car.
The Pitot was fixed on a tube 1.5 mt long, standing above the car roof to avoid 
air turbulence.
In an not windy day, on a straight street my wife compared Pitot measured speed 
with GPS and tachometer measured speeds. There was a difference of about 10% at 
60Km/H
It was funny to have such a tube over the car roof but it worked quite well.
0Km/H point instead was already good by itself as (I suppose) the eagletree 
sensor calculates offset internally. 
Anyway as long the sensor has a linear response, to calibrate it you need two 
parameters, one for OFFSET and one for SCALING. 
If the sensor has not linear response then you need a mapping curve but that's 
much more complex.

Romolo

PS: For a proper scientific approach, the calibration done is obviously valid 
only with the given length of silicon tubes from the Pitot to air speed sensor.

Original comment by romolo.m...@gmail.com on 9 Jan 2012 at 11:36

[GoogleCodeExporter]

@bsongis -- yes there is an answer, of course there is. :-D But I only asked 
the question in the first instance as another means of trying to communicate 
what I've been trying to say since the start. "A method of calibration is 
needed." The current "MaxV" thing DOES provide this method, when it is 
understood. But clearly, it is too hard to understand.

So, Cam and I have been discussing a new method of handling the situation such 
that your desires are also included. Of most important note, Cam made me 
realise that (electrical) calibration should be done on a per-model basis -- 
not per channel. I believe he is ready to share our most recent ideas with you 
and may have done so by now in private email.

Original comment by gru...@gmail.com on 9 Jan 2012 at 11:38

[GoogleCodeExporter]

@romolo -- that must have been fun. You did not mention whether you were 
calibrating the final result on the '9X screen or calibrating the output 
voltage on a multimeter only. (Personally, I'd have opted for the latter.)

Anyway ... I'm not clear how this topic wound up in this thread about on-screen 
switches. (Probably my fault.) Let's continue it in the discussion group or in 
private emails from here.

Original comment by gru...@gmail.com on 9 Jan 2012 at 11:41