openX9D

[mhotar]

Not convinced ... perhaps because I am too used to the original font!

As I expected Original font is not bad at all. It is up to individual taste.

For the bitmap, on simu you need to have .....

Thanks for explanation. I also had issue to set Timer2.

[bertrand35]

The new "Channels monitor" designed by Romolo does work in the simu!

snapshot_05.png (1.63 KiB) Viewed 10971 times

Bertrand.

[Rob Thomson]

Nice!

[bertrand35]

The "Switches view" designed by Kilrah now on simu

snapshot_01.png (2.39 KiB) Viewed 10946 times

Bertrand.

[Scott Page]

I like to see the progress and appreciate what you're doing so don't take what I say as criticism or personal. I'd like to see the area with the logo be a single telemetry value -- which is chosen on the telemetry setup page. It could be lowest cell, altitude, or whatever is the most relevant parameter for that model. I hate to say it this way -- but the logo area is a waste of valuable area in my opinion. However -- it belongs on the splash screen!

[Kilrah]

Well... there are some who say there's too much info, and some who say there's too little

We still have a 2nd voltage that's due there, and there's a 3rd available space with label if needed:

file.png (4.93 KiB) Viewed 10926 times

[Romolo]

I agree with Scott, that's why i proposed some post ago an alternate view..

[Kilrah]

Yep that view above with the custom switches could lose the logo and put something else there. That way the logo would only be on the main home screen with the sticks.

[mago]

little advice: since we are going to have a wide screen, please exploit every pointed word, i.e.:
"Ex.Limits" should became "Extended Limits".
We have space, let's use it

[Kilrah]

Yes it's planned, not the first priority though

[Scott Page]

Not necessarily more information -- but more efficient use of the area. Having a special icon or even a picture of the model is a good idea when choosing the specific model, but 5 seconds later that's wasted real estate. I believe the X9D may have a rotary encoder (I might be wrong) -- but having that model identification space coupled to the rotary encoder so that as it is turned just that section of the screen changes - from model ID to telemetry1, telemetry 2 telmetry 3, timer, etc. My problem as an older citizen who likes speed is that I can't take my eyes off the aircraft very long - so being able to look at the same space for the info I need would be sweeeeet. Now, coupled with voice as I roll through the encoder the voice could say; timer 1, timer 2, lowest cell, pack voltage, etc. so when I hear the parameter I want ... I glance down.

I'm completely cognizant that this is a coding challenge -- and something outside of the box -- but the magicians that have written the code to this point can do pretty much anything as near as I can tell.

[MikeB]

I would agree with the concept that data displayed while actually flying (e.g. telemetry, timer(s)) should be BIG, CLEAR and uncluttered.

Mike.

[Kilrah]

There's unfortunately no encoder. We were really wishing for one, but no...
There will be one (or more) directly accessible, entire screens dedicated to telemetry that can be customised (like now on the 9x). So you'll have no problem showing exactly what you want and where you want on these, you can of course duplicate the timers there and use only those screens in flight.

Now that we have multiple fonts we could even have several selectable sizes?

[jhsa]

There's unfortunately no encoder.

That's a very good reason for me not to buy this radio.. wife is happy now.. she just read what I wrote..
She's gone now........... so, the X12D has an encoder

[Kilrah]

Next idea, something I was frustrated that my very expensive brand-name radio didn't have: An "input summary" screen that lists the different uses of each input for the current model.

Search for occurrences of every input in all mixes, D/Rs, FPs, custom switches, custom functions and list them on a dedicated view. With the mixer / DR names (CS names would be welcome too BTW) it would be easy to quickly find what does what again on a model you haven't used after some time.

Something like:

Code: Select all

INPUT SUMMARY
Ail: CH1 Aileron (Mixer name here if present)
     CH5 Aileron2
Thr: CH3 (No mixer name was set here)
Rud: CH4
Ele: CH2 Elevator
P1: CH8 Camera
SW1: - DR1 Ail (number being order of the DR line for that channel, add name if present)
     ↓ DR2 Ail FP024  (if that DR is only active for these phases)
     !↑ DR1 Ele
     !↑ DR1 RUD
SW2: CH7 (SW2↑) Flaps
SW3: CH8 Camera mode
SW4: ↑ FP0
     - FP1 Landing
SW6: Trainer (custom function name)
SW7: Backlight
SW8: Safety CH3
CS1: v<ofs Vfas 10.8
CS2: v>ofs Curr 2 
CS3: AND CS1 CS2 Lowbat (custom switch name would be cool)
     Play Track "Alarm" (this is a custom function also assigned to CS3)

Ideally highlighting a DR line and pressing ENTER would send you directly to the DR screen with that relevant line selected, same with mixers, FPs, CSs and CFs.

This could probably be implemented on sky9x too.

[jhsa]

install the audio/voice and turn the switches on. They should tell you what they do

[Kilrah]

For single switches it would be OK, although you might for example toggle 5 of them for nothing if you had only used 3...

But switches can be ANDed or ORed together, and thus combinations needed to activate something would be pretty much impossible to find just by trying (especially with 8 switches, of which 7 are 3 positions). Also my telemetry alarm example can't be just triggered like that. There you have the advantage of combining a summary of all screens in one, instead of for example having to go to the custom functions screen, see CS3 plays a track, but then having to go to the custom switches screen to see what actually triggers it, then you see it's CH6 but you have to go to the mixer screen to see what CH6 is,...

