souldiver / open9x Goto Github PK

The HowHigh module is handle by Open9x for altitude but not accessible as a 
input for the vario module it would be nice to have it because when configured 
into feet mode (on the module side) we have a pretty stable info with around 
33cm delivered of precision delivered twice per second. that query lead me to a 
second query.

Right now we just can declare into open9x in witch unit howhigh is working 
(meter or feet) and it would be nice to have the module in feet and have a 
display in meter on the RX side that would allow to not loose 1/3 of the 
precision.

Would be glad to implement myself if it help

Vincent

I just noticed "Slow" was now in 0.5s increments, cool! However the change 
wasn't applied to the other similar parameters (delay, and flight phase fade)

What steps will reproduce the problem?
0. use up-to-date build environment (avr-gcc 4.6.2, avr-libc 1.8.0)
1. make

What is the expected output? 
compiled code

What do you see instead?
errors like:

error: variable 'foo' must be const in order to be put into read-only section 
by means of '__attribute__((progmem))' -- this is for old avr-libc

open9x.h: error: 'prog_uint8_t' does not name a type -- with updated avr-libc

What version of the product are you using? On what operating system?
Fedora 16 (linux kernel 3.1.5), avr-gcc 4.6.2, avr-libc 1.8.0

Please provide any additional information below.
gcc 4.6.1 is known to be broken, but 4.6.2 is ok
( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 )

with new avr-libc, problem is bigger:

Now you get:
error: 'prog_char' does not name a type
and other alike. There is a change in pgmspace.h:
==============
   This typedef is now deprecated because the usage of the __progmem__ 
   attribute on a type is not supported in GCC. However, the use of the 
   __progmem__ attribute on a variable declaration is supported, and this is 
   now the recommended usage.

   The typedef is only visible if the macro __PROG_TYPES_COMPAT__
   has been defined before including <avr/pgmspace.h> (either by a
   #define directive, or by a -D compiler option.)
==============
Because g++ does not handle PROGMEM correctly (it's attribute in typedef,
right?) avr-libc doped all prog_uchar and other prog_* variables (it won't work
anyway). In new version you need to add #define __PROG_TYPES_COMPAT__ (before
pgmspace include) if you want to compile your old code, other way you'll get
lot of "does not name a type" errors. Using that #define changes errors to 
warnings "prog_char is deprecated".

Anyway, fast fix to get it compiled is that #define. The Right Way (not using 
undocumented gcc's features that got removed) is to change
(const or not) prog_char *
to something like
const char * PROGMEM

avr-libc added const everywhere already as it's the only way expected to work.

http://lists.nongnu.org/archive/html/avr-libc-commit/2012-01/msg00006.html

That all still does not help, because (old) PSTR definition is not compatible 
with new gcc (4.6.2, containing The Fix). It was fixed in avr-libc, but your 
copy of that definition in open9x.h needs that fix too:

-#define PSTR(s) (__extension__({static prog_char APM __c[] = (s);&__c[0];}))
+#define PSTR(s) (__extension__({static const prog_char APM __c[] = 
(s);&__c[0];}))

Also I had to remove --combine option. From gcc upstream (4.6 changes):
unrecognized option '-combine':
    The -combine option has been removed, it has been very buggy and has
    been superceeded by -flto.  Either drop it, or build with -flto.


That's short summary how to compile the code with in new build environment. 

The result does not work with all combination of avr-gcc 4.3,4.4,4.5,4.6 and 
avr-libc 1.6.7..1.8.0 (btw, avr-libc is 2.5 years old, the oldest maintained 
version of gcc is 4.4.6).

I know it's not a good solution for everyone to update his build environment, 
so I've searched for solution that would work with any avr-libc & avr-gcc 
combination (starting avr-gcc 4.3.3 & avr-libc 1.6.7 that can be found in most 
wide spread build environments on windows and mac). It was quite difficult 
because different old version are... "different" or just not compatible). It's 
quite a mess... I got everything from "only initialized variables...", 
"conflict of sections",... to data not placed in program memory at all. 


In the end, I've found following solution (PROGMEM redefinition is not needed 
with avr-gcc 4.6.2): 

============ example: ======================
#include <avr/pgmspace.h>
#undef PROGMEM
#define PROGMEM __attribute__(( section(".progmem.data") ))

