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
- 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
* Updated and expanded batt_smbus to work with bq40z50-R2. Expanded battery_status.msg. Fixed mavlink_messages.cpp temperature, added commented out expanded battery_status.msg parameters for future mavlink expansion.
* Changed errx to PX4_ERR
* Added PX4_ERR returns
This prevents the autopilot from sending an invalid unix timestamp.
Usually, if no time is set yet by a GPS, the date is somehow set
to 2000-01-01, therefore we can ignore anything earlier than 2001.
* Revert "mavlink_mission: don't retransmit automatically"
This reverts commit 4e008fe89120e24e321e93fb551753242797f022.
* mavlink_mission: don't retry to send mission item
The mission items need to be requested one by one by a ground station.
This is a "pull" protocol and we should not retry to "push" the mission
items down.
If we do this we can trigger the situation where the autopilot keeps
retrying and the ground station does not time out because it keeps
receiving items (even though the items are the wrong ones).
* mavlink_mission: reduce retry timeout
When actively re-requesting lost mission items, we can be more agressive
and therefore lose less time when a mission item is lost on the way.
Instead of using a timeout to resend a mission item, we should directly
send the mission request again. This is needed because we removed the
automatic resending which lead to troubles.
acfloria