gruvin / gruvin9x Goto Github PK

It should be possible to to add a few resistors and capacitors around the stock 
9X FET beeper/buzzer driver transistor to produce cleaner (not so square) 
waveforms for audio tones. 

If not, then replacing said FET with a bipolar transistor and a simple one pole 
RC filter could be done instead.

When a model is deleted, another model in the list is immediately loaded. 
There's a warning about doing this in the existing ER9X User Manual, since if 
an electric model is powered up (or a nitro model with its engine running) is 
'listening', bad things could happen. Not likely for a nitro model, but could 
happen more frequently with otherwise silent electrics.

One idea I had was to maybe disable PPM_out whenever a model is deleted and 
then produce a pop-up message saying something like, "WARNING: Model changed. 
OK to enable transmitter?"

There could be problems with some TX modules with this however -- like, some 
might get upset and crash or shut down and not fire up again when the signal 
returns.

Another idea might be to simply add the warning message at the delete 
confirmation. "SWITCH OFF MODEL!" -- or something like that.

Ideas and comments welcomed.

Please describe the feature you would like added

Display amount of energy drawn from a battery pack using FrSky telemetry.

Please offer any specific implementation methods you might have in mine

Use one of the A/D inputs on the FrSky telemetry RXes with a current shunt to 
transmit instantaneous current readings to the 9X.  On the 9X, integrate 
current readings over time to show total energy drawn out of a pack.  Maybe add 
the ability to set the pack capacity and trigger an alarm when some percentage 
of the pack's capacity has been exhausted.

Currently, all EEPROM writes -- including those that occur from changing a trim 
just one click during flight -- disable ALL system interrupts and make the 
whole system wait for the write to complete. Surely this is not needed and can 
be vastly improved?

I have witnessed extreme latency delays due (I believe) to this fault -- even 
just on the bench. Try moving a stick steadily back and forth, while changing a 
trim one click now and then. Not always, but too often enough, the servo will 
be seen to stop dead for about half a second.

Trainer mode channel labels should reflect channel order selection and output 
channel use order selection in TEMPLATES should be moved to model SETUP, as it 
should not relate only to loading in templates, but to the set-up of the model 
itself. This would be a more logical place for it to be when the TRAINER menu 
relies on it, also.

In more detail ...

Currently the names are fixed at ...
RUD => PPMout Ch1
ELE => PPMout Ch2
THR => PPMout Ch3
AIL => PPMout Ch4

People using, for example, Futaba's "AETR" scheme see ...

AIL => PPMout Ch1
ELE => PPMout Ch2
THR => PPMout Ch3
RUD => PPMout Ch4

The SPektrum/JR "TAER" ...

THR => PPMout Ch1
AIL => PPMout Ch2
ELE => PPMout Ch3
RUD => PPMout Ch4

... and so forth.

Any chance of 5 flight modes like my Multiplex Evo ?

Should have added an RTC to support the SDCARD file system already -- not to 
mention its use in telemetry logging. 

Need to make sure there's one there for V3.

What steps will reproduce the problem?
1. Plug in an external PPM source (another switched-off 9X will do)
2. Observe PPM calibration screen is working
3. Enter Model programming menus, change some mixes etc

A (n often long) error beep is emitted fairly often. Diagnosis confirms this is 
the PPM_IN captureRing buffer overflow warning tone ... 