typedef char pm_char;
const pm_char hello[] PROGMEM = "Hello world";

int foo(const pm_char *s)
{
  const pm_char *str = s; 
============================================

This uses new type pm_* instead of prog_* because new avr-libc does not provide 
such types unless you use special define in which case it spawns tons of 
"prog_* is deprecated" warnings. Anyway, prog_* or pm_* does not affect 
variable storage at all, it's just we can see this is some variable stored in 
program section, so we can't use it directly.

Every variable using data stored in progmem section needs to be const or 
avr-gcc won't like you.

On variable initialization and *only* on variable initialization, there must be 
PROGMEM used - only where you specify the real data which should be stored in 
program section.

This builds fine with avr-libc 1.6.7 & avr-gcc 4.3.3 AND avr-libc 1.8.0 & 
avr-gcc 4.6.2 without single warning. (I had to use -flto instead of -combine, 
but old version does not know -flto, new version dropped -combine, so this 
can't be fixed without automake or cmake scripts. Anyway, it's much easier to 
change one line in Makefile than change whole code.)

I've attached a patch with changes that applies above changes. I've build 
open9x without single warning and used it in my tx - added new aircraft 
configuration and used it with simulator for one hour.

La valeur rpm indiquée sur l ecran n excede guère les 150 alors que mon 
hélice tourne aux alentours des 10000tr/m...

When we discussed the autoswitch option, we mentioned having it work for 
analogs too (with something like analog input changed >20% or so, can't find 
the thread anymore). Is it still on the list, or has it been somehow forgotten?
If it was, it now IS on a list ;)

We should try to keep this issues page up to date so everybody can see what's 
considered and what went forgotten... too many places we mention things in!

The code in file open9x.cpp related to PPM input channel value and end-of-frame 
sync determination on line 1908  being:

---
  uint16_t val = (capture - lastCapt) / 2;

---

Appears to be fragile, as "capture" and "lastCapt" are values from free-running 
timer, the computation will be wrong each time the timer overflows and wraps 
around, thereby "capture" will actually be less than "lastcapt" after each such 
event, yielding the wrong result and corrupting subsequent channel value and/or 
sync computations.

It appears?

(If so, there may be similar errors related to free-running timer values 
elsewhere in code base?)

What steps will reproduce the problem?
1. Allumage de la radio

What is the expected output? What do you see instead?
La puissance du moteur est très très faible, malgré le réglage de la force 
à 5...
Je vais dans les réglages de la force, et j'insiste à droite (même si je 
suis déjà à 5) et d'un coup, le moteur réagit à pleine puissance.
Ensuite, il n'y a plus de niveau de réglage possible, c'est soit tout à fond, 
soit OFF...
J'utilise un moteur récupéré d'un vieux téléphone Nokia.

What version of the product are you using? On what operating system?
Open9X révision 607 sur ersky9x board

Please provide any additional information below.
Je ne suis pas sur d'être très clair, le comportement est assez étrange...

I thought that the original Splash Screen looked a bit plain so I made a 
somewhat more advanced one. It is in the form of a Gimp file and contains 6 
layers that can be turned on and off to create a number of different bitmap 
splash screens (i.e.xbm files).
Three of the possible resulting bitmap files are attached as well.

Best Regards
Kjell Kernen

Bonjour Bertrand,

D'abord merci pour ton travail que je trouve génial!
J utilise open9x depuis sa sortie, et avec la version 448 j ai des soucis sur l 
affichage pour la télémétrie frsky, notamment l ecran personnalisable ...
Pour le configurer, open9x me propose par exemple pour l altitude des kts, pour 
la vitesse des tour/m, des minutes pour l affichages de la vitesse ou des trucs 
dans le genre...

Avant la version 448 tout fonctionnait bien pour moi, est ce que j ai loupé 
quelque chose? Une modifier hardware ?

Bonjour Bertrand,
J ai réussi à me fabriquer un capteur de courant avec un acs756.. celui ci me 
permet d avoir une varation de 2,80v pour 0A à 0v pour 100A.
 Dans open9x, pour le réglage des entrées analogiques il n est pas possible d entrer une valeur d offset supérieur à la moitié de la valeur plein champ de l entrée analogique . Serait il possible de ne pas limiter cette valeur d offset? Cela permettrai d avoir une lecture confortable du courant..

