Servers by jDrones

Copter-4.0.5 released!

This is another ROI loss providing a better clue for the ROI lost problem:

so really what happens is a channel shift: pulse width values appear shifted one place to the left. C1 is lost, C4 gets C5, and ROI is lost.

Controller is a Holybro Mini Pix on a QuadX. Reported above was a Pix Racer on Tradheli, where pulse width values appear shifted two (once) and three (twice) places to the left:

Common to all pulse width shifts:
·different controllers, but all without IOMCU,
·different receivers, but all were FrSky TFR4-B,
so it is not clear where the problem is located.

Note that pulse shift could occur in any situation; here it is noted since these are missions with ROI. A simple way to check could be:
·Choose a long log.
·Open it with MP.
·Filter on RCIN.
·Export Visible to .csv.
·Open .csv as a spreadsheet and order rows on last used channel column, ascending.
·Check if value is 0 on first row last channel.
·If so, check this row on .log log.


Nice investigation. Of course you are not using an RFD900 radio right? We saw a similar issue that was caused by a bug in the RFD900 radio’s software (i.e. not ArduPilot). I don’t think you are using this radio but I just want to check.

Wifi ESP’s. You indicate an aditional channel on a long interval; here are one or several channels lost (C1, C1+C2 or C1+C2+C3) in a single message.

I’ll try a different receiver next time.


We discussed this on the dev call and we think that it’s possible the receiver has a problem and simply cannot report all channels within the 22ms it is allowed. Is it possible for you to reduce the number of channels that are used? Also the problem may only happen when the total PWM of all channels goes above a certain number.

So one solution is likely just to replace the receiver with a newer model. FrSky may also have an updated firmware that resolves the problem.

If you have a link to a log file we could check whether the total PWM value is too high.

Here are two views of a T8FG+TFR4-B signal capture:

So the sync pulse lasts 7ms and the pulse interval 400 µs. For 8 2ms pulses the total duration would be 8x2.4+7.4=26.6ms. If pulses are made even longer at the transmitter, such as 2.2ms 8x2.6+7.4=28.2ms
Where does the 22ms limit come from?

I’ll try a different receiver.

Here you can find the .bin log of the Tradheli mission above with Futaba T8FG and FrSky TFR4-B, and a .ods file with exported RCIN messages, with two aditional columns:
·theoretical train pulses duration (assuming 7ms sync and 0.4ms intervals);
.markings for the ROI losses (rows 804, 2161, 2735 and 3468).

Correction/clarification: the pulse intervals are included in the pulse width.

With T8FG+TFR4-B, moving transmitter sticks and switches so as to generate maximum pulse widths manually, and reading RC_CHANNELS messages on the generated .tlog file:

For the indicated line with pulses 1941, 1940, 1751, 1940, 1814, 1940, 1940, 1941, its sum plus 7400 µs (sync pulse) gives 22607 µs.

Testing several battteries changed on the fly and a S.BUS receiver (so a totally different pulse train (coded widths)) no ROI losses:

Pending testing a different receiver (not S.BUS).

For clarification of the pulses train timing, hera are oscilloscope captures with a 8 channel receiver connected to a pulse multiplexer, which makes available the 8 individual pulses and the pulse train:

Pulses period, SYNC period and individual pulses. The periods are different, but this may be particular for the receiver used.
Note that the pulse multiplexer output is inverted, but this should not matter with respect to timing (detected on edges).

Individual pulses. C1 to C6 are synchronized but not C7-C8. Again, this may be particular for the receiver used.

Hello! please tell me how to disable the function, motor interlock enabled.
I plan to fly without a remote control through the QGroundControl
application and without a remote control I cannot disarm it.

And again yet another drone where the logs are not available. It’s a plague

Also can anyone explain this error message.
I get it only on USB and only on 4.0.5

what is your MP version ?
I think that is related.

it’s 4.0.5 didn’t’ get it from what I recall on 4.0.4 and it only seems to happen when powered via the USB.
My MP version is

I am observing that if pulse multiplexer output is inverted it is detected in Pixhawk (with IOMCU) but not in Mini Pixhawk and similar controllers (without IOMCU), as if edge detection were not detected both ways. Am I missing something?


I just have done the manual tuning today, in Stabilize mode, tuning Roll only. After a while, the drone faced toilet bowling issue, keep testing many times later on but still got the same problem. I have log file and parameters here, it would be nice if they got checked.


I’ve only had a quick look at the logs but a couple of things stand-out:

  • The vehicle seems to be in stabilize mode the whole time so I wonder how toiletbowling could be happening or maybe you mean something else? Toiletbowling normally means the vehicle circles on it’s own in Loiter mode (or sometimes other modes).
  • ARMING_CHECK = 0. This is nearly always a bad idea and disabling the checks could be hiding the source of the problem
  • EKF3 is enabled. Any particular reason? Normally it’s best to stick with the default EKF2 unless there is a good reason not to.
  • There are some very large deviations in the magnetic field at the end of the log. It may be motor interference or something else but certainly some kind of physical issue (i.e. not software) or maybe the vehicle crashed at the end? In which case you can ignore this comment, the mag field looks OK in the early part of the log.
  • Re tuning, have you seen the Tuning Process Instruction wiki page? I know it’s quite long but it is a good idea to follow this precisely.

Good Luck!

Hi @rmackay9,

Thanks for the response. That was my bad on that report. Basically, the symptom is similar to tb effects but in Stabilize mode. I also strongly believe that the tune was bad so today I have done another one. Everything seems better but the Yaw using dual GPS (I enable EK3 for that purpose before)
I have enable the EK3 for dual GPS heading function. It seems to me that the functions did not work.

GPS for base: 3D fix
GPS for rover: DGPS
GPS1_POS_Y : -0.15
GPS2_POS_Y : 0.15

The yaw angle kept drifting during the static condition.
Could you please have a look on my parameter:


Anyone having trouble upgrading to 4.0.5.
I have been successful on two other drones but one I had held off on doing and decided to do it today.
It went in but each time I connected with Mission Planner I got told that 4.0.5 was available …huh
So I check the system messages and found I had 4.0.3 installed.
So I tried again. Same result.
Again Same result.
You know what they say about insanity.
Anyway I then wiped the firmware and started from scratch. Still 4.0.3.
I realized there was a problem because the compass priority settings where gone.

Anyway I then went to 4.0.5 Beta and got 4.0.4 RC2…so I am back where I started.
I have no clue why.

Above (four batteries changed on the fly) is for a pulse multiplexer connected to a conventional receiver: no pulse shifting and no ROI loss. I have had other flights without any problem. So the problem seems to happen with this receiver, and it seems to happen also with other identical receiver. Anyhow, I think this receiver is not being manufactured any more, but S.BUS is the way to go.

BTW, it seems that if the multiplexer output has inverted pulses it is not always recognized by all FC’s, having IUOMCU or not.

Try upgrading with QGC.

I would like to report landing gear bug.
Case: LGR retract alt is set to 30m, deploy to 25m. RNGFND_MAX_CM is set to 35m (using lidar lite v3)
whenever i flight lower than 35-40m, LGR works fine deploys and retracts how it should, but when i go above 35-40m and lidar readings are 0/chaotic the LGR deploys. it wont switch to GPS/baro altsource.
This is a bad feature/bug, because it alway deploys LGR when flying above 40m.
And no i cant use a manual retraction/deploynment.

Servers by jDrones