PPM-in for trainer/trainee use needs an overhaul?

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by gru...@gmail.com on 23 Dec 2010 at 5:34

[GoogleCodeExporter]

I will start working on this feature as I really need it: mixers become too 
complex with PPM inputs.

What about adding this feature in the General/PPMIN screen (2/6). There would 
be:
- a choice for the switch (OFF means not used)
- a choice for the mode (Futaba/JR/other?)

Original comment by bson...@gmail.com on 12 May 2011 at 7:03

[GoogleCodeExporter]

Take a look at TH9X. If memory serves, he's already done this sort of thing.
Some of the code there might be useful for us too.

I only wish I had half the time required to get it done myself any time
soon. But unfortunately, I just don't. Work is crazy busy.

Bryan.

Original comment by gru...@gmail.com on 12 May 2011 at 10:21

[GoogleCodeExporter]

Modification tested on er9x and adapted to gruvin9x
Attached is a svn diff

Original comment by bson...@gmail.com on 16 May 2011 at 5:58

Attachments:

• gruvin9x.diff

[GoogleCodeExporter]

Thanks for this. I'll take a detailed look as soon as I can find the time.
Hopefully by the end of this coming weekend.

Can you give a few details on exactly what the diff includes and provides,
so I don't have to read the code to get the full story? Thanks a tonne.

Bryan,

Original comment by gru...@gmail.com on 17 May 2011 at 2:03

[GoogleCodeExporter]

will do as soon as possible with last mike's optimizations

Original comment by bson...@gmail.com on 23 May 2011 at 11:43

[GoogleCodeExporter]

@bsongis -- OK, cool. I didn't get a chance in the weekend to integrate the 
last diff you sent or do any testing. So if the next next can be based on the 
same code (current checkout I guess) that would be cool. I intended to make you 
a submitter, to make things easier. But we probably have to organise a 
development branch and instigate a policy that only I merge to the trunk -- or 
something like that. In the meantime, diffs will have to do.

Really DO appreciate the work! Very. very cool. Thanks.

Original comment by gru...@gmail.com on 23 May 2011 at 9:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@bsongis -- Can we have that brief text of exactly what the diff in comment #3 
achieves please? It's not entirely clear from just reading the code and I don't 
currently have a sufficiently unmodified '9X transmitter to run the code on to 
see it that way, either. Thanks.

Meanwhile, I've created a repository branch, '/branches/ppmin-bsongis', just to 
store and later test these mods. The current version there includes the diff 
you supplied in comment #3.

PLEASE NOTE: All development work should be getting applied to /branches/frsky, 
rather than the trunk. The dev. version already contains many changes for the 
V3/4 circuit board. So it could be a real mission to integrate your PPM-IN 
fixes into there, later on. Thus, it would seem a very good idea to re-code 
these changes against /branches/frsky development version, before going much 
further. Thanks. 

(Then, I'll then be able to apply your future diffs directly to the main 
development code, when the time comes. Soon after that, we can make you an 
official code committer, so you can update the code directly -- if you want.)

Original comment by gru...@gmail.com on 27 May 2011 at 12:58

[GoogleCodeExporter]

I'm not so quick in comments ;) So ...

Basically this function adds the possibility to configure a trainer function 
for all models of the radio. It was possible before of course, using the MIXER 
menu, but it was really complicate and almost impossible to have dual-rates / 
expo applied to the trainee radio. It saves also some memory and mixers (which 
are limited).

1) TRAINER menu (general settings 2/6)

- "PPMIN" title changed to "TRAINER"
- PPMin multiplier / PPM input values / calibration kept as in previous version
- Added 4 lines to configure how the sticks values will be replaced by PPM 
values:
   * one stick = one line
   * any switch can be used to enable the trainer function for each stick
   * all PPMin channels can be used for each stick
   * it's also possible to replace ":=" the value by the PPM input or to add these 2 values "+="
   * the PPM input value can be weighted by -100% => +100% (and then this weight may be used to reverse the input value, which is helpful)

2) EEPROM change

Instead of having 8 int16_t in memory (for the theorical 8 PPM inputs), there 
is now only 4 structs in memory for the 4 first PPM input channels. It makes 
the previous EEPROM version almost compatible with this new version, as the 
global size for PPMin remains unchanged.

typedef struct t_TrainerMix {
  uint8_t srcChn:3; //0-7 = ch1-8
  int8_t  swtch:5;  //the switch used to enable the trainer function for this stick 
  int8_t  studWeight:6; // weight: -100% => +100%
  uint8_t mode:2;   //off,add-mode,subst-mode
} __attribute__((packed)) TrainerMix;

Original comment by bson...@gmail.com on 27 May 2011 at 7:15

[GoogleCodeExporter]

The diff included above also includes a fix for the PPM output!

Here is an explanation: almost any longer beep (including indication of center 
of a trim), turns off PPM output. The reason: something must change SIMCONTROL 
signal for 4066 and cause switchover of jack line to PPM IN mode, temporary 
(e.g. for one second), which disconnect PG4 from normal operation...

Now the fix: really simple in fact ... when the radio beeps the SIMCONTROL line 
is not any more read to avoid this switch PPM-out => PPM-in!

Bertrand

Original comment by bson...@gmail.com on 27 May 2011 at 7:20

[GoogleCodeExporter]

And yes ... it would make things easier for you and me if I could commit into a 
branch, thanks!

Original comment by bson...@gmail.com on 27 May 2011 at 7:29

[GoogleCodeExporter]

All I need is your Gmail address to add to the project 'committers' in the
project settings. Can you email me directly with that? gruvin [@] gm...l.com.
Thanks. (Sorry if I already have it. Can't find it right now.)

We can then use branches/frsky until such time as a (potentially) better
scheme shows up. Just bear in mind that the current code in there is under
development for the V3 PCB board. That said, it *should* still be compatible
with the stock version. I just haven't got around to testing that
thoroughly, yet. Cheers.

I should make it known that this will be the first time I have personally
ever had more than just me working on a code tree. So I'm open to any gems
of experience that might come my way. (You will be the 3rd committer. The
2nd is Cam, who is working on the 'V4' PCB design -- using the 100-pin
ATmega2560.)

Bryan.

Original comment by gru...@gmail.com on 31 May 2011 at 1:55

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 21 Jun 2011 at 10:39

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 23 Sep 2011 at 1:52

• Changed state: Verified