What steps will reproduce the problem?
1. Select PPM 16 chanel
2. Set mixes so that You may reach -100 to +100 on all of them (all chanels to 
single stick will suffice)
3. Except selected 16ms frame rate (which is not real for 16 servos), all 
higher settings result in missing recognizable sync pause between PPM periods, 
so the module could detect start of new frame. Signal is lost.

What is the expected output? What do you see instead?
Normal servo control would be appreciated - I mean, assured at least 2.5ms sync 
pause between PPM frames (3ms would be safer).
Sync pause have to exist for sure between PPM frames, to avoid crashes in 
certain circumstances, e.g. after flaps deplyed.

What version of the product are you using? On what operating system?
Problem persist from August 2011 till now - 
Now tested with Open9x r936 EXT=Jeti

Please provide any additional information below.
32.5ms is still short for 16 servos at +100% = 2000us , plus initial pulse, and 
necessary sync pause. It gives 36ms, and even that does not take possible 
extended limits into account..
Problem may be reproduced at 8 chanels, but there is possible to set long 
enough period to avoid crash.

I checked out you telemetry updates and translated the new super long string 
definition.
I also went through the rest of the strings and made a small changes to other 
strings like tranlating Longitude and Latitude from English (Longitud och 
Latidud in Swedish :-)

The character encoder/decoder is appended.
Tested and functioning on Linux. Highly uncertain if it would work in Windows 
(I am almost sure that it will not work, but who knows).
The executables are compiled in Ubuntu. Should run on other flavors to, I guess.

What steps will reproduce the problem?
1. Set radio to TEAR or other channel order starting with throttle
2. Add throttle cut template
3. Enable throttle cut with THR switch
4. Browse through the function switch options

What is the expected output? What do you see instead?
Expected is nothing. But throttle goes to 50%


What version of the product are you using? On what operating system?
open9x-r515 2012-04-11

Please provide any additional information below.

Forum: http://9xforums.com/forum/viewtopic.php?f=45&t=677
Forum post:
But I was configurating this and suddenly my motor went on! At a save distance 
luckily. 

What happened is that I browsed through the options and when selecting THR, 
Security CH1 with 0 was auto selected. But THR was enabled by me because of the 
throttle cut. Created with the template. And CH1 is my throttle channel, so 
throttle went instant to 50% throttle!

By looking at the default channel setting (TEAR for me), it may be possible to 
change the default value of 0 to -100. It would make the system even more save.

Hi 
I have made a Swedish translation of open9x.
The texts are in the se.h file and compile just fine with the code tree I 
checked out yesterday.
You must use the two attached font bitmap files instead of the original ones to 
compile the Swedish language versions. Otherwise åäöÅÄÖ will not display.


Best Regards
Kjell Kernen (Dvogonen)

What steps will reproduce the problem?

Pressing the + or - button toggles the value of the channels to zero or back to 
stick position value.

What is the expected output? 
There should be no change

What version of the product are you using? On what operating system?
r766

Please provide any additional information below.

What steps will reproduce the problem?
1. Install a smartieparts 2.2 programmer board with backlight in your tx
2. Go to tx setup, and set up the backlight mode.

What is the expected output? What do you see instead?

That the backlight will go on and off as described by the documentation.
Instead, it does the opposite of what is expected.

What version of the product are you using? On what operating system?

SVN r1152

Please provide any additional information below.

This behavior is documented by smartieparts:

Starting with Rev 2.2, the backlight is designed to operate on by default to 
make it compatible with all firmware options.  However, in doing this it makes 
some firmware versions work "backwards".  Until a given firmware package has 
specific support for the Rev 2.2 board, you may have to program it to be "off" 
when you expect the light to be on, and vice versa. 

I simply toggled the definitions for BACKLIGHT_ON & BACKLIGHT_OFF to get it to 
work, as I didn't know if this should be a build option or yet another 
backlight menu entry:


--- open9x.h    (revision 1152)
+++ open9x.h    (working copy)
@@ -645,8 +645,8 @@
 #define BACKLIGHT_ON  PORTC |=  (1 << OUT_C_LIGHT)
 #define BACKLIGHT_OFF PORTC &= ~(1 << OUT_C_LIGHT)
 #else
