New Hardware

[hpmax]

I figured I'd start a new comment to discuss the second gen sensorboard. My proposed hardware at this point is:

1) LPS22HH (replaces MS5611). I really don't know which is better, but the LPS22HH is a LOT cheaper, and may actually be superior. It's worth testing.

2) MS4515DO (replaces AMS5915). Again, I don't know if its better, specs are slightly better, it's a little cheaper, and more available (at least in the United States). It's worth testing.

3) NCV8163 (NCP163 also seems to be a pretty equivalent part, replaces MCP1700) Slightly more expensive, and higher quiescent current (but still trivial compared to its load), it's smaller and spec-wise blows the doors off the MCP1700. Electrical noise is reduced by at least 30dB both in terms of PSRR and output noise. This is a DRAMATIC improvement. An open question on this is how many do we want? One for each sensor? Using independent regulators both improves PSRR and decreases cross talk noise on the supply.

4) ESP32-WROOM-32E Timo suggested it, I'm willing to go with it. I am a bit concerned about how much power it can consume, but I presume it's only consuming massive amounts of power when it's doing something useful.

5) LDL212PV33R... regulator for the ESP32. An NCV8613 could probably do the job, but they have a 250mA max, and aren't real good about dissipating power -- and the documentation I've seen on the ESP32 says you want a 500mA power supply. For manufacturing and cost reasons, it would be nice to stick with all one type, but oh well...

6) DS2482 (carried over)

7) LSM6DSM and MMC5983MA (replaces the MPU9150) The 9150 is long obsolete, the 9250 that replaced it is obsolete too. I spoke to Kris Winer who has a lot of experience testing different parts. Those were his recommendations along with the LPS22HH

Some additional comments/thoughts:

1) Is there supposed to be an audio amp on the sensorboard? The one I got from Stefan has the amplifier on the adapterboard. Regardless, I'd be inclined to replace the AS1701. Stefan is using the MAX9718A which seems to be a reasonable choice. The MAX98304 is a really nice Class D amplifier. Downsides are that you can't get more than 12dB gain out of it, and that its Class D and hence may emit noise. I'm building up an amplifier board now based on the MAX98304 and I think I can knock the EMI down by at least 60dB over all the frequencies I'd care about (IF, RX+/-IF freq) over already good results, and the 98304 is quiet to begin with by Class D standards. So I'm hoping it'll be okay. Otherwise, the MAX9718A is a decent choice, but it does have heat dissipation issues.

2) Do we want a drop-in replacement for the current board, or should this be an external unit which could interface to other things (for example a direct vario display) -- if so, how do we interface to the OV? One other possible choice here is the ESP32-S2, which is allegedly cheaper and lower power and supports USB. Downside is you also lose a core, and some memory, and Bluetooth. But allegedly the newer process is faster at floating point, which is what this thing is going to spend most of it's time doing. I like the notion of this being an external device that could directly receive GPS input, and directly drive an external display and then provide the OV with a complete IMU interface.

3) The new board is almost certainly going to be larger. The main driver for that is the ESP32, but there's just going to be more stuff on it period. I think there's plenty of room in the case, but I do worry because I think it's only held in place by the fitting screwed into the POM block. I don't know if this will cause a moment issue if the board extends further away from the end of the case.

4) Does anyone have a files with the board layout? I'd like to keep the sensor components in the same relative location so that the POM block can be reused.

5) EEPROM? I'm not sure what the point is. I'm not even sure what the point is in the current version. The data could just be stored in the configuration file (and in fact, it already is, so the EEPROM is just another compensation on top of the pre-existing compensation).

6) Anyone have any thoughts about putting components (capacitors in particular) on the bottom of the board? I want to be able to bypass the sensors under the POM block without interfering with the POM block.

[Blaubart]

Wow, thanks a lot! Now I only have to pay a twentieth!!

[jlder]

Hello, I am discovering this thread and very interested in what you are targeting.. I am working with a small group on improved algorithms to compute TE, Netto and relative Netto. Beside accuracy, our main goal is to eliminate wind gradients and load factor effects without damping the vario. Most of the algorithms we have tested so far require some sort of hybridization between IMU, GPS and air data. Therefore the board you are designing could be an excellent target to perform our testing. I am also familiar with the ESP32 and it would be easy to connect a display using a small TFT interfaced to the ESP32 SPI bus. Therefore also allowing for stand alone vario use.