It's already simpler on open9x than on most commercial radios, but still...
On the Futabas where you have like 15 predefined mixes, after a year of not using a model you basically had to spend an hour to enter the menu for every mix one after the other to see if you had used it or not and how to understand your programming again. On the T14MZ with a 640x240 color screen, they could really have done something like this that shows you what mixes are being used and what input does what, with maybe a way to directly jump to said setting from there.

[Rob Thomson]

Love the idea of this screen

[bertrand35]

Indeed. Let's wait that the "main" functions work, and I will spend some time on it ...
Now the switches work on simu, just press keys A-H and you will see the switches move on the screen!
Bertrand.

[bertrand35]

Calibration screen for the 4 sticks and 4 sliders ...

snapshot_02.png (1.25 KiB) Viewed 10708 times

Yes, the backlight is blue for a better simulation in the dark

Bertrand.

[Scott Page]

One thing I'd like to see in the X9D flavor of Open9x --- in fact I'd like to see it in the sky9x flavor as well, is a separate tab for assigning tracks and or sounds and or haptic. I've completely used up my custom functions tab with basic sounds and I'm really not even started yet.

You can see that Iv'e barely started to touch the custom switches options - but I'm out of slots for assigning sounds. I'd like to use the throttle trim to start and stop background music, and so forth.

Don't let this sound like complaint. It's not. I think the sound feature -- especially for telemetry - is incredible. Beyond that I've found that it helps having the "co pilot" confirm that I just hit the correct switch. the "copilot" also gives me a complete rundown of all switches at the initiation of the selecting the model. I would also like to have a function i can assign to a switch that will truncate all pending sounds ... so if there are a series of sounds in the cue - only the next sound trigger will and following.. will be heard.

Just some thoughts from my dream world.

[Kilrah]

Bertrand has started implementing my suggestion. This will already get rid of at least half of your FSWs.

[Rob Thomson]

Bertrand has started implementing my suggestion. This will already get rid of at least half of your FSWs.

You know what will be needed...

When you create a model.. auto create the folder.

When you rename the model.. auto rename the folder.

Make sense?

[Romolo]

No, I would not prefer to auto rename folders, as you may have two models with the same name,
And also autocreate folders, makes little sense as maybe they will stay empty forever

[Rob Thomson]

What happens if you have two with the same name? Using the same folder does not make sense then?

Not that it is a major issue

[Romolo]

What happens if you have two with the same name? Using the same folder does not make sense then?

Not that it is a major issue

Not if you rename...
This is the scenario MODEL1 and MODEL2 each one with it's folder...
if the radio automatically renames MODEL2 to MODEL1 we can have:
1) a merge (you will end up with the two models messed up)
2) delete MODEL1 folder (missing it)
3) do not rename MODEL2 as MODEL1 folder already exists and use model 1 folder leaving it there MODEL2 not used

the only acceptable in my point of view is 3)
About creating folders.... with mass storage the user can do by himself if needed, but i would prefer to avoid having a lot of folders not used.

[Scott Page]

I plan to use different voices for different models. I figured I can use the same names and simply put a numeric prefix on all the sounds from that voice (3AIhi = voice 3 Aileron High Rate). I doubt I'll have more than 9 voices in the card. But I doubted I'd ever have a talking transmitter....

I'm making a system for naming .. so I don't have a mess once I start doing the recording.

Right now I have:

AI = Aileron
BK = Brakes
CR = Crow
EL = Elevator
FL = Flaps
FM = Flight Mode
GR = Gear
P1 = Pot 1
P2 = Pot 2
P3 = Pot 3
RD = Rudder
SP - Spoilerons
TH = Throttle
TP = 3 position switch
TR = Trainer
VR = Vario


TA = Trim Aileron
TE = Trim Elevator
TR = Trim Rudder
TT = Trim Throttle

AC = Active
CT= Critical
DN = Down
HI - High
IN = Inactive
LO - Low
OF = Off
ON = ON
UP = Up
WN=Warning

TX = Transmitter
RX = Reciever
Altitude
RPM
Fuel
T1
T2
Speed
Distance
GPS Altitude
Cell
Cels
Vfas
Curr
Cncp = Total Amperage Used
Powr


If you see something obvious that I missed let me know. I have only started with the telemetry section. Had to do some real work today too.

[archer183]

X9D compiling question for you: Are there any special packages I need to install to compile with X9D set in the makefile? I have some friends who intend to buy this TX when it comes out but also want to use the turret convergence code I have worked into the stock board, so I wanted to start playing with it via simu and start making sure my code works, but I get a whole host of missing file errors when I try to compile it with the latest version of open9x (unmodified by me) from the svn site.

thanks
Greg

[Kilrah]

The simu should compile as usual, make simu PCB=X9D SDCARD=YES
It used to work, now I do have an error:

eeprom_arm.cpp: In function ‘void eeReadAll()’:
eeprom_arm.cpp:549:22: erreur: ‘soft_power_off’ was not declared in this scope

Probably just a simple bug.

AFAIK compiling for the actual device is still a work in progress.

[bertrand35]

Right, I have a lot of changes in progress for X9D. The LCD driver now compiles ok. This error is also fixed.

Bertrand.