A couple of suggestions

[Romolo]

FYI
Splash can be changed also at flash time using the tool provided by companion
And it can be any image type...

[bertrand35]

On Windows? Here:
http://www.icewalkers.com/Linux/Softwar ... /PyQt.html
Bertrand.

[ReSt]

Thanks for the tips,

I found the QT4 package for python2.7 and installed it.
It still didn't run. Did not find 'python'

Found that the system path variable had the path added to '...Python27\lib\site-packages\PyQt4' but not to '..\Python27;'

Added the path to the variable and now it's working

Thanks,
Reinhard

[ReSt]

My simple open9x splash screen

simple open9x screen

and as xbm file

[bertrand35]

Congratulations
Bertrand.

[sporez]

Has the Altitude source option been included yet? I seem not to find where to change it to use the GPS data.

[bertrand35]

GAlt is the one from the GPS.
It has been added very recently yes.
Bertrand.

[sporez]

Ahh found it! thanks.

[Orphee]

Hi,

Is it possible to always have sound for the trim buttons even in nokey mode ?
I think it is usefull when the plane is in flight to have an audio return to know button works.
same idea for haptic... ?

Thank you

Edit : Got the answer from Bertrand, thank you

[ShowMaster]

Can open9x on both the stock 9x and Sky9x boards set the tone, type and haptic values for the red, yellow, and orange alarms in the menue that refers to Frsky alarms?
Er9x allows this to be done.
I know all the various firmwares are being reworked all the time so this may be there and I've missed it, or it will be added soon?
Each FW has its good and not quite as good options and I keep trying them all to see what's best for my applications. Mostly telemetry with and without the hub.
SM

[cre8tiveleo]

My simple open9x splash screen
and as xbm file

That looks familiar... hmmm....

[bertrand35]

@showmaster:

I wrote an example here for Rob:
viewtopic.php?f=45&t=708

I could even add an example if needed: imagine you have a double alimentation and you want one alarm when one battery is bad and another alarm when the 2 batteries are bad. That's flexible

Bertrand.

[bertrand35]

Next ideas by Cam...

Ability to reverse sticks inputs.
Reason: This can make it quicker to alter copied model memories to suit a new model. For instance a copied model memory needs ailerons reversed for a new model, instead of reversing all mixers with aileron you can just reverse the aileron stick.

Ability to disable throttle warning on a per model basis.
Reason: I don't need the warning when the throttle stick is used for butterfly/crow brakes.

When setting custom switches, SWx labels inverts if the switch is active.
Reason: This stops you having to switch between this menu and the main switch view when setting switching points for pot source switches.

In telemetry menu A1 and A2 values after all the maths display.
Reason: This stops you having to switch between telemetry menu and main
telemetry view when trying to calibrate your battery voltage.

[Kilrah]

Mostly makes sense, just not sure about the first one. I don't see why you'd need to reverse the input. If the model is different (other servos or linkages) it's the servos you'd want to invert in the LIMITS screen, not the input. The logic/calculations are the same, right aileron should still act on mixes in the same way etc, only output mapping should change.

Just like with a delta mix, the easiest is to think about logic first, i.e. set CH1 to +50% ELE and CH2 to +50% ELE (elevator should act on the same direction for both), add +50% AIL to CH1 and -50% AIL to CH2 (they have to work in opposite directions), then invert one servo if your physical setup requires it instead of messing with the logic and start putting '-'s in the mixers and getting confused (I know I was on the Futaba, the polarities never made sense so I was always trying combinations of servo reverse and mixer polarities).

I think all inverted inputs would bring is confusion... if you get the logic right in the first place there's no reason to invert the inputs.

[Romolo]

I also agree on all them but the first,
The latter ones bring clarity and usability, not sure about the first...

[bertrand35]

Also inverting the sources means inverting all lines related to the channels in the EXPO menu. Sometimes if you have many expo settings depending on Phases or Switches, it's not so quick!
Bertrand.

EDIT: all other ideas now commited on svn, ready for testing before next release

[th9xer]

The first idea comes from a feature that exists on the Multiplex Evo and a real need that I had the other day. Multiplex class Dual Rates, Expo, and reverse under the banner of stick calibration. It is separate to servo calibration (which also exists).

Imagine you have an aircraft with a four surface delta wing, you program it wrong on the bench (or copy it from another setup), ailerons are reversed, elevator is correct. Now you have to reverse the aileron input on four mixers. (If you start reversing servos then you have that job to do and mixers to reverse as well). If you can reverse the aileron stick you only have one operation to do, it easy and intuitive.

(elevator should act on the same direction for both)

What if you have some servos in the other way up ? What if you can't even fit them in to allow this.

then invert one servo if your physical setup requires it instead of messing with the logic

No, I want the freedom to do it whatever way I wish. What if it's a 2nd hand model and the servos are already fitted.

I know this is only a little detail but none the less it is one I found useful on my Evo.

This leads me on to another feature that the Evo has that would make changing the direction of many mixers easy, a single press method to change the sign of a value (any value). So you could hover over -80 and quickly change it to +80.