Are you using this thread as the main communication tool or do you share information in other places as well? Regards, Jean-Luc

[hpmax]

@jlder Much of the conversation has been on this thread, but some has been on emails between me and @DanD222. He has completed a prototype board layout that is designed as a drop in replacement (from a hardware perspective) for the current sensorboard. Only downside is it loses the external I2C interface and is somewhat larger than the original board although it should still work with the original chassis. There is going to be a lot of work required on the software front and the most difficult of it will be sensor fusion so we'd certainly welcome any help you can provide.

[Blaubart]

@jlder I ordered a couple sensor boards they are completely assembled exept the differential pressure sensor. But I modified the board a bit, so it is now compatible to the OpenVario DS2, too. Here, what I've changed:

• I removed the amplifier (at OV DS2 it is on the adapter board)
• I moved the AMS-5915, the pneu block with both LPS22HH and the USB connector a bit
• I bring the RJ12 connector for I2C back to the board
• I removed the 10 pin IDC connector and replaced it with a RJ12

I have one board left and I think they will arrive end of March. But to be fair, I have to say that I can't guaranty, that there are no mistakes. Thats why I sell them at cost price! One board costs 67 Euros including shipping to Germany and custom. If you are interested, write me a message.

[jlder]

@hpmax, thanks for the info. I will therefore monitor this thread. I guess there will be boards available at some point of time. Is there an updated schematic/BOM? JL

[jlder]

@Blaubart, great to hear your prototype is progressing. Your proposal is very interesting. Looking at you deviation list, I noticed you talk about the AMS-5915. Didn't you replace it with an MS4515DO? The location of the sensors shouldn't be an issue since I don't have an openvario (yet) and would want to use the board standalone first. Would you have a schematic/BOM by chance, so that I could look at the interfaces you have on the board. I suppose that SPI or other I/O are not available on any connector and I would need to add wires directly to the ESP32? I will send you a message. JL

[Blaubart]

Didn't you replace it with an MS4515DO? Thats one of the reasons why I ordered without a differential pressure sensor. You can decide if you prefer AMS5915, MS4515DO or DLHR-L30G-E1BD-C-NAV8. Schematic is almost the same then DanD has designed. You can find eagle files of all version at DanD's GitHub: https://github.com/DanD222/sensorboard_NewHardware

[jlder]

@Blaubart, can I email you at Cap......@gmx.de ?

[Blaubart]

yes

[DanD222]

@jlder Hi and welcome. I like your plan with the display, at the moment you’ll need to solder wires to the ESP32 unfortunately.

I’ve bumped up the non-DS files to version 19 files in my repo - I've added a 6 pin header for SPI, 5V and GND.

I've also been thinking about adding two extra pins for I2C, but, we can use the pads of one of the unused differential pressure sensor for this. So it should be possible to run SPI, I2C and power to an 8pin RJ45 socket for example in order to interface to the outside world, if one figures out how to mount the extra RJ45 socket to the case.

[hpmax]

Wow, it's been a while...

My hardware doesn't seem to work (I think it was an assembly issue on my end) and I haven't messed with it in a while, but @Blaubart's sent me a copy of his DS2 board and it does work. I just started working on the software. I'm planning to ignore the ESP32 for now and just run it directly through the CubieBoard using the bypass mode, but I do intend to get the ESP32 working after that (I'd like to migrate to the ESP32-S3 also, as it's got a lot of improvements over the S2, still not quite out yet though).

I've written code to talk to the Amphenol differential pressure sensor (which I haven't tested), as well as code to talk to the LPS22HH. So far, I'm really happy with the LPS22HH compared to the MS5611. I set it for 75Hz sampling with the ODR/20 low-noise filter using continuous streaming/FIFO buffer.

I was able to detect the sampling speed by constantly polling the FIFO to see if there is a new slot in it and recording the last time before a sample is detected and the first time after a sample is detected. Most of the time, there isn't much jitter, but sometimes there is substantial jitter on the sampling rate. This could be a real problem since time between samples will DIRECTLY scale the climb/sink rate. The good news: it's possible it's not real. Given the previous timing issues we've seen on the CB this isn't shocking. I deliberately recorded the time between pollings, and the high jitter samples were well correlated to large deltas on polling time. Looking over a longer time period it appears the sampling rate is about 2% faster than advertised. The good news is, this is pretty easy to compensate for.

