search

Openvario / sensord

Daemon to poll air data from Openvario sensorboard
6 stars 11 forks source link

New Hardware #26

Open hpmax opened 4 years ago

hpmax commented 4 years ago

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.

hpmax commented 4 years ago

Update:

I've pretty much handed this off to @DanD222 since he was eager to work on it and had some particular use cases he was concerned about. Also, I've been distracted trying to fix the software on the current version.

After looking more into this I'm thinking that the AMS5915 sensor should be replaced with a DLLR-L30G-E1BS-C-NAV8. The new sensor is about $20 more than the 4515DO or AMS5915, but the performance is spectacular. Claimed performance is literally an order of magnitude better than the the 4515DO or 5915. Availability of the 5915 seems questionable, and the 4515DO appears to only be available in the low power version which may be vulnerable to the same problems as the 5611. Also, Amphenol (manufacturer of DLLR) has been providing me heroic levels of communication compared to Tyco or Austria Microsystems. The L30G also has 50% larger range, supporting airspeeds to 214 knots indicated, whereas the other parts only go to 175 knots. Note that the upper 5% is probably fairly questionable, so realistically it's probably only good to about 170 knots. An L20G which has the same range as the AMS5915 is theoretically orderable but doesn't seem to be actually available.

We are likely going with the new ESP32-S2-WROOM. This is only single core, and lacks BT, but it has USB, its lower power, and in many cases is faster than the older dual core models. The plan is to connect a USB GPS to the device and allow it to (at least eventually) perform full IMU and report all data to XCSoar.

Regarding the audio amplifier. My preference is the MAX98304. This is a Class D amplifier, with extremely low EMI, and high efficiency as well as programmable gain and high power output. The problem with Class D amplifiers is that they can throw out a lot of noise at frequencies that could affect our radios. Minimizing the radiated emissions is vital. If we don't do a good job, we could end up with one install that works, and another that doesn't, and the advice will just be... Move cables around and hope it works. The MAX98304 is MUCH better than most other parts in terms of emissions. DanD222 doesn't like the MAX98304 because it is a BGA that is harder to solder and the pitch may make it harder to manufacture the PCB, especially at cheap Chinese board houses. He has a point. I have proposed an alternative part which is the MAX98360A. This part basically has the same output stage as the MAX98304, but it uses an I2S interface instead of analog. The benefit of the MAX98360 is it is available in a large QFN style package, which would be easier to solder and easier to make a board that works. The downside is we are switching from analog to I2S. This is, theoretically an improvement, and the ESP32, CubieBoard, and RPi all have I2S interfaces, so I'd hope that switching between them should be fairly easy -- but I have no experience with this and have no idea what is involved. Another alternative would be to custom manufacture a carrier board (like with the ESP32) which is higher quality and then solder that on. Small boards like that, even in low quantity are only a few dollars.

Looking for comments here: @DanD222 @bomilkar @linuxianer99 @iglesiasmarianod @kedder

bomilkar commented 4 years ago

Hi, thanks for reaching out. Here my 2 cents:

  1. software development is a crucial part of the end product. I haven't seen much related to that in the above. I don't know ESP32 well enough. Maybe there is an efficient solution and that's the obvious choice. I suggest to use freeRTOS or alike on the ESP32 particularly if you implement a full BT and/or WIFI stack on the same OS.

  2. I have started to explore the BMP388 last winter. It isn't much better (says the data sheet) compared to the BMP280. But the real advantage is the ability to continuously sample an convert pressure values at rates up to 200 Hz. I'm currently experimenting with 25 Hz and 50 Hz which seem to be the best trade-off on my system. The BMP388 has FIFO to store the data which relaxes the timing requirements on the OS. This data stream passes through several stages of DSP. BTW: analyze the impulse response of the Kalman filter in sensord and compare it to a FIR: you'll be surprised. It's hard to predict the response of 1D Kalman, not to mention a 12D Kalman which you need for Sensorfusion.

  3. I don't want to duplicate functionality which XCSoar is already doing well, unless I have to. So if I want netto vario and/or s2f I need not only audio but also some information from XCSoar: real polar (including bugs and wing load) and McCready. Keep that in mind when you plan the data flow between the components. The OpenVario driver in XCSoar has all (?) the hooks already.

  4. regarding IMU: The bottom line: I failed to improve the vario signal with using an IMU. The math behind the sensor is COMPLEX! Sensor fusion with 10+ dimensions and ~100 iterations per second is a huge compute load. You can simplify the matrix calculations quite a bit, but then I ran into non-converging anomalies from time to time. After 2-3 months I gave up. And to be honest: a state of the art set of pressure sensors in combination of a DSP chain can do very well. In real live we are not interest in bubbles. We want to quantify thermals of 200m diameter. Wind calculation is important, too. But no sensor or algorithm in the world can indicate the wind 200m below.

  5. I don't think you need expensive differential pressure sensors for air speed. At speeds at which our gliders fly the pressure difference is quite substantial. There is no disadvantage to compute PTOT - PSTAT over doing it in the sensor element. You will always have a small pressure offset at very low speeds (< 20 km/h) regardless of which sensor type you are using. At speeds of > 70 km/h the offset doesn't really matter.

  6. I guess @hpmax mentioned the "non-real-time nature of Linux". Absolutely! That bites you when reading the pressure sensors. I decided to separate the vario into it's own box with it's own CPU. It's not so critical which processor you pick as long as it comes with a decent S/W development environment. In my opinion the very minimum is a fully fledged GNU compiler suite. I have picked a STM32F407 and I use mbed OS.

  7. a pressure sensor is a microphone, just for a different frequency range. You have to keep that in mind if you want to lower the noise in the system. It may have implications on the housing and the pcb design. And maybe on the plumbing between the probes and the sensors.

  8. newer satellite positioning systems (GLONASS, GALILEO) might offer higher resolution in space and time compared to GPS. This might be a good reason to support a dedicated input. It might help improve the measurement in certain corner cases e.g. wave.

