it is working correctly. The new P term is equal to the old D term. That is why I did the calculator to help people, because it isn’t really obvious the way the relationships work.
The old system was a fairly complex relationship which was created in order to preserve PID values from the very early days of ArduPilot when we had an angle controller instead of a rate controller. We converted to a rate controller a long time ago, but decided at the time to auto-convert from the angle PID values to rate PID values on the fly. That was a mistake which is fixed in 4.1.x. We now use direct rate PID values.
1 Like
Thanks for the quick and accurate reply. It’s really just a recalculation in the ArduPilot Plane 4.1.x PID Calculator. For example, if increase RLL2SRV_D in the 4.0.x PID Value then that would also increase the feed-forward gain 4.1.x RLL_RATE_FF and RLL_RATE_P. Now I can use these parameter 4.1.x Pitch PID values according to their definitions.
1 Like
my CUAV v5 Nano suffered the same issue, the update process seemed finish but the same problem occurred and now it is a brick.
Do you know how can recover it?
@tridge , I observe that the issues regarding the RPMs not showing in MP and also the motor not reversing are related to not rebooting phisically the ESC ( Holybro Tekko 32 F3 Metal). I can reproduce all this issues if I dont reboot the ESC and just reboot the AP. Dont know if this is a bug or just normal behaviour. BLHeli is not updating the new settings and this is the reason that it does not “sync” with ardupilot. If its not a bug it should be advised to reboot the ESC after making changes in BDSHOT and BLH parameter settings.
I would say its generally important to reboot the ESC if making changes that affect the ESC
The F.PORT still does not work in this release. Same behaviour as reported before. Sorry, but from my point of view this is CRITICAL as it fakes you in having the control of the aircraft but after 3 or 4 minutes the connection is lost and AP turns failsafe. I have a MatekH743 together with FrSky Archer RS receiver.
Below is the image I take after 25 minutes runnign with Fport (full control with no issues, besides the warnings being indoors)
Updated through MP to 4.1.2 (no bootloader update) and no issues after 15 minutes running.
After updating the Bootloader thorugh MP, Fport failed the connection after 5 minutes
If the bootloader suffer an update between the 4.0.9 and the 4.1 maybe this bug is related to the bootloader.
I agree with you maybe that recommendation should be in the wiki.
It is unlikely to be bootloader related. I have an Archer here and a MatekH743. I’ll see if I can reproduce the issue.
When you are testing this how is the FPort receiver being powered? Which exact pins is it connected to on the MatekH743?
The reason I ask is that the most common cause of a receiver losing connection in bench tests is marginal power to the receiver.
Also please send me a tlog of when it loses the receiver link, and let me know which MatekH743 variant it is.
I am connecting according to the manufacturing recomendation: Fport= Tx6 and SBus=Rx6, the power goes in 4V5 and Ground as shown in the picture.
You can see in the last post the 3rd picture shows the Failsafe (lost F.Port) while AP was full powered (HUD shows 16.45V)
Will send it tommorow, this is a Mateksys H743-Wing from this year.
You should be able to reproduce it in the bench. I have 2 aircrafts with the exact same setup concept using the Matek with same peripheral in same interfaces, I observed this F.Port issue in both of them, so its not an HW failure, remember F.Port was working in both aircrafts in FW 4.0.9.
Sorry, but If you are using Fport, why you connect SBUS to RX6?
Why not? This way I can configure SBUS for control and S.Port for telemetry or switch the F.Port to do both. This setting is done in the parameters. If I use the BDSHOT ( timer is occupied) I have to switch on the F.Port. If I don’t use the BDSHOT I can rely on the SBUS, as you see the F.Port is not reliable.
Thanks for the clarification, i did not understood that you were switching back and forth between FPort to Sbus+SmartPort.
Sorry, one more question, if you are doing this you should not wire it like this?
I thought that you could not share the same port for RX and TX using SBUS + Sport.
You can share the same port Rx6 +Tx6 (SBUS + S.PORT). Just try it, you will see it works 
When you use the DBshot then the Rx6 is taken ( because of the timer) then you need to use another UART for the SBUS, that is why I select the F.PORT (you dont need the Rx6, just the Tx6).
Thanks for the tip, i did not know that!
Here you are, the tlogs and log bins:
FPORT with no issues in FW 4.1.2 if no Bootloader upgrade from 4.0.9
https://drive.google.com/file/d/1gCplrztfJvhKcQA4eXxpdsuWoi1Xykjr/view?usp=sharing
FPORT issue in FW4.1.2 including BL upgrade.
https://drive.google.com/file/d/1gHeaiG1HpJ_SZT5hf0fF5hHh2rSU-IV0/view?usp=sharing
cheers!
@tridge I updated a Matek F405 WSE and a Matek F765 from 4.1.1 to 4.1.2 and both would not arm asking for the accelerometers to be calibrated again. I compared the Params and they all came across. What causes the board to decide to request a new calibration?
that is not expected. There were no changes that should trigger the accel cal not to be still valid.
Has anyone else seen this?