openrcforums

Kilrah wrote:

driedeker wrote:Updated to 2.01 and the 10 second bug is still there on my setup says ten seconds ten times not 10 9 8 7 6 etc

Choose "Voice" as timer countdown mode.

I think there is a bug here, unless I am missing something. If I set the timer countdown mode to "Silent", I get a single beep at zero, and nothing else.

If I set the timer countdown mode to "Beeps", I get voice for 30 seconds, 20 seconds, 10 seconds, 10 seconds, 10 seconds, etc, on down to zero, and a single beep at the end. I would think that this mode would be beeps instead of voice from 10 seconds on down to zero, and maybe single beeps at 30 seconds and 20 seconds. The behavior this mode is exhibiting is certainly unexpected, at least to me, since it is called "Beeps".

If I set the timer countdown mode to "Voice" I get the 30 seconds, 20 seconds, 10 seconds, 9, 8 , 7, 6, etc, and a single beep at the end. This would seem to be the expected behavior.

Am I missing something?

Jon

Beeps is beeps UNLESS you have audio files called timer10.wav, timer20.wav and timer30.wav in your SYSTEM sounds folder, in which case those are played instead. Sounds like you have some, you might want to delete them if you're not happy with them.

That did it. I've never seen this documented anywhere, even for the 2940 firmware and earlier.
Thanks.

strange behaviour with input settings

input
Ail
source Ail
weight 80%
switch SA-

Mix
CH1
source Ail

when SA is different from -
CH1 freeze

Perfectly normal, you defined in the input that the Ail stick only controlled the Ail input if SA is middle. I.e. otherwise nothing controls it and it goes to center.

Kilrah wrote:Perfectly normal, you defined in the input that the Ail stick only controlled the Ail input if SA is middle. I.e. otherwise nothing controls it and it goes to center.

Ok
Now, if switch change output remains in last position
A proposal:

if I need a D/R function two lines are required
Ail
source Ail
weight 50%
switch A-

source Ail
Weight 100%
switch !A-

In my opinion in case of a singol line of input it colud be better if switch condition is not true the Ail will be equal to source
In case of multiple line the condition is determined by last true line , if no true condition are present output is equal to source

in case of D/R or similar function only a line is required
When the program becames complex it could be avoided strange behaviour or channel freeze

But this is only my opinion , please let me know your comments.

Thanks

if I need a D/R function two lines are required

Yes that's what's intended (although you would typically not put a switch in the "default" last line, which would then be active if no other is before it).

if no true condition are present output is equal to source

But as it's the Source field in a line that defines what the source is, if there is no active line there is no source! The input name has nothing to do with it, you may call an input Thr but source being S1 with one switch position, MAX in another, the Thr stick in another... If no line is active, then the input has no source and we can't guess what you want it to be, so it will stay still.

You simply always to define the default source for an input if you want it to always respond, with other lines replacing it if desired.

Kilrah wrote: But as it's the Source field in a line that defines what the source is, if there is no active line there is no source! The input name has nothing to do with it, you may call an input Thr but source being S1 with one switch position, MAX in another, the Thr stick in another... If no line is active, then the input has no source and we can't guess what you want it to be, so it will stay still.

The meanning of Input is clear and I think very usefull
only one consideration
Mixer and channel output are associated to Input
if, for some reason, an input freeze because no true condition is verified ,the related output (Through mixer)also freeze.
In simple configuration is easily verifiable, but in case of very complicated program may occour an impredictable situation
Of course hypothesis is very pessimistic...............

Has a 6th Flight Mode been discussed at all ? It would make sense with APM users.

Taranis has 9 flight modes, others have less because of limited resources.

What limited resource has the skyboard?

Sent from my GT-I9195 using Tapatalk

The sky boards also have 9 flight modes. The only limit on sky9x boards is the Lua scripts feature which won't be available (too little RAM).

I've seen a reference to Lua being able to be compiled to only use 5K RAM.
How much RAM does openTx on the SKY board actually use?

Mike.

Please do your magic Mike

5k without any script loaded, why not (it currently uses 10k if I remember well), but it will be difficult to launch scripts like the wizard which is 20k of text ... That's said, I would be really happy if it was possible to reduce the memory footprint, any idea is welcome (I reduced it a little bit already using packed structs).

Here is another example of what we can do with Lua scripts, here for telemetry screens: It is Altitude and vertical speed page with flight history.

At the left:
- Actual time elapsed (TMR1)
- Maximal height reached in actual flight.(this is also the scale of the altitude graph)
- History of the total-flight-time and maximal-height-reached during single launch. Launch start/end is determined by the TMR1 start/reset