gruvin9x.cpp:
ISR(TIMER3_CAPT_vect, ISR_NOBLOCK) //capture ppm in 16MHz / 8 = 2MHz
{
...
  if(nWr == captureRd) // ring buffer overflow
  {
    captureRing[(captureWr+DIM(captureRing)-1) % DIM(captureRing)] = 0; // destroy last value
    beepErr(); <========= HERE
...
}

Such an overflow should ideally never occur. Perhaps the call to evalCaptures() 
should be moved out of perMain() and into the already pretty busy per10ms()? 
Another option is to increase the buffer size (currently 8 x uint16_t)

I have noted that the main loop can take up to 38ms to complete, under certain 
(hitherto unknown) circumstances, as reported by the tmain value on the STAT2 
page. Hmmm.

(Note also however that the same issue occurs under ER9X on a stock radio.)

*SVN:Trunk-r478
VERS:V1.2-gruvin
BLD:285
DATE:14.01.2011
TIME:09:09:19


What steps will reproduce the problem?
1.If i copy a model without the fault and rename the model and sooner or later 
the alieron trim will start moving in flight.  
2. Only one model is affected
3. The issue was noted by Erazz 
http://www.rcgroups.com/forums/showpost.php?p=16679620&postcount=3215
http://www.rcgroups.com/forums/showthread.php?t=1266162&page=218


What is the expected output? What do you see instead?
For the Alieron not to move without input

What version of the product are you using? On what operating system?
Turnigy 9X (version 2 firmware) obviously the firmware is gone. TX is about 6 
months old and this issue only occoured after flashing.

Please provide any additional information below.

Having PPM-in is nice. Having the ability to do lots with it in the mixer 
settings is also nice. However, in practice, there's no way that I can find to 
have PPM-in values stuck into AIL/ELE/THR/RUD channels such that the trainer 
radio can take care of all the dual-rate and expo settings -- while the trainee 
radio just sends raw, linear position information.)

Thus, the trainee radio needs to have a duplicate set-up for all channels, 
making things quite tedious -- especially if several different models are 
involved.

I propose that an option be made available to have the trainer (THN) switch 
cause PPM1-through-4 to be mapped over top of (to replace) the local 
AIL/ELE/THR/RUD stick positions. This would then allow the trainee radio to 
have a simple, default set-up and the trainer radio to handle all the specifics 
for a given model.

The channel mapping for this should be programmable, thus allowing even mode 2 
radio trainees to operate through a mode 1 radio trainer.

Example ...

 Typical Futaba trainee radio ...
 PPM1 --> AIL
 PPM2 --> ELE
 PPM3 --> THR
 PPM4 --> RUD

... or ...

 Typical JR trainee radio ...
 PPM1 --> THR
 PPM2 --> AIL
 PPM3 --> ELE
 PPM4 --> RUD

... or whatever.

I suppose there's no reason we shouldn't be able to map PPM5-through-8, since 
they are available, at least when using another '9X radio as the PPM source.

That also brings up another point -- which is that, really, the PPM-out from 
our '9X radios should only carry the FOUR main control channels, not all 8. 
Why? Because servo movement and responsiveness from the trainee's perspective 
would be (4 x 1.5ms =) 6ms, or a net 150% better than the present, noticeably 
poor responsiveness from using all 8 channels -- with channels 5 to 8 just 
wasting time. This four-channel-only system on the trainee end could be a) 
optional and b) only occur when no RF power is detected (main power switch OFF).

Of course, an even better option would be to use a higher speed digital 
protocol across the PPM line. However, that would require a whole bunch more 
code again -- and might not actually be faster given the need to implement it 
using software only -- and I'm not aware of any existing standards for this.

The SW1-SW6 and SW7-SWC main screen views (where the graphical stick position 
boxes are) are very useful. 

But I think thse should be changed to be alternative views for that original 
view (with THR/RUD/ELE and AIL/GEA/TRN) -- and accessed by using [LEFT] and 
[RIGHT} keys from there

This would be similar to how the alternative view for the telemetry data works.

Copy/Paste from ER9X Issue: 190

----
What steps will reproduce the problem?
Switching to reverse throttle, direction of the trim buttons doesn't change

What is the expected output? What do you see instead?
throttle trim should be reversed too 

What version of the product are you using? On what operating system?
(ER9X r 273)
----

TODO: Not fixed as at gruvin93 r418

drivers.cpp in both trunk and branches/freesky in function 
eeprom_write_byte_cmp ...

{{{
///opt/cross/avr/include/avr/eeprom.h
static inline void __attribute__ ((always_inline))
eeprom_write_byte_cmp (uint8_t dat, uint16_t pointer_eeprom)
{
  //see /home/thus/work/avr/avrsdk4/avr-libc-1.4.4/libc/misc/eeprom.S:98 143
  while(EECR & (1<<EEWE)) /* make sure EEPROM is ready */
    ;
  EEAR  = pointer_eeprom;

  EECR |= 1<<EERE;
  if(dat == EEDR) return;

  EEDR  = dat;
  uint8_t flags=SREG;
  cli();
  EECR |= 1<<EEMWE;
  EECR |= 1<<EEWE;
  SREG = flags;
  // sei(); // !!! <<---
}
}}}

