- Catch the case where the case where the driver gets stuck because nothing is received by +SBDRB
- Add a mutex for the rx buffer
- Stop the standby loop if a mode change is already scheduled
- Move publishing the telemetry status from the IridiumSBD driver to the mavlink instance
- In the commander use the iridiumsbd_status message for heartbeat in case of a high latency link
- Move positive acknowledge to the mavlink instance
- Add a failed acknowledge in the commander if no high latency link exists
Flight tested: ekf2 w/ mag and compass by @nathantsoi: https://logs.px4.io/plot_app?log=79b81031-cf1e-41f0-890b-d6cd7d559766
NOTE: external I2C devices need a pullup. I have tested with a 3.3v 2.2k pullup.
Working:
- mpu6000, bench tested and verified via nsh
- fmu
- all 6 ch output bench tested w/ pwm and oneshot via nsh
- ppm input bench tested
- dsm input bench tested
- bmp280, bench tested and verified via nsh
- hmc5883, bench tested and verified via nsh, but requires an external i2c pullup
- gps on uart6
- startuplog, nsh, mavlink on uart4, but params are not sent for some reason. RSSI pin is TX, MOTOR 5 is RX (normal mode, 57600 baud)
- rgbled over i2c, bench tested and workingp
- sbus via the shared sbus/ppm pin (which includes an inverter to the mcu SBUS in pin), remove the solder bridge or jumper to the ppm pin before use
Not yet implemented:
- ADC
- OSD: passthrough video is untested, use at your own risk until a basic driver is implemented.
The description of IMU_GYRO_CUTOFF was incorrectly saying that it only
affects the driver filtering, but in fact it also set the on-chip filter
to the next higher supported value. This patch fixes that.
And because the IMU_GYRO_CUTOFF and not the IMU_ACCEL_CUTOFF was used for
the on-chip filter, after #9070 which sets the default gyro filter to 80,
we were effectively using a dlpf of 98 Hz.
For this reason this patch changes the on-chip cutoff frequency to 98 as
well, so that the overall default behavior is unchanged.
acfloria