> On Mar 25, 2018, at 9:44 AM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > On Sat, 24 Mar 2018 16:06:17 -0700 > John Syne <john3909@xxxxxxxxx> wrote: > > This thread is becoming unmanageable so I am cropping this down to just > the questions that remain open. > >>>> Probably easier to copy and paste this table into a spreadsheet. Let me know if there is anything I got wrong. Thank you again for all your help. >>> Yeah, we need to shrink this if we do it again. >> I’ll send an updated copy after this e-mail. Can you accept a spreadsheet >> attachment or a CSV file? > We need to keep the discussion visible on list so it needs to stay in > plain text. Just need to drop any columns we aren't caring about to make > it easier to read. Done >>> > ... >>>> 0x439C CVAROS in_powerreactive0_phaseC_offset in powerreactive 0 phaseC offset R/W 24 32 ZPSE S 0x000000 Phase C total reactive power offset adjust (ADE7858, ADE7868, and ADE7878). >>>> 0x439D AFWGAIN in_power0_phaseA_fundamental_scale in power 0 phaseA_fundamental scale R/W 24 32 ZPSE S 0x000000 Phase A fundamental active power gain adjust. Location reserved for ADE7854, ADE7858, and ADE7868. >>> Hmm. Fundamental needs to be represented using a separate channel index >>> and description of the frequency filters applied. That should map it >>> a generic way. >> How do I do this? > Define additional channels with different index and for them > use the the infomask elements > IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY, > IIO_CHAN_INFO_HIGH_PASS_FILTER_3DB_FREQUENCY > and provide suitable values from the read_raw callbacks for that > channel. > > ... >>>> 0x43C0 AIRMS in_current0_phaseA_rms in current 0 phaseA_rms R 24 32 ZP S N/A4 Phase A current rms value. >>> in_current0_phaseA_rms_raw as otherwise we don't know we need to apply >>> in_current0_phaseA_rms_scale to it (or the shared value that maps to that). >> Yeah, this is still confusion to me. This should read in_current0_phaseA_rms_gain >> as it directly affects the value in_current0_phaseA_rms_raw. We still have to apply >> a scale value to turn this cryptic number into something meaningful. > So I'm a little lost. We have variable gain fine. > Does it effect the necessary scale factor to go from raw to real value or not? Yes > 1) Yes it does - then roll it as appropriate into the _scale attribute. > It should not be separated. This often requires some interesting maths > but is a onetime thing as the value isn't changing dynamically. > > 2) No it doesn't - then it is calibgain as it represents a necessary > parameter to change the incoming circuit to compensate for external effects. The hardwaregain and calibgain are setup only once and do not vary. The ADE7854 can accept various input ranges such as 0-250mV, 0-5V, etc The calibgain is used to compensate for the inaccuracies of the sensors and the termination components. > > It is possible you have a mixture of the two and hence need both but that > is normally only the case with devices where the calibgain is about fixing > the factory calibration. > > ... -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