-#define BACKLIGHT_ON  PORTB |=  (1 << OUT_B_LIGHT)
-#define BACKLIGHT_OFF PORTB &= ~(1 << OUT_B_LIGHT)
+#define BACKLIGHT_ON  PORTB &= ~(1 << OUT_B_LIGHT)
+#define BACKLIGHT_OFF PORTB |=  (1 << OUT_B_LIGHT)
 #endif

 #define BUZZER_ON     PORTE |=  (1 << OUT_E_BUZZER)

What steps will reproduce the problem?
1.Go to MIXER, doubleMENU select a row.
2.Move row and press MENU

What is the expected output?
Move Item only.
What do you see instead?
Item moves, but enters value editing mode. Sometimes is cursor stuck in editing 
mode on the next empty line on CHxx.

What version of the product are you using? On what operating system?
r760 stockT9X

Just noticed some text overlap in the mixer edit page on the French version 
that I didn't remember seeing - apparently the values for delay and slow were 
aligned to the other parameters in r987, and that's what shortened the 
available space. As it's rather hard to describe the parameter in some 
languages in so little space, why not instead move the other parameters to the 
right a bit so that Multiply just fits?

What steps will reproduce the problem?
1.Go to TEMPLATES, apply one.


What is the expected output?
What do you see instead?
No kursor movement possible after applying a TEMPLATE.


What version of the product are you using? On what operating system?
r771 in companion-simu

I want to suggest to introduce the modification of abscissa of the points of a 
curve like on Futaba's radios (8FG for example) because I think that it is very 
usefull, especially for special models like VPP because curves with special 
abscissa can be more accurate than a traditional 9-point curves !


Thank you


