Need clarity for battery service parameters 0.2

[echoGee]

https://github.com/UAVCAN/public_regulated_data_types/blob/master/reg/drone/service/battery/Parameters.0.1.uavcan has a parameter unique_id.

I think it needs more clarity on how it may be defined. If its 64 bits, is the idea for a vendor to use a random 40 most significant bits to identify the vendor and the rest bits to identify a particular battery ?

1. Shouldn't the vendor bits be shorter than the number of batteries they may represent ?
2. Is it supposed to be CRC64WE of (ManufacturerName + DeviceName + ManufactureDate + SerialNumber) or the random bit representation ?

Also need clarity for uavcan.si.unit.electric_current.Scalar.1.0 charge_termination_treshold # End-of-charging current threshold
What does this parameter represent ?

[pavel-kirienko]

If its 64 bits, is the idea for a vendor to use a random 40 most significant bits to identify the vendor and the rest bits to identify a particular battery ?

Yes.

Shouldn't the vendor bits be shorter than the number of batteries they may represent ?

The vendor bits are chosen at random so the collision probability estimates look as follows:

Collision probability, n. vendors vs. ID width	1000	10000
32 bits	0.01%	1.16%
40 bits	0.00005%	0.005%

If you, as a vendor, prefer to switch to 32/32 over the current 40/24 and you are comfortable with the marginally increased risk of collision, we can do that. Going any further would be a mistake.

Is it supposed to be CRC64WE of (ManufacturerName + DeviceName + ManufactureDate + SerialNumber) or the random bit representation ?

Hashing is intended for use with smart battery protocol converters that have to provide a DS-015 compliant interface based on the data they obtain from the battery. If your battery stores a unique numerical ID, then you can just use that, otherwise, use hashing. See, the only requirement for this field is to be unique, everything else is optional.

Also need clarity for uavcan.si.unit.electric_current.Scalar.1.0 charge_termination_treshold # End-of-charging current threshold
What does this parameter represent ?

From https://batteryuniversity.com/learn/article/charging_lithium_ion_batteries:

Figure 1 shows the voltage and current signature as lithium-ion passes through the stages for constant current and topping charge. Full charge is reached when the current decreases to between 3 and 5 percent of the Ah rating.

Field charge_termination_treshold informs the charger when the charging should be terminated. This field was introduced in the original draft definitions and I think it was proposed by NXP. @PetervdPerk-NXP might or might not have additional info.

[echoGee]

If its 64 bits, is the idea for a vendor to use a random 40 most significant bits to identify the vendor and the rest bits to identify a particular battery ?

Yes.

Shouldn't the vendor bits be shorter than the number of batteries they may represent ?

The vendor bits are chosen at random so the collision probability estimates look as follows:

Does it need to be chosen at random ? Since this DSDL is the reference that would be used by any vendor/user of the DSDL, does it not make sense to create a repository with the vendor names. If a vendor badly wants to use an existing ID, they may still do that with the downside that it will collide with the existing vendor.

Collision probability, n. vendors vs. ID width 1000 10000
32 bits 0.01% 1.16%
40 bits 0.00005% 0.005%
If you, as a vendor, prefer to switch to 32/32 over the current 40/24 and you are comfortable with the marginally increased risk of collision, we can do that. Going any further would be a mistake.

I think its easier to maintain a repo with the hopefully 1000s, maybe not upto the millions vendors, than rely on a random number to prevent collision?
2^32 different unique battery ID seems enough to start :)

Is it supposed to be CRC64WE of (ManufacturerName + DeviceName + ManufactureDate + SerialNumber) or the random bit representation ?

Hashing is intended for use with smart battery protocol converters that have to provide a DS-015 compliant interface based on the data they obtain from the battery. If your battery stores a unique numerical ID, then you can just use that, otherwise, use hashing. See, the only requirement for this field is to be unique, everything else is optional.

Also need clarity for uavcan.si.unit.electric_current.Scalar.1.0 charge_termination_treshold # End-of-charging current threshold
What does this parameter represent ?

From https://batteryuniversity.com/learn/article/charging_lithium_ion_batteries:

Figure 1 shows the voltage and current signature as lithium-ion passes through the stages for constant current and topping charge. Full charge is reached when the current decreases to between 3 and 5 percent of the Ah rating.

Field charge_termination_treshold informs the charger when the charging should be terminated. This field was introduced in the original draft definitions and I think it was proposed by NXP. @PetervdPerk-NXP might or might not have additional info.

Makes sense. Would be good to be more verbose above this.

[pavel-kirienko]

Does it need to be chosen at random ? Since this DSDL is the reference that would be used by any vendor/user of the DSDL, does it not make sense to create a repository with the vendor names. If a vendor badly wants to use an existing ID, they may still do that with the downside that it will collide with the existing vendor.

Randomness allows us to avoid the cost of maintaining a registry. I am not sure if there are any tangible downsides here. We could perhaps define these 32-bit as crc32c(ManufacturerName) if you want determinism as it would unambiguously bridge the numerical ID with the vendor name without the need for centralized management. Then the lower 32-bit would be crc32c(DeviceName + ManufactureDate + SerialNumber) or a simple sequence number. Here, crc32c stands for Castagnoli CRC32 function (it is already used in other parts of UAVCAN for other purposes).

If you find it sensible, we can update the description of the field accordingly. As I said above, this is a mere recommendation rather than a hard requirement.

I think its easier to maintain a repo with the hopefully 1000s, maybe not upto the millions vendors, than rely on a random number to prevent collision?

It is not easier because vendors are bad at following rules and having to maintain another centralized registry complicates the standard.

Makes sense. Would be good to be more verbose above this.

Would you like to extend #105 with these changes?

[echoGee]

Randomness allows us to avoid the cost of maintaining a registry. I am not sure if there are any tangible downsides here. We could perhaps define these 32-bit as crc32c(ManufacturerName) if you want determinism as it would unambiguously bridge the numerical ID with the vendor name without the need for centralized management. Then the lower 32-bit would be crc32c(DeviceName + ManufactureDate + SerialNumber) or a simple sequence number. Here, crc32c stands for Castagnoli CRC32 function (it is already used in other parts of UAVCAN for other purposes).

Please make it crc32c(ManufacturerName) . That way it stays constant for a vendor.

If you find it sensible, we can update the description of the field accordingly. As I said above, this is a mere recommendation rather than a hard requirement.
It is not easier because vendors are bad at following rules and having to maintain another centralized registry complicates the standard.

It is ok even if they dont follow from what I understand. But I dont care either way. Thought a list of vendor may be helpful to a maintain for marketing/product search perspective.

Makes sense. Would be good to be more verbose above this.

Would you like to extend #105 with these changes?

Can do.

[pavel-kirienko]

Please make it crc32c(ManufacturerName) . That way it stays constant for a vendor.

Ok. I will be waiting for updates in #105