New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Taranis Latency #4640

Open
Ozzy33 opened this Issue Mar 19, 2017 · 172 comments

Comments

Projects
None yet
@Ozzy33

Ozzy33 commented Mar 19, 2017

It has been said the Spektrum system has less latency in many threads and on YT.
https://www.youtube.com/watch?v=_rxAPlYr9FQ

There is a 0-9ms latency inconsistency due to the OpenTx OS is not synced to the XJT heartbeat signal, Mike B has done this Tx OS to RF module syncing on erSky9x, should be capable doable in OpenTx.

I found this post by Mike Blandford:
I've done a very specific latency test using a Taranis plus (internal XJT) and a X8R (both using non-EU firmware). This is a test of the FrSky latency leaving out any latency in openTx/ersky9x. The protocol was set to PXX/D16.

I created a very specific pulse sequence on channel 6, and generated a 'scope signal as the PXX frame is created just before it is sent to the XJT. I then triggered the 'scope from the change in the output pulse from the X8R.

I noticed the X8R output pulses were synchronised to the XJT heartbeat pulse.

As the 9mS timing on the radio is just very slightly different to that of the XJT, the time between the PXX signal and the X8R output pulse slowly reduced to a minimum of about 10.4mS, at which point it jumped out to 28.4mS and proceeded to slowly reduce back down to 10.4mS.

Every 9mS, the XJT sends 8 channels, alternately channels 1-8, then 9-16, so channels 1-8 are only sent every 18mS, which explains the jump of 18mS from 10.4mS to 28.4mS.

By synchronising to the heartbeat signal, it should be possible to fix the latency to either about 11mS or 20mS, depending on the phasing between channels 1-8 and channels 9-16.

Since it takes around 3.5 mS to send a complete PXX frame, it would be possible to send all 16 channels within a 9mS frame time. Whether this would reduce the latency is subject to test.

My investigations continue!
Mike.

Edit: I added something to synchronise to the heartbeat signal. The result is the latency fixed at either 11.2mS or 20.2mS.
I did try sending the PXX data twice as often, but the result is the Rx lost signal at times.

ANOTHER POST:
PXX sends 8 channels every 9mS to the XJT.
The XJT also sends a "heartbeat" signal. I use this in ersky9x to synchronise the PXX data to the XJT to minimise latency, otherwise you can get a 'random' extra latency of 0 to 9mS. I'm not sure that openTx uses this signal.

@RealTadango

This comment has been minimized.

Contributor

RealTadango commented Mar 21, 2017

Sending twice as much should not be a problem. FrTX is sending MUCH more frames to the XJT module and it works fine.

And how to deal with dual XJT modules? Is there a heartbeat from the second module also even with telemetry fully disabled?

@kilrah

This comment has been minimized.

Member

kilrah commented Mar 21, 2017

If we do something it would be nice to do it right, since we already already schedule calculations based on when we transmit it would be cleaner and more optimal to align that to heartbeat than to spam the module with less recently updated data or increase CPU consumption with more frequent calculations than needed.

But there's care to be taken for spurious heartbeat signals as in the dual XJT case. I don't know if Mike has hardened his implementation for this case, but if not done properly receiving a heartbeat pulse while processing the previous could cause problems.

On the other hand, most of this latency nonsense is only there as a marketing con and I think we've got much more important / interesting / actually useful stuff to do than play that game and by that help "justify" all that "omg you absolutely NEED to shave off those couple of ms! Get our new XXX stuff!" BS.

@RealTadango

This comment has been minimized.

Contributor

RealTadango commented Mar 21, 2017

I am very interested in a total latency test from stick input to FC reception. If that is close to the latency differences it makes sense to optimize it.

For planes nobody cares... :) 150msec added delay is not noticeable by an experienced flier....

@projectkk2glider

This comment has been minimized.

Member

projectkk2glider commented Mar 21, 2017

And why do you think that it matters when using the FC!?

What is important in such case it the local loop latency - ie accelerometer - CPU - servo outputs - ESC - motor response time is what it matters for fast multicopters and not so much the radio link latency.

@kilrah

This comment has been minimized.

Member

kilrah commented Mar 21, 2017

That. Many people don't understand that and say "we've now got FCs that look at xx kHz, the radio link has to do the same!" but no. It's still a mechanical thing, and while local loop speed certainly improves stability and response (up to a point) the response to controls still has inertia to overcome and that already represents more than RC link latency.

