open9x-r1670

[Kilrah]

Changelog is now available here for convenience:
http://code.google.com/p/open9x/wiki/Op ... angelog_EN

Code: Select all

=== [stock] ===
 * Flash savings 
 * Screen redraw optimisations
 * Stick -> servo latency reduced  
 * Fixed DSM2 instability  

=== [gruvin9x] ===
 * Fixed WDT reset when changing protocol 
 * Fixed stack overflow during backup / restore of models  

=== [sky9x] ===
 * Rotary encoder navigation improved

Previous announcement: open9x-r1563

[Helle]

Hy,
flashed r1670
runs faster! before 9,5ms, now 3,6ms with same eeprom and modell-test
stabil with less jitter
Is this real possible?
seems much better
will test with oszi
Helle

[Rob Thomson]

I believe a "fox" had something to do with that.

Sent from my Nexus 7 using Tapatalk 2

[Kilrah]

runs faster! before 9,5ms, now 3,6ms with same eeprom and modell-test
Is this real possible?

Just one thing, the main "visible" difference in the timing is that now "Tmix max" measures ONLY the mixer calculation time, while the older "Tmain max" also included screen refresh. That's why there is so much difference.

The "real" changes aren't all that apparent on the screen, but yes the screen is now redrawn a bit faster and less often, and more importantly the inputs are sampled and mixers are calculated as close as possible to when the next PPM frame is scheduled to be output. This is what allows lower latency.

[bertrand35]

Yes, that's a big improvement that we did with Fox (issues 157 and 160 in the project page). Fox is a new commiter in open9x, welcome to him, it was not an easy patch!
Bertrand.

[Rob Thomson]

Does he have a forum account yet? I should add him to the developer group

[myfox20]

Nice to meet you all...

Thank bertrand for inviting me to here, but I am always too busy to write something.

Actually, the new improvement all comes from bertrand.
What I do is just sitting & waiting for his new code.

Anyway, I would like to share some facts here...

Before:

The shortest latency of previous version

CH1 is GEAR switch
CH2 is PPM output, the timeslot 5 represents GEAR position

The longest latency

As you see, any changes must take place before PPM early enough, otherwise you will miss 1 train and
must wait for the next one.

The worst is that, UI & etc., are executed with doMix together.

The latency depends where you are (i.e. different menu / views has different latency),
and what you do (i.e. telemetry / bar drawing / EEPROM accessing / SD accessing / ...)
Most likely, the latency depends on the complexity of the screen drawing.

The STAT view displays the max latency between two doMix call. (include LCD update of course)

After:

sticks & switches are read, mixed, just be in time...
No matter where you are, what you do!

do mixing just before PPM setup

CH2 rising edge is when doMix started
CH2 falling edge is when doxMix completed
CH3 is PPM output

Any UI operation shall not affect the latency now.
The STAT view displays the max latency and UI not included. (Since UI doesn't affect latency anymore)
In other words, the value is the positive pulse width of CH2 above.

If the mixing setting is very very complex, and totally different between Fight Phase, when you switch
ID0 makes the computing time is significantly changed,then the arrangement of mix & PPM is adjust quickly.
That keeps you always enjoy the smallest latency in your flight.

Again, all of these must credit to bertrand.

(Ok, if you have any question, bertrand will tell you the whole story. )

[Kilrah]

Hmm I'm gonna be picky, but...
The "start" of a PPM frame is actually the first edge AFTER the pause. The pause is the "end" of a frame. So from your graphs, we're actually done calculating mixers a whole 11ms before the first servo order calculated there gets put out!
If we really wanted to optimize latency, we should be syncing with that one, not with the last edge of the "previous" frame

Not saying this is easy or even possible with the current code I don't know enough of, but ideally...

[myfox20]

kilrah, you got it!

But not as long as you expected, since if all channels are max, the sync. pulse is only about 4ms.
(i.e. PPM spec.)

In theory, we may optimize extra 4ms.
In practice, this is not easy.

The current data structure of sync pulse in *9x is prefix.
So, setupPulse begins with sync.

We were trying to change it to postfix
Again, this is not easy.

Anyway, trust me! bertrand is the MAGICIAN.
What he need is only time.

(Ha~~~ Bertrand, somebody is pushing you... )

[Kilrah]

But not as long as you expected, since if all channels are max, the sync. pulse is only about 4ms.
(i.e. PPM spec.)

Yeah, the improvement would actually depend on the channel values - on the pictured case it would be about 10ms, but when the values are all high then the improvement would get reduced to 5ms or so...
We'd also get constant latency with the "postfix" layout, not variable like now

(Ha~~~ Bertrand, somebody is pushing you... )

And then someone else is pushing for the X9D, so...

[myfox20]

But not as long as you expected, since if all channels are max, the sync. pulse is only about 4ms.
(i.e. PPM spec.)

Yeah, the improvement would actually depend on the channel values - on the pictured case it would be about 10ms, but when the values are all high then the improvement would get reduced to 5ms or so...
We'd also get constant latency with the "postfix" layout, not variable like now

(Ha~~~ Bertrand, somebody is pushing you... )

And then someone else is pushing for the X9D, so...

The frame length ( or frame rate ) is constant, e.g., 22.5ms

That's, no matter what the CHs value is, TX module scanning PPM & transmit via RF in fixed rate.
It's not variable now.

In other word, the maximum optimization is 4ms only.

The current design generates the whole bit stream when setupPulse, with sync pulse prefixed.

In my opinion, current patch is good enough.

The point is -- Now we can expect the max latency, can pre-determine the latency.
Never worry about if complex screen + complex mix will postpone the PPM generation and miss next train.

minus extra 4ms will be benefit of, but not must-have.

[Kilrah]

The frame length ( or frame rate ) is constant, e.g., 22.5ms

Yeah, but from your scope capture we sync on the last edge of the "previous" frame, right? The thing is, the sync pulse's length will vary...
For example if period is set to 22.5ms and we have 8x 1ms channels, then the sync pulse is 22.5-8=14.5ms, but if we have 8x 2ms channels it's 6.5ms... So if we really sync on the last edge then latency will vary by the same amount...

Or am I missing something?

[myfox20]

The length of leading sync pulse is variable.

We sync on the completion of a whole frame, not a specific pulse.

[bertrand35]

Here are the steps:
1) doMixerCalculations (in the main)
2) setupPulses (in the pulses interrupt)
3) send the pulses (in the pulses interrupt, one after one)