It would be advantagous to have both packs visable at the same time.


1) Could the size of the font be increased so that if can be seen easily when 
flying. Perhps the top and bottom of screen could have bar with rx and pack 
voltage bars with numbers in the middle
2) Ability to assign an alarm tone to Ora or Red for example.
3) Ability to easily calibrate voltage by entering the real world values of 
each. eg.below


12.6v = 2.1v = 4.2v
9.0v = 1.5v  = 3.0v

Thanks

This idea came from flame_hawk, via an email to the gruvin9x discussion group. 
I think it has real merit. (Gruvin)
- - - - 

Hi Guys,

I lost a plane the other week and found it using a combination of low signal 
beeps and switching to the range check mode. i placed my hand on diffrent sides 
of the aerial so that i could tell which side had the strongest signal.

I plan to expand on this by building a directional antenna. What I would like 
to know is how hard would it be to create another screen specifically designed 
for this purpose. Essentially it would need beeps as the signal became stronger 
with the ability to reduce sensitivity using one of the trim pots up the top as 
you got closer.

That would be nice to switch PB5 <-> PB0 because with the toogle property of 
PB5 port PPM could be handle by hardware without any latency regarding the 
timming datagram whatever the cpu workload and TIMER1_COMPA_vect interrupt 
would be keep only for scheduling the next event and not for swiching by 
software the PB0 pin .

Vincent

Please describe the feature you would like added
Add a USB Flash or SDCARD based bulk storage device to allow storing of more 
models and recording of telemetry data.

Editing a model name since r650 is buggy. The cursor starts one column too far 
left.

Please describe the feature you would like added

Ampair (parkflyers.org.nz) inadvertently suggested that different splash 
screens should be made for each hardware version firmware.

That is, if you've downloaded the gruvin9x-stock.hex file, your splash screen 
probably shouldn't include the word "telemetry" -- as in the present, 
"telemetry series".


Please offer any specific implementation methods you might have in mine

Currently, there are four binary versions available for download: stock (no 
hardware changes), frsky-no-speaker, frsky-speaker and plain gruvin9x.hex, 
which has all of Gruvin's hacks. The latter will need to be replaced by a 
gruvin9x-hacked.hex, since the PCBV2/3 platform will become the default.

So that's, umm, probably five (5) different splash screens. No problem! :-P

Bertrand

In model SETUP, there is still 'Trim Sw'. Is this still supposed to be there, 
now that there is a similar option on the new FUNCTION SWITCHES screen?

Also, the ability to set what switch to use for Trainer is no longer on the 
TRAINER screen but moved instead to the FUNCTION SWITCHES page.

Both of these seem counter-intuitive to me. I think that the trainer switch 
should be set on the TRAINER scree, like it used to be. I also think it's 
better to have "Trim Switch" right next to the trim options, in the model SETUP 
screen, no?

I do like the functions switches screen. But I don't think this is a good use 
for it. 

Also, although I decided to get rid of the 'TRIMS to Offsets" function, I have 
a local user here who would like the option to work that way for some things. 
Would it be easy to have that function added back to FUNCTION SWITCHES?

Another good thing to have on FUNCTIONS SWITCHES would be to assign a switch to 
get straight into telemetry view. Whilst I do prefer the new "telemetry in main 
views" thing, it is actually quite frustrating not being able to just use [DOWN 
long] to go straight to telemetry view, like we used to. So at least having a 
function switch for that would be good.

I would like to resolve all of the above before committing to stable, as we 
plan to do soon, if that is reasonable and agreeable to you.

The v4.0 LED back light circuitry was flawed, meaning the back light can never 
be turned off.

The chosen solution was to install an additional NPN transistor. All v4.0 
builders will have to do this to bring their boards to current 4.1 (and thus 
source code) design compatibility.

Cam has supplied images of all the mods needed so far. Please see the "Build 
Your Own Board" wiki page.