@RealTadango

This comment has been minimized.

Contributor

RealTadango commented Mar 21, 2017

True but the loops are mainly 1khz or better so 1msec between calculations. This is not true latency but it is what counts for most, and i can agree. With all esc / motor optimizations latency in the quad is getting lower and lower.

With the small powerfull brushless quads inertia is overcome with raw power.

@projectkk2glider

This comment has been minimized.

Member

projectkk2glider commented Mar 21, 2017

Another popular and similar marketing BS is the stick ADC resolution.

@Ozzy33

This comment has been minimized.

Ozzy33 commented Mar 21, 2017

If Taranis is in 9ms mode (D16 1-8ch), but its really 20~24ms, heck yes it matters (well not to most of the plane guys). Going from D4R to X4R was night and day, next was 1-16ch to 1-8ch, another noticeable improvement (for good quad pilots), why not drop 1-9ms off, it's not a few ms, its 50% less. It's already been done on ersky9x, why not do it to OpenTx?

@RealTadango

This comment has been minimized.

Contributor

RealTadango commented Mar 21, 2017

No, it is not 50% less of total probably, so wee need to know total first. But it could be noticable...

@kilrah

This comment has been minimized.

Member

kilrah commented Mar 21, 2017

I just had a look at some blackbox logs... the time between the quad receives an order to move and the time it actually starts to move (motor response is near instant thanks to fast loop, BUT the mass has inertia and takes time to respond as mentioned previously) is 70ms. 9ms (at best! average gain would only be half of that!) is negligible in comparison.

Going from D4R to X4R was night and day

But from D8 (with PPM I guess) to D16 (SBUS) you shaved off about 10 times more than those average 4.5ms.

It's already been done on ersky9x, why not do it to OpenTx?

Go ahead and do it, no prob! Anyone interested is welcome.
But unless someone shows a blackbox log of their quad mechanically responding in <25ms to an input (mine is certainly not tuned like the pros) I'll still consider our developers' time is best spent elsewhere (and they seem to think so too).
People's capability to anticipate is 10 times more important than latency. Problem is BS marketing is playing the "get the fastest gear so you can do like the pros!" which is completely incorrect. The pro can do well with 3 year old gear, and to get to pro level the average guy has to either have fast coordination/anticipation "naturally" or train to acquire it.

@Ozzy33

This comment has been minimized.

Ozzy33 commented Mar 21, 2017

"Many people don't understand that and say "we've now got FCs that look at xx kHz, the radio link has to do the same!" but no. It's still a mechanical thing, and while local loop speed certainly improves stability and response (up to a point) the response to controls still has inertia to overcome and that already represents more than RC link latency."

That's not true at all, I can move the stick from center to full in 40ms, but it only takes a few ms to move it a little (like corrections), say 5 or 10ms, then the sampling of the stick to output of the Rx is ~24ms, 5 times longer than my stick movement took. I am now over 50 and I can feel the difference in lower latency.

"On the other hand, most of this latency nonsense is only there as a marketing con and I think we've got much more important / interesting / actually useful stuff to do than play that game and by that help "justify" all that "omg you absolutely NEED to shave off those couple of ms! Get our new XXX stuff!" BS."

Have you tried PPM and SBUS, can you tell a difference? By staying BS, clearly you're not in the high preformance quad racing and that is fine, this stuff does make a difference to us. Why did Spek spend a lot of time to minimize latency from stick to Rx output on the first 4 channels, because top pilots can tell a difference. We don't need it on all the channels or the "second" ext module. We drop the X4R from 16 to 8ch to get a noticable improvement. The new racing quads are pushing the limits of control, a lot of us laughed when they said we can do a flight control looptime of 1KHz, but it turns out it was much better than 300Hz, then 4K, 8K, 16K and now 32K, every one has made an improvement. Happy Flying!

@Ozzy33

This comment has been minimized.

Ozzy33 commented Mar 21, 2017

My quad from hover to 1400d/p/s is ~60ms, most racers use about half that roll rate, and corrections are a part of that, so under 20ms.

responce to stick input 9ms
EDIT#2: Here is a zoomed in BB picture showing 9ms response time. This is when stick starts to command (+1) a right roll, to the gyro (+5d/p/s). This is with a econo quad, $9 motors, $9 esc's, 37 cent heavy props (kk5050x3). Times have changed, electronics and FW is much better now than even a year ago. Look at the 3yo APM2.5 FC, now $21 and does what the military was doing for hundreds of millions not to long ago.

@Ozzy33

This comment has been minimized.

Ozzy33 commented Mar 21, 2017

"It's still a mechanical thing, and while local loop speed certainly improves stability and response (up to a point) the response to controls still has inertia to overcome and that already represents more than RC link latency."

Taranis 20+ms, quad under 10ms (EDIT: or less than 5ms, see below).

"People's capability to anticipate is 10 times more important than latency. Problem is BS marketing is playing the "get the fastest gear so you can do like the pros!" which is completely incorrect. The pro can do well with 3 year old gear, "

Anticipation is only part of flying/racing. After you anticipate and then make the move, then the small corrections are needed, this is not anticipation and where lower latency is king, it makes you feel more connected to the vehicle. With lower latency, you have to anticipate less ahead of time which is better for everyone, even though the casual pilots won't notice.

EDIT: The main dev for betaflight posted this:
"Twitch test excludes rc input as the twitch test is activated on switch and takes over the control from the pilot. That means that zero is really zero in there. Its an instant command from fc to roll or pitch.
The most delay occurs in first 5ms as it really can take up to 5ms to even start moving the quad. It does move a little bit in first 3ms, but really almost not noticeable in the graph"

With this data it looks like the Taranis latency is about 4 times slower than the quad reaction time. Since flight control looptimes are generally 32~128us, this is not a factor. We are not in sales or marketing, this is real data.

@MikeBland

This comment has been minimized.

MikeBland commented Mar 28, 2017

I don't think my code needs any changing if you have two XJT modules. You can't sync. to both and as the heartbeat signal is open collector, wire-ored, you can't pick out a specific heartbeat.
All my code does is adjust the period, for sending PXX data, if the heartbeat signal is more, or less, than 4mS away from when we run the mixer and send the data.
The period is never more than 10uS away from 9mS. This means you might take around 500, 9mS periods to get into sync, but that is less than 5 seconds.
If you have two heartbeat signals, then the period will just stay 10uS away from 9mS and you won't get sync.

Mike.

@schwabe

This comment has been minimized.

Member

schwabe commented Mar 28, 2017

Can you point me at your implementation? I will take a look how feasible it is to port this to opentx.

@MikeBland

This comment has been minimized.

MikeBland commented Mar 28, 2017

Ersky9x sources are here: https://github.com/MikeBland/mbtx
Look in radio/ersky9x/src
The code is in drivers.cpp (drivers.h) and pulses_driver.cpp.

In pulses_driver look at TIM1_CC_IRQHandler.
In drivers look at:
struct t_XjtHeartbeatCapture XjtHeartbeatCapture ;
void init_xjt_heartbeat()
void stop_xjt_heartbeat()
EXTI9_5_IRQHandler()
and also check for calls to init_xjt_heartbeat() and stop_xjt_heartbeat() when the heartbeat input may be used for another purpose (trainer input).

The EXTI9_5_IRQHandler() must run at the highest priority so it has no latency itself in reading the timer.
On ersky9x, I've very carefully allocated interrupt priorities so this is the only interrupt at level 0.

Mike.

@Ozzy33

This comment has been minimized.

Ozzy33 commented Apr 3, 2017

This guy (GadgetMart) pretty much hates the Taranis, I quote him in the rcg Taranis thread: "it is supposed to have a low latency rf module. Up to 60% faster. Like the Horus."
Found here:https://www.rcgroups.com/forums/showpost.php?p=37231914&postcount=51221
He is talking about the Taranis with CF paint and M9 gimbals shipped, is there any truth to this or is the heartbeat now working or?
Schwabe, any update to you looking into the heartbeat sync?
Thanks Mike for posting your info!
TIA!

@schwabe

This comment has been minimized.

Member

schwabe commented Apr 3, 2017

@Ozzy33 planing to, when time permits, but that might not be anytime soon. So if you really need the feature now, don't bet on me.

That low latency rf module is probably nothing substantiated. I am not aware of any differences in terms of latency in the Taranis/Horus modules. And all Taranis (X9D, X9D+, X7D) modules run the same firmware.

@Ozzy33

This comment has been minimized.

Ozzy33 commented Apr 3, 2017

Thanks for the reply, I am not looking for anything real soon, thanks for looking into this.
You mention the FW is the same in the RF modules, but "I think" the improved low latency comes from improved OpenTx FW side (syncing with the modules heartbeat signal).

