On Thu, Apr 16, 2020 at 5:32 PM Stephan Gerhold <stephan@xxxxxxxxxxx> wrote: > On Thu, Apr 16, 2020 at 04:09:17PM +0200, Linus Walleij wrote: > > The manual for the HSCDTD008A gives us a scaling for the > > three axis as +/- 2.4mT per axis. > > I wonder if we can really assume that this applies to > the other models (e.g. AK8974) as well? Patches are for testing :D I have a Ux500 reference board with the AK8974 vanilla variant mounted so I will check with that one. > > + case IIO_CHAN_INFO_SCALE: > > + /* > > + * The datasheet for HSCDTF008A, page 3 specifies the > > + * range of the sensor as +/- 2.4 mT per axis, which corresponds > > + * to +/- 2400 uT = +/- 24 Gauss. So 0x7fff is 24 Gauss and > > + * 0xffff is -24 Gauss. To account for the one missing value if > > + * we multiply by 1/S16_MAX, instead multiply with 2/U16_MAX. > > + */ > > I just want to note that (according to the datasheet), HSCDTD008A > produces either 14-bit or 15-bit measurements (depending on > the HSCDTD008A_CTRL4_RANGE bit that we set by default). Argh OK I will fix this. I try to get an AMI datasheet as well. > I think this isn't exposed correctly in the AK8974_AXIS_CHANNEL() macro > (realbits is 16 instead of 15), so this might need special casing for > hscdt008a? Yes definately. It's a bug. I'll make a separate patch for this. > The reason I mention this is because I think it would also affect the > scaling that you implement here. With 15-bit output it produces values > from +16383 (0x3fff) (= 2.4 mT?) to -16384 (0xc000) (= -2.4 mT?). > > So it would never reach the 0x7fff and 0xffff you mention > in your comment. You're right. What I need to do is put the HSCDTD008A and AK8974 side by side and compare. Yours, Linus Walleij
