OpenTX 2.1 - Discussions about new features

openTx has introduced a range of new features, ideas and bling. It is fast becoming the firmware of choice for many users. openTx will run on ALL current hardware platforms, including the gruvin9x and sky9x boards. Work has already started to support the new FrSky X9D radio!
Post Reply
lvale
Posts: 13
Joined: Thu Oct 11, 2012 1:31 am
Country: -

Re: OpenTX Nightly builds

Post by lvale »

Hi Bertrand

Defining the telemetry on 2.1 does the sensor definitions on frsky_sport.cpp correspond to id on this form ?
Screen Shot 2014-11-10 at 20.21.09.png

[tab=30]#define FR_ID_ALTITUDE 0x0100 //ALT_FIRST_ID
#define FR_ID_VARIO 0x0110 //VARIO_FIRST_ID
#define FR_ID_VFAS 0x0210 //VFAS_FIRST_ID
#define FR_ID_CURRENT 0x0200 //CURR_FIRST_ID
#define FR_ID_CELLS 0x0300 //CELLS_FIRST_ID
#define FR_ID_CELLS_LAST 0x030F //CELLS_LAST_ID
#define FR_ID_T1 0x0400 //T1_FIRST_ID
#define FR_ID_T2 0x0410 //T2_FIRST_ID
#define FR_ID_RPM 0x0500 //RPM_FIRST_ID
#define FR_ID_FUEL 0x0600 //FUEL_FIRST_ID
#define FR_ID_ACCX 0x0700 //ACCX_FIRST_ID
#define FR_ID_ACCY 0x0710 //ACCY_FIRST_ID
#define FR_ID_ACCZ 0x0720 //ACCZ_FIRST_ID
#define FR_ID_LATLONG 0x0800 //GPS_LONG_LATI_FIRST_ID
#define FR_ID_GPS_ALT 0x0820 //GPS_ALT_FIRST_ID
#define FR_ID_SPEED 0x0830 //GPS_SPEED_FIRST_ID
#define FR_ID_GPS_COURSE 0x0840 //GPS_COURS_FIRST_ID
#define FR_ID_GPS_TIME_DATE 0x0850 //GPS_TIME_DATE_FIRST_ID
#define FR_ID_A3_FIRST 0x0900 //A3_FIRST_ID
#define FR_ID_A4_FIRST 0x0910 //A4_FIRST_ID
#define FR_ID_AIR_SPEED_FIRST 0x0A00 //AIR_SPEED_FIRST_ID
#define FR_ID_RSSI 0xF101 // used by the radio system
#define FR_ID_ADC1 0xF102 //ADC1_ID
#define FR_ID_ADC2 0xF103 //ADC2_ID
#define FR_ID_BATT 0xF104 // used by the radio system
#define FR_ID_SWR 0xF105 // used by the radio system

User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX Nightly builds

Post by Kilrah »

Yes, but filling them up manually in companion makes no sense. The way you'd typically do it is connect your sensors to the receiver, power everything up and bind, and all physical sensors will be discovered automatically.
Then you add any calculated items based on them.
Helle
Posts: 577
Joined: Sat Jul 21, 2012 7:08 am
Country: -

Re: OpenTX Nightly builds

Post by Helle »

Hy Kilrah,

OK, but how can I set the Frsky standard sensors at Companion and at Simu?

Helle
lvale
Posts: 13
Joined: Thu Oct 11, 2012 1:31 am
Country: -

Re: OpenTX Nightly builds

Post by lvale »

ok, that's understandable. So what is the allowed range of ID's 0x0000 to 0xffff ?? And the reserved range is the current values on the frsky_sport.cpp ??




Also, some of the values when transmitted had some special sequencing (GPS comes to mind) How are these going to be dealt ?

On the scripting side I would assume this type of instructions disappears

FVas_id = getFieldInfo('vfas').id

since the names (like 'vfas') are not defined

or is the definition of the sensors exposed to Lua ?

tks Andre

ps: You say to connect the sensors to the receiver and bind. Is the sensor discovery only made at the binding process ??

Kilrah wrote:Yes, but filling them up manually in companion makes no sense. The way you'd typically do it is connect your sensors to the receiver, power everything up and bind, and all physical sensors will be discovered automatically.
Then you add any calculated items based on them.
bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

OpenTX 2.1 - Discussions about new features

Post by bertrand35 »

Post reserved for the list of new features and useful links
Coming soon...

User avatar
HC1969
Posts: 421
Joined: Wed Dec 28, 2011 8:47 am
Country: Hungary
Location: Istvan Magi
Contact:

Re: OpenTX 2.1 - Discussions about new features

Post by HC1969 »

We raised a claim that it would be good to create the calibration of the sensors.
Eg. The thermometer pretty much cheating. It would be nice if it could push the value of a free set value.
http://rc.emiter.hu/ (MegaSound 9X, GCL-2, FrSky-RSSI-DAC, etc.) Keress fel!
bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by bertrand35 »

Calibration. Did you test 2.1 nightly builds, it should already work
Helle
Posts: 577
Joined: Sat Jul 21, 2012 7:08 am
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by Helle »

Hy

first solve open issues and bugs first

mixer monitor (mixersignal before Servos)
Servo calibration funktion (for gliders)
solve bug at Diff Funktion, see issue #1807

Language selection at opentx intern
Language selection at Simu intern
Sound at Companion
expo dualrate at both sides separate (opentx)


Helle
User avatar
HC1969
Posts: 421
Joined: Wed Dec 28, 2011 8:47 am
Country: Hungary
Location: Istvan Magi
Contact:

Re: OpenTX 2.1 - Discussions about new features

Post by HC1969 »

Why not download the companion is the latest FW(V2.0.13)?
http://rc.emiter.hu/ (MegaSound 9X, GCL-2, FrSky-RSSI-DAC, etc.) Keress fel!
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 - Discussions about new features

Post by Kilrah »

2.0.13 is not released yet.
softaflyer
Posts: 1
Joined: Wed Nov 12, 2014 8:40 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by softaflyer »

Can the output from a lua model script be treated like a telemetry value?
I have been struggling with a mAh sensor whose value need to be adjusted using Peukert's law.
Ok, first approximation is multiply with a constant factor but it can be more complex that so.
So a model script where the output is kind of a normal telemetry variable for display and
for use in e.g. custom switches would be very useful. I don't see that the new formula
variable nor the calibration can really solve this.
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX Nightly builds

Post by Kilrah »

lvale wrote:ok, that's understandable. So what is the allowed range of ID's 0x0000 to 0xffff ?? And the reserved range is the current values on the frsky_sport.cpp ??
Any ID can be entered, but the firmware will only know how to decode those that are defined. One of the major points of the system is to be able to add such IDs in the future in only a single place in the code.
lvale wrote: Also, some of the values when transmitted had some special sequencing (GPS comes to mind) How are these going to be dealt ?
Like before, updated as they come. There's never been any particular sequencing done in OpenTX.
lvale wrote: On the scripting side I would assume this type of instructions disappears
FVas_id = getFieldInfo('vfas').id
since the names (like 'vfas') are not defined
or is the definition of the sensors exposed to Lua ?
Nothing has been done on the lua side so far.
lvale wrote: ps: You say to connect the sensors to the receiver and bind. Is the sensor discovery only made at the binding process ??
No, anytime a not yet known sensor is seen it's added automatically.
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 - Discussions about new features

Post by Kilrah »

Helle wrote: mixer monitor (mixersignal before Servos)
Never seen an issue for that
Helle wrote: Servo calibration funktion (for gliders)
Can already be done manually with a simple dedicated model memory.
Helle wrote: expo dualrate at both sides separate (opentx)
Already there.
Helle wrote: Language selection at opentx intern
Language selection at Simu intern
Sound at Companion
Very low priority, read "might happen one day if someone ever finds the motivation for it but don't count on it".
Helle wrote: solve bug at Diff Funktion, see issue #1807
Yep, that one's needed.
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 - Discussions about new features

Post by Kilrah »

softaflyer wrote:Can the output from a lua model script be treated like a telemetry value?
No not at this point. But as said the new telemetry system doesn't have any lua bindings yet.
frater
Posts: 77
Joined: Sat Aug 30, 2014 11:04 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by frater »

Am I correct there's no equivalent for != in logical switches?
I know I can get there by using "NOT", but in some cases it improves the readability of a switch if you do not have to use " NOT"
User avatar
Rob Thomson
Site Admin
Posts: 4543
Joined: Tue Dec 27, 2011 11:34 am
Country: United Kingdom
Location: Albury, Guildford
Contact:

Re: OpenTX 2.1 - Discussions about new features

Post by Rob Thomson »

X > v or x < v ?
Slope Soaring, FPV, and pretty much anything 'high tech'
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
frater
Posts: 77
Joined: Sat Aug 30, 2014 11:04 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by frater »

Rob Thomson wrote:X > v or x < v ?
Not really the same.
I'm talking about aesthetics, not about mathematical equivalents.
It exists in almost any programming language.
On top of that it's less efficient if it needs to be interpreted and the autistic part of any programmer detests this.