@kilrah

This comment has been minimized.

Member

kilrah commented Apr 4, 2017

This guy has been on my ignore list for quite a while, he's just a troll. Most of his posts are intentional provocation or unreasonable comments often backed with wrong "info".

@kilrah

This comment has been minimized.

Member

kilrah commented Apr 4, 2017

BTW, looks like your data was missed by some of us (you edited your posts instead of adding new ones, so no notification...). It does show that the improvement may be worthwile indeed and was what we wanted before considering time spent on that to be an interesting investment.

@kilrah kilrah added this to the OpenTX 2.2.X milestone Apr 4, 2017

@Ozzy33

This comment has been minimized.

Ozzy33 commented Apr 4, 2017

Thanks! Yea, I am a total noob at github, I am not even sure how to correctly quote someone's post, doh! Thanks again.

@mythreeleggedcat

This comment has been minimized.

mythreeleggedcat commented Apr 6, 2017

I have been following this idea for a while and here are a few comments and notes in case it is helpful to whoever tries to implement this...

The Horus IXJT is different from the XJT and FrSky have stated that it has lower latency and probably is "faster". Apparently FrSkyOS sends updates to the IXJT more frequently than every 9ms and that may account for their claim to have lower latency on the Horus. They don't need to sync if the FrSky OS sends PXX data a lot faster than 9ms - say 2x 8ch PXX packets per 9ms frame - because the IXJT will always have the latest data when it sends..either lo8 or hi8. I suspect OpenTX 2.2 sends PXX packets every 9ms on the Horus and so gets more or less the same varying latency as the X9D+.

According to Mike B's findings, the X9D+ XJT (Q-X7 is likely the same) apparently cannot tolerate PXX updates twice as fast and it dropped transmissions when he tried. Sync is a good solution in that case. One issue with it is that the heatbeat is every 9ms and does not indicate if the XJT transmitted lo8 or hi8. To get the best latency you have to restrict the PXX interface to sending only 8 channels. Then the XJT will either optimize to sending lo8 every 9ms (it is widely believed it does) or if it does not optimize then at least the lo8 data will be fresh each time the lo8 packet is sent every 18ms. If you send 16 channels in 2 PXX alternating packets, one every 9ms, then you risk being out of phase and then the latest data has to consistently wait > 9ms before the XJT will send it. EDIT: This would still be an improvement over the current situation where the PXX transfer and XJT transmissions drift in an out of phase causing the latency to vary over time

From what I can gather the D16 protocol does allow optimization to just sent the lo8. I haven't seen anything definitive that indicates it actually does this although there are plenty of anecdotes. I'm pretty sure that the channels are ordered 1-8 and 9-16 in an array but not named. I think there is a flag or something that says if the array is lo8 or hi8. EDIT: protocol information can be gleaned from https://github.com/pascallanger/DIY-Multiprotocol-TX-Module

Another point is that the external module heatbeat pin is apparently used by the "Linker" wireless trainer feature so presumably sync'ing the Module and using the "Linker" wireless trainer feature will need to be mutually exclusive either via a build option or via some other configuration. Presumably Mike B has handled this in er9X so the same solution might work for OpenTX.
http://alofthobbies.com/linker.html
EDIT: presumable the affected feature are Master SBUS and Master PPM trainer options

The Horus IXJT cannot run exactly the same firmware as the X9D XJT/ Q-X7 XJT/ XJT because FrSky made fixes to it on the Horus to i) allow both antennas to be used for TX diversity and ii) to fix some kind of lockout that was causing RX failsafes. The original XJT does not have an antenna switch and as far as I am aware has not had that lockout problem.

GadgetMart is likely mistaken in suggesting that the X9D+ SE has an IXJT. I have not seen that stated anywhere else. Without OpenTX being changed to send the PXX packets either in sync or twice as fast there probably no significant improvement so why would FrSky go to the expense and trouble? Also technically they may have to re-certify with the FCC if they put a new TX module in the Taranis case. Everything else on the SE is just mechanical assembly stuff.

Mike's original post...with note about the heatbeat pin and Linker
https://www.rcgroups.com/forums/showpost.php?p=34821735&postcount=48226

Mike's findings...
https://www.rcgroups.com/forums/showpost.php?p=34823968&postcount=48240

A discussion of the phasing issue
https://www.rcgroups.com/forums/showpost.php?p=34827101&postcount=48265