(and sorry for my English, I'm French)

What steps will reproduce the problem?
1. svn checkout (r621)
2. src/Makefile: AUDIO=YES, HAPTIC=YES
2. make clean
3. make

Many compiler errors under the CrossPack build environment on the Mac -- IE. 
the exact same one used for Gruvin9X without errors.

...

$ make

-------- begin --------
avr-gcc (GCC) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Generate Version-stamp:
//Automatically generated file (Makefile) - do not edit
#define DATE_STR "2012-04-23"
#define TIME_STR "17:49:33"
#define VERS_STR "2.00-"
#define SVN_STR  "open9x-r621M"
for f in board_gruvin9x.cpp open9x.cpp pulses_avr.cpp   stamp.cpp menus.cpp 
model_menus.cpp general_menus.cpp main_views.cpp statistics_views.cpp 
eeprom_avr.cpp lcd.cpp drivers.cpp o9xstrings.cpp audio.cpp gruvin9x/gtime.cpp 
gruvin9x/rtc.cpp gruvin9x/ff.cpp gruvin9x/diskio.cpp templates.cpp  ; do echo 
"# 1 \"$f\"" >> allsrc.cpp; cat "$f" >> allsrc.cpp; done

Compiling C++: open9x.elf
avr-gcc -mmcu=atmega2560 -I. -x c++ -gdwarf-2  -DREV1 -DF_CPU=16000000UL 
-DTRANSLATIONS_EN -DSPLASH -DFLIGHT_PHASES -DPCBV4 -DAUDIO -DHAPTIC 
-DROTARY_ENCODERS -DDECIMALS_DISPLAYED -DTEMPLATES -O2 -Wall -fno-exceptions 
-Wno-strict-aliasing -I. -Itranslations -Igruvin9x -fno-inline-small-functions 
-I../gtest-1.6.0/include  -fwhole-program allsrc.cpp --output open9x.elf 
-Wl,-Map=open9x.map,--cref  -lm
allsrc.cpp:1: error: expected unqualified-id before '-' token
In file included from 
/usr/local/CrossPack-AVR-20100115/lib/gcc/avr/4.3.3/../../../../avr/include/intt
ypes.h:37,
                 from open9x.h:40,
                 from board_gruvin9x.cpp:34:
/usr/local/CrossPack-AVR-20100115/lib/gcc/avr/4.3.3/../../../../avr/include/stdi
nt.h:159: error: 'int8_t' does not name a type
/usr/local/CrossPack-AVR-20100115/lib/gcc/avr/4.3.3/../../../../avr/include/stdi
nt.h:213: error: 'int8_t' does not name a type
In file included from open9x.h:46,
                 from board_gruvin9x.cpp:34:
gruvin9x/gtime.h:47: error: 'int8_t' does not name a type
gruvin9x/gtime.h:48: error: 'int8_t' does not name a type
gruvin9x/gtime.h:49: error: 'int8_t' does not name a type
gruvin9x/gtime.h:50: error: 'int8_t' does not name a type
gruvin9x/gtime.h:51: error: 'int8_t' does not name a type
gruvin9x/gtime.h:52: error: 'int8_t' does not name a type
gruvin9x/gtime.h:53: error: 'int8_t' does not name a type
In file included from open9x.h:74,
                 from board_gruvin9x.cpp:34:
/usr/local/CrossPack-AVR-20100115/lib/gcc/avr/4.3.3/../../../../avr/include/avr/
pgmspace.h:215: error: 'int8_t' does not name a type
In file included from open9x.h:75,
                 from board_gruvin9x.cpp:34:
pgmtypes.h:66: error: 'int8_t' does not name a type
In file included from open9x.h:86,
                 from board_gruvin9x.cpp:34:
myeeprom.h:61: error: 'int8_t' does not name a type
myeeprom.h:72: error: 'int8_t' does not name a type
myeeprom.h:72: error: 'int8_t' does not name a type
myeeprom.h:102: error: 'int8_t' does not name a type
myeeprom.h:102: error: 'int8_t' does not name a type
myeeprom.h:102: error: 'int8_t' does not name a type
myeeprom.h:102: error: 'int8_t' does not name a type
myeeprom.h:102: error: 'int8_t' does not name a type
myeeprom.h:102: error: 'int8_t' does not name a type
myeeprom.h:102: error: 'int8_t' does not name a type
myeeprom.h:102: error: 'int8_t' does not name a type
myeeprom.h:102: error: 'int8_t' does not name a type
myeeprom.h:150: error: 'int8_t' does not name a type
myeeprom.h:150: error: 'int8_t' does not name a type
myeeprom.h:161: error: 'int8_t' does not name a type
myeeprom.h:161: error: 'int8_t' does not name a type
myeeprom.h:221: error: 'int8_t' does not name a type
myeeprom.h:221: error: 'int8_t' does not name a type
myeeprom.h:221: error: 'int8_t' does not name a type
myeeprom.h:221: error: 'int8_t' does not name a type
myeeprom.h:221: error: 'int8_t' does not name a type
myeeprom.h:239: error: 'int8_t' does not name a type
myeeprom.h:239: error: 'int8_t' does not name a type
myeeprom.h:271: error: 'int8_t' does not name a type
myeeprom.h:292: error: 'int8_t' does not name a type
myeeprom.h:411: error: 'int8_t' does not name a type
myeeprom.h:411: error: 'int8_t' does not name a type
myeeprom.h:411: error: 'int8_t' does not name a type
myeeprom.h:446: error: 'int8_t' does not name a type
myeeprom.h:478: error: 'int8_t' does not name a type
myeeprom.h:478: error: 'int8_t' does not name a type
myeeprom.h:478: error: 'int8_t' does not name a type
myeeprom.h:478: error: 'int8_t' does not name a type
myeeprom.h:478: error: 'int8_t' does not name a type
myeeprom.h:478: error: 'int8_t' does not name a type
In file included from open9x.h:94,
                 from board_gruvin9x.cpp:34:
eeprom_avr.h:96: error: 'int8_t' does not name a type
eeprom_avr.h:100: error: 'int8_t' does not name a type
In file included from open9x.h:98,
                 from board_gruvin9x.cpp:34:
lcd.h:98: error: 'int8_t' has not been declared
lcd.h:103: error: 'int8_t' has not been declared
lcd.h:105: error: 'int8_t' has not been declared
lcd.h:106: error: 'int8_t' has not been declared
lcd.h:107: error: 'int8_t' has not been declared
lcd.h:126: warning: 'lcd_hlineStip' initialized and declared 'extern'
lcd.h:126: error: variable or field 'lcd_hlineStip' declared void
lcd.h:126: error: 'int8_t' was not declared in this scope
lcd.h:126: error: expected primary-expression before 'y'
lcd.h:126: error: expected primary-expression before 'w'
lcd.h:126: error: expected primary-expression before 'pat'
lcd.h:126: error: expected primary-expression before 'att'
lcd.h:127: error: 'int8_t' has not been declared
lcd.h:127: error: 'int8_t' has not been declared
lcd.h:128: error: 'int8_t' has not been declared
lcd.h:128: error: 'int8_t' has not been declared
lcd.h:131: error: 'int8_t' has not been declared
In file included from open9x.h:99,
                 from board_gruvin9x.cpp:34:
menus.h:83: error: 'int8_t' does not name a type
menus.h:97: error: 'int8_t' does not name a type
menus.h:98: error: 'int8_t' does not name a type
menus.h:105: error: 'int8_t' does not name a type
menus.h:106: error: 'int8_t' does not name a type
menus.h:115: error: expected initializer before '*' token
menus.h:117: error: 'int8_t' does not name a type
menus.h:118: error: 'int8_t' does not name a type
menus.h:119: error: 'int8_t' does not name a type
menus.h:123: error: 'int8_t' has not been declared
menus.h:123: error: 'int8_t' has not been declared
menus.h:123: error: 'int8_t' has not been declared
menus.h:123: error: 'int8_t' has not been declared
menus.h:140: error: 'int8_t' does not name a type
menus.h: In function 'void minit()':
menus.h:145: error: 'm_posVert' was not declared in this scope
In file included from board_gruvin9x.cpp:34:
open9x.h: At global scope:
open9x.h:463: warning: 'idx2char' initialized and declared 'extern'
open9x.h:463: error: 'int8_t' was not declared in this scope
open9x.h:502: error: 'int8_t' was not declared in this scope
open9x.h:502: error: expected primary-expression before 'bool'
open9x.h:502: error: initializer expression list treated as compound expression
open9x.h:521: error: 'int8_t' has not been declared
open9x.h:534: error: 'int8_t' does not name a type
open9x.h:555: error: 'int8_t' does not name a type
open9x.h:557: error: expected initializer before '*' token
open9x.h:667: error: 'int8_t' does not name a type
open9x.h:688: warning: 'calc100toRESX' initialized and declared 'extern'
open9x.h:688: error: 'calc100toRESX' declared as an 'inline' variable
open9x.h:688: error: 'int8_t' was not declared in this scope
open9x.h:689: error: expected ',' or ';' before '{' token
In file included from board_gruvin9x.cpp:34:
open9x.h:746: error: 'int8_t' has not been declared
In file included from open9x.h:823,
                 from board_gruvin9x.cpp:34:
audio.h:105: error: 'int8_t' has not been declared
audio.h:107: error: 'int8_t' has not been declared
audio.h:169: error: 'int8_t' does not name a type
audio.h:175: error: 'int8_t' does not name a type
board_gruvin9x.cpp: In function 'void board_init()':
board_gruvin9x.cpp:78: error: 'struct gtm' has no member named 'tm_year'
board_gruvin9x.cpp:79: error: 'struct gtm' has no member named 'tm_mon'
board_gruvin9x.cpp:80: error: 'struct gtm' has no member named 'tm_mday'
board_gruvin9x.cpp:81: error: 'struct gtm' has no member named 'tm_hour'
board_gruvin9x.cpp:82: error: 'struct gtm' has no member named 'tm_min'
board_gruvin9x.cpp:83: error: 'struct gtm' has no member named 'tm_sec'
board_gruvin9x.cpp:84: error: 'struct gtm' has no member named 'tm_wday'
open9x.cpp: At global scope:
open9x.cpp:70: error: 'int8_t' does not name a type
open9x.cpp:99: error: redefinition of 'char idx2char'
open9x.h:463: error: 'char idx2char' previously defined here
open9x.cpp:99: error: 'int8_t' was not declared in this scope
make: *** [open9x.elf] Error 1

As it's unnecessary, because a channel's output may already be easily inverted 
by assigning it a negative scaling factor in it's model mix specification. The 
"Limits" screen should be left for limits related things.

Thereby the column otherwise used to display a channel's inversion state, could 
be used to interactively display that channel's offset and limited output 
value, either as a percent, or PPM servo pulse width as may be desired. (Which 
seems more useful to know, and more closely related to channel output limits.)

What steps will reproduce the problem?
1.Turn on switch warning (I am using Down)
2.Put a switch in the wrong position
3.Turn TX OFF and then ON

What is the expected output?
A Switch Warning saying something like:
Brytare Påslagna! (=Switches on)
Stäng av dem      (=Turn them off)

What do you see instead?
Brytare Påslagna! (=Switches on)
Slå av gasen      (=Turn off the throttle)
Stäng av dem      (=Turn them off)


Please note that the throttle is not on and turning throttle alarm on and off 
has no effect.

Build info:
SVN version: 448
Date:. 2012-03-28

The switch startup warnings:

- It would be nice if three-state setting were used for each switch 
(ignore/forward/reverse), so that some do not need to be in any particular 
position, for example a backlight switch.

This could be designated with a three-state check box, containing either 
nothing, an up-arrow, or down-arrow, or "--"/ " "/ "+", or simply 
"Off"/"Fwd"/"Rev")