The sei() issued near the beginning of the USART RX INT handler leaves the 
return code (pops and original compiler generated sei) open to re-entrance.

The sei is needed as early as possible (directly after the RX byte is read), to 
enable global interrupts for the PPM_out INT handler to prevent excessive PPM 
jitter.

The only was to solve this problem (besides using hardware PPM_out switching -- 
another story on its own) is to write the entire USART RX INT handler in 
assembler. This will not be difficult.

NOTE: The chance of actual re-entrance occurring at 9600 baud serial receive is 
highly unlikely. But it should not be left a possibility.

Thanks to Bertrand for keeping on this until I finally realised there was a 
problem. I was putting too much reliance on the C compiler without checking the 
assembly code! My bad.

*What steps will reproduce the problem?*
Turn the unit on and observe the on-screen battery voltage display 

On some units, there is excessive ADC jitter, causing false low-bat alarms and 
generally looking ugly.

*What is the expected output? What do you see instead?*
A nice stable battery voltage

What steps will reproduce the problem?
1. Navigate to MIXER menu
2. Select or add a channel on a switch (eg. GEA)
3. Set "Warning" to 3

What is the expected output? What do you see instead?
Expect periodic "3-bips", but get anything from 1 to 3 bips at each interval -- 
most often 2 or 3, and when 3, sounds like the middle one is missing.

The "bips" should be marginally longer to make them more like short "beeps" too.

What steps will reproduce the problem?

The countdown timer currently beeps every second after reaching zero unless 
reset using the exit key or stopped using the assigned trigger switch.

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

It would be useful to know how long past the alarm time we have been flying, 
without looking at the LCD screen

I propose that things work exactly as now for countdown mode, but we add that 
the trigger switch (assuming it's a switch) could semi-silence the alarm, then 
leaving the beeps doing 1, 2, 3, 4, 5 bips for 10,20,30,40,50 seconds? Perhaps 
extend that to a one long beep at one minute, then reverting to 1, 2, 3 bips 
etc, and two long beeps at 2 minutes, and so forth?

In this way, we might know how long we have been flying beyond the alarm point, 
without looking at the screen.

In other words, a new 'Alarm recognised. Now counting up' state for the timer 
could be entered if the trigger switch is activated once in the 'zero-reached 
alarm' state.

What steps will reproduce the problem?
1.Turn unit on. Watch the display.

There seems to be a problem on the AT'2561/0 system where the watchdog timer 
triggers once after power-on. The splash screen appears (and can be clearer by 
pressing a button) and then a reset occurs and the splash screen re-appears.

If the splash screen is disabled, the reset still occurs.

That this happen only once is very odd, since the WDT should be re-initialised 
at each reset.

Further more -- when a WDT reset occurs, there should be no splash screen at 
all - regardless of the setting. The system should get back into full operation 
ASAP. The longer it takes, the longer a model could be flying with zero 
control. NOT good.

Tone pitch/frequency should remain as it was at the point low/mid/high is 
reached, rather than returning to default 'beepWarn' pitch.

Knowing the maximum main loop execution time is handy, but knowing a running 
average would be arguably more useful. Let's add that to STAT2.

Can the division of free adjustable rate?
So Flytron (1:11=max. 36.3V) dividers could be used as well!

Hi, here are my two ideas for improving the custom pcb:

1- add a switching regulator or a low dropout one. So the power efficiency can 
be further increased and 2S cells can be used.

2- read every cell's voltage with a multiplexer, and a third input can be used 
to sense light with a cheap photoresistor and turn on backlight only when in a 
dark place.

The NO DATA Alarm is currently a system wide setting only. It should also be in 
the model settings menus and eeprom storage.

myeeprom.h
typedef struct t_EEGeneral {
  ...
  uint8_t   enableTelemetryWarning:1;   // 0=no, 1=yes (Sound alarm when there's no telem. data coming in)
}


typedef struct t_FrSkyData {
  FrSkyChannelData channels[2];

  uint8_t   enableTelemetryWarning:1;   // 0=no, 1=yes *** SHOULD PROBABLY GO HERE ***

} __attribute__((packed)) FrSkyData;

What steps will reproduce the problem?
1. Connect slave TX to trainer port
2. Calibrate stick centres in PPMIN menu as normal
3. Moving slave stick slightly right results in sudden jump to large negative 
number. Moving left is OK, but range is very limited (20% of expected.)

What is the expected output? What do you see instead?
Something close to +/-100 results from moving slave stick full left/right

For electric models, I'd like to see an addition to the throttle-hold scheme.

As an option for any given model, when an assigned throttle hold switch is 
disengaged (throttle active) an on-screen pop-up menu would appear, asking for 
confirmation ...

THROTTLE ARM?
[MENU LONG] to confirm
Any key to cancel.

If cancelled, the throttle hold switch would need to be set and reset again 
before another confirmation would appear.

Why? Because electric models can be dangerous -- that's a given -- and because 
it's easy to bump a throttle-hold switch when carry models, etc -- however much 
we may think it is not.

Also, once when working on my electric 450 helicopter, with throttle-hold 
engaged to set up main blade pitch angles, I have actually had an accident 
where a piece of loose clothing flicked the throttle hold switch to "armed" 
when reaching for a tool! The result was anything but pretty, to be true!

Credit for this idea goes in part to Brano, in Ontario Canada. He implemented 
throttle hold using the [EXIT LONG] key in an on/off manner, favouring it to 
the toggle switches for extra safety. I came up with this slightly different 
idea when he described his solution to me.

(Yes, I know that two or more switches could be used for added safety. But that 
uses up switches often best put to other uses -- and it still isn't as fool 
proof as this system INHMO.)

What steps will reproduce the problem?
1. Load data in mixers (perhaps using a template)
2. Activate "CLEAR MIXES" at bottom of TEMPLATES 11/11
3.

What is the expected output? What do you see instead?
All mixer lines on MIXER 5/11 screen should be cleared. But instead, they 
appear completely unchanged.

(circa r825)

What steps will reproduce the problem?
1. Get to the SETUP / TRAINER screen
2. Navigate down to the "Cal" field
3. Press [MENU] to reset values to zero
4. Note that you are now in a hidden edit mode, where [Up] and DOWN] won't 
work. You have to press [MENU] again to exit edit mode.

