# BatteryInfo message

**URL:** <https://forum.opencyphal.org/t/batteryinfo-message/977>\
**Category:** Applications & Usage\
**Created:** [November 2, 2020, 8:00am UTC](https://forum.opencyphal.org/t/batteryinfo-message/977 "2020-11-02T08:00:55Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [November 11, 2020, 5:12pm UTC](https://forum.opencyphal.org/t/batteryinfo-message/977/7 "2020-11-11T17:12:05Z")

</div>

> [@kishore](#):
>
> Of the two products, the first is a battery to 5V step down power supply that also measures the battery voltage and load current that passes through it. The second device is effectively an integral part of the battery (Source). It is entirely possible that these both nodes co exist on on system. First, for providing a 5V supply rail and second for managing the charge / discharge of the battery itself. These two devices would then have an overlap of functionality of measuring Current and Voltage.

Of course. If you have, say, a braking resistor on a robot, it would probably also measure the current, voltage, and the amount of dissipated energy, hence a yet another Source. There may be a separate battery for the payload – also a Souce, etc. It is only natural that similar physical processes are modeled using the same type; that’s what types are for, in the end.

> [@kishore](#):
>
> I think the type in lines 5 & 6 should be edited to remove “sesnor.”

Thank you, fixed.

> [@kishore](#):
>
> I’m looking forward to this. It would help me understand better. Any existing file pair of .uavcan ↔ .h[pp] that i can refer to?

This has been finished yesterday, although it is not yet merged ([currently under review](https://github.com/UAVCAN/nunavut/pull/161/), ETA next week). But you can already use it; here’s a relevant quote from the pull request:

> ```
> git clone https://github.com/UAVCAN/nunavut --branch c-serialization-corrections
> cd nunavut
> pip install .
> cd -
> git clone https://github.com/UAVCAN/public_regulated_data_types/
> nnvg --target-language c --pp-max-emptylines=1 --pp-trim-trailing-whitespace --target-endianness=little --enable-serialization-asserts public_regulated_data_types/uavcan
> 
> ```
> 
> Options `--pp-max-emptylines=1 --pp-trim-trailing-whitespace` will become unnecessary after #159 is fixed.
> 
> Option `--target-endianness=little` may be omitted, which will result in endianness-agnostic code that is portable but slower and possibly larger.
> 
> Option `--enable-serialization-asserts` injects cross-checks in the generated serialization routines which slows them down and increases the ROM footprint but protects against possible memory corruption and detects some of the possible issues in the generated code. It is recommended to always enable it.

> [@kishore](#):
>
> On the device implementation, I think I understand how to publish subject messages as public Heartbeat messages (using an own implementation of the payload message structure) but still need to understand services. Any small examples?

These examples might help, I think: [Libcanard: Examples, Starters, Tutorials - #4 by hugo](https://forum.opencyphal.org/t/libcanard-examples-starters-tutorials/935/4). If you have any specific questions, do ask.

---

_[View the full topic](https://forum.opencyphal.org/t/batteryinfo-message/977)._