And as mentioned on the forum, I also find the check-box settings difficult to 
see, so would also prefer that if graphics are used, they should be easy to see 
and differentiate.

Just tried r1100 with my "nearly full" eeprom file (attached). 
- Select model 9 (255 bytes). radio reports 345 bytes free.
- 1 click of right aileron trim. Model size now 256 bytes, free eeprom 150 
bytes (huh?)
- Cycle power -> EEPROM alert - but there is already a temp file there, so we 
have more than enough eeprom left!

So.. what about this?

[quote="Kilrah"]So if my understanding is correct, the old file should be 
discarded right after the new one has been successfully written. And a more 
sensitive approach to triggering the low eeprom alert would be if(available 
memory < ((current model size + whatever it can grow by on a single change, a 
couple of bytes?)) OR (same for general settings file))[/quote]

If the radio is powered up and shows a warning screen, the inactivity alarm 
won't activate.
Typical problem scenario: Turn radio on to flash it (no interest in dismissing 
the warning screens), and forget about it...

http://9xforums.com/forum/viewtopic.php?f=45&t=429

Currently, when connection is lost between an FrSky receiver and the TX, the 
telemetry screens just freeze at the last good received values. This is good as 
it allows to see what happened just before the link was lost, but at the same 
time is confusing because nothing shows the link has actually been lost.
Having the RSSI fields show obviously that this is the case, by flashing 0, 
saying NO DATA or such would improve feedback.

