souldiver / open9x Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/open9x
Automatically exported from code.google.com/p/open9x
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.
Original issue reported on code.google.com by [email protected]
on 28 Feb 2012 at 9:13
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.
Original issue reported on code.google.com by kjell.kernen
on 4 Mar 2012 at 10:42
Attachments:
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)
Original issue reported on code.google.com by [email protected]
on 1 Jul 2012 at 9:08
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!
Original issue reported on code.google.com by [email protected]
on 23 May 2012 at 10:32
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...
Original issue reported on code.google.com by [email protected]
on 25 May 2012 at 12:35
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 :)
Original issue reported on code.google.com by [email protected]
on 5 Jul 2012 at 5:15
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.)
Original issue reported on code.google.com by [email protected]
on 9 Jun 2012 at 4:34
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
Original issue reported on code.google.com by [email protected]
on 13 May 2012 at 10:29
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 :-)
Original issue reported on code.google.com by kjell.kernen
on 22 Mar 2012 at 3:54
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 28 Feb 2012 at 6:23
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...
Original issue reported on code.google.com by [email protected]
on 5 Apr 2012 at 8:46
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
Original issue reported on code.google.com by [email protected]
on 11 May 2012 at 7:22
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
Original issue reported on code.google.com by kjell.kernen
on 3 Apr 2012 at 8:23
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.)
Original issue reported on code.google.com by [email protected]
on 26 May 2012 at 3:41
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.
Original issue reported on code.google.com by [email protected]
on 1 Feb 2012 at 10:34
Attachments:
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.
Original issue reported on code.google.com by kjell.kernen
on 3 Mar 2012 at 11:49
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 10 May 2012 at 8:10
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.
Original issue reported on code.google.com by [email protected]
on 24 May 2012 at 11:03
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
Original issue reported on code.google.com by kjell.kernen
on 2 Mar 2012 at 10:39
Attachments:
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)
Original issue reported on code.google.com by [email protected]
on 18 Jul 2012 at 8:48
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.
Original issue reported on code.google.com by [email protected]
on 31 May 2012 at 7:42
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.
Original issue reported on code.google.com by [email protected]
on 12 May 2012 at 9:06
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.
Original issue reported on code.google.com by [email protected]
on 10 May 2012 at 9:09
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.
Original issue reported on code.google.com by kjell.kernen
on 3 Mar 2012 at 9:56
Attachments:
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?
Original issue reported on code.google.com by [email protected]
on 1 Jul 2012 at 9:03
Attachments:
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]
Original issue reported on code.google.com by [email protected]
on 10 Jul 2012 at 9:30
Attachments:
RX Channel order in Radio Setup is hardcoded to RETA and its combinations -
should be localized to match stick names in other languages
Original issue reported on code.google.com by [email protected]
on 23 May 2012 at 9:03
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)
Original issue reported on code.google.com by kjell.kernen
on 2 Mar 2012 at 10:32
Attachments:
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.
Original issue reported on code.google.com by kjell.kernen
on 6 Mar 2012 at 12:10
Attachments:
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.
Original issue reported on code.google.com by pbootsma
on 13 Apr 2012 at 12:15
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.
Original issue reported on code.google.com by kjell.kernen
on 3 Mar 2012 at 9:53
Attachments:
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.
.
Original issue reported on code.google.com by kjell.kernen
on 23 May 2012 at 9:36
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.
Original issue reported on code.google.com by [email protected]
on 26 May 2012 at 6:23
Nothing more to say :)
Original issue reported on code.google.com by [email protected]
on 30 Jun 2012 at 7:44
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 4 Jun 2012 at 11:23
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.
Original issue reported on code.google.com by kjell.kernen
on 3 Mar 2012 at 10:58
Attachments:
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 ?
Original issue reported on code.google.com by [email protected]
on 3 Apr 2012 at 12:40
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)
Original issue reported on code.google.com by [email protected]
on 22 Jul 2012 at 5:42
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?)
Original issue reported on code.google.com by [email protected]
on 23 Mar 2012 at 5:40
Petits ajustements de traduction
Original issue reported on code.google.com by [email protected]
on 3 Feb 2012 at 6:11
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.
Original issue reported on code.google.com by [email protected]
on 24 Jul 2012 at 5:09
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 21 Apr 2012 at 2:27
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
Original issue reported on code.google.com by [email protected]
on 16 Jun 2012 at 10:08
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..
Original issue reported on code.google.com by [email protected]
on 5 Apr 2012 at 8:38
Trims only beep once every 2 clicks now (stock board/beeper, trim step fine)
Original issue reported on code.google.com by [email protected]
on 10 Jul 2012 at 9:27
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...
Original issue reported on code.google.com by [email protected]
on 29 Apr 2012 at 6:32
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.
Original issue reported on code.google.com by [email protected]
on 10 May 2012 at 9:13
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.
Original issue reported on code.google.com by [email protected]
on 9 Jun 2012 at 11:55
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
Original issue reported on code.google.com by [email protected]
on 23 Apr 2012 at 5:53
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
Original issue reported on code.google.com by [email protected]
on 13 May 2012 at 10:38
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.