OpenTX - Nightly builds for pre-2.0 testing
- MikeB
- 9x Developer
- Posts: 17990
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: OpenTX - Nightly builds for pre-2.0 testing
If you flashed ersky9x for Taranis first, you will have my original bootloader. This uses the "Firmware" directory.
Mike.
Mike.
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
- Scott Page
- Posts: 864
- Joined: Wed Dec 28, 2011 3:32 am
- Country: United States
- Location: Tri-Cities, Washington State
Re: OpenTX - Nightly builds for pre-2.0 testing
I posted this in RCG but will here as well. I audited the sound packs against the original sound pack and also the popular "Amber" sound pack.
The following were added to 2.0
0110.wav = "and"
0139.wav = "foot"
0141.wav = "mile per hour"
0142.wav = "miles per hour"
a3_org.wav = "A3 Low"
a3_red.wav = "A3 Critical"
a4_org.wav = "A4 Low"
a4_red.wav = "A4 Critical"
eebad.wav = "Bad eeprom" (missing in Amber pack)
rx_org.wav = Reciever battery low
rx_red.wav = Receiver battery critical
timerlt3.wav = "Time up" (missing in Amber Pack)
To spell this out a little bit more - (for readers not developers) if you update to 2.0 but don't update your sounds as well, those are the sounds you will be missing.
The following were added to 2.0
0110.wav = "and"
0139.wav = "foot"
0141.wav = "mile per hour"
0142.wav = "miles per hour"
a3_org.wav = "A3 Low"
a3_red.wav = "A3 Critical"
a4_org.wav = "A4 Low"
a4_red.wav = "A4 Critical"
eebad.wav = "Bad eeprom" (missing in Amber pack)
rx_org.wav = Reciever battery low
rx_red.wav = Receiver battery critical
timerlt3.wav = "Time up" (missing in Amber Pack)
To spell this out a little bit more - (for readers not developers) if you update to 2.0 but don't update your sounds as well, those are the sounds you will be missing.
- Scott Page
- Posts: 864
- Joined: Wed Dec 28, 2011 3:32 am
- Country: United States
- Location: Tri-Cities, Washington State
Re: OpenTX - Nightly builds for pre-2.0 testing
This came to me via PM. I read through it and I agree with him -- I believe it merits consideration.
Quote>>>>>
1. The logic of SP Page looping in one direction and LP Page looping in the reverse direction within a given menu group doesn’t work from within the Main Screens group. The SP Page rotates one way, but the LP Page exits Main Screens and enters Telemetry View. This is inconsistent use of the LP Page command. It shouldn’t be used as a “rotate backward” command one time and a “Exit to Another Menu” command another time. Confusing for us folks with arthritic linear thought processes.
2. The entry into the Telemetry View actually enters at the last item viewed instead of entering at a fixed starting point. That’s not necessarily a bad thing, but it’s not done that way in the other menu entries. I personally find it helpful to know where I’ve landed if I always see the same starting place when I enter a new menu. The other menus all have a fixed starting place but the Telemetry View doesn’t.
<<<<end quote
Quote>>>>>
1. The logic of SP Page looping in one direction and LP Page looping in the reverse direction within a given menu group doesn’t work from within the Main Screens group. The SP Page rotates one way, but the LP Page exits Main Screens and enters Telemetry View. This is inconsistent use of the LP Page command. It shouldn’t be used as a “rotate backward” command one time and a “Exit to Another Menu” command another time. Confusing for us folks with arthritic linear thought processes.
2. The entry into the Telemetry View actually enters at the last item viewed instead of entering at a fixed starting point. That’s not necessarily a bad thing, but it’s not done that way in the other menu entries. I personally find it helpful to know where I’ve landed if I always see the same starting place when I enter a new menu. The other menus all have a fixed starting place but the Telemetry View doesn’t.
<<<<end quote
Re: OpenTX - Nightly builds for pre-2.0 testing
You're kidding - right.
Great idea. Lets change something that's been in use since the start and really confuse everyone.
That's already happened with the one/two trim business. There's now two different procedures in use to really confuse the users.
Let's restrict requests for changes to real problems and bugs. Not just "I don't like that".
Great idea. Lets change something that's been in use since the start and really confuse everyone.
That's already happened with the one/two trim business. There's now two different procedures in use to really confuse the users.
Let's restrict requests for changes to real problems and bugs. Not just "I don't like that".
Scott Page wrote:This came to me via PM. I read through it and I agree with him -- I believe it merits consideration.
Quote>>>>>
1. The logic of SP Page looping in one direction and LP Page looping in the reverse direction within a given menu group doesn’t work from within the Main Screens group. The SP Page rotates one way, but the LP Page exits Main Screens and enters Telemetry View. This is inconsistent use of the LP Page command. It shouldn’t be used as a “rotate backward” command one time and a “Exit to Another Menu” command another time. Confusing for us folks with arthritic linear thought processes.
2. The entry into the Telemetry View actually enters at the last item viewed instead of entering at a fixed starting point. That’s not necessarily a bad thing, but it’s not done that way in the other menu entries. I personally find it helpful to know where I’ve landed if I always see the same starting place when I enter a new menu. The other menus all have a fixed starting place but the Telemetry View doesn’t.
<<<<end quote
Re: OpenTX - Nightly builds for pre-2.0 testing
I (almost) always want to go to the view I have set up when I enter telemetry view. Why in the world would I want to enter at a fixed location and have to page through screens I don't want to get to the one I set up. And if "That's not necessarily a bad thing" why even bring it up and suggest something that is.
As to 1., I agree with the other persons comment. It works, why create confusion by changing something everybody already knows how to do. There are only so many buttons so multiple use seems a necessity. And before somebody suggests it, moving it to a selection in a long press context menu would require many more keystrokes and much more effort then pressing one key.
How hard is it to remember what the keys do. I'm old and even I can figure it out after a couple of tries. The answer is fly more, it becomes second nature.
Jim
As to 1., I agree with the other persons comment. It works, why create confusion by changing something everybody already knows how to do. There are only so many buttons so multiple use seems a necessity. And before somebody suggests it, moving it to a selection in a long press context menu would require many more keystrokes and much more effort then pressing one key.
How hard is it to remember what the keys do. I'm old and even I can figure it out after a couple of tries. The answer is fly more, it becomes second nature.
Jim
Scott Page wrote:This came to me via PM. I read through it and I agree with him -- I believe it merits consideration.
Quote>>>>>
1. The logic of SP Page looping in one direction and LP Page looping in the reverse direction within a given menu group doesn’t work from within the Main Screens group. The SP Page rotates one way, but the LP Page exits Main Screens and enters Telemetry View. This is inconsistent use of the LP Page command. It shouldn’t be used as a “rotate backward” command one time and a “Exit to Another Menu” command another time. Confusing for us folks with arthritic linear thought processes.
2. The entry into the Telemetry View actually enters at the last item viewed instead of entering at a fixed starting point. That’s not necessarily a bad thing, but it’s not done that way in the other menu entries. I personally find it helpful to know where I’ve landed if I always see the same starting place when I enter a new menu. The other menus all have a fixed starting place but the Telemetry View doesn’t.
<<<<end quote
Re: OpenTX - Nightly builds for pre-2.0 testing
Windows 7 OpenTX 2.01 still getting "Cannot write destination" when writing eepromt to TX. Will read OK Is it writing to the SD card or processor trying to figure if it is an SD card problem.
-
- Posts: 750
- Joined: Tue Dec 27, 2011 11:22 pm
- Country: United States
- Location: Carson City, Nv
Re: OpenTX - Nightly builds for pre-2.0 testing
EEPROM is a type of memory connected to the tx processor, not related to SD card.
Dean
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1
OldDmbThms: 1. Takeoff, 2. Crash, 3. Repair, GOTO 1
- Scott Page
- Posts: 864
- Joined: Wed Dec 28, 2011 3:32 am
- Country: United States
- Location: Tri-Cities, Washington State
Re: OpenTX - Nightly builds for pre-2.0 testing
I agree with you.lexm wrote:You're kidding - right.
Great idea. Lets change something that's been in use since the start and really confuse everyone.
That's already happened with the one/two trim business. There's now two different procedures in use to really confuse the users.
Let's restrict requests for changes to real problems and bugs. Not just "I don't like that".
After being given more understanding the poster has since rescinded his suggestions. It was a matter of education. I needed to be educated about what his point was (I missed it) and then he needed to be educated why this was not well considered.
Re: OpenTX - Nightly builds for pre-2.0 testing
I seem to have a problem with haptic repeat in special functions. If i set a repeat rate in companion and transfer to the radio, the repeat rate gets lost. If I set it in the radio and transfer to companion it gets lost.
Anyone else seen this?
(Vers 2.0.1)
Anyone else seen this?
(Vers 2.0.1)
- guttedgeek
- Posts: 7
- Joined: Wed Feb 19, 2014 10:52 pm
- Country: -
Re: OpenTX - Nightly builds for pre-2.0 testing
Yes. Noticed that behaviour in 1.99.1 back in May. Best to raise an issue: easily missed in herelexm wrote:I seem to have a problem with haptic repeat in special functions. If i set a repeat rate in companion and transfer to the radio, the repeat rate gets lost. If I set it in the radio and transfer to companion it gets lost.
Anyone else seen this?
(Vers 2.0.1)
Re: OpenTX - Nightly builds for pre-2.0 testing
Already reported https://github.com/opentx/opentx/issues/1219
projectkk2glider@github
Re: OpenTX - Nightly builds for pre-2.0 testing
These guys are Quick!!!!!! Make a donation everyone.dinamich wrote:Already reported https://github.com/opentx/opentx/issues/1219
Re: OpenTX - Nightly builds for pre-2.0 testing
I don't know if it has been reported earlier, but here it is.
OpenTX 2.0.1
strange reaction of timer1 on a standard 9x radio with M128
Setup a new model
Setup Timer1 for TH% and T-Source = Thr
Timer1 speed is according to position of throttle.
This is ok.
Now change T-Source to P3
Timer1 runs at full speed, independent of the position of P3
not ok
Set P3 to a middle Position
Power off and on the radio
You get a throttle warning even with throttle stick low
Turn P3 to low and the warning is gone.
not ok
Reinhard
OpenTX 2.0.1
strange reaction of timer1 on a standard 9x radio with M128
Setup a new model
Setup Timer1 for TH% and T-Source = Thr
Timer1 speed is according to position of throttle.
This is ok.
Now change T-Source to P3
Timer1 runs at full speed, independent of the position of P3
not ok
Set P3 to a middle Position
Power off and on the radio
You get a throttle warning even with throttle stick low
Turn P3 to low and the warning is gone.
not ok
Reinhard
Re: OpenTX - Nightly builds for pre-2.0 testing
Reinhard, I think this one is ok?ReSt wrote:
Set P3 to a middle Position
Power off and on the radio
You get a throttle warning even with throttle stick low
Turn P3 to low and the warning is gone.
not ok
By changing the THR source to P3 you are telling the radio that throttle is on P3 and not on Throttle stick anymore. Therefore you get the alarm on P3. I think it is correct?? Or didn't I understand something, as usual?
Do you also get an alarm with P3 down and thr stick up when turning the radio on? with the source set to P3 of course..
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
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
Re: OpenTX - Nightly builds for pre-2.0 testing
Not so clear.
You only set the source of the timer to P3.
Throttle remains on throttle stick
Reinhard
You only set the source of the timer to P3.
Throttle remains on throttle stick
Reinhard
Re: OpenTX - Nightly builds for pre-2.0 testing
Hmm, I don't think so, maybe someone from the opentx team will confirm what is the expected behavior
I think the Throttle should move to P3 so we could use the Thr stick on something else like flaps or spoiler, and the motor will be on a pot.. I think that is the idea.
João
I think the Throttle should move to P3 so we could use the Thr stick on something else like flaps or spoiler, and the motor will be on a pot.. I think that is the idea.
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
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
Re: OpenTX - Nightly builds for pre-2.0 testing
This is cut from the OpenTX manual:
"Throttle source defines what triggers the THx functions of the timers. It's common to set it to the throttle channel instead of the stick, so that throttle cut or other modifiers are taken into account."
So yes, it would seem that Reinhard's observations are correct, at least as to the timer start. The timer should not start of p3 is set to -100. I just reproduced the behavior using the THt trigger. It is definitely controlled by the throttle stick, regardless of what I set as throttle source.
It is not clear from the manual if changing Throttle source is intended to affect also the warnings.
I have posted an issue report here: https://github.com/opentx/opentx/issues/1235
"Throttle source defines what triggers the THx functions of the timers. It's common to set it to the throttle channel instead of the stick, so that throttle cut or other modifiers are taken into account."
So yes, it would seem that Reinhard's observations are correct, at least as to the timer start. The timer should not start of p3 is set to -100. I just reproduced the behavior using the THt trigger. It is definitely controlled by the throttle stick, regardless of what I set as throttle source.
It is not clear from the manual if changing Throttle source is intended to affect also the warnings.
I have posted an issue report here: https://github.com/opentx/opentx/issues/1235
Re: OpenTX - Nightly builds for pre-2.0 testing
I think it should.. for the reason I said above. People might want to use a pot as throttle and not the stick. . So, defining where the throttle is would make it safer.
Just my 2c anyway.
João
Sent from my GT-I9195 using Tapatalk
Just my 2c anyway.
João
Sent from my GT-I9195 using Tapatalk
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
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
Re: OpenTX - Nightly builds for pre-2.0 testing
Up to now, I saw this function always as the possibility of a different input for the timer (and only the timer) to get the timer running with a percentage, the same as Th% does.
I compared it with OpenTx r2942 and there it works as I was used to.
If you set the timer1 to Th% and T-Source to a pot, the speed of the timer depends on the position of the pot. The throttle channel is totally untouched.
btw, the T-Source is also the source for the throttle grafik of the statistic screen and on r2942, it follows the position of the pot (if T-source is a pot)
In 2.0.1 the grafik only displays constant 100% if T-source is a pot.
Reinhard
I compared it with OpenTx r2942 and there it works as I was used to.
If you set the timer1 to Th% and T-Source to a pot, the speed of the timer depends on the position of the pot. The throttle channel is totally untouched.
btw, the T-Source is also the source for the throttle grafik of the statistic screen and on r2942, it follows the position of the pot (if T-source is a pot)
In 2.0.1 the grafik only displays constant 100% if T-source is a pot.
Reinhard
Re: OpenTX - Nightly builds for pre-2.0 testing
jhsa is right. Throttle warning was recently changed so that it followed the Throttle Source setting, for people who use a pot or slider as their throttle control (mostly glider pilots).
So the only bug is that Thr% does not follow the source, works fine on Taranis but it's broken on stock indeed.
So the only bug is that Thr% does not follow the source, works fine on Taranis but it's broken on stock indeed.
Re: OpenTX - Nightly builds for pre-2.0 testing
So you say that in Taranis, the T-source, when using a pot, really replaces the throttle stick ??
As I don't have a Taranis, should I understand that
Reinhard
As I don't have a Taranis, should I understand that
Reinhard
Re: OpenTX - Nightly builds for pre-2.0 testing
When you choose a pot as T-source it's considered you want to use said pot as throttle control, yes. On all platforms.
Re: OpenTX - Nightly builds for pre-2.0 testing
Thanks for the clarification
Reinhard
Reinhard
Re: OpenTX - Nightly builds for pre-2.0 testing
And that is as it should be.. Throttle is throttle wherever it is. On a glider I understand that the throttle could be on a slider or a pot.
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
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
Re: OpenTX - Nightly builds for pre-2.0 testing
Or in some cases the throttle stick becomes a control for crow/flaps whilst the motor (if fitted) is controlled by a switch.jhsa wrote:On a glider I understand that the throttle could be on a slider or a pot.
Re: OpenTX - Nightly builds for pre-2.0 testing
As this also triggers the "Throttle warning" display at power on, the "Throttle not idle" message should be completed with the reason, which analog input gives the error eg:Kilrah wrote:When you choose a pot as T-source it's considered you want to use said pot as throttle control, yes. On all platforms.
"Throttle (P3) not idle"
Reinhard
-
- 9x Developer
- Posts: 2764
- Joined: Fri Dec 30, 2011 11:11 pm
- Country: -
Re: OpenTX - Nightly builds for pre-2.0 testing
This one is fixed.
Re: OpenTX - Nightly builds for pre-2.0 testing
Thanks
Reinhard
Reinhard
-
- Posts: 1
- Joined: Tue Jun 10, 2014 8:42 pm
- Country: United Kingdom
- Location: Coventry
Re: OpenTX - Nightly builds for pre-2.0 testing
Hi, I am new here (and loving the Taranis), does anybody know if 'Amber' is recording the missing sounds?
Scott Page wrote:I posted this in RCG but will here as well. I audited the sound packs against the original sound pack and also the popular "Amber" sound pack.
The following were added to 2.0
0110.wav = "and"
0139.wav = "foot"
0141.wav = "mile per hour"
0142.wav = "miles per hour"
a3_org.wav = "A3 Low"
a3_red.wav = "A3 Critical"
a4_org.wav = "A4 Low"
a4_red.wav = "A4 Critical"
eebad.wav = "Bad eeprom" (missing in Amber pack)
rx_org.wav = Reciever battery low
rx_red.wav = Receiver battery critical
timerlt3.wav = "Time up" (missing in Amber Pack)
To spell this out a little bit more - (for readers not developers) if you update to 2.0 but don't update your sounds as well, those are the sounds you will be missing.
Re: OpenTX - Nightly builds for pre-2.0 testing
Go over here to get your answer to Amber these guys have nothing to do with that.
http://www.rcgroups.com/forums/showthre ... 65&page=73
http://www.rcgroups.com/forums/showthre ... 65&page=73