Bertrand: I have no idea how to fix this, as I simply don't understand the menu 
and events system well enough. I'm sure there's something very simply that can 
be done though, which you are bound to know.

See "general_menus.cpp" line 413, as at r968

Thanks.

When a new model is created and named, the name entry field should 
automatically start from completely blank if it's the first time we are 
entering a name. 

This should not be difficult because I believe the name is in fact blank under 
these conditions anyway. It seems there must already exist code that recognises 
the name is blank and inserts "MODELxx" for display purposes only. For example, 
if you edit the name, "MODEL02", make no changes and exit edit mode, then the 
actual model name remains blank. But if you change just once character, then 
the whole name gets saved. Ex. "NODEL02".)

If the name is left blank (remains blank after exiting edit mode) then it 
should probably return to "MODELxx". However, it would seem that this will 
already be the case, if my observations above are correct.

This is a reminder for Gruvin to get to the bottom of a problem with his 
ATmega2561 based development unit.

For some reason, each and every ADC sample of the '2561's internal bandgap 
voltage reference returns a different value. If read are done immediately after 
the last, then the value steadily decrease, having started at a value almost 
twice what it should be. This does not happen with the '64A stock hardware. 

I've made a request for help with this at AVRfreaks.com: 
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=847208#847208

Meanwhile, I suspect the bandgap reference electronics in this particular chip 
is actually faulty. However, swapping the chip for another is something I 
cannot do without the right tools. :-/

What steps will reproduce the problem?
1. Just look at the ANA CALIB page any time

This started after the new fonts were added. I recall a mention of it over at 
ER9X. The fix is probably in the lcd_outdez function. (?)

What steps will reproduce the problem?
1. Set A1 such that measured RX voltage is greater than maximum graphical bar 
value
2. When the bar is plotted, it tries to go beyond the edge of the screen, 
causing serious issues.

What is the expected output? What do you see instead?
A maximum pixel count / line length needs to be enforced to prevent this.