Here I describe my configuration in the glider if you are interested: https://forum.xcsoar.org/viewtopic.php?f=30&t=2974#p16507 It has some details on the my vario and OV.

hpmax commented 4 years ago

@bomilkar

1) ESP32 was suggested by Timo. I'm okay with it, but no one seems to have any experience with it. I'm not an embedded systems guy, but I assume I can figure it out. I don't know if WiFi will be used. BT would be great, but the ESP32-S2 doesn't have BT, so @DanD222's plan was to add an HC-05 module to support that. Perhaps on the underside since I think the top is filling up quick.

2) I'm inclined to go with the LPS22HH based on comments by Kris Winer. It also has continuous sampling mode and a FIFO. It's dirt cheap, and according to him, it's got the best noise performance available.

3) XCSoar can provide that information to the vario (I think) and I want it to... not because I want it to replicate netto functionality, but because I want a better Kalman filter. When the Kalman filter propagates the state, it would be nice to have the polar and start off with an assumption of sink rate based on airspeed. If you have IMU information, that could be further refined with... oh look, you're pulling 1.5G's in a bank, your sink rate goes up because of it. This gives more accurate information out of the vario, even just the regular compensated portion.

4) I agree that sensor fusion is very difficult, but I think we should at least try. Like I said in the above paragraph, I think it is helpful. An artificial horizon is a nice thing to have just in case. An accurate compass that is compensated for variation and deviation would be nice to have. And it's truly hard for me to imagine that accelerometers wouldn't be useful in vario calculation. The point is to include the hardware, and hopefully someone will be able to figure out how to make these useful in software at a later date. This will likely be the hardest part, I have no illusions it will be easy.

5) The problem is, if we use a pressure sensor we need to use one that is a good choice overall. To be blunt, I'm pissed off with Tyco with regards to the MS5611. Their support has been awful, and the 4515DO which they claim to have slightly better performance than the AMS5915... the only version with the appropriate dynamic range uses a "low-power mode" which isn't continuous sampling. I think it's very possible it will have the same problem as the MS5611. That leaves the question about the AMS5915. Maybe in Europe they are readily available. In the US, not so much. There's ONE company that sells them, and I've never heard of the company. When I contacted them, it felt like I had to pull teeth to get info from them. They wanted a lot of money and had a Minimum Order Quantity, which they said they would waive because they didn't have enough to fulfill the MOQ. Support from AMS was limited, as with Tyco.

Talking to Amphenol is totally different. Their sales guy has been helpful, and has consistently responded within an hour or two of me emailing him. They are readily available from Mouser. There are two versions, one is somewhat better than the AMS5915, and only about $5-8 more, the other is MUCH MUCH better and $20 more. I think the footprints and usage should be the same, so we can design for the low cost one, and if then test the high cost one, and if it makes a difference, switch to it easily.

At around 40 knots, I think the AMS5915 could be off by as much as 4 knots indicated. We can calibrate some of that out with a single point cal, but the cal does drift with temp and time. The Amphenol part is, as I stated, nearly an order of magnitude better and the sensorboard is putting out airspeed, not just up/down. I mean, I agree, at some point, the extra accuracy is effectively useless even if we have it. But frankly, I really dislike dealing with TE and AMS at this point.

8) As an American, allow me to point out, the US is now rolling out Block III GPS which is a substantial improvement over Block II in terms of accuracy, and other things. The point was to use an external device so that people could add a cheap GPS receiver with the best available capabilities and upgrade easily.

My big concern here really is the audio amplifier issue.

bomilkar commented 4 years ago

@hpmax I'm using an audio am lm4871mx. I don't see any of the issues that were mentioned above.

From looking at the datasheet the LPS22HH seems like a very good choice. I had spend a lot of time analyzing the performance of the pressure sensors just by running it in a mode which I planned to use and on the (near) final PCB. Capture the raw data and analyze for noise, quantisation, linearity.

When do you expect to have the first prototypes up and running?

hpmax commented 4 years ago

