Comments (5)
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.
from public_regulated_data_types.
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.
from public_regulated_data_types.
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?
from public_regulated_data_types.
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 becrc32c(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.
from public_regulated_data_types.
Please make it crc32c(ManufacturerName) . That way it stays constant for a vendor.
Ok. I will be waiting for updates in #105
from public_regulated_data_types.
Related Issues (20)
- Define a new standard register for CAN sample point configuration HOT 2
- reg.drone.service.battery.Parameters.0.2 is missing the nominal cell voltage HOT 17
- Pregenerated headers of public_regulated_data_types to ease development HOT 3
- Incorrect nested type in reg.drone.physics.kinematics.translation.Velocity3Var
- Suggestions and questions HOT 3
- Some questions about the dsdl file under /uavcan/equipment/power HOT 2
- Migrate to GitHub Actions
- uavcan.can.iface is not exposing available interfaces HOT 5
- Extend primitive types with small fixed-size arrays HOT 2
- pycyphal demo HOT 2
- Remove the translational/rotational segregation in `reg.udral.physics.kinematics` and `reg.udral.physics.dynamics` HOT 1
- Modify the servo interface for compatibility with common trajectory generators HOT 1
- Incorrect name of uavcan.si.magnetic_field_strength
- Define standard registers for publication priority setting
- Stabilize v0.x data types in the `uavcan` namespace
- Add luminance to si types HOT 1
- Allow full stop inside the PORT_NAME
- Transfer UDRAL definitions to the DS-015 project
- Define new minor versions of data types that contain strings
- Cyphal/UDP: provide a standard register for overriding the priority to DSCP mapping
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from public_regulated_data_types.