What steps will reproduce the problem?
1. Switch unit off
2. Switch 3-way switch (IDL) to third (lowest) position
3. Switch unit on

System won't boot up. In my case, I get garbage all over the screen. There's no 
watch-dog reset or anything. It's just dead.

The DIAG screen indicates that ID01 and IDL2 are both functioning properly 
besides.

IDL2 is connected to PB), also labelled PCINT0 and /SS. Is there some function 
this pin does at system boot time if it's grounded?

What Version of the firmware are you running?

Repository UUID: f6e3ec8c-4711-3139-51d9-7b347ef5a272
Revision: 526
Node Kind: directory
Schedule: normal
Last Changed Author: gruvin
Last Changed Rev: 511
Last Changed Date: 2011-01-19 13:34:45 -0600 (Wed, 19 Jan 2011)



What steps will reproduce the problem?
Simple 4 channel set up.  TEAR

1.  Program channel 1 with switch THR with value -100 using EEP
 BTW EEP ver is below.

Revision: 246
Node Kind: directory
Schedule: normal
Last Changed Author: erezraviv
Last Changed Rev: 246
Last Changed Date: 2011-03-09 22:48:48 -0600 (Wed, 09 Mar 2011)

2.  Test in simulator.  This works.  hit the switch and the throttle output 
goes to -100  :)
3.  Upload to TX.  

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

No throttle output in either switch position.

The safety switch menu on the TX does not show the programming that I did under 
eep.  :(

Before I programmed the throttle safety cutoff switch the throttle was 
functional.


Is your forked version compatible with eep?  Have you changed the structures 
stored on the eeprom?  Do you have a branch of eep that I should use?



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


Please provide any additional information below.

#0  0x0000003163430215 in raise () from /lib64/libc.so.6
#1  0x0000003163431cc0 in abort () from /lib64/libc.so.6
#2  0x0000003163429696 in __assert_fail () from /lib64/libc.so.6
#3  0x0000000000418c7a in lcd_vlineStip (x=12 '\f', y=2 '\002', h=-14 '▒', 
pat=255 '▒') at lcd.cpp:323
#4  0x0000000000418da3 in lcd_vline (x=12 '\f', y=74 'J', h=-14 '▒') at 
lcd.cpp:344
#5  0x0000000000415a61 in menuProcStatistic (event=0 '\0') at 
statistics_views.cpp:42
#6  0x00000000004099f4 in perMain () at gruvin9x.cpp:1421
#7  0x0000000000403d26 in Gruvin9xSim::onChore (this=0x1f0c2c00) at simu.cpp:420
#8  0x0000000000406b4d in Gruvin9xSim::handle (this=0x1f0c2c00, 
sender=0x7fffe2a7bb30, sel=3801089, ptr=0x0) at simu.cpp:121
#9  0x00002b8ec8316416 in FX::FXObject::tryHandle () from 
/usr/local/lib/libFOX-1.7.so.0
#10 0x00002b8ec81a03fe in FX::FXApp::getNextEvent () from 
/usr/local/lib/libFOX-1.7.so.0
#11 0x00002b8ec819bc1f in FX::FXApp::runOneEvent () from 
/usr/local/lib/libFOX-1.7.so.0
#12 0x00002b8ec819dfbc in FX::FXApp::run () from /usr/local/lib/libFOX-1.7.so.0
#13 0x0000000000405755 in main (argc=1, argv=0x7fffe2a7c408) at simu.cpp:470

The number of hardware mods required for some of the more advanced extras -- 
like mass storage and mp3/apcm audio for telemetry etc -- are becoming too 
tricky to handle on the original PCB.

One thing I want to do for example if reconfigure all the trims and button 
switches into a 8-bit 4x4 scanned matrix, in order to free up most of PORTB on 
the ATmega. This requires disconnecting all the existing switch GND circuits 
and has proven impractical to do on the stock PCB, without major butchering.

Then there's the already 'fiddly' changes just to free up USRAT0 for telemetry 
data, and even more tricky stuff to free up USART1. These mods alone are too 
tricky for all but the most steady-handed and skilled soldering-iron wielders I 
should think.