Looking at the recorded pressure and temperature data sitting on the bench, it looked really good... There was approximately 280 mPa discrepancy between the two sensors (judging from previous data I published this is a substantial improvement over the MS5611). Over 22 minutes of sampling, the discrepancy nearly linearly decreased to 270 mPa. Looking at the difference between the two sensors, we see:

Min: 233 mPa, Max: 319 mPa, std dev: 10.1 mPa, mean: 276 mPa (ST advertises a typical absolute error of +/- 500mPa --- so this is pretty close to the "expected" error).

Since there was a decreasing discrepancy over time, I decided to compare the difference to the moving average (+/- 15 samples around it):

Min: -33 mPa, Max: 34 mPa, std dev: 7.7 mPa

Looking at the individual sensors (after comparing to the moving average), I get: Min: -25.6mPa, Max: 26.0 mPa, std dev: 5.54 mPa (Sensor 1) (ST advertises a typical noise of 6.5mPa) Min: -21.7mPa, Max: 24.4 mPa, std dev: 5.32 mPa (Sensor 2)

One sensor is clearly better than the other. Unfortunately, utilizing that isn't trivial since you can't simply swap the TE and static plumbing since the static is plumbed into the differential sensor too...

Visually, the distribution looked very Gaussian with absolutely no glitches or weird behavior.

Similarly, temperature had a std deviation of 3.8 mK, with a worst case of +/- 35 mK. Temperature distribution didn't look as good, as there appeared to be multiple spikes in the distribution, but no large outliers. It's worth noting that this MAY be a resolution issue since the resolution of the sensor is only 10mK. The two sensors showed a discrepancy of about 358 mK which may have been changing slightly over time. Either way, I don't think temperature is an issue.