In the middle:
- Record of altitude as you have guessed

At the right:
- Actual altitude
- Bars show positive/negative vertical speed.

.. designed by Martin Hotar!

That looks great Bertrand..

João

Bug in Companion 2.0.3 Jun 17 2014 (OpenTX for M128 / 9x board)

When editing a mix, the weight field always is set to +100% independent of the real value of the field in the mix. This wrong value also is put back into the mix line when the edit window is left with "ok".

Reinhard

This one is fixed in my workspace now, it will be in 2.0.4

bertrand35 wrote:Here is another example of what we can do with Lua scripts, here for telemetry screens:

Wauuu, I am impressed. This is even beyond my imagination what the Lua scripts can/will do. And Martin has produced another superb design, again.

Problem in OpenTx 2.0.2
When modifiying language files *.h.txt (on Win Xp editing the files with "Write") I get compilation errors with the Fi.h.txt and the Fr.h.txt files as soon as the files are saved with windos program "Write", no changes at all on the content, only open and save it.

Error is : UnicodeDecodeError: can't decode byte ... in position ...: invalid continuation byte.

Problem seems to be, these two files have "0A" as carriage return line feed at the end of a line while Windows Write uses "0D0A". That's the only difference I can find.

Reinhard

Write uses rich text AFAIK, you can't edit code with that. You need a plain text editor, like the basic Notepad if you've got nothing else, preferably something a bit better Notepad++, PsPad,...

I can edit and modify all files for OpenTx with "Write" without destroing them. They are saved in plain text. I compared the files with a hex editor. No difference except the line end.

Write "can" save files in RTF format but also as textdocument (plain text) or as Text-document - MS DOS Format or Unicode.
And as I said, I modified all the other language files in the same way and they do still work.

Notepad does not work with these two files, as it does not interpret a x'0A' as a carriage return line feed and thus displays all the text as one long line, broken at maximum line length.

Reinhard

btw. I just checked the original language files of my 2.0.1 download with and de, it and se open fine with "Notepad" (so they probably have 0D0A as line end) while all the others seem to have only the 0A as line end.

ReSt wrote:I can edit and modify all files for OpenTx with "Write" without destroing them. They are saved in plain text. I compared the files with a hex editor. No difference except the line end.

Write "can" save files in RTF format but also as textdocument (plain text) or as Text-document - MS DOS Format or Unicode.
And as I said, I modified all the other language files in the same way and they do still work.

Notepad does not work with these two files, as it does not interpret a x'0A' as a carriage return line feed and thus displays all the text as one long line, broken at maximum line length.

Reinhard

btw. I just checked the original language files of my 2.0.1 download with and de, it and se open fine with "Notepad" (so they probably have 0D0A as line end) while all the others seem to have only the 0A as line end.

Line endings are always problematic when collaborating on code using both Unix and Windows machines. Especially when a central repository is used for coordination. The editors, git clients and git server all have their own ideas about what is "right" and "wrong" and may all switch line endings without telling you.

I gave up fighting this issue a long time ago and only use tools that automatically adapt to whatever standard is used in the existing code. Write does not. I don't use it.

I agree with Kilrah; give Notepad++ a go. It is quick to start and has brilliant support for all forms of source code.

I found a circumvention and the files in question now work as I was used to.

When I edit the language files with a "normal" windows editor, all the files start with /* in the first line.

But when I use the "Edit" command from the command window, there are three characters in front of the /* (A hex editor shows that they are 0xEF BB BF)

No idea what that is good for, but after deleting these three characters and saving the file, I can use the 'normal' windows editor (Write) and modify the file without any problems at compile time

Reinhard

http://en.m.wikipedia.org/wiki/Byte_order_mark

File has utf8 coding. That header should not be removed! Use editor capable of handling utf8.

Thanks for that link.
That explains why the files behave different.
Only remaining question is, why are most of the language files 'normal' files and only the 'fre' and the 'fi' file UTF coded?
And they work fine when this identification is removed.

Shouldn't be all files of the same coding type?

Reinhard

That is because special characters for different languages can't be encode into ASCII code table.

I'm afraid, just that is not the case.

The *.h.txt files do not contain special national characters. They do contain strings like \200 up to \225 instead and then these strings are converted according to the language during compilation and written into the newly created *.h files

So to my understanding (that might be wrong) there is no need to have the *.h.txt files UTF coded.

But, as I said before, I do no longer have a problem with it as I can circumvent my problem.

Reinhard