@bomilkar The LM4871 is a Class AB amplifier which would not have those sorts of issues. It has an entirely different sort of issues. I've had two MAX9718 (VERY similar to the 4871 fail on me). Are you using a 4 ohm speaker or 8 ohm and how much voltage gain do you have?

As for when it will be complete, that's a question for @DanD222... I'm afraid this is going through feature creep.

bomilkar commented 4 years ago

@hpmax It's one of those small speakers commonly used in gliders. Don't know which impedance this thin is supposed to have. The gain is 15k/22k inverting. 5V supply. I'm driving it from the DAC output of the STM32F407 which is fed by one of the DMA channels, which is controlled by one of the timers.

WRT the differential pressure sensor: why do you want one at all? 3 identical pressure sensors (vs. vacuum) is entirely adequate and it simplifies H/W and S/W.

hpmax commented 4 years ago

@bomilkar I'm a bit confused, are you not using the Cubieboard2 and sensord and variod? 15k/22k sounds like you may be getting about a gain of 3x. All I know is that the MAX9718 that Stefan used in mine died, twice, as a result, likely of leaving it on for many hours continuously and it makes me scared of running a Class AB amp. Stefan is using a gain of 4, which Maxim stated is probably higher than it should be (they suggest a max of 2). But I didn't exactly consider it to be loud when it was working. It wasn't quiet, but even at full volume it wasn't uncomfortably loud and considering that there may be all sorts of other noises in the cockpit, I'd prefer not to reduce power output.

As for the differential pressure sensors... I'm not sure how you came to the conclusion you did. I'd like to point out that the CURRENT sensorboard has a differential pressure sensor. I'm not in love with it, because frankly, Austria Microsystems may be available in Europe, but not so much in the US. There is one place in the US that has it, they have a minimum order quantity, they are a pain to deal with, they want a lot of money for shipping. And frankly, it's not that great of a part to begin with.

The sensorboard has a cal routine to calibrate 0 on the AMS5915. My calibration is about 1/3rd of a Pascal. By comparison, typical difference between static and pitot when the ports are plumbed together is about 60 Pascals, but it can vary +/- significantly, over time temperature, etc. In other words, people disliked the offset of the AMS5915 so much that they wrote a cal routine to deal with it, and the offset was about 200x less than the offset between two MS5611s, and they move around.

If you want an accurate number you want a differential pressure sensor. It's also worth pointing out that full scale on the differential pressure sensor is something like 5000 Pascals, whereas it's 120k on the regular ones, and absolute accuracy is typically a percent of full scale, so you're about 25x more accurate with a differential sensor. I mean... Why are we designing a new sensorboard to get a worse outcome than the original?

hpmax commented 4 years ago

@bomilkar pressure

Orange/red trace is the the TE pressure in kPa. Blue trace is the sample by sample difference in pressure between the static and TE ports (with the two ports tied together with a PVC tube). For comparison, 40 knots indicated is about 240 Pascals.

bomilkar commented 4 years ago

I'm not using variod nor sensord. I'm using SteFly w/o sensorboard and I'm not using SteFly's audio amp. Just XCSoar running on the Cubie2. I have my own vario with 3 pressure sensors (BMP280 soon BMP388), STM32F407, sending 2 NMEA sentences per second to XCSoar (TE in m/sec, PSTAT in hPa, PDYN in Pa. Example: $POV,E,2.98,P,877.13,Q,562.59*17). The vario drives a speaker and a gauge indicating m/s vario or netto vario. Plus a FLARM.

Relative accuracy (after DSP) is better than +/- 2.5 Pa. That is good enough for ~0.3 km/h at reasonable IAS. No static port on any glider I've seen delivers an accuracy of +/- 2.5 Pa. Usually much worse! And the acoustic noise adds on top if you are not careful.

Dynamic pressure serves to calculate wind speed. A wind speed error of ~0.3 km/h can be neglected.

I don't understand the trouble you have with the audio amp. The voltage gain for my configuration is 15k/22k = 0.68 inverting. It works well. Maybe you had a DC offset in your amp input? How else can you fry the amp?

I don't understand what you are trying to show in the graph. What is the x-axis? "the two ports tied together" ???

BTW: if you want to get a feel for the quality of the static port, compare TE, STAT, PITOT. On paper: Dyn = PITOT - STAT Dyn = STAT - TE So you have 2 ways to calculate Dyn if you have 3 sensors. If you had ideal pressure ports the 2 values of Dyn would be the same (even keel, no acceleration). But they are substantially different. That's why the handbook of your glider has a error graph for IAS. I have a combi-probe (TE,STAT,PITOT) and the usual STAT ports on the side of the glider. One project for the next season is to compare the 2 STAT values.

hpmax commented 4 years ago

Regarding the audio amp. It wasn't clear to me which was 22k and which was 15k, but a quick look through the datasheet indicated voltage gain was 2*Rf/Ri.

