Improvement of stick to pulses latency on stock board

[bertrand35]

Ok. I have worked during these last days with Fox on a new patch. This patch makes the mixer run just before the pulses are calculated (~1.5ms between the end of mixing and setupPulses). Also the mixer doesn't run when not needed, and the menus are drawn just after the mixer calculations.

Don't hesitate to review the patch, and try it, if you feel the difference on the sticks please tell us!

Here is the description of the issue:
http://code.google.com/p/open9x/issues/detail?id=157

And here is our last patch:
http://code.google.com/p/open9x/issues/ ... 3358657048

Bertrand.

[bertrand35]

Latest patch:
http://code.google.com/p/open9x/issues/ ... 3361469670
Bertrand.

[bertrand35]

I have commited this change to trunk.
Also applied ton gruvin9x board (the mixer was running in an interrupt before). It will reduce stack usage and remove maintenance problems ...
Feedback welcome!
Bertrand.

[bertrand35]

New "enhancement" issue opened by Fox this morning:
http://code.google.com/p/open9x/issues/detail?id=164

So the idea is simple, we have reduced the delay between doMixerCalculations() and setupPulses(). Now we want to reduce the delay between setupPulses() and the time these pulses are out.

I will need to port it to sky9x board, or it will remain behind the stock and gruvin9x boards

Bertrand.

[MikeB]

Do I understand that you are only calculating the mixers once for each set of PPM pulses, but doing this as close to the start of the pulses as possible?
So if your PPM sequence is 22.5 mS long, this is the time between mixer calculations?

If so, I am wondering about complex mixes where a high channel is affected by a user control and a low channel is afected by the high channel, e.g.
CH01: +100% CH16
CH16: +100% AIL
(Very simple example).

Unless you do something very special in calculating the mixers in suitable order, a change on the AIL stick will affect the CH16 value on one calculation, but this result will NOT affect the CH01 output until the next mixer calculation. You will have the whole 22.5 mS latency on this. More complex dependent mixes may need more mixer calculation cycles, thus increasing the latency for these further.

Some time ago I investigated setting the output pulses "on the fly" so each pulse used the most recent calculated mixer value for it, as it is sent. With the mixer running as frequently as possible, this would reduce most of the latency problems completely. I did test this and it appeared to work with no problems. Most of the required code is still in pulses.cpp of er9x, but commented out.

Mike.

[myfox20]

Hi Mike, you may check the issue 164.

We do re-calculate the latency every time, and re-arrange the setupPulses.

In issue 164, I had captured the waveform between Flight Phase changed.
You will see what happens when the mix time increase from 2.2ms to 6ms.

We will miss, and ONLY miss 1 train. Then, re-sync again.
Normally, stay within the same Flight Phase , the mixing time is almost the same.

In addition, we DO consider the variation of mixing time.
So, we select a safe margin to prevent slight mixing time difference will miss the next train.

The patch above had been finished in Issue 157.
It also prevents from complex UI behavior occupies time slot for re-calcuating the mixing.

Now, Issue 164 is fixing PPM generation to saving another 10ms.

[Kilrah]

Yes, but Mike's comment still stands. If you cascade mixes, then latency will go through the roof. For example CH3:100% CH4, CH4: 100% CH5
As the calculation order is fixed, on the first pass CH5 will get calculated. CH4 was calculated before, so was using the "old" value. It will only be updated on the next cycle 22.5ms later. But then CH3 has the old value of CH4 as it was calculated before too... so that's another 22.5ms latency.

Running the mixers continuously means that mixers might be calculated 2-6 times between 2 pulse trains, and thus eliminate that problem.

[bertrand35]

Fox, Mike is right, but leave it with me
Bertrand.

[myfox20]

Yes, but Mike's comment still stands. If you cascade mixes, then latency will go through the roof. For example CH3:100% CH4, CH4: 100% CH5
As the calculation order is fixed, on the first pass CH5 will get calculated. CH4 was calculated before, so was using the "old" value. It will only be updated on the next cycle 22.5ms later. But then CH3 has the old value of CH4 as it was calculated before too... so that's another 22.5ms latency.

Running the mixers continuously means that mixers might be calculated 2-6 times between 2 pulse trains, and thus eliminate that problem.

For such indirect addressing , the most efficient way in compiler is re-organizing the sequence of computing.

That could be done in doMix()

After all, 2 phase compiling is enough (what a compiler does)
We can even check if some recursive error occurs within syntax checking.

Otherwise, even we call doMix() many many times, we cannot assume it's enough.
Also, we have no time to do >2 times mixing within a short PPM duration.

Before we have a fix, re-arrange the order should be the fast approach to eliminate the problem.

(I knew, sometime we use virtual CHs for mixing)

[bertrand35]

We don't need to execute many times the doMix(), only to recalculate the channels which are marked as dependant of other higher channels!
Bertrand.

[myfox20]

We don't need to execute many times the doMix(), only to recalculate the channels which are marked as dependant of other higher channels!
Bertrand.

Absolutely agree!!!

I didn't review the doMix() yet, that's why I didn't get Mike's idea.

On the other hand, I think re-calculation is unnecessary.

We can pre-process the mixing setting, sort the related channels, and let higher priority channels be processed first.
Then, if there is additional relationship, must be a 'recursive' loop.
(Is it a mistake??)

[njozsef]

I compile and flashed the R1702M from svn. This version includes the pach? or only optimized the code?
Stat screen latency is 2-3ms is gerat. (tx module frsky dht) (old firmware version 8-10ms)
PPM settings 18ms frame 300us delay
I will measure the actual latency of a full line of frsky system. (frsky inside latency 22msec)
Congratulations, thank you.

[Kilrah]

No, the latency improvement patch from issue 164 has not been committed to trunk yet.
On the old firmware, the time included LCD refresh time, but it now really only counts mixer execution time. This explains most of the "visible" reduction. The real changes aren't visible without a scope.
See here:
viewtopic.php?f=45&t=2210

[njozsef]

Thank you the faaast reply.

[myfox20]

...
We can pre-process the mixing setting, sort the related channels, and let higher priority channels be processed first.
...

To reduce atmeg64's computing time, we could pre-process the mixing setting, sort them by priority when loading a model from eeprom.

Then, a rank list is generated.

e.g.

mix_order[MAX_MIXERS] = { 6, 1, 3, 5, 2, 4, 0 };

When doMin(), we directly calculate from line 6 -> 1 -> 3 -> ...

for (uint8_t i=0; i<MAX_MIXERS; i++) {

MixData *md = mixaddress( i ) ;
Change to => MixData *md = mixaddress( mix_order ) ;

Only several bytes of RAM is used.

[MikeB]

You will need to pre-process again, every time the mixes are edited. The mixes will, of course, be ordered by channel number as well, all mixes on a channel must be processed in order for that channel, otherwise REPLACE mixes won't work properly. Also alloow for a mix to be dependent on its own channel! This is used to 'LOCK' a channel at the current output value.

Mike.

[myfox20]

Yes. Whenever a mixing setting had been changed (i.e. Load/Adjust/Copy/Paste/...
a simple rule is Load Model & Exit Mix menu) , we must call
rankingMixing( )

To sort all mixing, the strategy is somewhat like the 'bubble sort',
let all dependent mix# be moved forward.

After going through all mixing rules, the ranking should be adjusted correctly.
If not, there must be recursive setting.

[Romolo]

Not true, mixer ranking also changes with switches, i see the ranking solution not so simple considering limited resources on stock.

[bertrand35]

I also think that ranking will not be the best solution. Just a simple 2 phases mixer (second phase applies only to "dirty" channels) should be enough.
Bertrand.

[kaos]

Just two cents from my limited electronic knowledge (if any ). this is really good for faster processor like the SKY9x board. but for stock board, it may run into problem of not enough time to do all these. I am glad to see this reduction of latency is being worked on. but keep in mind if it is not working for the stock board, it may be good for SKY9X board, instead of compromised for the stock Atmega chip. There is a limit of a given chip.
Can't overclock a 1.2 GHz AMD chip to 3.0 GHz.

[myfox20]

The switches may change the logic of mixing, so I treat all related channels in a mix are referenced.
Even after ranking, we cannot get the only one solution, we get the most optimized mixing sequence.

Anyway, for limited resource, I agree that Bertrand's opinion, but if the calculation duration not exceed
a limitation (e.g. 6ms or etc.) we can loop more.

[Helle]

Hy,

not enought time, speed to slow?
does anyone check the XDIV XTAL Divide Control Register at the meag64?
does it realy run with 16MHZ intern?

Helle

[Kilrah]

Of course it runs at 16MHz. But the potential improvements mean quite a bit of extra calculations.

[bertrand35]

Improvement commited. More tests needed before releasing but first tests from Fox show an average latency which is by > 10ms better than other firmwares and previous open9x releases!

Bertrand.

[Kilrah]

...and a solution has also been implemented to eliminate the extra latency when using a channel of higher order in a mix. Up to 4 levels of indirection will now be calculated without any extra latency.

So, with something like this:
CH1: 100% CH2
CH2: 100% CH3
CH3: 100% CH4
CH4: 100% CH5
CH5: 100% ELE

all 5 channels will be updated simulateously directly on the next frame, instead of one after the other, frame by frame (CH1 was updated only on the 5th frame before the improvement).

[kaos]

reduction by 10 ms? wow, that is a lot. What is the overall latency before?

[Kilrah]

It depended a lot more on the mixer setup than now, and would never be lower than about 14ms. For example my (albeit ridiculous) mixer setup above could take up to 110ms. It can now go down to about 4ms, and the same setup would take no more than one cycle (22.5ms default). You now need VERY ridiculous setups to push it to 45

It's not constant simply due to the nature of the RC signal that is sent at regular intervals. If you flick a switch just after a frame has been calculated and sent then the new switch position will have to wait an entire cycle before being sent out, but if you flick it just before then it will be sent out straight away.

Sent via mobile

[Rob Thomson]

ill have to wait an entire cycle before being sent out, but if you flick it just before then it will be sent out straight away.

That would be a real killer.. waiting 10ms for it to go out!

[MikeB]

Indeed, with the nature of the PPM pulse train, each channel data is sent once at the frame rate (default 22.5mS). So if you change anything, just after the output pulse it is controlling is physically sent, then you will have 22.5 mS latency.

Mike.

[jhsa]

So much? That is an eternety..