OpenTX - Nightly builds for pre-2.0 testing

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!
User avatar
Scott Page
Posts: 864
Joined: Wed Dec 28, 2011 3:32 am
Country: -
Location: Tri-Cities, Washington State

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Scott Page » Fri May 02, 2014 11:57 pm

bertrand35 wrote:Perhaps switch to Linux?
Pretty difficult for me to test the Windows version of CompanionTX 1.99 using Linux. :D

rdeanchurch
Posts: 521
Joined: Tue Dec 27, 2011 11:22 pm
Country: -
Location: Rio Vista. CA

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by rdeanchurch » Sat May 03, 2014 1:23 am

Scott Page wrote:
bertrand35 wrote:Perhaps switch to Linux?
Pretty difficult for me to test the Windows version of CompanionTX 1.99 using Linux. :D
but other than that, Mrs. Lincoln, how was....
Dean
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1

fryfrog
Posts: 5
Joined: Mon Jul 22, 2013 4:02 pm
Country: -

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by fryfrog » Sat May 03, 2014 3:28 am

Couldn't you do all of this with a single curve?

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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Kilrah » Sat May 03, 2014 7:14 am

Wrong topic?

User avatar
MikeB
9x Developer
Posts: 14362
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by MikeB » Sat May 03, 2014 10:21 am