I am using Stefan's board which has a MAX9718 configured for 4x voltage gain. The design other than resistor values is the reference schematic shown in the datasheet. It includes coupling capacitors on the input. It failed. Stefan sent me a new board and the new board failed as well. I spoke to Maxim and they suggested that 4x gain was really high and that it was possible that the amplifier is overheating. They claimed that despite short circuit protection and thermal protection that prolonged power dissipation could kill it. I'd estimate I put 100-200 hours on it while doing testing. I regard the volune level as adequate but not exceptional. Others have complained volume is too low. I wonder if Stefan turned up the gain without realizing it was causing long term damage. I would like to switch to Class D so we can run the amp harder without risking damage. OTOH, maybe it just doesn't like a gain of 4.

The X axis of the graph was successive samples (you can treat it as time). The Y axis is the difference (in Pascals) in the reading of the static and total energy ports of the CURRENT sensorboard when I logged data over a long period of time. I ran PVC tubing to connect all three ports together and then connected them to a vacuum pump. So I vacuumed it down to about 40kPa and then allowed the vacuum to slowly leak out over hours. In otherwords what you are seeing is the difference between the two sensors on a sample by sample basis as a function of outside pressure. Now, in fairness... I believe that data was unfiltered. And I was deliberately injecting timing jitter and my compensation was clearly not completely dialed in, so that deliberately exaggerated the noise, but the noise should have been approximately the same on both.

The current sensor board uses two MS5611s and an AMS5915. The zero reading on the 5915 is about .35 Pascals. The cal routine tries to determine the correct value and subtracts it out to zero it, after cal its probably within .1 Pascal most of the time. By comparison the difference in static and TE readings (just from a noise perspective) is 10-20 Pascals and the absolute difference is perhaps 20 to 80... And that's over one temperature and a few hours. Without extraordinary measures I think you have 40 Pascals of uncertainty between two MS5611s.

bomilkar commented 4 years ago

Voltage gain is 2*Rf/Ri = 1.36. You are right: I forgot it's differential output.

Now I understand the graph. Blue is the difference between TE and STAT, with the same sensor types MS5611. That's really ugly. I'm surprised it's that bad! Could it be EM noise on the supply or over air?? My vario is in a separate box and the sensors are shielded from EM and acoustic noise and have a good thermal insulation so their temperature cannot differ too much. Can you put the sensorboard into a separate box away from the noisy computer?

hpmax commented 4 years ago

@bomilkar I have no idea why it's that bad, but I have no reason to suspect the sensors just aren't that bad. As for could it be EM and acoustic noise and thermal insulation etc, etc... They are located on a board, no more than an inch apart from one another. They are fed with 3.3V supplies which come from identical linear regulators that are fed from the same 5V supply. They are connected to the same tubing. In other words, this is about as ideal of a setup as it's ever going to see. And this is 100% Stefan's hardware.

I have no reason to believe it's not just that bad. Now, that said... Sensord is now sampling every 12.5ms, in a ping pong fashion. One samples temperature while the other samples pressure, and then they flip. Each sample on my graph represents one pressure sample from both sensors. So 1 million samples is ostensibly 7 hours. That said, I was deliberately throwing in a 300ms timing error every 700 samples in order to induce noise which I was trying to compensate out. I didn't do a perfect job and that may partially be why it was worse at higher pressure (toward the end of the graph) but the time noise I threw in was largely going to be common mode, so it's really not as bad as it might seem. Also, the mean shift from around 80 at the low end to 30 at the high end is real, and wasn't caused by my timing noise.

If we take that as a +/- 20 Pascals shift, over a range of 60kPA, I don't know why you think it's unreasonable to expect to otherwise ostensibly identical sensors to have a linearity discrepancy of .033% Page 19 of the MS5611 datasheet indicates it's reasonably to expect an error of anywhere from -.5 to .5 mbar over pressure AFTER 2nd order compensation. 1 mbar = 100 Pascals, so that's -50 to 50 Pascals over that range. I would be shocked if you can expect better than 50 Pascals of absolute accuracy, and you should expect them to shift somewhat over the entire range. The reason differential sensing is preferred, isn't just that you have a single sensor and therefore don't have to worry about offset from one sensor to another, but because the range is 0-5000 Pascals instead of 0-120000 Pascals, and most of these things are specified as accurate as a percent of full scale.

Also, if you are proposing that putting it in a "separate box" away from the "noisy computer" then I think we have a few issues. First, that is a complete architecture change from how we are doing things now. I think the whole group should be discussing this. Second, the sensorboard also has an audio amplifier and will have an ESP32 on it which you'd probably also classify as a "noisy computer." To be clear, I'm not opposed to having this as separate hardware, but this is a much bigger discussion and it will have implications on the design of the board.

DanD222 commented 4 years ago

