when we are looking for FPort input, we normally switch UART3 on the
IOMCU to 115200 to look for inverted inputs at 115200 baudrate. We
need to disable this switching when we have SBUS output enabled to
prevent a change in the SBUS output baudrate
Many thanks to afishman for finding this bug
Fixes#15522
this prevents mis-calculation of the angle when RC input goes outside
of the configured range. This impacted on throttle nudge in plane when
reverse thrust was enabled
thanks to Pompecukor for reporting!
This allows more channels to be passed to RCInput_UDP protocol while
also allowing less than 8 channels - this is similar to the approach
used by SITL in which the packet size is used to figure out the number
of channels.
(cherry picked from commit 29d8586ea4)
This implements a max quota of GPIO interrupts per 100ms period to
prevent high interrupt counts from consuming all CPU and causing a
lockup. The limit is set as 10k interrupts per 0.1s period. That limit
should be high enough for all reasonable uses of GPIO interrupt
handlers while being below the level that causes significant CPU loads
and flight issues
This addresses issue #15384
Rework after review:
- Kept old IMU and barometer definition of crazyflie 2.0 in hwdef
- Added comment regarding soft-reset command
- Added defaults.parm for crazyflie
when you have a moving baseline pair of ublox GPS modules and the
rover GPS does not have full fixed RTK lock on the base GPS then we
should not use it as our primary GPS as it's position and velocity can
be badly affected by the attempts of the GPS to gain a fixed lock.
This was observed in a flight with two F9P GPS, where the GPS velocity
data from the rover GPS went way off when it lost full RTK lock. It's
status stayed at 4, so it was selected as the primary GPS
This reverts the change from #13895 and instead resolves the issue by
increasing the scale factor limit to 1.4
There is an open question as to why some RM3100 compasses show a
different scale factor (by about 1.25 times) to other versions of the
same sensor. As we haven't resolved this properly it seems the correct
thing to do is follow the datasheet but allow for a wider range of
scale factors to cope with the variation between sensors