I checked out the updates you made today.
I have now updated the se.h file to use the \200\201... notation for 
åäöÅÄÖ. After the modification I test built the simulator and it worked 
fine! 

P.S I saw that you had inserted a test string on top of the model page. I 
changed this back to the original text.

I missed that the TR_VCURVEFUNC string contained the special character |
This character is used to represent ä in 7-bit ASCII, and in my translation 
process the |:s got replaced with ä:s, which looked very strange.
A corrected file is attached.

Trying to gather all suggestions on here, easier than having them lost in the 
middle of a forum thread.

Now we have model-specific switch and throttle alerts, it makes sense to 
enforce them when changing model. 

What steps will reproduce the problem?
1. Edit the Makefile in emacs
2. Run the emacs save-file command

What is the expected output? What do you see instead?
I expect the file to be saved.
Instead, I get prompted about "Suspicious whitespace."

What version of the product are you using? On what operating system?
svn revision 1084

Please provide any additional information below.

This is solved by deleting some extraneous whitespace on otherwise blank lines. 
See attached patch.

This is an intermittent issue where the haptic will sometimes turn on full 
blast on the ARM board - when programing the system.

It seems to happen every alternative time!

I suspect the issue is that the port needs to be 'turned off' for the USB mode 
of operation to prevent power going to the motor.

What new feature/ability do you want?
Using TRIM button to adjust The Current EXPO/DualRate value of the associate 
Stick if exist.
We normaly adjust the TRIM value when the stick is around the center position, 
and anyway its difficult to use TRIM button when you use your finger to push or 
pull a stick at the same Time.
Why not changing the TRIM button Behavior when the stick is push or pull at 
more than 70% of the course to impact the DUAL RATE value. That would allow 
quick modification on the field without entering the menu. 