Here's where I'm currently at (it's still WIP):

The aim is for the new sensorboard to be backwards-compatible with the current OpenVario/Stefly OV setup hardware-wise, while at the same time allowing for future development with the ESP32.

sensorboard_v11

Schematic: sensorb_v11_sch.pdf sensorb_v11_sch

Thoughts, anyone?

bomilkar commented 4 years ago

My thoughts in addition to what I wrote earlier:

  1. the connection between the sensors and the ESP32 should be SPI. It is faster and has a more flexible addressing scheme compared to I2C. I2C might be the only choice if you want to be compatible with the old sensorboard, but that shouldn't keep you from improving for the new functionalities with ESP32.
  2. consider a DS3231 RTC (plus backup battery on the flip side of the board). Its better to have system time right from start.
  3. consider a metal shield around the sensors to reduce electromagnetic noise on the sensors. At least on the prototype to see how much impact it has.
hpmax commented 4 years ago

@DanD222 I think you're doing a great job. I only have a few minor nitpicks and/or questions...

1) Why is filtering on the 3.3V regulators different? 2) It looks like you put three passives on the back. What were they and was there a good reason for it? 3) The bottom side wire that goes through the 10 pin connector looks like the spacing is slightly asymmetric... it's bothering my OCD... ;) 4) I'm not sure where the Class D amp pads are. Did you put soldermask on the bottom of the Class AB as suggested by Dave Jones? 5) I'm not a PCB expert, but based on feedback I've heard on other boards I've done, I'm not sure you are attaching to pads (particularly on the passives) properly. I have concerns about tombstoning, particularly near the IMU and C42 look a bit scary to me.

@bomilkar

1) SPI is theoretically better, but it requires a lot more pins since now we'd presumably need one SS line per sensor. The board is pretty packed in terms or routing. To get that, we might need to go to 4 layer which we were trying to avoid. Some sensors are not available in SPI (the AMS5915 which is what we are CURRENTLY using for airspeed), or require a larger or more expensive package to use. The interface to the CB2 is pretty much already defined to be I2C and we don't have the pins to switch to SPI, so this means there would be no way to talk directly to the sensors if we have to.

2) Why do we need a real time clock? It's possible that it could assist GPS in getting a lock, but that might be GPS specific AND most GPS's probably have RTC's in them to begin with. Other than that, why would the ESP32 need to know what time it is, especially when they will find out as soon as the GPS becomes live.

3) I suspect shields would require switching to a 4 layer board, and even then it would be hard to shield them. The LPS22HH have the POM block over them. The AMS5915 is mounted vertically, and have hoses coming out of it. The 4515DO and DLLR/DLHR sensors similarly have hoses coming out of them. So pretty much the only sensors I can think of that you could shield are the IMU and Mag sensor.

DanD222 commented 3 years ago

