Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
[deleted comment]
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:
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
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
Sounds good to me. Carry on. :-D
Original comment by gru...@gmail.com
on 3 Jan 2012 at 5:13
What about this screen?
Original comment by bson...@gmail.com
on 3 Jan 2012 at 6:27
Attachments:
Original comment by bson...@gmail.com
on 3 Jan 2012 at 6:41
fantastic !!!
Original comment by gbir...@gmail.com
on 3 Jan 2012 at 7:06
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
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
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
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
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
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
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
@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
@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
Original issue reported on code.google.com by
gbir...@gmail.com
on 7 Dec 2011 at 3:19