Edit: 4/27/2018: fixed typo

@RealTadango

This comment has been minimized.

Contributor

RealTadango commented Apr 6, 2017

FrOS updates the external XJT much faster also then OpenTX ;) The module can handle it :)

@kilrah

This comment has been minimized.

Member

kilrah commented Apr 6, 2017

That's exactly what he said above...

The fact that nobody knows exactly what the XJT does is sure also putting off from making much effort there. Many things would need to be tried and measurement tools developed to really be sure the right thing is done.

@3djc

This comment has been minimized.

Contributor

3djc commented Apr 6, 2017

And also at least one other device is affected, but how many others out there would be too ? There are A LOT of OpenTx users, with extremely varying needs and usage, that's need to be factored in too.

@schwabe

This comment has been minimized.

Member

schwabe commented Apr 23, 2017

@MikeBland I started looking into implementing this on the Taranis. Since we already have a dedicated timer for the heartbeat/Trainer pin. Is there reason not to start this timer from the xjt output timer (with the stm32 timer sync support) and use the already existing code that captures trainer inputs to parse the heartbeat signal instead of the highest priority interrupt? Or am I overlooking something.

@joelucid

This comment has been minimized.

joelucid commented Aug 26, 2018

@brycedjohnson - yeah you should be able to bring it down to ~ on air time +1-2ms if you optimize everything. What was airtime for 8 channel frsky d16 again? 9ms, right?

Meanwhile check this out:
calibrated

This is the unfiltered derivative of a throttle ramp from mid to full throttle. Red is uncorrected. Blue is corrected by the average non linearity of 4 separate throttle ramps. Like >4-5db noise attenuation with zero latency!

@brycedjohnson

This comment has been minimized.

brycedjohnson commented Aug 26, 2018

@joelucid the actual over the air time is something like 4.5ms for all the RC channels. The rest is used for telemetry. The total time between packets is 9ms.

@joelucid

This comment has been minimized.

joelucid commented Aug 27, 2018

Kind of interesting: https://www.novotechnik.com/technology/tech_reference.html. Shows that these types of problems are inherent to pots. Look at the micro linearity and micro gradient variation graphs.
It definitely is the pots: I compared the micro non linearity of throttle to roll and there's no correlation.

I can measure the micro linearity issues fairly well by comparing local values to a moving average. But other more global non linearities are more difficult - just difficult to manually move the sticks at constant speed.

Some sort of automated setup might work - but then that doesn't really scale. I'm tempted to try the hall gimbals. @kilrah, you mentioned they have linearity issues, too. Do you have any data on this?

@kilrah

This comment has been minimized.

Member

kilrah commented Aug 27, 2018

No, no measurement. But since they're based on a contactless measurement of a magnetic field by a part that's a few mm away it's easy to understand that anything but perfect aligment (and a perfect magnet) will lead to errors.
Would be interesting to have measurements though.

@schwabe

This comment has been minimized.

Member

schwabe commented Aug 27, 2018

And it is imperfect enough that people have noticed the non-linearity in comparision to the non hall effect gimbals on the X9D

@DieHertz

This comment has been minimized.

Contributor

DieHertz commented Aug 27, 2018

Either the datasheet has the characteristic, or we could collect it ourselves, and then linearize

@kilrah

This comment has been minimized.

Member

kilrah commented Aug 27, 2018

The datasheet is of no help since the result is highly dependent on the mechanical setup.

@DieHertz

This comment has been minimized.

Contributor

DieHertz commented Aug 27, 2018

For you my message has the second part, after or.

@joelucid

This comment has been minimized.

joelucid commented Aug 27, 2018

I'd think the hall gimbals likely don't have the micro non-linearities. It's those that really mess up any derivative calculations. macro non-linearities should be fine to calibrate.

@joelucid

This comment has been minimized.

joelucid commented Aug 28, 2018

Well, finally got weak and ordered these hall gimbals to try out 😄.

Meanwhile pretty good progress on the micro non-linearity avoidance approach. Getting the derivatives is still not easy though. Best one so far:

derivatives

Red is stick position corrected for local non-linearities and almost undelayed - like call it 100uS delay due to median filtering etc. Blue is stick velocity and yellow is acceleration. Using just about every trick I could think of to get these smooth without undue delay. Extreme points in x and v correspond to zero crossings in the derivatives with almost no delay (one point on the x axis is 13uS, so it looks like total delay of acceleration could be as low as 1ms). It is certainly fast enough to provide substantial benefit for the FC.