@hpmax

  1. I put pads for the ferrites after the linear regulators back, after reading this: https://www.analog.com/media/en/technical-documentation/application-notes/an101f.pdf
    We could theoretically put 0R resistors in their place if we decide we don’t need them. But it seemed like a good idea to have them back. I’ve also added caps after the ferrites.

  2. Those are solder jumpers - two of them are links for the “internal” and “external” I2C buses, the third one is a hook for future use to potentially enable or disable the ESP32 Wifi in case it’s not needed (for example, the ESP32 could read the pin on startup, and would only enable Wifi in case the pin’s high). I put the pads on the bottom so that they’re easily accessible. Are you concerned about ground plane integrity, build-ability, or both?

  3. Thanks - I don’t like that either :)

  4. I’m going for the daughterboard amp concept, so I didn’t put pads for an additional Class D amp on the board, but rather used the space for heat-sinking vias. I removed the solder mask on the bottom layer of the class AB amp (for anyone following this, it’s video “EEVblog #434 - SMD Thermal Pad & Drag Soldering Tutorial” on Youtube).

  5. I haven’t considered tombstoning actually. My plan was to have a friend reflow only the sensors, and do the rest by hand. So I tried to make the traces as short and thick as possible, including adding thick traces from some GND pads to vias in order to ensure a direct route. The aim was to have everything around the regulators as low impedance as possible, while at the same time lowering the risk of thin traces de-laminating by excess heat during assembly. I’d actually kind of like to keep it this way.

In the meantime, I’ve also added a polarity protection Schottky and a PTC for over-current protection to the bottom layer, both next to the 12V input pads.. and some over-the-top via spamming.

I’ve uploaded the files here: https://github.com/DanD222/sensorboard_NewHardware

hpmax commented 3 years ago

Regarding tombstoning... I'm not a PCB guy in general, but when I asked a more experienced friend to look over my layouts her primary complaint was about tombstoning.

If you have access to a reflow oven it makes sense to solder everything with reflow, especially if you have to reflow some components.

Her response to me trying to do exactly what you are doing was... It's a bad idea. The parasitic resistance and inductance from tiny length stubs just isn't that much and if you're really concerned use 2 oz copper.

I think designing it knowing you're going to create tombstoning issues is a boneheaded plan.

As for removing the soldermask. Inspired by Dave Jones I just sent off for a TPA6211 board to replace my MAX9718 board that keeps breaking and removed the lower soldermask. I intend to try to reflow it. Also I'm going to replace the MAX9718 on there with reflow.

That said... My calculation was that it was only delivering about 350mW to a 4 ohm load so it shouldn't be dieing of thermal issues.

I did notice two unusual things (I have a scope shot of one I can add). First, the inverting terminal seemed to be floating. If I probed between the coupling cap and CB, the signal would typically be about .5V and then slowly fall to ground. If I pull the probe off, wait a while and then re-probe it would do it again. This doesn't neccesarily seem fatal but it does seem weird.

The other thing was that I noticed what almost looked like a digital signal on my 5V rail. It had a variable width negative going 200mV pulses on it. Pulse widths were often in ms range (sometimes 10-20). Transition time on edges was in the single digit hundreds of microseconds (200-500 us) range.

DanD222 commented 3 years ago

I have a couple of PCBs on their way for the new sensorboard - is there anyone besides hpmax who’d be interested in contributing with coding for the project, and who’d welcome a ready-built or partially-built sensorboard?

Blaubart commented 3 years ago

Hi DanD222,

do you have a BOM? You didn't write any values for parts in your Eagle files. Can you publish the current files, pleas?

Regards Dirk

DanD222 commented 3 years ago

Hi Dirk - I've updated my repo with newer version files, which now have the values. Are you going to build it?

Blaubart commented 3 years ago

Thanks a lot and thanks a lot for your work!! So it is the final version? What is the deferent between sensorboatrd_V18 and sensorboard_18_V7?

I like to build it, but I like to modify a litte bit, so I can use it with OpenVario DS2:

hpmax commented 3 years ago

@Blaubart If all you want to do is physically move connectors around, that's fine so long as there are no parasitic issues.

I have to reiterate that I'm not sure how the ESP32 interfacing (including original programming) will work, but it is possible that the USB interface will be absolutely essential to programming the device and if you do not have USB access as in DanD222's design the board will not work.

What I don't want to happen is to get a design fork which will require different software. I have no intention of supporting multiple software configurations to handle a ton of different hardware configurations.

Blaubart commented 3 years ago

Hi Dan,

sorry, you misunderstood the point about USB connector. I connect one of the USB connectors from the hub directly with the sensor board. So I only change the place, nothing more!!

DanD222 commented 3 years ago

Sensorboard18_v7 are files exported for version 7 of Eagle, primarily for the benefit of hpmax.

V18 is a version after I had some PCBs made, the major changes are in that the via sizes are smaller (apart from the vias which are under ICs, which are bigger), and that the smaller vias are tented, reducing the risk of shorts. The USB EMI filter was also changed to a bigger sized component.

Where do you anticipate moving the pressure sensors to, and by how much? I would gather that they should be compatible as-is.

Blaubart commented 3 years ago

Hi Dan,

I can send you a picture of both PCB, the original sensor boar and the sensor board DS2, if you send me your mail address. At sensor board DS2, the small pressure sensors are more on the left. First one has 15mm distance from the edge and second one 30mm. AMS 5915 is 8 mm away from the left sensor board edge and 27mm away from the bottom edge. I also can send you his eagle files, if you like.

Regards Dirk

DanD222 commented 3 years ago

@Blaubart If you’re going to adapt the new sensorboard PCB for the DS2 project, may I suggest you keep the USB connector on the new sensorboard and not run wires from the USB hub inside the case? If you really want to keep the I2C connector, you could put it back where it was on the original sensorboard, and move the USB connector to where the audio amp is on the new sensorboard.

What do you plan to use the I2C connector for anyway? A temperature / humidity sensor can be connected easily via USB, as described in the forum, and you’ve got 7 USB ports in the DS2 project.

Blaubart commented 3 years ago

If you really want to keep the I2C connector, you could put it back where it was on the original sensorboard, and move the USB connector to where the audio amp is on the new sensorboard.

That's a good idea, if there is space enough. With this definitely good solution, all the housings of the already built OpenVario DS2 unfortunately have to be changed if you want to install the new sensor board. The other would be plug and play. But still I think your idea is better than mine! I want to use the I2C to measure the temperature. The sensor connected via USB ensures that my OpenVario stays open for a long time to shut down. I also always like to keep options open. Who knows what ideas we will have in a year. Then we might be annoyed that the port has disappeared

DanD222 commented 3 years ago

OK, see how it goes. What we’re trying to do with the new sensorboard is to have it backwards-compatible with existing Stefly hardware, where there are quite a few units around, whereas the OV DS2 is a new project, so my assumption is that you haven’t got a large existing user-base. So the way I see it, modifying the DS2 enclosure to have the USB connector cutout at this point in the project shouldn’t be as big of a deal.

(In case you’ve already built one, you could probably run the wire to the USB footprint in place of the audio amp like you wrote earlier as a workaround, but it’s not something I’d like to see the project inherit from the beginning).

Blaubart commented 3 years ago

Hi Dan,

I've made some changes at the sensor board today so it fits to the OV DS2. I would be very appreciate if could cross check it. https://vdrblaubart.dynvpn.de/s/8nsBqBi7RkHeGs3

But I still have some questions:

Thanks!!

Blaubart commented 3 years ago

I think you swapped two PINs on the OAT connector, at least compared to the original sensor board. The tip should be the signal and the ring should be 3.3V

hpmax commented 3 years ago

I asked for the DLHR sensor footprint to be included because I don't know what is going to be used. It's possible we can support multiple options, but it is intended only one will be populated on the board.

The AMS5915 is from, no offense, a dinky Austrian IC manufacturer and is not readily available outside Europe. Support is questionable. The 4515DO is a gpod alternative which claims to be more accurate, but it's from our friends who brought us the MS5611, which is the whole reason a new board is being designed... Also, it may only be available in a low power version that scares me.

The Amphenol part is a whole different level. It's available, support has been good so far, and performance is in a whole different class. It's more expensive, but not wildly so.

DanD222 commented 3 years ago

Hi Dirk,

5VC = “Clean” 5V power rail, feeding the sensors 5VD = “Dirty/Digital” 5V power rail, which is where the Cubieaboard and the display live

The 5VC rail has additional filtering separating it from the 5VD rail, in order to:

The intention with the OAT connector was to prevent the jack momentarily shorting the 3V3 rail to GND in case of plugging the OAT sensor under power - I’m still not sure if it’s better to keep the old pinout and use say an inline resistor on the OAT power rail to limit current draw in case of a short circuit, or whether to switch to a new pinout.

Please also don’t change the OAT sensor jack to 3.5mm - keep 3.5mm for audio, use 2.5mm for OAT

Blaubart commented 3 years ago

Thank you for your advice! I swapped 5VD for 5VC on the I2C connector. I also replaced the OAT connector with a 2.5mm jack. I also took over your PIN assignment again, because your argument is a good one!

I hope I have implemented all of your advice correctly! New schematics: https://vdrblaubart.dynvpn.de/s/mBgzpHJsbPcKNQE

Can you help me to remove you holes for mounting and for the pneu block, please? I don't know why, but I can't remove them. I think I got it now. I copied everything and make a new board. It seem I could copy everything exept the holes. So they are removed now.

The 4515DO-DS3BK030DPL_NO_SILK is an alternative for AMS5915 or DLHR sensor, too? It seems no so easy to get. I can't find any shop. I prepare the assembling of the board but values for R1, R2, R16, R17, R23, R24 and D1 are missing.

Blaubart commented 3 years ago

I asked for the DLHR sensor footprint to be included because I don't know what is going to be used. It's possible we can support multiple options, but it is intended only one will be populated on the board.

The AMS5915 is from, no offense, a dinky Austrian IC manufacturer and is not readily available outside Europe. Support is questionable. The 4515DO is a gpod alternative which claims to be more accurate, but it's from our friends who brought us the MS5611, which is the whole reason a new board is being designed... Also, it may only be available in a low power version that scares me.

The Amphenol part is a whole different level. It's available, support has been good so far, and performance is in a whole different class. It's more expensive, but not wildly so.

The DLHR has almost the same price as AMS5915. So you would recommend to use that one?

DanD222 commented 3 years ago

A couple of things I see with the layout at a quick glacne:

You should be able to order everything from Mouser (apart from the parts that are currently out of stock) and get free shipping.

Another alternative to the 4515DO-DS3BK030DPL could be the 4525DO-DS5AI001DP, which is not a low power version, and is pin compatible.

hpmax commented 3 years ago

DLHR should be somewhat better and slightly more expensive. The DLLR should be MUCH better and somewhat more expensive than the DLHR ($10-20 more than DLHR).

I think they are very close to pin compatible if not completely pin compatible.

Blaubart commented 3 years ago

First of all, thanks for your help and patience! I hope I have implemented your advice properly.

You’re putting a big electrolytic cap (C32) where the tubing for the differential pressure sensor’s going to be. OK, the cap might not get populated. OK, thats no problem, I moved it a bit.

Keep power traces thick if you can (3V3_DIG). Thicker traces = lower resistance (in theory), and better trace adherence No Problem

Try to keep the USB D+ and D- lines close to each other (you could probably also rotate IC1 to avoid the “detour”) It has to be better now

You want the component decoupling capacitors “right at” the component pins (C3 should be next to a pressure sensor, not sitting in the middle of the board) solved

You don’t need to use the large vias around the I2C pull-up resistors (I did that on the power rails so that they wouldn’t be tented and I could probe them, but that probably wasn’t necessary either) You are talking about R1, R2, R23, R24, right? I've made them smaller

You should try to not break the ground plane, if it means moving a few traces and/or vias (for example the area around U13, or around the I2C pull-up resistors). I spent a lot of time on this on the new sensorboard layout, and there’s a lot of room for improvement in this respect in your current version. I think you are talking about the the vias you have distributed around the parts, right? I hope I got that right and revised the arrangement. If that's not OK, I unfortunately need a little more specific help here.

The new schematics: https://vdrblaubart.dynvpn.de/s/yaLEE48icf5RnnQ

hpmax commented 3 years ago

@Blaubart

The TR suffix means "tape + reel". You would want tape + reel if you are doing automated manufacture with a pick and place machine. Otherwise, it may just be a slightly less convenient packaging when shipped from the supplier. The actual component that is placed on the board is identical.

That said I would recommend the LPS22HH NOT the LPS22HB. The HH has better performance, and may be very slightly more expensive (<$1) but is the same package, pinout, and software interface.

Blaubart commented 3 years ago

Hi Dan,

Thanks!!

DanD222 commented 3 years ago

I think you are talking about the the vias you have distributed around the parts, right?

Yes - you want to move those vias and the traces so that you don't have breaks in the ground plane, both top and bottom. Plus you also want to place vias in places you've modified, so that you link the top and bottom ground planes together in places where they aren't linked.

See the amended _sensorboard_18_DS2dD1 files here: https://github.com/DanD222/sensorboard_NewHardware

You also had a lot of unnecessary trace jumping back and forth between the top and bottom layers, I've fixed some of that. I'll get back to you later about the part values.

Blaubart commented 3 years ago

Thanks a lot!!

hpmax commented 3 years ago

Hi Dirk,

I was speaking with someone from TE and he stated that the HTU31D replaced the HTU21D... the usual... better, faster, smaller, cheaper. Interface is different but not hugely different. It doesn't have a filter option available at the moment though.

Dan

Sent from my T-Mobile 5G Device Get Outlook for Androidhttps://aka.ms/ghei36

From: Blaubart notifications@github.com Sent: Thursday, February 4, 2021 7:21:51 PM To: Openvario/sensord sensord@noreply.github.com Cc: hpmax hpmax@hotmail.com; Mention mention@noreply.github.com Subject: Re: [Openvario/sensord] New Hardware (#26)

Thanks a lot!!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Openvario/sensord/issues/26#issuecomment-773691949, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAW5LUYY2NQ2X6PKJL276XLS5M2Z7ANCNFSM4RKQAHUQ.

Blaubart commented 3 years ago

Hi Dan,

but it is not a better option I would say. No filter available and it is much harder to get. I found one at aliexpress, but I couldn’t receive it before 15th of April.

Regards Dirk

Am 06.02.2021 um 01:12 schrieb hpmax notifications@github.com:

Hi Dirk,

I was speaking with someone from TE and he stated that the HTU31D replaced the HTU21D... the usual... better, faster, smaller, cheaper. Interface is different but not hugely different. It doesn't have a filter option available at the moment though.

Dan

Sent from my T-Mobile 5G Device Get Outlook for Androidhttps://aka.ms/ghei36

From: Blaubart notifications@github.com Sent: Thursday, February 4, 2021 7:21:51 PM To: Openvario/sensord sensord@noreply.github.com Cc: hpmax hpmax@hotmail.com; Mention mention@noreply.github.com Subject: Re: [Openvario/sensord] New Hardware (#26)

Thanks a lot!!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Openvario/sensord/issues/26#issuecomment-773691949, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAW5LUYY2NQ2X6PKJL276XLS5M2Z7ANCNFSM4RKQAHUQ. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Openvario/sensord/issues/26#issuecomment-774355047, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSBDZFGGJ4R3V2OUFRACJTS5SCPFANCNFSM4RKQAHUQ.

Blaubart commented 3 years ago

Hi DanD,

sorry for my impatient. Can you please send me the missing values? Thank you!!

DanD222 commented 3 years ago

Hi Dirk,

R1, R2, R23, R24 - These are all I2C pull-up resistors. There’s some interesting reading about the values of these on the web. 10k should do the job.

R16, R17 - Use ferrite beads here

R13 - DNP = Do Not Populate. That's a pad that was meant for testing purposes with the low power version of the differential pressure sensor, it's probably not necessary given that the 4525DO-DS5AI001DP should be available.

D1 - Any diode with a low-ish dropout that fits the footprint and has a high enough voltage and current rating, basically. I went on the Mouser site and searched around, looking for a product that wasn’t overly expensive and was in stock in large quantities. I’ve ordered SS24FL Schottky diodes for all polarity protection, but you can order pretty much anything here.

FERRITES - I’ve ordered LI0805H151R-10, but in hindsight I should have probably gone for something like the MI0805K601R-10, where the peak impedance frequency is nearer to our radio operating frequencies (see https://www.mouser.com/catalog/specsheets/Laird_10092020_Laird%20MCP%20Catalog-EMI%20Filtering%20and%20RF%20Inductor%20Sep%202020.pdf)

Blaubart commented 3 years ago

these ferrite beads are OK? https://lcsc.com/product-detail/Ferrite-Beads_Sunlord-PZ2012U121-1R0TF_C370081.html

DanD222 commented 3 years ago

Yeah, these look OK.

Blaubart commented 3 years ago

thanks a lot for helping!!

Blaubart commented 3 years ago

Hi DanD,

I get the quotation for the PCB. It is 20 times more expansive then comparable PCBs. The reason are 0.2mm drills. Is there any reason not change them to 0.3mm?

DanD222 commented 3 years ago

Hi Dirk,

OK, that wasn't intentional. I've enlarged the via hole sizes, see if that helped.