I just browsed through all the operators and thought I might have missed it.
I would really like it in.
I guess I need to create a ticket for this in github.
User avatar
Kilrah
Posts: 11108
Joined: Sat Feb 18, 2012 6:56 pm
Country: Switzerland

Re: OpenTX 2.1 - Discussions about new features

Post by Kilrah »

frater wrote:Am I correct there's no equivalent for != in logical switches?
Yes. Just use the NOT form... it's actually the exact same as != being the NOT operator concatenated to the equal operator ;)
davx
Posts: 210
Joined: Sun Sep 15, 2013 7:01 am
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by davx »

Hi,

I've made some tests with the new telemetry system (2.1 next) and I find really nice the sensors automatic detection and the * character blinking when receiving telemetry packets !

However, it would be convenient to have presets for the commonly used sensors in the dropdown list "Type" so that we can set them within Companion or without receiver.
And perhaps RSSI and A1 (or receiver voltage) should be there by default.

Also, some more information about the sensors settings on their lines (like log enable...) could be good:
OTX_B2.1_tele.png
A little problem, A1 (receiver voltage) is recognized as Batt which is confusing with Batt from TX main battery.

Bye.
bertrand35
9x Developer
Posts: 2764
Joined: Fri Dec 30, 2011 11:11 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by bertrand35 »

Longer names will be difficult, remember we have to use those names in inputs sources / logical switches etc.
Helle
Posts: 577
Joined: Sat Jul 21, 2012 7:08 am
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by Helle »

Hy,

yes, need it, have presets for the commonly used sensors in the dropdown list
so that we can set them within Companion or without receiver.

Helle
frater
Posts: 77
Joined: Sat Aug 30, 2014 11:04 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by frater »

- More global variables (99?)
- System wide variables
- special folder for bgmusic
offers
Posts: 81
Joined: Tue Jan 22, 2013 4:14 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by offers »

Ability to set "minimum volume" level
When assigning a slider to volume in custom function




-- Offer --
frater
Posts: 77
Joined: Sat Aug 30, 2014 11:04 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by frater »

offers wrote:Ability to set "minimum volume" level
When assigning a slider to volume in custom function
You can do that with the current firmware and I just did.
Create an input VOL based on the RS (right slider) and create a 2-point curve that starts at -20 and goes to 100.

I assume you want it so you don't miss any warnings like "A1 critical"
Thank you for that idea and thank myself for working it out ;-)
offers
Posts: 81
Joined: Tue Jan 22, 2013 4:14 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by offers »

I know it's possible, But since the setting is NOT per transmitter, and since volume is a basic functionality in every device that have speaker,
it should be simpler in such quality program(!!)
than make a user like my set 28 different tasks [emoji26] for my 14 models (2 task per model)




-- Offer --
idar66
Posts: 38
Joined: Tue Aug 19, 2014 8:12 am
Country: New Zealand

Re: OpenTX 2.1 - Discussions about new features

Post by idar66 »

plz can someone sort out the heli wizard as i think it should have been done with the others, i know alot of people are wanting it sorted, thanks idar
Excaliburst
Posts: 5
Joined: Mon Dec 01, 2014 5:17 am
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by Excaliburst »

Agree with Offers this should not be set pr model. It is a generic thing that should be handled under Tx settings and have a switch shortcut to adjust it while flying.

It is cumbersome for users to have to create mixes for this kind of generic thing. And it cannibalize on mixer lines.

It could be done by holding the momentary switch while adjusting the pot closest to the switch.

Of course if this combo is then inadvertently used in the mixers - an alarm should pop.
nigelsheffield
Posts: 308
Joined: Fri Nov 08, 2013 9:56 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by nigelsheffield »

I noticed there are just 4 telemetry screens in 2.0.99, where as 2.0 we can have 7 lua telemetry plus the normal ones, 4 should be enough though but would it be easy to add more if needed later? Sorry if there is a better place to ask please tell me.
nigelsheffield
Posts: 308
Joined: Fri Nov 08, 2013 9:56 pm
Country: -

Re: OpenTX 2.1 - Discussions about new features

Post by nigelsheffield »

We have global functions but not global logic switches or tx global variables
One use would be when swapping the tx battery out for a spare in the field,
Assuming using stock NiMH as main and putting in the 1500mah 3 cell life as spare, NiMH has Max volt of 8.6v and life has min safe volt of around 9 to 9.3v so tx could detect the battery type and set alarms accordingly with logic switches.
With gvars the battery type could be set manually if needed.
I see there is lua available from the global functions so it could be done there if this is considered too much.

Perhaps the battery meter range could be updated with these setting too somehow in future.

Post Reply

Return to “openTx”