Skip to content

Add operator to convert raw adc units to volt #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

bruno-f-cruz
Copy link
Member

This PR adds an operator that can be used to convert a raw adc payload to a struct wit converted SI volt units. The current implementation allows bare payloads or Timestamped.

It should be noted that if in the future we add converters support to the device.yml, one can make this operator backward compatible by simply making it a passthrough on top of the converted values.

// ADC input = 2.0 V means 5.0 V on boards input
// 4096 -> 3.3/1.6 = 2.0625 V
// ~3972 -> 2.0 V @ ADC -> 5.0 V @ Analog input
return (float)(5.0 / 3972.0) * adcValue;
Copy link
Contributor

@artursilva0 artursilva0 Feb 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 - To be more precise, the 2.0625V is the configured maximum range of the Atxmega ADC, however the maximum value that the ADC receives when the input is at 5V is dependent on input resistive divider, i.e. 15/39 * 5V for hw >=v2.0. Therefore Vmax input ADC = 1.92307V ~ 3918.2 => return (float)(5.0 / 3918.2) * adcValue;
2 - For hw <= v2.0 the value is 16/40*5V = 2V ~ 3970.9;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok this is not good... @glopesdev I can only think of having an extra property that sets this value and it is by default for hw>=2.0. From the point of view of the interface, there is no way to distinguish a message coming from different hw versions, unfortunately.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok after thinking about this. I think we have 2 options

  1. Have two options in the operator that can be toggled for the two converters
  2. Change the firmware in <hw 2.0 boards to correct the raw adc unit scale to the same scale as hw2.0. From the point of view of the interface they would be fully compatible.

I am leaning towards the second solution has it would make the system a bit more robust from the point of view of the user. So I think for now we just implement this operator for hw 2.0 and release a new firmware version with the full scale patched.

Copy link
Collaborator

@glopesdev glopesdev Feb 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bruno-f-cruz @artursilva0 @filcarv there is a 3rd option to consider: generate two different packages, one for Behavior v1 and one for Behavior v2.

It might make sense because there are other differences than just the scaling factor, for example the v1 only has one ADC, so the packages could be structurally different.

We could either keep them in the same repo and have two branches with different YML files, or two different repos.

Copy link
Contributor

@artursilva0 artursilva0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please double check and correct the calculations for the voltage conversion. Thanks!

@CLAassistant
Copy link

CLAassistant commented Jun 9, 2025

CLA assistant check
All committers have signed the CLA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants