My MP is 1.3.7530.26934 and if I check for updates it only offers a beta update that fails “Error getting Parameter Information” so I canceled it. I guess I’ll wait a day or two. Was headed out flying tomorrow morning so hoped to get this loaded.
if your using windows 10 you need to run it as ADMIN to update it
Interesting - started it with admin and mp updated to 1.3.7555.20712 but still only offers 4.05 stable and beta up to 4.06b5.
Maybe I’ll check the github repository… Yep 4.06 stable is there but for some reason it won’t show in my MP. It uploaded fine manually but still odd that it doesn’t show in MP for me.
Hi.
Thanks for great work and detailes information. I had Matek F405 wing board and R9mm frsky receiver. Till now i cant the telemetry work through inverted F.port of R9mm (on 4.0.5 version) to TX2 uart pad on fc with frsky passthrough protocol(serial protocol 10) Everybode recommended an inverter for fport in case of f4 boards. Will this release solve this issue so can i use R9mm receiver inverted Fport without diode and ttl converter to get telemetry.?!
What is the right setup: is serial2 prtocol10 or 23 ? serial_option 0 or 7?
Many thanks
I could not get F-Port working with the latest FrSky firmware. I think it’s a bug because it works with the older version. Cross posted here: FrSky FPort support - testers wanted
I downloaded the latest version of ArduPlane today to a Kakute F7 but now I cannot control the flaps from the transmitter. I cannot find how to control it anymore.
My fault or code change?
Mr Anders W
Sweden
can you send me a tlog showing you trying to move the flaps on the ground? Or a bin log with LOG_DISARMED=1
Hi Tridge
Nice to hear from you.
If I am correct there was something like “FLAP_RC_CH”. Now there is not.
I have no clue how to connect an RC channel to the control the flaps.
The RC input is working.
The Flaps are working in Setup -> Servos and if I click Reverse they move as they should
I’m running the code on a Kakute F7. The Flaps on CH 5 and Dshot on Ch 6.
Motor, and all other servos are working perfectly but I cannot control the flaps.
Anders
in 4.0 there is a parameter FLAP_IN_CHANNEL that you are probably referring to.
For 4.1 (in development now) this has been replaced with a RCn_OPTION “FLAP” (value 208). So you RC7_OPTION=208 to make flap input come from channel 7.
I’ve just released plane stable 4.0.7beta1. This is a minor release with some important bug fixes against 4.0.6.
The changes are:
- Fixed F32Lightening board IMU fast sampling issue
- fixed issue with EKF2 and EKF3 with use of high accuracy GPS modules. This is important for anyone flying with a RTK GPS
- Fixed KakuteF7 DShot glitch issue
- Fixes issue with checking for valid RC input in ICE disable channel
- fixed an interrupt flood issue with any sensor that uses interrupt timing measurement, such as RPM sensors.
- Modified RM3100 driver to problem all 4 possible I2C addresses
- Fixed UDP RC input on Linux boards to accept up to 16 RC inputs on UDP
The most critical fix in the above list is the ISR flood issue.
ISR Flood Issue
The ISR flood issue happens when a misbehaving external sensor (such as an RPM sensor for a petrol motor) starts providing pulses faster than the flight controller can process them. If this happens then the CPU can be overloaded in the interrupt handling for the sensor and stop flying the vehicle. The level of interrupt rate needed to cause this issue is around 500k interrupts per second, so to be safe we have added a limit of 100k interrupts per second. If a single interrupt source produces more than 10k interrupts in a single 0.1 second period then we disable that interrupt source, print a warning to the user and raise an internal error.
Happy flying!
2 Likes
Thanks a lot 
Have a very good weekend
Thanks Tridge,
Will this be in Copter as well? I plan to put a RPM sensor for a ICE generator motor in soon.
yes, in copter 4.0.5, which should be in beta today or tomorrow
I’ve just released 4.0.7beta2, with a small set of changes from beta1. The changes from beta1 are:
- enable telem3 on Durandal
- fixed SBUS output when scanning for FPort on IOMCU
- keep a backup of storage of last 100 boots
- fixed a race condition in handling UART DMA transmit
Happy flying!
1 Like
Bad news, not sure if it’s a beta issue. This plane was landing well in previous flights, but in this one came up 100 yards short. Screenshot shows it didn’t achieve anywhere near the intended land slope, and the takeoff/arming location are the same as the intended landing spot. Log here: Note: We thought the first landings were going poorly due to the rangefinder engaging on the 10m tall trees 100m short of the landing zone.
No expert here, but it looks like the esc got hot (80+) and shut down putting the plane into a stall
I have looked at the ESC part of the logs, and the RPMs don’t indicate any form of shutdown; the plane would literally glide this slope, but it uses reverse thrust to manage the energy. Here is why I don’t believe the stall theory; the pitch demanded and achieved are consistently together throughout, and the pitch recovers once reverse thrust stops during the late attempted go-around:
Also note the reverse thrust all of the way to the crash site; if it was below slope and descending rapidly, it should NOT be applying reverse thrust and pitch down command. Period.
I’ll attach successful logs soon of the flight just hours earlier with full auto landing successes; the only change was the addition of a rangefinder, and that was disabled for this last landing attempt.
@tridge, @MagicRuB, or @WickedShell, would you guys be able to take a moment to review the automatic landing sequence posted above on 4.0.7beta2 that resulted in a rapid descent and crash? I’m available all day on discord.