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
* 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.
The debug messages are too verbose to be run in a production vehicle and inherently were something that should only be run in SITL / debug sessions on hardware. Switching the flag to the PX4_DEBUG() macro does not only make this more explicit, but also saves a lot of flash space that otherwise was consumed by the strings.
If 2 or more vehicle_command are queued a call to update() will
return the oldest vehicle_command and set the _cmd_time to the
timestamp of the last vehicle_command queued losing it.
Using update_if_changed() fix this causing all item being consumed
one at each call of send().
This will initialize those structs with zero in all fields not set
and all fields set will only be change once to the final value not
wasting CPU time zeroing it.
This will guarantee that no non-unitialized structs will have
a trash value on from_external causing it to be sent to the
MAVLink channel without need it.
The previous approach was checking system id and component id but it
will not work in 100% of cases as external devices can send MAVLink
message with the right system id but with broadcast component id.
The message handling was not obeying action focused messages and high-rate messages properly before. With this change update rates track the desired rates closely. Critical high-rate messages such as ADS-B are queued additionally to guarantee that all received packets are being correctly forwarded.
Mohammed Kabir