I haven't been testing this, so I don't know if the following has been implemented. If not, then I think it is a VERY good safety feature that should be added (I know it's late on).

On er9x/ersky9x, I added (at Jhsa'a suggestion) a lock on using the trainer inputs such that, if there is NO trainer input, then control is never swapped to the trainer inputs. This provides a safety mechanism to prevent the throttle going to half setting.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!


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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Kilrah » Sat May 03, 2014 10:39 am

It's been in the TODO list for at least a year I think, and still is...

User avatar
MikeB
9x Developer
Posts: 14362
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by MikeB » Sat May 03, 2014 10:43 am

I'm asking because of this thread: viewtopic.php?f=97&t=5420.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by bertrand35 » Sat May 03, 2014 3:41 pm

Good idea, I missed this thread completely, I will add this feature next week.

User avatar
MikeB
9x Developer
Posts: 14362
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by MikeB » Sat May 03, 2014 4:01 pm

You can find code in er9x/ersky9x:

Code: Select all

  		if(ppmInState && ppmInState<=8)
			{
  	  	if(val>800 && val<2200)
				{
					ppmInValid = 100 ;   <---- ADDED LINE
  		    g_ppmIns[ppmInState++ - 1] =
  	  	    (int16_t)(val - 1500)* (uint8_t)(g_eeGeneral.PPM_Multiplier+10)/10; //+-500 != 512, but close enough.

		    }else{
  		    ppmInState=0; // not triggered
  	  	}
  	  }
Every 10mS:

Code: Select all

		if ( ppmInValid )
		{
			ppmInValid -= 1 ;
		}
In the mixer:

Code: Select all

                if (!(att&NO_TRAINER) && g_model.traineron) {
                    TrainerMix* td = &g_eeGeneral.trainer.mix[index];
                    if (td->mode && getSwitch(td->swtch, 1))
										{
											if ( ppmInValid )
											{
                        uint8_t chStud = td->srcChn ;
                        int16_t vStud  = (g_ppmIns[chStud]- g_eeGeneral.trainer.calib[chStud]) /* *2 */ ;
                        vStud /= 2 ;		// Only 2, because no *2 above
                        vStud *= td->studWeight ;
                        vStud /= 31 ;
                        vStud *= 4 ;
                        switch ((uint8_t)td->mode) {
                        case 1: v += vStud;   break; // add-mode
                        case 2: v  = vStud;   break; // subst-mode
                        }
											}
                    }
                }
and also:

Code: Select all

        if (md->swtch && (md->srcRaw >= PPM_BASE) && (md->srcRaw < PPM_BASE+NUM_PPM)	&& (ppmInValid == 0) )
				{
					// then treat switch as false ???				
					t_switch = 0 ;
				}	
This last bit says, If we have a switch controlling a mix with PPMx as source, and the PPM input is missing, pretend the switch is OFF.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by bertrand35 » Sat May 03, 2014 5:24 pm

Thanks!

User avatar
dinamich
Posts: 288
Joined: Mon Apr 01, 2013 1:21 pm
Country: Slovenia
Location: Ljubljana

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by dinamich » Sat May 03, 2014 5:38 pm

Kilrah wrote:Turning the mousewheel when the cursor is over a control edits it, it's always been like this, same in 1.52, and is simply standard Windows behavior. Not even sure it's possible to avoid it.
The mouse scroll behaves exactly the same on Linux too. It is annoying, I agree. Maybe we could disable mouse scroll modifying values?
projectkk2glider@github

User avatar
Scott Page
Posts: 864
Joined: Wed Dec 28, 2011 3:32 am
Country: -
Location: Tri-Cities, Washington State

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Scott Page » Sun May 04, 2014 5:39 am

I had gotten the impression that setting DR and Expo would no longer work in Inputs (formerly sticks) for 2.0. May I have some clarification on that.

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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Kilrah » Sun May 04, 2014 6:49 am

Why? That's the whole point of this screen!

User avatar
Scott Page
Posts: 864
Joined: Wed Dec 28, 2011 3:32 am
Country: -
Location: Tri-Cities, Washington State

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Scott Page » Sun May 04, 2014 6:58 am

Kilrah wrote:Why? That's the whole point of this screen!
I mis-understood something said earlier.

User avatar
Scott Page
Posts: 864
Joined: Wed Dec 28, 2011 3:32 am
Country: -
Location: Tri-Cities, Washington State

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Scott Page » Sun May 04, 2014 8:12 am

"Default audio files can be placed on the SD card for each model for all switch positions (both for physical and logical switches"

Is procedure for this documented anywhere yet? I checked https://docs.google.com/document/d/1lL8 ... 5RQGA/edit and didn't find it there.

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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Kilrah » Sun May 04, 2014 8:55 am

That document is far from complete at this point. It's basically same as for flight modes on current release, with names "SA-up" "SA-mid" "SA-down" "LS1-on" "LS1-off" etc.

rilot
Posts: 9
Joined: Fri Jan 24, 2014 12:19 am
Country: -

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by rilot » Sun May 04, 2014 11:12 am

Is there any chance we could - in the telemetry bars page - have the mAh consumption bar able to go above 5100mAh?
The ability to select consumption above 5100mAh in the custom switches was added in an earlier build but the limit on the bars remains.

rdeanchurch
Posts: 521
Joined: Tue Dec 27, 2011 11:22 pm
Country: -
Location: Rio Vista. CA

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by rdeanchurch » Sun May 04, 2014 5:38 pm

Kilrah wrote:That document is far from complete at this point. It's basically same as for flight modes on current release, with names "SA-up" "SA-mid" "SA-down" "LS1-on" "LS1-off" etc.
Do I understand this correctly?

The model is named....Omega
In a folder in SOUNDS/lang/Omega/
put in tracks named
Launch-ON.wav (for FlightMode1)
SA-up.wav
SA-mid.wav
Dean
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1

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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Kilrah » Sun May 04, 2014 6:02 pm

SOUNDS/lang/en/Omega/

But yes for the rest.

User avatar
Scott Page
Posts: 864
Joined: Wed Dec 28, 2011 3:32 am
Country: -
Location: Tri-Cities, Washington State

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Scott Page » Sun May 04, 2014 8:41 pm

rdeanchurch wrote:
Kilrah wrote:That document is far from complete at this point. It's basically same as for flight modes on current release, with names "SA-up" "SA-mid" "SA-down" "LS1-on" "LS1-off" etc.
Do I understand this correctly?

The model is named....Omega
In a folder in SOUNDS/lang/Omega/
put in tracks named
Launch-ON.wav (for FlightMode1)
SA-up.wav
SA-mid.wav

To be sure I understand - you've named FlightMode1 "Launch". So whatever I name the Flightmode would be the trigger.
When I get to work (where my test TX is) I'm going to test to see if: in the absence of a flightmode name would I use "FlightMode1" , "Flightmode2" etc - will work.
I'm also going to check to see if Input Line name will work as the trigger. Seems like it should??
I assume that other sounds will be picked out of the EN folder -- but I'll test that tomorrow (at work) as well. Guess I now what I'll be doing with break time and lunch. :mrgreen:

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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Kilrah » Sun May 04, 2014 8:51 pm

Nope, switch and flight mode names (user entered) are the only ones that are picked up. For the rest you can use the switch ;)

User avatar
Scott Page
Posts: 864
Joined: Wed Dec 28, 2011 3:32 am
Country: -
Location: Tri-Cities, Washington State

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Scott Page » Sun May 04, 2014 9:00 pm

Kilrah wrote:Nope, switch and flight mode names (user entered) are the only ones that are picked up. For the rest you can use the switch ;)
Ok Sweet. This will save a bunch of Custom Function lines!!!