Food for thought.

Cam.

[Rob Thomson]

Changing the mix direction 'is easy'.

Simply press and hold the + and - at the same time. Instant inversion of the number

Rob

[Kilrah]

(elevator should act on the same direction for both)

What if you have some servos in the other way up ? What if you can't even fit them in to allow this.

I'm takling about the logic and the expected result. On your airplane you want that when you pull the elevator stick both surfaces go up. So you mix both elevators with the same sign. You want the ailerons to act opposed to each other, so you use opposing signs. At this point you do not care about how the servos are installed, you just think of how the controls should work.
If you think of that first, then you do not program it wrong on the bench

then invert one servo if your physical setup requires it instead of messing with the logic

No, I want the freedom to do it whatever way I wish. What if it's a 2nd hand model and the servos are already fitted.

I'm not talking of inverting the servo physically, as in taking the model apart - but just of setting that channel to INV on the limits screen (= invert the servo direction)

Once you've set the logic right like I mentioned above, then all you have to do after setting the mixes is power up the plane, pull your elevator, and invert (still in the limits screen ) the servo(s) that go in the wrong direction.

Changing the mix direction 'is easy'.
Simply press and hold the + and - at the same time. Instant inversion of the number

Didn't know about that, awesome

[Kilrah]

Changing the mix direction 'is easy'.
Simply press and hold the + and - at the same time. Instant inversion of the number

Didn't know about that, awesome

Hmm now I see that, I also see something else... in the LIMITS screen when editing an offset value if you exit edit mode with MENU LONG it takes the current position as offset
Which bring 2 more suggestions:
- Easy RESET of any editable field to 0: with up/down simultaneously, or with EXIT?
- Same MENU long thing to set the end points, of course changing the one that corresponds to the direction the channel is currently to

[gbirkus]

An example of Channel value 2 Offset was here: http://code.google.com/p/open9x/wiki/Open9xFeatures

[MikeB]

Please see viewtopic.php?f=7&t=40&start=90#p11171 for a suggestion to handle the ARM board processing in a better way for future enhancements.

Mike.

[bertrand35]

The interrupt approach as described by Kilrah seems to me nice and super simple. I will give it a try in a separate branch of open9x.
Bertrand.

[th9xer]

Kilrah: OK I understand the distinction you were making and this is what I would normally do if going from scratch, but the other day I found myself in a hurry so I copied a model over, ailerons needed reversing, went straight for the "reverse the stick feature", it wasn't there so instead had to take more time than I had to do it as you suggest.

Rob: I tried every combination I could think of before posting, but obviously not that one, oopsy. I was convinced I had used it before to.

Cam.

[MikeB]

The interrupt approach as described by Kilrah seems to me nice and super simple. I will give it a try in a separate branch of open9x.
Bertrand.

Couple of things to watch out for.
1. getEvent() is called,and the result is first passed to checkTrim(). The return value from this is then passed to the menu handler. checkTrim will be in the interrupt, and the menu handler will not. I'm thinking we might need a specific getTrimEvent() routine, and the normal getTrim() routine returns all events except trim events.
2. On the ARM board, the 6 main keys (menu etc.) share the lcd data signals. These signals are normally left as inputs, but 'turned round' to be ouputs while writing to the lcd. There will be a problem if the interrupt then occurs while writing to the lcd. My idea for this is for refreshDisplay() to call readKeys() at the start, store the result in a global variable, then set a global flag to indicate it is running. At the end, it clears the flag. readKeys() actually checks this flag, and if it is set simply returns the stored value. This works, I have tested a version of it when investigating how to add an external sound unit to er9x, and trying to use trim switch inputs as outputs as well.

Mike.

[jhsa]

hhmmm, external sound unit.. me like it.. hhmmm beer..

[Kilrah]

- the stock board, it will be difficult, unless the hardware gurus find a solution to have a SOMO-14D connected to the 64A?

I've just had a look at this one.

The SOMO-14D needs 3 pins to the MCU, a clock pin, a data pin, and the busy signal.
Assuming someone has already made the frsky and haptic mods, and thus uses the 3 relevant pins, we still have 2 free pins (35/PC0 and 17/PB7). BUT, now that we have the ability to generate PPM from the PPM_IN port (the whole PPMSIM deal), we do not need the 4066 anymore. We could thus cut the trace that goes to it, tie the 4066's input permanently to the level it needs to be at, and regain the SIMCONTROL pin (19/PG4).

Pretty easy mod to do, and jhsa would be happy (except maybe for the price of the SOMO )

[jhsa]

lool yeah, it's a bit expensive.. I wonder if there is another cheaper module that need the same connections
If not I guess that would have to do..

[jhsa]

Wait a second.. doesn't pin 17 control the backlight??

EDIT: Yep, just confirmed. it's the backlight.. can't use that one

[Kilrah]

Who would notice if the backlight flickers for a couple of ms when a sound play is initiated (pin 17 = data)?

Just leave your BL on anyway, what's 15mA