OpenTX 2.1 - Discussions about new features
Re: OpenTX Nightly builds
Hi Bertrand
Defining the telemetry on 2.1 does the sensor definitions on frsky_sport.cpp correspond to id on this form ?
[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
Defining the telemetry on 2.1 does the sensor definitions on frsky_sport.cpp correspond to id on this form ?
[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
Re: OpenTX Nightly builds
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.
Then you add any calculated items based on them.
Re: OpenTX Nightly builds
Hy Kilrah,
OK, but how can I set the Frsky standard sensors at Companion and at Simu?
Helle
OK, but how can I set the Frsky standard sensors at Companion and at Simu?
Helle
Re: OpenTX Nightly builds
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 ??
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.
-
- 9x Developer
- Posts: 2764
- Joined: Fri Dec 30, 2011 11:11 pm
- Country: -
OpenTX 2.1 - Discussions about new features
Post reserved for the list of new features and useful links
Coming soon...
Coming soon...
Re: OpenTX 2.1 - Discussions about new features
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.
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!
-
- 9x Developer
- Posts: 2764
- Joined: Fri Dec 30, 2011 11:11 pm
- Country: -
Re: OpenTX 2.1 - Discussions about new features
Calibration. Did you test 2.1 nightly builds, it should already work
Re: OpenTX 2.1 - Discussions about new features
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
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
Re: OpenTX 2.1 - Discussions about new features
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!
Re: OpenTX 2.1 - Discussions about new features
2.0.13 is not released yet.
-
- Posts: 1
- Joined: Wed Nov 12, 2014 8:40 pm
- Country: -
Re: OpenTX 2.1 - Discussions about new features
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.
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.
Re: OpenTX Nightly builds
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: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 ??
Like before, updated as they come. There's never been any particular sequencing done in OpenTX.lvale wrote: Also, some of the values when transmitted had some special sequencing (GPS comes to mind) How are these going to be dealt ?
Nothing has been done on the lua side so far.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 ?
No, anytime a not yet known sensor is seen it's added automatically.lvale wrote: ps: You say to connect the sensors to the receiver and bind. Is the sensor discovery only made at the binding process ??
Re: OpenTX 2.1 - Discussions about new features
Never seen an issue for thatHelle wrote: mixer monitor (mixersignal before Servos)
Can already be done manually with a simple dedicated model memory.Helle wrote: Servo calibration funktion (for gliders)
Already there.Helle wrote: expo dualrate at both sides separate (opentx)
Very low priority, read "might happen one day if someone ever finds the motivation for it but don't count on it".Helle wrote: Language selection at opentx intern
Language selection at Simu intern
Sound at Companion
Yep, that one's needed.Helle wrote: solve bug at Diff Funktion, see issue #1807
Re: OpenTX 2.1 - Discussions about new features
No not at this point. But as said the new telemetry system doesn't have any lua bindings yet.softaflyer wrote:Can the output from a lua model script be treated like a telemetry value?
Re: OpenTX 2.1 - Discussions about new features
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"
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"
- 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
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!
...........if you think it should be in the wiki.. ask me for wiki access, then go add it!
Re: OpenTX 2.1 - Discussions about new features
Not really the same.Rob Thomson wrote:X > v or x < v ?
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.
Re: OpenTX 2.1 - Discussions about new features
Yes. Just use the NOT form... it's actually the exact same as != being the NOT operator concatenated to the equal operatorfrater wrote:Am I correct there's no equivalent for != in logical switches?
Re: OpenTX 2.1 - Discussions about new features
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: A little problem, A1 (receiver voltage) is recognized as Batt which is confusing with Batt from TX main battery.
Bye.
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: A little problem, A1 (receiver voltage) is recognized as Batt which is confusing with Batt from TX main battery.
Bye.
-
- 9x Developer
- Posts: 2764
- Joined: Fri Dec 30, 2011 11:11 pm
- Country: -
Re: OpenTX 2.1 - Discussions about new features
Longer names will be difficult, remember we have to use those names in inputs sources / logical switches etc.
Re: OpenTX 2.1 - Discussions about new features
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
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
Re: OpenTX 2.1 - Discussions about new features
- More global variables (99?)
- System wide variables
- special folder for bgmusic
- System wide variables
- special folder for bgmusic
Re: OpenTX 2.1 - Discussions about new features
Ability to set "minimum volume" level
When assigning a slider to volume in custom function
-- Offer --
When assigning a slider to volume in custom function
-- Offer --
Re: OpenTX 2.1 - Discussions about new features
You can do that with the current firmware and I just did.offers wrote:Ability to set "minimum volume" level
When assigning a slider to volume in custom function
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
Re: OpenTX 2.1 - Discussions about new features
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 --
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 --
Re: OpenTX 2.1 - Discussions about new features
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
-
- Posts: 5
- Joined: Mon Dec 01, 2014 5:17 am
- Country: -
Re: OpenTX 2.1 - Discussions about new features
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.
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.
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: OpenTX 2.1 - Discussions about new features
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.
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: OpenTX 2.1 - Discussions about new features
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.
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.