rdeanchurch
Posts: 521
Joined: Tue Dec 27, 2011 11:22 pm
Country: -
Location: Rio Vista. CA

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by rdeanchurch » Sun May 04, 2014 10:07 pm

Scott Page wrote:
rdeanchurch wrote:
Kilrah wrote:That document is far from complete at this point. It's basically same as for flight modes on current release, with names "SA-up" "SA-mid" "SA-down" "LS1-on" "LS1-off" etc.
Do I understand this correctly?

The model is named....Omega
In a folder in SOUNDS/MyLang=en/Omega/
put in tracks named
Launch-ON.wav (for FlightMode1)
SA-up.wav
SA-mid.wav

To be sure I understand - you've named FlightMode1 "Launch". So whatever I name the Flightmode would be the trigger.
.....
:mrgreen:
Yes that is the way it works in 2490 also.
I did not test for this explicitly on a "nightly", but think I would have noticed had it not worked.
Dean
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1

Dthomson39
Posts: 8
Joined: Sat Nov 23, 2013 11:56 am
Country: -

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Dthomson39 » Sun May 04, 2014 10:11 pm

I thought I would try to contribute to the work of finalising version 2.0 but I have not been able to configure my Taranis to work with the new version. I write firmware to the TX and on restoring the transmitter reports bad eeprom etc and reformats it - I expected that. Trouble is I have not then been able to write the models back to the TX even though it claims to have transferred them correctly. I assume the firmware has been upgraded hence the reformatting but I cannot get past this point.
Any suggestions - is there a step I am missing?

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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Kilrah » Sun May 04, 2014 10:20 pm

The first time you turn the radio on after reflashing it shouldn't format, but upgrade settings automatically (you'll see "Converting EEPROM" with a progress bar), then you've got your data ready for 2.0.
If you want to write things with companion when 2.0 is on the radio, you of course need to use the matching nightly build of companion. But if you said you could write the EEPROM successfully the usual way, and the radio says it's corrupt you probably flashed a wrong file to the radio. What did you use?

User avatar
MikeB
9x Developer
Posts: 14362
Joined: Tue Dec 27, 2011 1:24 pm
Country: -
Location: Poole, Dorset

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by MikeB » Sun May 04, 2014 10:21 pm

I think you will find you need to run the Taranis in "bootloader" mode to access the EEPROM now. Hold both horizontal trims towards the centre while switching on, this selects "bootloader" mode. Now plug the USB cable in and you should get two disk drives, the SD card and a drive that is mapped to the EEPROM and FIRMWARE. Companion should now read/write you EEPROM.

Mike.
ersky9x/er9x developer
The difficult we do immediately,
The impossible takes a little longer!

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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by bertrand35 » Mon May 05, 2014 8:54 am

rilot wrote:Is there any chance we could - in the telemetry bars page - have the mAh consumption bar able to go above 5100mAh?
The ability to select consumption above 5100mAh in the custom switches was added in an earlier build but the limit on the bars remains.
10200mAh in 'next'
https://github.com/opentx/opentx/commit ... d79750749b

rilot
Posts: 9
Joined: Fri Jan 24, 2014 12:19 am
Country: -

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by rilot » Mon May 05, 2014 11:10 am

bertrand35 wrote:
rilot wrote:Is there any chance we could - in the telemetry bars page - have the mAh consumption bar able to go above 5100mAh?
The ability to select consumption above 5100mAh in the custom switches was added in an earlier build but the limit on the bars remains.
10200mAh in 'next'
https://github.com/opentx/opentx/commit ... d79750749b
Brill, thanks.
Is 10200mAh a limit of the radio? I sometimes fly with anything up to 20000mAh of cells (2 x 10000mAh in parallel), can it be raised further?

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

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by Kilrah » Mon May 05, 2014 11:45 am

The way bars are designed there is only an 8-bit value available (256 possibilities) to store the min and max.
Allowing up to 20'000 means that we'll lose precision on the mostly used small values. We'd have to do 100mAh steps, not sure guys with 500mAh batteries will be happy...

Anyway this should be all redesigned for a future version. In the meantime we'll have to choose which is least annoying... 100mA steps could probably be OK.

User avatar
jhsa
Posts: 16557
Joined: Tue Dec 27, 2011 5:13 pm
Country: Germany

Re: OpenTX - Nightly builds for pre-2.0 testing

Post by jhsa » Mon May 05, 2014 1:01 pm

that is asking for some scalers as in er9x/ersky ;) :)

João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9

Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW

Post Reply

Return to “openTx”

Who is online

Users browsing this forum: No registered users and 2 guests