What is the expected output?
IF a stick is PUSH or PULL at more than 70% of the center then trim button will 
affect DUAL RATE instead.

Please provide any additional information below.
Fact is i have already modify for my own use ER9X code to try this behavior and 
i found it very very cool.
Exemple  
 1) i was using my throttle to adjust the camber of my F3K wings so full throtle was my Full speed mode and no Throtle was the thermal mode with this functions i was able to modify during fly both function in a very natural way.
2) on the ground i could adjust my elevator down trow just by push the elevator 
stick UP and using elevator TRIM
This could be  a (on/off) property associate with each EXPO/DualRate property 
so you could control this behaviors.

This is really a open proposition i am e curious to know if anyone else would 
find this useful ?

As now i am seriously considering to jump into OPEN9X (love the function & and 
love the code cleaning) and would love to contribute to the coding.
Right now i am studying the OPEN9X code but feel confident that i could help to 
actualy propose and code new function if you invited me onboard. 

What steps will reproduce the problem?
1.select a model to copy or move in the model menu
2.move model up or down quickly or by holding up/down button to move the model 
around fast 

3. tell it to proceed with the operation

What is the expected output? What do you see instead?
it should complete the operation and return to the menu
instead it completely freezes the whole system and will not reset or reboot 
until a hard shutdown is performed (yank the battery)

What version of the product are you using? On what operating system?
revision 606 of open9x-arm-heli-templates-en.bin this has been an issue since i 
first tried open9x at revision 541

Please provide any additional information below.

Small and big extension files for Swedish fonts. Just as ordered.

Two different bitmap formats for each font size. One bitmap with room only for 
the new fonts and one with identical size to the original font bitmap.

What steps will reproduce the problem?
1.Set SwitchStartupWarning to UP
2.Switched ON radio allways warns.

What version of the product are you using? On what operating system?
r767 stock T9x

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Trims only beep once every 2 clicks now (stock board/beeper, trim step fine)

Petits ajustements de traduction

The character map of the larger font has a white line above and below each 
character. Yet again I have no clue if this is what is easiest for you, but I 
have added a white line on top and bottom of each character.

Nothing more to say :)

RX Channel order in Radio Setup is hardcoded to RETA and its combinations - 
should be localized to match stick names in other languages

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

Here are the special Swedish characters in the smaller font.

I tried to figure out the positioning of the character by looking at the bitmap 
file. It seems like each character has a line of white space at the bottom so I 
aded a blank line below each character.

1. Assign throttel security switch to the lowest possible value (-126)
2. Flip the switch
3. Observe the channel output screen. 

I expected to see the channel output for channel 1 (my throttel channel) as a 
filled line on the left hand side of the center.

Instead I got a solid line over both the negative and positive sides of channel 
5! Nothing was shown on channel 1.
.

Sound alerts when triggered by the function system need to have a limit on the 
rate at which they are triggered.

Issue as follows:

Alert triggers for low battery - to do a 'siren'.  Siren takes 3 seconds to run.

If we keep firing an alert to the queue every 1 seconds.. then the audio will 
go absolutely crazy!

The solution I believe is to trigger the audio alerts in response to the 
'trigger' once every 4 or so seconds.  The exact figure does not need to be 
configurable - but should be long enough to allow all alerts to play... then 
pause.. then play.

Says it all - so we can check if the FAS-100 actually does report a voltage 
measurement or not, and we can add it in the voltage sources :)

As also listed for companion9x, although likely really an open9x issue.

- The order of Rud/Ele/Thr/Ail within Expos/DR should likely corresponded to 
the order defined in general settings, which I presume it should as it says 
"Channel Order (for Templates)". If I set my default to mode 2 (RTEA), the 
order as they appear in for Expos/DR is not effected, it would be nice if they 
reflected the default selected order.

- lastly, it would be nice if Expos/DR also supported negative weights as can 
be specified for mixes, and thereby instead of having to define a negative 
curves, the control may simply be given a negative weight,
(I thought this worked before, but I must have been wrong.)

What steps will reproduce the problem?
1.Go to trainer screen, to the RETA rows.
2.Moving cursor to the side changes values in colums.


What is the expected output?
Not to change values before Menu is pressed.
What do you see instead?
Cycling through colums increases/decreases values.

What version of the product are you using? On what operating system?
r749