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.
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.
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 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).
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.
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.
Thanks.
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.
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.
Hello.
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)
ALTSOURCE is set to BARO.
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.
