0

I have two DPS310 sensors. My aim is to find the altitude value from these sensors. Both sensors give different altitude values.

I have checked the calibration coefficients. Two are similar, but have slight differences.

Altitude values are 60.435 m and 67.75624 m. The decimal points will change, but it will always keep approx 7 m difference.

Is the issue in the calibration coding?

Program output:

temp 28.626144 pressure 100491.070313 
temp 28.632156 pressure 100491.148438 
temp 28.625565 pressure 100491.351563 
temp 28.617828 pressure 100491.445313 
temp 28.608093 pressure 100491.039063 
temp 28.609528 pressure 100490.960938 
temp 28.609528 pressure 100491.109375 
temp 28.599792 pressure 100490.882813 
temp 28.612099 pressure 100490.843750 
temp 28.615540 pressure 100490.937500 
temp 28.615257 pressure 100490.882813 
temp 28.613823 pressure 100490.773438 
temp 28.614105 pressure 100490.867188 
temp 28.620125 pressure 100491.046875 
temp 28.612679 pressure 100491.101563 
temp 28.614967 pressure 100490.601563 

altitude = 44330 * (1.0 - pow((pre[0] / sea_level_pressure), 0.1903));
Lundin
  • 17,577
  • 1
  • 24
  • 67
Vivek pkd
  • 5
  • 3
  • 1
    Are the results within sensor tolerance? – Justme Feb 01 '22 at 05:14
  • 1
    Datasheet links help. What does datasheet suggest? What values are you getting? ( Nobody can answer the question without that last information) – ATCSVOL Feb 01 '22 at 05:38
  • @ATCSVOL [DPS310](https://www.infineon.com/dgdl/Infineon-DPS310-DataSheet-v01_02-EN.pdf?fileId=5546d462576f34750157750826c42242) i followed programming technique from datasheet .the two sensor values are like 60 ,67 everytime keeps ~7 difference . but decimal points makes calculation accuracy wrong. – Vivek pkd Feb 01 '22 at 05:42
  • 5
    Absolute accuracy +\- 8m. If your difference is 7m, then it is within spec. – Kartman Feb 01 '22 at 05:51
  • Related, if not identical: https://electronics.stackexchange.com/questions/602344/dps310-altitude-sensor-values-changing-over-time – winny Feb 01 '22 at 08:13
  • Also you are using some Arduino software floating point lib so you won't get better accuracy than what that lib can do. It's a very bad idea to use floating point on an Arduino. – Lundin Feb 01 '22 at 08:41
  • @Lundin sry, its not arduino . Iam using NRF52832 uc, i modified above. – Vivek pkd Feb 01 '22 at 08:47
  • That's quite a different MCU, it's a Cortex M4 with FPU so you should be fine then, at least floating point-wise. – Lundin Feb 01 '22 at 08:52
  • @Lundin - why is it 'bad' to use floating point on an AVR based Arduino? Its accuracy should be the same as a NRF52 using hardware FP as it is only single precision. Performance is hardly an issue in this application. – Kartman Feb 01 '22 at 12:26
  • @Kartman Because it eats up every resource on a crappy AVR. Also I can't vouch for the accuracy of whatever floating point sw lib they are using. And then there's always the possibility of "sloppy typing", using `1.0` instead of `1.0f` etc and if the sw lib happens to support double precision, you get accuracy or type problems there too. – Lundin Feb 01 '22 at 14:13
  • When to use floating point in general: https://electronics.stackexchange.com/a/494924/6102 – Lundin Feb 01 '22 at 14:14
  • @lundin, your reasons don’t seem to be based on verifiable fact. How does the fp lib differ between avr-gcc and arm-gcc? Sloppy typing affects both. Eats up every resource? How does hardware fp change anything else but performance? Cm4 fp is only single precision - back to sw if you want double or get a cm7. besides a hw fpu still has the precision issues of fp and it does help with fixed point. – Kartman Feb 01 '22 at 14:37
  • @Kartman Again, I have no idea how the fp lib works but it ought to be adapted to the specific ISA since they are normally written in assembler. I haven't used sw fp in AVR, but I've done so on HCS08, STM8, HCS12 and R8C which are fairly similar 8- and 16-bitters. The sw fp libs typically take some 2k to 5k flash and a single equation typically boils down to (very roughly) some 300 to 1000 instructions. If we make a generous estimate, say 300 instructions, 3 ticks per instruction, 8MHz system clock... then that's >100us per floating point equation in C. See the problem here? – Lundin Feb 01 '22 at 15:25
  • I fail to see a problem. In this instance getting the sensor data via I2C will probably take longer than 100us. If we were wanting to do a real time fft using floating point on a tiny44, then, yes, we have a performance and resource issue. We all know running Basic on a 6502 is slow and it used fp so how is the AVR any different? Using fp is perfectly ok if you understand the limitations. Shared variables with ISRs without atomic protection is bad as it can cause unwanted side effects. – Kartman Feb 01 '22 at 22:26
  • @Kartman Is there any better sensor to track the height of an object in 3D. – Vivek pkd Feb 02 '22 at 04:49
  • ‘Better’ in what respect? ST have a fancy 8 point LIDAR sensor that is mainly targeted to focus for cameras. There’s GNSS. You need to tell us some specifications and cost constraints - ‘cheap’ is not a valid cost description! – Kartman Feb 02 '22 at 05:59
  • @Kartman , You said right the sensors have 0 to +/- 8 difference . i have done lot of test. its in this range . But its not fixed .one day i put both sensor together in ground its giving 4.5 m difference. Next day its giving 6.1 m . Because of this every day i need to change this offset .. is there is any fix for this???? – Vivek pkd Feb 04 '22 at 05:48
  • You do realise these sensors use air pressure to determine altitude? Air pressure changes. Even pilots have to recalibrate their altimeters before they take off. I think you might be expecting too much from the wrong sensor. – Kartman Feb 04 '22 at 06:23
  • @Kartman thanks for your support and guidance. I got some valuable information from all these comments, I will research it. – Vivek pkd Feb 04 '22 at 06:57

0 Answers0