Acceleration while not perfect does look good enough to be applied to motors in my view. All of this is matlab, not yet running on the Taranis.

@joelucid

This comment has been minimized.

joelucid commented Aug 31, 2018

Ok - I think I’ll give up on acceleration with the stock gimbals. Carefully calibrated all channels without the springs and I could get very good derivatives - until I tightened the springs again.

Turns out that the local non-linearities are very similar if a channel is used the same way. But as soon as you adjust springs etc the calibration becomes invalid.

My hypothesis is that anything that changes contact pressure of the pots washer modifies these local non linearities. Too bad.

But even without acceleration - I do get good velocity measurements. So will focus on getting these transmitted with low latency to the quad and revisit acceleration when the hall gimbals arrive.

@joelucid

This comment has been minimized.

joelucid commented Aug 31, 2018

@schwabe, I’ve been looking for the multi module branch which sends the heartbeat for the taranis to sync to. It’s not in master and I didn’t find a branch that had it. It’s that implemented yet?

@schwabe

This comment has been minimized.

Member

schwabe commented Aug 31, 2018

pascallanger/DIY-Multiprotocol-TX-Module#107

Basically pascal manually picked all other changes from that pull request (status output, constants instead of hardcoded numbers etc..) but never merged that sync code.

If you want to pick that up and port it current multi master and try to get it integrated you are very welcome.

@joelucid

This comment has been minimized.

joelucid commented Sep 1, 2018

Thanks @schwabe, I’ll take a look at it. Btw strikes me that this synchronization problem is an issue on the FC as well: if you calculate the derivatives on the FC not being synchronized with the pid loop you’ll get significant errors due to the misalignment - esp at high frame rates.

I see three ways out: synchronizing the pid loop to the receiver, computing the derivatives on the tx or sending a time stamp with each packet so that delta t can be computed based on these rather than pid loop delta t. The latter could also be done if the spi rx is serviced by Irq and time stamps reception.

The whole spirx code in betaflight currently uses polling as far as I can tell (at least Bayang). Likely needs to be converted to irq driven and use dma to read/write the radio in order to get 1khz rates without impacting loop execution.

@VoltAmpere

This comment has been minimized.

VoltAmpere commented Sep 1, 2018

The PID loop runs much faster than the frame rate. (I run at 8KHz but newer stuff runs 32KHz) Betaflight has interpolation and filtering to smooth the RC command and that runs with the PID loop. One advantage of Crossfire is that it runs at a higher frame rate than Sbus which further reduces latency due to sampling.
Crossfire runs at 150 Hz frame rate. (reduced to 50 Hz when signal degrades though)

@DieHertz

This comment has been minimized.

Contributor

DieHertz commented Sep 1, 2018

@VolrAmpere SBUS has 150Hz update rate on R9 receivers

@VoltAmpere

This comment has been minimized.

VoltAmpere commented Sep 1, 2018

I guess it does. I have not fooled with R9 but it's an attempt to compete with Crossfire. I still run 2.4GHz SBUS receivers on my quads using only 8 channels so frame rate is 111Hz.

@joelucid

This comment has been minimized.

joelucid commented Sep 1, 2018

@VoltAmpere, yeah I’m quite aware. I want to run the frame rate at 1khz though and then missing one loop iteration is a 12.5% error for the time delta. That is bad for stick derivative but deadly for stick acceleration.

Also aware of all the interpolation and smoothing stuff. There’s still a lot of potential for improvement in this area in my view.

As far as pid loop rates go I don’t see how running 32k can make any significant difference. I run 8k and am happy with it. I also run 1k on silverware and don’t see disadvantages there either.

@VoltAmpere

This comment has been minimized.

VoltAmpere commented Sep 1, 2018

The only reason I see to run the loops at 32KHz is to improve the filtering. The boards I have can only sample the gyro at 8K anyway.

@Ozzy33

This comment has been minimized.

Ozzy33 commented Sep 2, 2018

Hi Mike, is this 0.1uF cap on the main board in Taranis?

I have the first batch Taranis 5+ yo now. The gimbals in them had a op-amp circuit without a cap across the pot. I am pretty sure this was done because they did not have the correct pots with the physical resistance range proper for the 60 degree angle (maybe the standard 270 deg) the stick moves. So the amp boosted the output signal for better output resolution. The second cap in the photo is the op-amp's Vcc bypass cap.
taranis gen1 first batch gimbal amp circuit