Since we're using the integrated filter, it's hard for me to correlate this to a real world comparison of the MS5611 (minus all of the MS5611's bad behavior) and it's probably worth performing similar tests without the filter, and with different sampling rates. Once I can determine the ideal settings, I'm inclined to update sensord just to talk to the LPS22HHs directly, that way @Blaubart et al can start using this thing sooner rather than later. Unfortunately, I can't do real world testing on his board since our POM blocks are different.

I tried a simple FIR filter: Y[i]=X[i].5 + X[i-1].5, followed by Y[i]=X[i].25 + X[i-1].25 + X[i-2].25 + X[i-3].25, and then Y[i]=.125X[i]... and then Y[i]=.0625X[i]..., here's what I got in terms of std deviation:

Sensor1: 5.5439 mPa: Sensor2: 5.3184 mPa (baseline) Sensor1: 5.0723 mPa, Sensor2: 4.8750 mPa (/2) 91.5% of original (should be 70.71%) Sensor1: 4.4266 mPa, Sensor2: 4.2646 mPa (/4) 79.9% of original (should be 50%) Sensor1: 3.4384 mPa, Sensor2: 3.3195 mPa (/8) 62.2% of original (should be 35.36%) Sensor1: 1.9817 mPa, Sensor2: 1.9145 mPa (/16) 35.9% of original (should be 25%)

Clearly, the noise is NOT white (looking at an FFT confirms this), but again, that's to be expected because it was already filtered.

So my immediate plan is to take more data in different configurations and confirm which is best. One realistic question is... Does the built-in filtering actually buy anything? If we're planning to run a filter on the data anyway, could a more sophisticated filter just be constructed.

The next stage will be modify sensord to support the LPS22HH. I'm undecided as to whether to make this an updated version of the current software, or to pull the MS5611 support out. I should be able to auto-detect the presence of the LPS22HH, but there's so much crap that is in there because of the MS5611 it'd be nice to just get rid of it. The LPS22HH appears to just work, and so it should be drastically simpler as long as the FIFO buffer doesn't overflow (which take a timing glitch of over 1.2 seconds).

[hpmax]

All data is from a bit under 100k data points at each point.

Unfiltered: 10Hz: Sensor1: (-81.425 to 68.178) std: 16.360 mPa Sensor2: (-67.855 to 69.454) std: 15.644 mPa 25Hz: Sensor1: (-70.927 to 68.021) std: 16.292 mPa Sensor2: (-68.021 to 69.454) std: 15.644 mPa 50Hz: Sensor1: (-69.281 to 93.569) std: 16.383 mPa Sensor2: (-66.296 to 78.487) std: 15.689 mPa 75Hz: Sensor1: (-71.297 to 70.557) std: 16.541 mPa Sensor2: (-73.045 to 65.760) std: 15.762 mPa 100Hz: Sensor1 (-207.622 to 215.206) std: 47.507 mPa Sensor2: (-224995 to 178.703) std: 44.818 mPa 200Hz: Sensor1 (-200.250 to 228.059) std: 47.335 mPa Sensor2: (-227.051 to 186.090) std: 44.885 mPa

Filtered: 10Hz: Sensor1: (-23.942 to 23.564) std: 5.4844 mPa Sensor2: (-24.879 to 25.320) std: 5.2700 mPa 25Hz: Sensor1: (-24.524 to 26.666) std: 5.4791 mPa Sensor2: (-23.296 to 24.225) std: 5.2895 mPa 50Hz: Sensor1: (-23.934 to 23.374) std: 5.5207 mPa Sensor2: (-23.414 to 23.374) std: 5.2691 mPa 75Hz: Sensor1: (-35.597 to 26.328) std: 5.5539 mPa Sensor2: (-26.643 to 22.973) std: 5.3397 mPa

My conclusions from this is the best choice is 75Hz.

Here's comparison of magnitude of the FFT of 75Hz filtered vs unfiltered.

Woopsie... My bad... What I described as mPa in both this and the previous post, is actually 1/10ths of a Pascal (or alternately 100s of mPa). Looking at the data, re-reading my code, and re-reading the datasheet... All of these were taken in "low-noise" mode, which ceases to be an option at 100Hz. So, in fact this is why the noise gets worse at 100Hz. I was thinking the "low-noise" option was being set when I turned the filter on, but it's two totally independent things. I guess the real question is do we use the in-built filter or can we construct a better filter external to the device.

It looks like noise is worse on the LPS22HH than the MS5611, but the effective sample rate is almost twice what we were getting out of the MS5611 -- averaging the data gives about 10% better noise than the MS5611 at about 6% lower sample rate.

[hpmax]

I initially thought that the unfiltered noise coming out of the sensor was white. I don't think so any more, I think there are peaks every 6000 samples, or roughly 2.4-2.5Hz. It's possible this is a result of the LPF0 filter that is permanently installed. The "fundamental" of this noise is CLEARLY higher than the harmonics. I tried experiments with putting in a Chebyshev Type 1 filter, and it does a great job of knocking out all the high frequency noise... far better than their ODR/20 filter does... But after the ODR/20 filter, a lot of noise content is still in the fundamental, which they clearly knock down somewhat over the unfiltered noise.

A survey of various vario manuals, seems to indicate most manufacturers have time constants in the 1-4 second range. I mean, other than adjusting the time constant to match that does anyone have any idea on getting noise out without messing with the actual data?

[hpmax]

I have a new version of sensord which appears to work fine with the new board. Anyone who has the new board (either of @DanD222 style or the DS2 style) and wants to try it out, please let me know. This should have all the functionality of the original (if you are using the AMS5915 -- if you're using the Tyco or Amphenol parts, let me know, and I'll work with you to get them working). I'm still working on developing a better filter though.

[norbertkuehne]

Now, with a little support, I have connected my sensorboard_Newhardware to an OpenVario with an adapter board DS v1. Currently I only have 5V SDA SDL connected. The hex addresses found on the I2C bus are: 18 28 AMS-5915 30 48 5C LPS22HB 5D LPS22HB 6A

There is probably a magnetic sensor hidden behind the addresses not listed IMU EEPROM

I have to try this again. In any case, the calibration tool gave me the error message that it couldn't find an eeprom.

[hpmax]

@norbertkuehne

Glad you've joined the party!

It's difficult for me to answer since things got kinda jumbled and not everyone used the same hardware. Revision control becomes a nightmare.

It's supposed to have two LPS22HH (not HB) . It supports several different pitot sensors as well as LSM6DSM (accel/gyro) and MMC5983MA (magnetometer) but it's hard to know what you are using.

As you can imagine the march of progress continues, there are newer and better sensors: LPS22DF (I think), and LSM6DSR (there is another sensor now available that Kris claimed has substantially better gyro performance).

At this point software development hasn't kept up. I want to get a nice IMU/Kalman engine going on before switching to a better hardware.

[bomilkar]

Regarding the LSM6DS* IMUs. I've discovered a strange behavior and verified it with more than 10 individual sensors. I've described it here: https://community.st.com/t5/mems-sensors/lsm6ds3-how-to-avoid-acceleration-steps-when-temperature-changes/m-p/65510

I've seen this "step function" with LSM6DS3 and have not verified it with other members of the LSM6DS family. However, I got no reaction from ST on this bug report.

I wasn't expecting this IMU to support anything fancy, like an artificial horizon. I was just looking for G-load (which XCSoar can use) or a simple slip/turn indicator. But with this "step behavior" I consider this sensor entirely useless. I'm currently using a BMI160 which is good enough for simple applications but also not good enough (too much offset drift) for an artificial horizon (which I'm not even interested in).

One more point and I'd like to get your comments on it. I want to implement a protocol to provide XCSoar with data from an IMU. A preliminary proposal is here: https://forum.xcsoar.org/viewtopic.php?f=30&t=4273 I'd appreciate your comments on this! So far nobody (except Max) had replied.

[hpmax]

@bomilkar I can try to investigate the problem you cite, but I don't think I saw that. I believe the LSM6DSM is considerably different from the LSM6DS3. There's also the newer LSM6DSR and LSM6DSV. The LSM6DSV has MUCH better gyro performance vs prior models. Kris had been recommending the LSM6DSM, and is now recommending the ICM-42688... However, the LSM6DSV performance is comparable to thepublished ICM42688. I think before you condemn the LSM6DSM/R/V based on the LSM6DS3 we should check it. Do you want me to try to take continuous readings while heating it with a heat gun and look for plots similar to what you showed?

As for your proposal... One question that I realistically have is how does XCSoar deal with contradicatory information. For example, if you have two GPS sources putting data in and they show a difference of 20 meters. Is one believed over the other? Are they both believed? Is it an average (weighted or unweighted?) I can see potential issue with this.

I'd like to see quite a few things added to the protocol, which would include control position (elevator, aileron, rudder, flaps, air brakes, wheel brakes, gear). These could be a -1 to 1 real value. Gear and wheel brake would presumably be 0 or 1, and air brakes would be 0 to 1.

I would propose it be something like: $SOMETHING,(EARFBWG),#,(EARFBWG),#,...*xx Where each EARFBWG would be one of those characters, and would be optional, but if selected the next field is mandatory.

Similarly, I think if you want to extend with IMU data it should be: $IMU,AV (accel vector),#x,#y,#z,G,#roll,#yaw,#pitch,M,#x,#y,#z*xx alternately, you could have $IMU,AS(acceleration scalar),#,H(eading),#

In the case of the IMU things are a bit more complicated because there's a question of whether or not these are calibrated values. Magnetometers are subject to hard and soft iron offsets. Is the reported number compensated for that? Is it compensated for magnetic variation? Is there compensation being misaligned with the aircrafts axes?

It would also be nice to be able to communicate: mute and volume, and to do so fairly bi-directionally.

[mhaberler]

in our project we found the sensor with the lowest noise and best vertical resolution by far is the Infineon DPS368

[bomilkar]

in our project we found the sensor with the lowest noise and best vertical resolution by far is the Infineon DPS368

The Infineon DPS368 is a pressure sensor. This isn't the issue here. I was referring to IMUs.

[bomilkar]

@hpmax

you are probably right, the LSM6DSM/R/V don't suffer from that issue. But I strongly recommend to test it thoroughly! Yes please "take continuous readings while heating it". I don't have LSM6DSM/R/V.

I'm reluctant to define a protocol to transport data which XCSoar can't use. What's the point? So what information do you have, which XCSoar can make use of (now or in the near future)?

In my opinion, calibration, compensation, or that kind of calculation should happen near the sensor, not at the consumer side of the data. The consumer (XCSoar in our case) should receive data in "normal" physical (metric) units. I'm proposing acceleration values in units of m/s² .

As far as I understand, XCSoar prioritizes the information according to the list of devices. For instance, if (an active) Device A in the list provides valid IAS data, all IAS data from Devices further down in the list (B, C, ...) will be ignored. So, if you have a good GPS source, make sure it is listed before your FLARM. And if your "good GPS" fails for a while XCSoar will fall back to your FLARM.

[hpmax]

in our project we found the sensor with the lowest noise and best vertical resolution by far is the Infineon DPS368

From what I see, vertical resolution is irrelevant, the only thing that matters is noise within the bandwidth of concern (which is probably a few Hz, I suppose if you're being anal, maybe 10Hz). It's important to remember that what we care about is accuracy of the first derivative not the original data. I looked through the datasheeet and saw no characterization of noise. If this were truly low noise why wouldn't they be screaming that in the datasheet? There competitors certainly do... Also as @bomilkar points out, we are talking about the IMU not the pressure sensor.

[hpmax]

@hpmax

you are probably right, the LSM6DSM/R/V don't suffer from that issue. But I strongly recommend to test it thoroughly! Yes please "take continuous readings while heating it". I don't have LSM6DSM/R/V.

I'm reluctant to define a protocol to transport data which XCSoar can't use. What's the point? So what information do you have, which XCSoar can make use of (now or in the near future)?

In my opinion, calibration, compensation, or that kind of calculation should happen near the sensor, not at the consumer side of the data. The consumer (XCSoar in our case) should receive data in "normal" physical (metric) units. I'm proposing acceleration values in units of m/s² .

As far as I understand, XCSoar prioritizes the information according to the list of devices. For instance, if (an active) Device A in the list provides valid IAS data, all IAS data from Devices further down in the list (B, C, ...) will be ignored. So, if you have a good GPS source, make sure it is listed before your FLARM. And if your "good GPS" fails for a while XCSoar will fall back to your FLARM.

To be clear, my only setup is a LSM6DSM. After looking at the datasheets again, I think the ICM42688 is actually probably considerably superior to the LSM6 and it's not just noise, it's also gyro drift.

I would love to have compensation done at the source rather than at the OV, however, I will point out that in some cases, it's impossible to do compensation without user input. Two obvious examples of this:

1) The accelerometer can probably do a decent job of telling which direction the Z-axis is, but it doesn't know the aircraft's attitude. So in order to calibrate the accelerometer, you would need to hold the aircraft in a certain position (say the position you use to measure weight and balance and push a "cal" button. You might then have to get a second known position, as a single cal point may be inadequate to fully calibrate. If you're perfectly aligned your transformed Z vector may be showing 1G and the X and Y showing 0. So how do you know which is which? Multiple measurements may need to be taken.

2) Properly compensating for the magnetometer involves taking multiple vector measurements in order to fit the data to an ellipsoid. Then calculate a transformation to turn it into a sphere centered at the 0,0,0. Then you have to define the axes in the same way you did the accelerometer. However, there is an additional issue as you also need to know which the nose is pointed when doing the cal.

This likely will require a somewhat sophisticated interface. If it's the sensorboard... guess what, you're only interface is through OV, whether it's a separate software package that's loaded through ovmenu, or something built into xcsoar. Your choices aren't that broad.

As for why include data XCSoar isn't going to use. What you mean is, XCSoar isn't using it right now. Why not? Because it has no way to get the information. Sort of a chicken and the egg problem. But someone may decide to use it if it were available... And the thing is... there's really very little cost to create the protocol. XCSoar presumably ignores NMEA sentences it doesn't understand, so you could define the protocol, and XCSoar could simply ignore it until it supports it.

In my case, I wanted to do a full IMU, because I was hoping it would help improve the vario performance. Perhaps I'm kidding myself. In that case, I want the ability to transfer IMU data (magnetic heading, pitch, roll, yaw, slip/skid info, air speed, ground vector, lat/lon/altitude, G's, etc). Some/most of this information is already available (and supported) in the Levil protocol.

[bomilkar]

I would love to have compensation done at the source rather than at the OV

If compensation cannot be done in the sensor itself, it should be done in OV. Not in XCSoar. That's what I meant. That would require some code (also for calibration procedure and measurements) in OV. This part I'm not talking about.

[bomilkar]

I think the ICM42688 is actually probably considerably superior to the LSM6 and it's not just noise

Yea, the ICM42688 IMU looks great .... on paper. However, I don't know what would be acceptable (for drift and noise) in order to still be useful to build a IMU-based variometer. A LSM6DS3 and a BMI160 is not at all sufficient, I think. And don't forget: what about availability? Where can you buy this thing in low quantities?

BTW: your comment about the pressure sensor. I fully agree, modern pressure sensors' performance in terms of accuracy and noise are much better than what we need. Don't forget our pressure ports are much much worse, So a vertical resolution of 0.5 m is about 10x better than what your TE, Stat, Pitot ports deliver. A more important feature which most of the differential pressure sensors and some of the "normal" sensors are lacking is a deep enough FIFO. This relaxes the timing on the S/W side immensely. Particularly important when the S/W is not a real time OS, like it is in the case of OV.

[DanD222]

If compensation cannot be done in the sensor itself, it should be done in OV.

I've noticed the appearance of Android-based OV-like devices running XCSoar, so that's also something to consider, especially if the New Hardware is to be used as a stand-alone sensor box.

[hpmax]

@bomilkar I'm American so in terms of availability, I'll say that both Digikey and Mouser have over 10k units of the ICM42688 in stock, and they are available in qty 1. At this point in time, I see no reason to consider availability as a problem.

Is it good enough? Again, I got the suggestion from Kris Winer... he claimed he was able to get drift down to 6 degrees per hour. I think that was uncorrected drift, but I could be wrong. In this case he stated he was driving the ICM with an external clock, from a ST uC and claimed: "The STM32L4 is capable of outputting a 32.768 kHz square wave from its 1-ppm-accuracy RTC embedded clock."

Github

Flat out, that sounds absurd to me. 1ppm is expensive and no dirt cheap micro is going to have a built in 32kHz oscillator that's 1ppm. It's possible that the 32kHz output is derived from a crystal oscillator and within 1 ppm of the derived clock noise. However, that said, I was able to find a SiT1566 that was 3ppm for $4, and there's a variant closer to $1 which is 5ppm. They're both TCXO, and I'm confident it's substantially less jittery more accurate than what Kris used.

Is 6 degrees per hour too much? My guess is... no, remember you have a magnetometer which when properly calibrated should give you the correct angle (which is the integral of the output of the gyro). So how hard should it be to mostly null out long term drift as long it's small. But I'm not an expert.

Regarding pressure sensors... Modern sensors have more than adequate resolution and accuracy for what we need, but noise... Noise is problematic. It's hard to emphasize how little of a pressure change is needed to really screw you up. The problem is that noise is effectively multiplied by the inverse of the sample period. Half the sample period, double the noise... And that's just the noise because of the derivative term. The sensor itself probably has noise that increases by 41% because you doubled the bandwidth. A fast responding sensor is VERY vulnerable.

This brings up the other source of noise you mentioned. Jitter in the clock. The LPS22 series have an internal oscillator. This is way better than relying on a non-real time system like the original sensorboard... but i don't know the characteristics of the LPS22 clock. There is likely to be some error, perhaps 1% or so which should translate to the same percentage error in the derivative. A 1% error is probably tolerable, but it's also easily corrected. Just pipe the 32kHz oscillator into a counter on the uC, and count how many samples you get per 32k clock ticks. But what about jitter in the LPS22 oscillator. There's no spec I saw on that. If it's high frequency jitter, no problem, it gets filtered. If it's low frequency... in or near your passband, you're going to have a bad day. It may be you could run it off a divided down clock from the SiT1566. Looking at the datasheet, it looks like worst case jitter is on the order of 0.1% from one period to the next, but typical is closer to 0.01%. To make things a bit more confusing. that's noise characterized from 100Hz to the Nyquist rate. Which is basically WAY more thermal noise than we are likely exposed to, but way less flicker noise. So... who knows what the real values are.

I'd love to spin a new board that uses the LPS22DF, the SiT1566 and the ICM42688 -- it could be a major step up. BUT... I've done the low hanging fruit. I wrote software to read the LPS22HH, and LSM6DSM... but I don't have the software in place to use it, and without that, what's the point.

Other upgrades would be to switch to ESP32S3 which has Bluetooth and a second core, and switching to a better (cleaner) power converter. Those two upgrades would make using this as an external board (outside the OV) far more desireable and make more sense of removing the custom electronics package from the computer/display/interface which theoretically could be more generic.