Our patch fixes the latency between 1) and 2) It doesn't change something between 2) and 3). Perhaps next step, Fox? I am even wondering if (at least with PPM) the setupPulses step could be removed...

Bertrand.

[myfox20]

Here are the steps:
Our patch fixes the latency between 1) and 2) It doesn't change something between 2) and 3). Perhaps next step, Fox? I am even wondering if (at least with PPM) the setupPulses step could be removed...

Bertrand.

It's possible if we could calculate pulse quick enough within the pulse ISR.

Even speeding up by schedule IRQ timer properly, ISR is only serviced when falling / rising edge.
Not in the 2MHz rate.

You know, the pulse width is long enough, over 300uS at least!!
Only tens of IRQ calls are wanted!!

This also saving a lot of RAM buffer.

[myfox20]

The most challenge is how we could keep the timing 101% accurate ?
ANY extra latency or speed-up causes unwanted servo jitter!!

Extreme short routine is not necessary, but keeping constant instructions is required in each ISR call.

If you have oscilloscope, carefully arrange code, enough time & test, it should not be too difficult.
Anyway, this is why I leave it alone now

[Scott Page]

Since updating: In screen 8/10 Custom Functions:
I seem unable to make any choices on Play Track -- that is -- I'm unable to choose a track to play.

I'm seriously over my head in all of this so it certainly could and probably is something I'm doing -- but seems it should be straight forward enough.

Also -- Am I able to add my own sounds (Assuming they are correct sound format) with my own names and choose them.

Finally -- a question. BG music? how is this to work?

[bertrand35]

Since updating: In screen 8/10 Custom Functions:
I seem unable to make any choices on Play Track -- that is -- I'm unable to choose a track to play.

I'm seriously over my head in all of this so it certainly could and probably is something I'm doing -- but seems it should be straight forward enough.

Also -- Am I able to add my own sounds (Assuming they are correct sound format) with my own names and choose them.

Finally -- a question. BG music? how is this to work?

Is there any error, nothing when you press on [MENU] when on the --- ?

Bertrand.

[Rob Thomson]

Is your sdcard actually working?

[Scott Page]

Is your sdcard actually working?

Yes, I can copy files to it (via USB connection with TX) and I can play files that were already set up.

Maybe I need to format the card and start from scratch.

So far to use my own files I've just renamed my file to match the name of an existing file -- and previously deleted the replace an existing file

I'd like to "play music" or add files of my own with my own names and choose them in open9x with the ersky9x board. Is this possible?

[Romolo]

Yes, it's possible...
using play file function..

[bertrand35]

Scott, would you send me one of the sounds you are trying to play? I will check the format and codec inside for you.
Bertrand.

[Scott Page]

Scott, would you send me one of the sounds you are trying to play? I will check the format and codec inside for you.
Bertrand.

Attached.

[Scott Page]

New observation. In C9x when I am on Custom Functions tab I'm able to "add background music" just fine - as well as assign any of the sounds in the C:\Users\xxxxxxx\Desktop\9XSOUNDS folder. Where I'm having trouble changing sounds is using the Transmitter interface -- not connected to the computer.

Additionally -- and quite curiously -- If I add sounds to the C:\Users\xxxxx\Desktop\9XSOUNDS folder they will show up in C9x as available.

I'm not able to test uploading this to the Tx just now because I'm in bed next to a sleeping bear and I'm horrified of making any beeping. In a few hours will be a sleeping beauty -- then I'llto take the Tx to work and give it a go on break.

[bertrand35]

I can't understand the english inside, but your Cleared.wav file is encoded perfectly, it should work!
Bertrand.

[Rob Thomson]

The issue here is not so much that he cant play the sound...

but rather that he cant select the sound from the menu.

Question... what folder are you placing the wav file in on your sd-card?

[myfox20]

The current data structure of sync pulse in *9x is prefix.
So, setupPulse begins with sync.

I must correct myself

After carefully reviewed the code, I found I'm wrong.

I will try to do some patches and confirm by DSO again.

[Scott Page]

I can't understand the english inside, but your Cleared.wav file is encoded perfectly, it should work!
Bertrand.

I found that I can convert the files and they work. What does not work is choosing the sound in the Custom Functions menu using the Transmitter.

IF I have an identical folder to the SD card on my computer -- I can use Companion9x to configure a sound to play on a particular function -- such as momentary switch of throttle. Then when I upload the mix to the transmitter it works.

However if I am in the transmitter and want to change which sound is playing for any function -- I press the top right key (menu) and I'm not able to select any other sound. In fact, I've tried alot of different long press -- short press -- standing on my head and pressing -- but nothing gives me the ability to change sounds from within the Tx.

[Rob Thomson]

Is the folder on your sdcard called 9XSOUNDS? And located on the root of the drive?

Sent from my Nexus 7 using Tapatalk 2

[jhsa]

In fact, I've tried alot of different long press -- short press -- standing on my head and pressing -- but nothing gives me the ability to change sounds from within the Tx.

I've read somewhere that someone did it standing on one leg, or was it one leg and one hand?? Can't remember