img_20180831_124317

I have three of these Tx's, all of them has the 3.3V rail set to 3.08v, verified by the voltage dividing feedback resistors, I dont know why. I did trim them to the proper voltage. I mentioned this years ago, but the guys with the schematic are tight lipped under nda.

@joelucid

This comment has been minimized.

joelucid commented Sep 2, 2018

@schwabe, I'm trying to increase the baud rate of the external module. Can get it to work up to 400kbit but above no chance. Signal looks very soft at 800kbit, too, easy to see how that won't work. Read about the 10k output resistors in the x9e+. That could certainly be the problem. Is there a way to increase beyond 400kbit?

@MikeBland

This comment has been minimized.

MikeBland commented Sep 2, 2018

@Ozzy33 0.1uF caps on the main board are C7, C8, C23 and C24. Signals connect to PA0-PA3 via 200 ohm resistors R10-R13. At least those are the items on the circuit diagram I have.
The analog reference voltage is 3.0V, a specific reference chip is used (U10, XC6201_3V), not the 3.3V supply.

joelucid: Is that on the SPort signal or the PPM/PXX signal? If it is the PPM/PXX signal, then you are limited by the switching of the output transistor. In particular, the parasitic base-emitter capacitance stops the transistor switching off quickly. THis may be overcome by fitting a small (5-10pF) capacitor across the 10K resistor from the signal source (PA7?) to the base.

@joelucid

This comment has been minimized.

joelucid commented Sep 2, 2018

Ok. After an afternoon of massaging I can get a 1.5ms inter packet delay or a 666hz frame rate to the external multimodule running. That should be enough to start testing lower latency protocols. About 1.1ms from starting to evaluate the mixes until sending pulses. At 400kbit the packet to the module should take less than a ms on the wire, so around 2ms from stick to external module. Not super happy - but good enough for now.

@schwabe

This comment has been minimized.

Member

schwabe commented Sep 2, 2018

If you want really fast external serial, the xlite hardware has proper fast serial to the external module. (not even inverted).

@joelucid

This comment has been minimized.

joelucid commented Sep 2, 2018

@schwabe yeah but that has the pwm hall gimbals. I've ordered a t8sg v2+ which I believe has the radio chips SPI connected. That might be really fast - though another stack (deviation) to latency optimize ...

@joelucid

This comment has been minimized.

joelucid commented Sep 2, 2018

Alright. 666hz frame rate including telemetry! So like 2.5ms worst case stick to FC.

@Ozzy33

This comment has been minimized.

Ozzy33 commented Sep 3, 2018

@MikeBland The seeming low 3.3 voltage was coming from the dc-dc converter (SO-8 package circled in red, not the 3 pin package that the linear U10, XC6201_3V uses and circled in blue) and set with a voltage divider of R76 is the top voltage feedback resistor, R77 is the lower feedback resistor (red arrow pointing to them). It ended up being 130KΩ on top of R77 (in parallel) brought it from 3.08v to 3.302V.

Is the dc-dc output voltage should be 3.3v or 3.1v or?
Is the pots feed with 3.3v or 3.0v?
tia
taranis 3 3v reg

@kilrah

This comment has been minimized.

Member

kilrah commented Sep 3, 2018

Pot supply is 3V.
Main reg is supposed to be 3.3V but it was common for it to be around 3.1 on those old units, without impact.

@Ozzy33

This comment has been minimized.

Ozzy33 commented Sep 3, 2018

@ Kilrah, thanks for the info.
The datasheet https://www.torexsemi.com/file/xc6201/XC6201.pdf
shows
Dropout Voltage :
0.16V @ 100mA
0.40V @ 200mA

With a 3.080V input, the output would not be regulating at 3.0V with only 80mV headroom, thus feeding the switching buck regulator switching noise straight though the linear regulator to the most sensitive circuits (pots and adc).
Anyways, I flew with it like that for ~4 years w/o noticing, but most of this RC controlled stuff, humans correct for what the vehicle is doing (wrong, lol). :)

@bexamous

This comment has been minimized.

bexamous commented Sep 27, 2018

Awe I've been running @schwabe's sync_heartbeat_pulses for past month or more without issue. But FWIW today tried setting external module to R9 and radio resets after a few seconds. Still reproduces if in a new model I disable internal module and then try enabling R9.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment