Closed GoogleCodeExporter closed 9 years ago
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
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
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:
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
will do as soon as possible with last mike's optimizations
Original comment by bson...@gmail.com
on 23 May 2011 at 11:43
@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
[deleted comment]
[deleted comment]
@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
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
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
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
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
Original comment by gru...@gmail.com
on 21 Jun 2011 at 10:39
Original comment by gru...@gmail.com
on 23 Sep 2011 at 1:52
Original issue reported on code.google.com by
gru...@gmail.com
on 23 Dec 2010 at 5:34