Due to the old heartbeat of the high latency telemetry when activating it after flying sufficiently long in normal telemetry it is first detected as lost until the first message is sent.
By updating the heartbeat to the current time on switching this issue is avoided.
Also includes a small style fix for the HIGH_LATENCY2 stream
- Check if changing to a non standby state if the current state is the standy state and no change is already scheduled.
- Add prefix _ to all class variables
- Every time data is written to the iridium module all previous untransmitted data is overwritten
- The buffer is reset only on the following conditions
- A sbd session is successfully completed
- An incoming mavlink message would result in less than SATCOM_MIN_TX_BUF_SPACE free bytes after it is written
- Any other incomming data would result in less than SATCOM_MIN_TX_BUF_SPACE free bytes after it is written to the buffer.
- Reorder functions so that they have the same order in the .h and .cpp file
- Update documentation for functions
- Make variables and some functions private
Switch to the high latency telemetry, if available, if every low latency link is lost. Switch back if any low latency link is regained. Only indicate that all links are lost if all high and low latency links are lost. Allow different timeouts for high and low latency links.
- Update heartbeat after successful sbd session and fill it in the telemetry_status message
- Add parameter for session timeout, read interval, and stacking time
- Add sbd session timeout
- Fix updating the rssi at a constant rate when no sbd session is scheduled
- Add variable timout to read_at function
- Check if test command is valid to avoid being stuck in the test state
Allow enabling/disabling transmitting data from all mavlink instances
with a specific mode/type. When disabled the instance can still receive
data. The uORB message used is the vehicle_command and uses the following
parameter:
param1: Specifies the mode/type of the instances to enable/disable transmitting
param2: Boolean to indicate if transmitting should be enabled or disabled
- prior to this fix the fw attiude controller used airspeed to scale control
surfaces even though airspeed was disabled
Signed-off-by: Roman <bapstroman@gmail.com>
Since assertions lead to crashes, we need better failure handling. In all
the cases in this patch, the assert is not required.
All the ones with the task id should be replaced with the module base
class.
Ah yes, and this reduces flash space, since the ASSERT macro will expand to
a printf that contains the source file name.
acfloria