We're also going to need more programming space if we want to implement mass 
storage without having to purchase relatively expensive external modules.

I've got a sneaky plan for a 3D PCB that would replace the ATmega with a '128 
version while also breaking out the new connections I'm using. But, there will 
soon come a time when a completely new PCB starts aking a lot of sense. 

Preliminary work has already begun on this, with low-volume Chinese 
manufacturing lined up for the future to keep costs down. Time frames are 
completely unknown at this stage.

But really, why? Well, I want to take this project as far as it can go -- 
especially in the telemetry context. If I don't lose motivation through lack of 
interest from others, some pretty cool things emerge in time.

PPM_IN is not working properly and in fact can be made to crash the system with 
resulting EEPROM data corruption.

PPM in samples are recorded as effective 10-bit values (0-to-1024) whereas 
internal stick ADC samples and PPM out is 11-bit (0-to-2048). This results in a 
multiplier of "2.0" being needed on the PPMIN calibration page to make things 
works as expected. This I don't like.

Solution: Add a *2 to the (two?) places it will be required.

This email received with idea and links for implementing a boot loader than can 
re-flash the 9X from the SD card....

On 15 August 2011 08:21, finjjo <[email protected]> wrote:

    I like to see SD card reader to used for FW load (like i.e. in DX9)

    My propose is following.

    When you turn 9X ON boot loader check SD card holder switch status and
    if it is pushed (SD card in place).
    Boot loader read firmware.hex (or bin) from card and flash it to MCU
    memory.

    I link few site what I think might be helpful to do that boot loader.
    http://seili.net/weblog/2010/07/14/avr2boots-dual-bootloader-released/
    http://false.ekta.is/2011/06/petitfatfs-sd-card-bootloader-for-atmega2560-arduino-mega-2560/

    I can also help develop that as soon as I get my own 9X from
    HobbyKing...

    I'm waiting to get gruvin9x custom board, I hope you sell those
    soon....

Note to re-work bat voltage averaging (BATVOLTS=AVERAGE) as a running 'this 
plus last' average instead of averaging the previous 10 live samples -- for 
better efficiency.

Gruvin.

This is a hardware compatibility issue, not fixable by code (alone).

What steps will reproduce the problem?
1. Use a 'buddy lead' to connect a Spektrum (or other?) brand radio into the 
'trainee' jack on the back of the '9X
2. Got to PAGE 2 in the Set-Up menus 'PPMIN'
3. Note that very little, if anything happens when you move the sticks on the 
trainee (slave) radio.

What is the expected output? What do you see instead?
PPM-in should work

The problem is caused by the '9X expected full 5V-TTL level signal from the 
PPM-in phono jack. But the Spektrum (and others?) radio only makes available a 
capacitively decoupled approx. 1.5V peak-to-peak signal. 

An additional buffer transistor (or external adaptor) will be needed if this is 
to be overcome. If the buffer inverts the signal, a small code change will also 
be required.

What steps will reproduce the problem?

See here: http://www.rcgroups.com/forums/showpost.php?p=17666813&postcount=5365

Fix

A fix was written. See here: 
http://www.rcgroups.com/forums/showpost.php?p=17710737&postcount=5399

--- Suggest using a scope to watch PPM out while messing about with various 
beep causes to confirm fault in gruvin9x or not. Fix as required.

Notice of this possible fault from: Bertrand, via the discussion group. Thanks 
mate.

We need to take a look at the brown-out and watchdog reset conditions, such 
that things like "throttle warning" and the start-up splash screen do NOT 
prevent system-start-up and PPM_out from beginning when an emergency system 
reset occurs under WDT or BOD conditions.

I started to look at this already but have hit a snag in that it appears that 
even a normal power-up is setting all three of the power-up, external-rest and 
Brown-Out detected flags. It would be illogical to simply reset these at 
start-up, since that logic dis-allows knowing if the next time the flags are 
detected, maybe they're for real this time.

So we need at least a work-around solution. Some way of definitively telling 
the difference between a user power-on via the main switch and a fault-sourced 
reset. Really, we need to ask Atmel et al what is going on with their power-on 
reset logic, so that we can get these important status flags to work correctly 
in the first place.