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.

[DanD222]

My two cents..

Regarding point 3. - separate regulators for each sensor please. However, are we sure about the ferrite after the regulator, like in the original sensorboard schematic? I would expect it to be pre-regulator, to better decouple the regulators from each other, and to not increase high frequency PSU impedance to the sensor?

Audio amp - I wanted to suggest the PAM8303 / PAM830 line for consideration as these can be hand soldered, but given that this won’t be possible for a lot of the components you’ve mentioned, it’s probably a moot point (same goes for through-hole electrolytic capacitors).

Regarding additional point 2 - I would love this to be able to live inside an OV as a drop-in replacement, but also to be able to exist on its own, feeding airspeed and vario data to XCSoar running on a mobile phone.

Regarding additional point 6. - I’ve wondered whether you could get air leakage from a via to a pressure sensor when using bypassing on the bottom side close to the sensor..?

[hpmax]

Going through your responses:

Ferrites: I don't see any ferrite beads. There are inductors in a Pi filter. I'm not sure that's the best structure. It doesn't help that I literally can find no published inductor values. I do wonder if the Pi filter may be responsible for the blip behavior that I saw. In other words, if it's causing voltage droop whenever you start a conversion, then after doing so many with a fixed interval you will establish a steady state voltage profile, but if you change the timing, it causes erratic results. On the other hand, the time constants seem like they'd have to be awful long.

Audio amp: The MAX98304 has substantially lower radiated (and possibly conducted) EMI than the PAM8303. Stefan had mentioned he had tried the Adafruit PAM8302 and found that the EMI did interfere with the VHF transceiver. It is possible that the board could be better optimized to limit emissions, for example, running two filter caps instead of just one. While I realize that soldering modern packages is more difficult, the reason they are used is not just they are cheaper but because they have better performance from a heat perspective and a parasitic perspective.

Inside/Outside: I agree it'd be nice to get a board that works both ways... However, the question then becomes what interface if its external? And do you supply 5V or 12V?

Bottom/top: Both the LPS22 and the MS5611 have holes in the top of the package. if you do not seal against the hole, there will be leakage. I don't know how the POM block works. Is there a gasket? Is there one hole per MS5611 or 2? If the POM block does seal against the top of the package, I fail to see why components on the bottom would or vias from bottom to top would screw things up. FWIW, Stefan's sensorboard has components on top and bottom.

I'd still like to know what the difference between Stefan's board is and the current schematic/layout and if the schematic/layout is available in digital form somewhere -- I'll need it to make sure components are properly aligned with the POM block.

[iglesiasmarianod]

Hi @hpmax please visit www.openvario.org or ftp.openvario.org. You'll find all original schematics and gerbers there. Sensorboard files are in Altium format. POM block is sealed against PCB with sealant. It has a hole for each MS5611.

[DanD222]

@hpmax I meant ferrite beads as in https://mouser.com/Search/Refine?N=19978750.

EDIT - here's the actual part as specified in the May 2016 BOM available in the Downloads section of openvario.org: https://uk.farnell.com/laird/hz0805d102r-10/ferrite-bead-2012-100mhz-1000r/dp/2292410?ost=2292410

I can see a Pi filter being useful after a switching regulator to filter out any switching spikes, but here it’s just slowing down the response of a linear regulator. Putting it before the regulator could however help filter out whatever’s going on in the main supply rail. If you have a chance to desolder the inductors and hook up a bench PSU directly to the MS5611s you could see if that has any effect. Might be worth a try.

Audio amp - fair enough. It’s hard to say whether Stefan’s interference was caused by EMI or whether it could have been caused by power supply coupling, but if you have a product that has better EMI specs than the PAM chips then why not.

Interface - Bluetooth or Wifi, whatever’s available from the ESP32 board that gets decided on. I realise that there’d need to be extra coding involved to get the interface working. I’d prefer 12V input, so that you can power it directly from the glider's battery. I’m using an AP65211 buck converter in another project that accepts 4.5V to 18V input, that might be worth looking at.

Bottom/top: You can find photos of the POM block here: https://www.openvario.org/doku.php?id=projects:series_00:mechanics You don’t seal right against the sensor, rather, the sensor sits within a “cave” as it were. So having a hole within this cave could indeed screw things up. The build guide suggests sealing the POM block with PUR sealant to get an airtight seal.

Stefan’s sensorboard looks to be pretty similar to the OpenVario one: http://www.stefly.aero/wp-content/uploads/2018/03/06_Sensorboard1.jpg

[hpmax]

Yeah, that's the first I saw of the BOM which included the actual parts for the "inductor", I agree that's the part listed. Not sure why it was listed as an inductor when it's not. I also agree it would make more sense to put them on the input to the regulator. That said, the datasheet has a maximum impedance of about 1000 ohms resistive. The cap is 100nF. That gives a time constant on the order of 0.1 ms. The blip behavior seemed to noticeably change on the order of 10s of ms of timing jitter. But with 25+ ms, it might as well be DC as far as that filter is concerned.

Audio amp - I just bought a Controleo3 and will build it up this weekend (hopefully). Will then build up a MAX98304 amplifier and see how it works. If not I'll go back to the MAX1871.

Interface - The AP65211 seems reasonable although my big concern with these switched converters (like the Class D) is noise. A resistor/zener divider could be connected to the enable line, and if installed in the OV, the 5V power from the OV, could be connected to a BJT (or FET) pull-down. I am a bit concerned about the ESP32. I'd like GPS input into this, which would presumably be through USB. It would then have to forward this information to the OV. If it's internal, it could probably be over I2C or SPI or something, but if external, then what? The ESP32-S2 only has one USB, and no BT. The ESP32-E has BT and WiFi but no USB.

Regarding the POM block... I think I understand now. Basically it's sealing against the board, not against the top of the component and since the "cave" has an 8mm diameter, I don't think its necessary to put stuff on the bottom. The LPS22 is 2x2mm. If we assume the caps are another 2x2mm that means the total diagonal is only about 4.5mm. No problem. Even the larger MS5611 is still 5x3, which would potentially give 5x4=6.5mm. Is the perimeter supposed to be sealed with PUR?

Regarding Stefan's sensorboard. It's clearly missing the audio amp and all related components, but otherwise it's at least close.

[DanD222]

The inductor - yes… it may not be related to the blips, like you say; it’s just something I thought worth mentioning when looking at the sensorboard schematic.

The interface - are you sure about including the GPS? It opens up a whole new can of worms, while in my eyes providing little extra benefit, given that you’ll probably want to have an IGC-certified logger connected to your OV anyway so that you can declare to it (which will also give you GPS and baro data). On the other hand, if I was to use the sensorboard purely with a mobile phone, I’d be OK with the phone’s internal GPS (but I’d probably have a logger connected to the phone via Bluetooth anyway).

Connecting an external GPS to the ESP32 via USB would also be a pain mechanically; I’d probably go for an external I2C interface through a 4-pin RJ connector, although I’m not sure what the susceptibility to interference would be like. Or maybe a 6-pin connector and use the extra pins to add GND wires between the signal lines. The current OV sensorboard has a 6-pin RJ11 connector with I2C, 3V3, 5V and GND, so maybe keep the same connector and pinout.

Regarding power - I like the idea of disabling the AP65211 if the board is powered by 5V. I would place a Pi filter after the AP65211 to filter out switching spikes, and have a “clean” and “dirty” supply line, the “dirty” one being taken from before the Pi filter and powering the ESP32, and the “clean” one taken from after the Pi filter and powering all sensors. I’d also place inductors/ferrites in the supply line to each sensor’s regulator.

Then you have the question of whether routing the ground returns of the “dirty” supply line to the main filter cap separately from the “clean” supply returns would be more beneficial than a ground plane.. but you could probably eliminate that by component placement (i.e. have the sensors to one side of the PSU and the ESP32 to the other side).

You could also place another Pi filter before the AP65211 to help isolate it from the glider’s main power supply line.

Regarding the POM block sealing.. I guess it’s “whatever you manage to come up with” ;) Personally, I’d put a thin layer of sealant around the pressure sensor caves to avoid pressure leaks from one sensor to the other, then maybe around the whole block.

One other thing I’d also suggest when designing a new sensorboard would be to keep some free space at the sides of the sensorboard PCB for monting brackets, so that you don’t rely on the barbed connectors for mounting the sensorboard to the case.

EDIT - It would also be useful to have the 5V from the OV go through the Pi filter after the AP65211 - at the moment the sensorboard shares the same 5V line as the Cubieboard and the LVDS without much additional filtering going on.

[hpmax]

If we are putting an ESP32 on the device as Timo suggests we have a fair amount of computational horsepower. I'd like to essentially run it as a full IMU. In other words, I want it not just to go vario and airspeed data, but full AHRS and GPS. It is useful to have access to all of this data in the IMU algorithm. It's not just that AHRS is useful to have, it's that accelerometers or gyros can help more accurately calculate the vario data. The problem with accelerometers and gyros are that they can drift. GPS has zero net drift, and so the GPS is useful for correcting drift in the accelerometer/gyros. It all works together. That's why I want GPS. If you want to hook it to your phone, I presume you want it hooked via Bluetooth? That could be a problem for the ESP32-S2. Bear in mind, whether you are using this with your phone or whatever, this is likely to be a semi-permanent installation in the glider. Not only do you have to have it hooked up to the plumbing system, but you are also should be calibrating the installation for pretty much every sensor, and the magnetometer and acceleratometers are definitely going to require a rigid and fixed attachment point to the aircraft.

Regarding your filter, seems reasonable. Essentially we are talking about having two power supplies, the 12V-5V (although perhaps 4V?) which is bypassed if inside the OV and then the linear regulators, of which we are having a bunch. You are proposing putting one in front of each regulator except the regulator that drives the ESP32.

Please bear in mind we don't have infinite space. I'm kind of pushing the components around in Eagle, and I'm near full capacity. I can probably fit everything in, but we can't just keep adding and adding.

[DanD222]

GPS - Ah, got you. In that case, yes. However, as far as I’m aware, AHRS, etc is only implemented in XCSoar as proof-of-concept and isn’t fully functional, so I don’t know if the sensor fusion you’re proposing is something you can take on. In any case, the ability to connect a GPS is probably worth having for any future development in this area.

Regarding connecting to a phone, either Bluetooth or Wifi’s fine for me. I’m currently interfacing to a logger via Bluetooth, which would mean I could keep the phone’s Wifi turned off to save a bit of power, but I’m running the phone off a power bank anyway, so it’s not really an issue. I’m OK with a fixed installation in the aircraft - like you say, it’ll be needed for the plumbing anyway.

Yes on the power supply - one switching regulator, several linear regulators for the sensors except for the ESP32 (unless you decide on the Wifi-only ESP32-WROOM-32E, in which case you’ll need one). Not sure about 4V off the switching regulator, maybe keep some headroom for the filtering and for the LDOs to have something to work with? The dropout’s pretty low, so up to you.

If you’re tight on space then I guess we could skip the input Pi filter, but I think keeping the post-regulator ripple filter is a good idea.

[hpmax]

The sensor fusion is best done earlier in the chain. Right now, we have a Kalman filter on the TE sensor. Wouldn't it be better to do a Kalman on all the sensors simultaneously? That's a huge deal actually. Remember, assuming the dynamic data doesn't change, TE and static should be changing together. Which means, you can substantially improve the performance. by merging those. You don't want to do Kalman on top of Kalman on top of Kalman because it becomes much harder to understand the dynamics.

USB seems to be the current gold standard on how to connect to GPS.

Another question is... what about audio? Should the sensorboard produce its own audio?

[DanD222]

Sure, if you can do the sensor fusion on the ESP32 and output only the result then that’s probably best.

What USB GPS modules are you considering, and do you plan on connecting them directly to the ESP32’s micro USB connector? I’d have concerns over the long-term reliability of the connector what with the vibration and everything, but I guess if it’s a fixed installation it shouldn’t be as much of an issue as if you were constantly plugging and unplugging the cable.

Audio… good question. The big question for me is, how will you control the volume? If you can interface a dedicated rotary encoder to the board through a 4-pin RJ connector and have the board space for it and also the audio amp and connector then that’s awesome and would make the next-gen sensorboard a very useful stand-alone unit. A dedicated volume control is pretty important in my opinion; I also like the idea that you could place just the encoder on the instrument panel if you’re tight on space and run a cable to the sensor unit which could be located elsewhere.

[hpmax]

Here's my first pass. It's 73mm across by 52mm deep. The cavity is about 110mm x 60mm. So I can grow the thing a bit. I think rotating J1 90 degrees would give some more space. I think the current board (Stefan's anyway) is about 28mm deep. Caveat: I don't think the DS18B20 connector is properly located, it's close though.

Each sensor is on its own regulator. I added a ferrite bead on the inputs to each regulator. The analog supplies are using MMZ1608A252BTD25 with an NCV8163 regulator This has an 800m ohm DC resistance, but considering that the analog supplies are typically running 20mA max, this shouldn't be an issue. The ferrite bead is going to throw some noise in at the low-end because of this, but the NCV8163's have almost 80-90dB of PSRR at low frequency.

I anticipate about 35dB@1MHz, 68dB@10MHz, 66dB@100MHz, 32dB@1GHz on the digital (prior to the regulator) I anticipate about 56dB@1MHz, 92db@10MHz, 75dB@100MH,z 40dB@1GHz on the analog.

Digital is using the same HZ0805D102R-10 with a LDL212PV33R regulator. The board has no audio capability, no 12V regulator and no USB... for now.

@iglesiasmarianod @kedder @linuxianer99 Would you guys like to make some comments on what you'd like to see on a new board or what you think of the layout

[DanD222]

OK, I know I haven’t been asked, but I thought I’d chime in anyway ;)

Regarding the 3.5mm audio jack for the OAT sensor - are we sure about that? In case you’re going to be putting an audio amp on the new sensorboard, I would ideally not like to carry over the cinch connector for the audio output from the current sensorboard. IIRC, one had to be careful for the audio ground on the cinch connector to not touch the case, otherwise you’d get noise on the output. The ideal audio connector for me is a 3.5mm TRS jack, with the amp output + and - connected to T and R, and GND to S. The speaker would then be connected with a shielded two-wire cable and would be floating on + and -, with the shield being connected at the sensorboard end only.

Which leads me to the question whether it’s a good idea to have two identical connectors for an OAT sensor and for audio out - I don’t think it is, so I’d probably think about what connector could be used for the OAT sensor instead (2.5mm TRS jack? 4-pin RJ45?)

Also, are you sure about the caps in parallel next to the pressure sensors? I’d be worried about potential unintended resonant peaks. Is the intention to use identical cap values?

Another thing I see is the ground plane to the right of the ESP32 antenna - are you sure about that? (see https://www.espressif.com/sites/default/files/documentation/esp-wroom-02_pcb_design_and_module_placement_guide_0.pdf)

[hpmax]

@DanD222 You are welcome to comment too, I just was hoping to bring some others people into it as well. Timo had suggested a new board driven by an ESP32.

Regarding 3.5mm jack/OAT. Part of the problem here is, I have Stefan's OV. I don't know what the difference between Stefan's setup and everyone else's is. On his, the audio is coming out the DB-15, so it'd be impossible to confuse the speaker for the temp sensor unless you were literally not reading any documentation whatsoever. The case of the 3.5mm is plastic, so it can't ground against the OV case. I'm trying to copy the format so I can do a drop in replacement for what I have (with the possible exception that I might need a longer 10 pin cable).

Regarding the multiple caps. Any time you have a cap, you are going to have a resonant peak. That's sort of by definition as they all have self-resonance. I'm an IC designer, not a board designer, but it's my understanding that running multiple caps a decade apart is a standard technique. Let's say the SRF of a 1uF cap is 10MHz, and the SRF of a 100nF cap is 100MHz. If the spec calls for a 1uF cap, I can't see how adding a 100nF cap would hurt. On the other hand, I suppose there might be a case made that if the specs calls for a 100nF cap, adding a 1uF cap could hurt, but my gut feeling is it's just not that bad.

As for the ground plane. Thanks for pointing out the app note. I'll take that into account. I might also move the regulator to the other side of the ESP32, cut the ground plane a bit short and then run power to the DS2482 under the ESP32.

[iglesiasmarianod]

Hi guys, Allow me please to write some random thoughts I've been having:

1) If the board is internal a "nice to have" would be firmware update via OpenVario menu. 2) GPS, I would stick with IGC protocols. OpenVario is not an IGC logger and because it's open source I don't see that changing in the future. All loggers have an IGC interface. We can benefit from FLARM too. 3) AHRS. I would only use it to improve relevant soaring information, Vario, wind direction, thermal assistant, etc. Anything that can help improve XC performance. As AHRS is forbidden in competition (cloud flying) and OpenVario is not an IGC logger I see difficult to log the AHRS enable/disable. LX writes to the IGC log if this function is enabled or not to be competition compliant. 4) Perhaps we would need two boards. One compliant with OpenVario's group shape and one with Stefan's. We have multiple screen sizes, I don't see much trouble having two board shapes as long as the components and software are the same.

My two cents, hope it helps.

[hpmax]

1) Two way communications is required with OV/XCSoar, so I think this is a no-brainer

2) FLARM is useful, but I don't see it as useful in the context of the vario or AHRS functionality. I am actually using a SoftRF which I have hooked up to my OV as well as a "European Edition" Stratux. Together that should give me full visibility of FLARM and ADS-B In (plus FLARM Out). My main issue is I want the sensorboard to have access to GPS information. It's perfectly fine with me, if for example, a GPS plugs into the sensorboard and then the sensorboard repeats the GPS strings to XCSoar. The other alternative is OV repeats strings to the sensorboard, but this means its less useful as an independent device.

3) I have never understood why AHRS is forbidden. Obviously this is not certified for cloud flying, so deliberately flying through a cloud with or without this is illegal, not just a violation of contest rules. I would consider it a safety feature though. I have been sucked into a cloud before, and I know someone else who had a cloud build around them. Having AHRS would make things feel much more confident in terms of getting out. That said, your ability to display AHRS information can be limited through XCSoar. So I don't think there is a good reason to not use AHRS information in a vario. The intention would be to improve the responsiveness of the vario information and there are multiple ways this could be done. We use a Kalman filter to estimate the actually output of the vario. As it stands now, if you know your polar, you can estimate your sink rate based on airspeed. With AHRS information you could also calculate G loading and modify the sink rate. It could also estimate slip/skid and better estimate wind direction and velocity by comparing corrected magnetic heading to airspeed and ground track.

4) Multiple layouts isn't an awful idea. I'd just want to maintain software compatibility between them because the software is going to be a lot of work. My initial layout will be to comply with Stefan's board. I don't know how different other hardware is. Also worth pointing out that the boards on openvario.org are getting a bit long in the tooth, fair number of obsolete parts there. I think the main difference between Stefan's and the standard hardware is that the audio amp isn't on his.

[DanD222]

I pretty much agree with what’s been said by hpmax above.

Regarding multiple layouts, I’m not sure if this would be needed actually. Both versions of the sensorboard seem to have the components in roughly the same place, so it would be worthwhile to check this. The audio connector for the standalone board could be where the current OV cinch connector is at the moment, which would be to the left of the I2C connector here: http://www.stefly.aero/wp-content/uploads/2018/03/13_OpenVario2.jpg

If doing a Stefly retrofit, one could then simply not populate the audio connector (or drill an extra hole for it in the Stefly case I guess). My idea of a dedicated volume controller for the standalone version kind of goes out of the window in that case.. On the other hand, maybe not - if you can provide pins for a rotary encoder on the PCB, then I can probably interface them to the outside world some other way without compromising backwards-compatibility with existing projects.

I’d probably also be OK with having both the OAT sensor and the audio output on 3.5m jacks, in the grand scheme of things.

Regarding capacitors in parallel - I’d be worried about what you see in Figure 3 happenning: https://incompliancemag.com/article/using-capacitors-in-parallel-dangerous/ Probably hard to predict beforehand, but something to keep in mind I guess.

[iglesiasmarianod]

I agree with the legal aspects of AHRS. I believe AHRS is forbidden to avoid collisions. You can fly perfectly well inside cloud with it but not be able to see other gliders. I agree it can be used to improve data. I tried to say we may avoid sending AHRS info to XCSoar just because we can't prove it is not being used. Climbing into cloud when nobody else can is an unfair advantage. Regarding GPS I meant not using USB. I would prefer the use of a serial port with an RJ45 connector so we can use commercial loggers/gps/flarm. If it is fed directly to the board or through mainboard, I have no strong opinion.

[DanD222]

I quite like the idea of the GPS source being a cheap GPS module rather than an expensive commercial logger - those I would connect to the existing RJ45 sockets on the adapterboard that go through their respective RS232 converters (or wire them to the D-Sub on the Stefly unit). So I’d be perfectly OK with the GPS that connects to the sensorboard being USB or I2C or whatever. “Out-of-the-box”, a bare OpenVario has no GPS source of its own, so why not have the option to connect an inexpensive one to the the sensorboard.

[hpmax]

Can someone give me the max dimensions of the standard board? I'll confirm that against the Stefly hardware and then just assume we should make the board as big as possible.

I'll try to add a 12V->5V converter and an audio amplifier. We can then design it to select between internal audio and external audio. On the Stefly enclosures it can be unpopulated. On internal it can take audio from Cubieboard and for external, it can take audio from the ESP32.

Connector can be another 3.5mm connector. I agree that that's a bit ugly having two 3.5mm connectors.

I wasn't planning to add an I2C connector because it just ate board space, but perhaps I could add it.

I'm thinking we talk between OV and sensorboard with SPI. All talking on the board is I2C. In terms of GPS, I'm highly inclined to just use USB. USB GPS's are cheap and plentiful and new and better ones keep coming out. I have no real interest in forcing people to buy an expensive proprietary logger.

[hpmax]

Also, will look into the compliance article more. However, their self resonant frequency seems off by an order of magnitude. Which means their potential resonance they're worried about could be several hundred MHz on real life. Perhaps that could still be stimulated by a harmonic of a clock.

[DanD222]

I’m measuring 30mm x 10mm on the standard sensorboard; you could probably scale the drawings in the Pressure-sensor.pdf from the openvario website to this to get the locations of the parts. Let me know if you want me to do that, of if you need more measurements.

There is an I2C connector on the Stefly kit, see here: http://www.stefly.aero/wp-content/uploads/2018/03/13_OpenVario2.jpg

You could probably just about fit a vertical USB-A connector into the cutout instead of the 6-pin connector if you decide that’s the way to go.

Please check the comms between the OV and sensorboard - I’m pretty sure it’s all I2C. SPI is brought out to the UEXT connector on the sensorboard, but doesn’t go anywhere from there. The schematic's in the link "Schematics and Gerber Files Sensorboard" located here: https://www.openvario.org/doku.php?id=downloads

Not sure how much fussing about the two parallel caps is worth.. you could probably investigate on a real board and just not populate one of the caps if it turns out to be a problem. My original line of thinking was that one cap next to the regulator, one cap next to the pressure sensor and the PCB trace between them as the inductance would probably do.

[iglesiasmarianod]

I'm not against USB or cheap GPS. I think we shouldn't close the door to the option of using IGC gliding standards. Connecting a cheap GPS board is possible with the hardware and software as is, and you still have the option of using expensive loggers available.

I like racing a lot. I think OpenVario is mainly used for XC and competition soaring. From my experience anyone using OpenVario this way is highly likely to have an IGC logger or FLARM. In my country FLARM is not optional so everybody has an IGC logger / GPS source already available. I believe FAI does not accept logs that are not IGC compliant either. If that is true, without an IGC logger you can't apply for badges, insignias or records.

Regarding comms. It is all i2c, we will need to move the ADC voltage sensor to sensorboard.

[DanD222]

@iglesiasmarianod Yes, but why connect IGC loggers to the sensorboard, when you can already connect them to the rest of the OpenVario..? If I understand hpmax correctly, the intention here is not to replace the base OpenVario board or the adapterboard, but only the sensorboard (which will have additional on-board processing for handling the sensors and passing the information to the OpenVario base board). So the logger connected to your OpenVario unit will remain connected the same way as it is now, no doors closed.

[iglesiasmarianod]

I was thinking to use only one GPS source. If we can connect the old GPS source, why not feed AHRS with it? Please correct me if I'm wrong! I always understood sensorboard will have it's own GPS.

[iglesiasmarianod]

Sorry Guys, English is not my native language so I may be missunderstanding.

I understood @hpmax is proposing to feed sensorboard with it's own gps and then feed openvario with preprocessed data. He is proposing a USB gps for this. If I understood this right we won't be able to connect an RJ45 to sensorboard from openvario leaving AHRS without GPS data unless we use USB GPS.

[DanD222]

The main issue I see is board space / panel space - where would you connect the IGC logger, and would the board be backwards-compatible with existing OV units without adjustments to the case?

There’s a 6-pin connector on the sensorboard currently used for I2C; if you wanted to replace it with an IGC-compatible connector, it’d be better to use an 8-pin connector. To be able to use that in an existing Stefly or “classic” OV unit, you’d need to enlarge the hole for it in the case - I'm not sure many people would want to do that.

You could probably turn the 6-pin connector into an IGC socket, but I’m not sure that’s a good idea.

Regarding your summary - yes, that’s how I understand it. You could in theory have OV feed the sensoarboard with GPS data, but - If you wanted to use the new sensoarboard as a stand-alone unit like I do, you probably wouldn’t connect your logger to it, as you’d want to declare to it. I have a dedicated Bluetooth module for that, and declaring to a logger is also not something I’d expect the new sensorboard to do.

So in my eyes connecting a logger to the sensorboard makes things more complicated than they need to be (I don’t mind having two GPS sources actually), and potentially closes the door on a cheap GPS source. It just seems like a lot of extra effort in order to avoid having two GPS sources really.

[iglesiasmarianod]

I feel that sacrificing OpenVario in favor of a stand alone sensorboard is a big nono. If a stand alone external unit is the goal you can take Timo's approach and connect your unit's output to one of the OpenVario's input connector or use bluetooth to connect to your smartphone. An independent sensorboard, to me, is a project on its own. It has its own software and hardware and you can interface with any protocol you have available in XCSoar without any modification to OpenVario. On the other hand If this is an improved sensorboard we should make it as backwards compatible as possible and think the future software developement follows only one path. We should favor OpenVario decisions instead of stand alone decisions.

This is what we have today.

We have I2C connection to sensorboard and an I2C ADC soldered to mainboard. Each arrow is an IDC cable. Still don't understand how are we thinking this is going to communicate. If we change I2C pins to serial we end up with two different kernels... The compromise solution I'm thiking is putting a GPS connector, USB and RJ45, on sensorboard and feeding serial data to OpenVario through connectorboard IDC pins. Still we end up with one sensor on the mainboard using I2C. We don't loose an RJ45 connector. Another solution is using MMC pins as TTyS5 and feed sensorboard output directly to the cubieboard,

[DanD222]

I don’t want it to be a sacrifice, I’d like it to be an addition to. I see that there’s a proposal to utilise an ESP32 on a new version of the Sensorboard for connecting to the Mainboard over the current IDC cable, however that may be. I also see that this ESP32 would have Bluetooth or Wifi capability, so I would like this feature to be utilised to send fused sensor data to the outside world.

I also see that there’s not all that much room on the OpenVario case, so my concern is about utilising the existing cutouts without making users make new holes in their cases.

That’s about it.

[hpmax]

Just to be clear... This whole thing came about because I discovered the MS5611 is sensitive to timing and we were getting glitches out of it. Timo proposed using an ESP32 to directly interact with the sensors relieving us of the non-real-time nature of Linux. I'm not actually clear it's the best solution but it is fairly economical and it has plenty of processing power to do a far more advanced Kalman filter.

In the meantime, I'm proposing changing all the sensors: MS5611->LP22HH, AMS5915 -> MS4515DO, MPU9150 ->LSM6DSM +MMC5983MA plus switching to better regulators and a better filter topology.

I'm not expecting a huge improvement in the pressure sensors, but I'm hoping for some improvement, and the removal of glitches. I am expecting a huge improvement in the other MEMS sensors.

I'm also hoping for a far more advanced filtering scheme.

Here's the deal:

1) Its going to fit into Stefan's case (if someone gives me the regular OV case dimensions, I'll try to make sure it fits there too). 2) I am all for putting additional stuff on it that I don't need so long as it fits in the cases. 3) I want it to have access to GPS. This can either come directly from a USB GPS or from the OV. There are benefits to both.

I'm not interested in putting in RJ45. It's large, its expensive and my guess its probably not as good as a $10 USB GPS from AliExpress.

If I can add enough hardware to make it function external to the OV, I'm happy to do that.

I would however point out that I'm volunteering to do this and so far, no one's offered to help. So I'm all for trying to make it better, but I'm not real interested in having this overdesigned or putting in a bunch of features I personally don't want.

Some questions:

1) If I add an audio amp, Class AB or Class D? 2) Cavity dimensions? Someone said 10x30mm, no way! 3) If there is no SPI that's going to be a problem. The ESP32-S2 has WiFi and USB, the ESP32E has WiFi and Bluetooth. That to me suggests we need to use the S2, and if the USB is used for GPS, I'm not sure how to communicate with the OV (either internally or externally).

[iglesiasmarianod]

@hpmax I understand it's volunteer work and thank your efforts. I'm no expert circuit designer but I can rearrange your layout to fit website's board shape and distribution. I'm pretty busy now so I can't promise a fast delivery. As long as you can test your board, I can modify it later to fit other cases. I still see important to look for the least traumatic integration option. What do you think about using ESP32 as I2C master for sensors and I2C slave for mainboard? I've used ESP32 WROOM before. (https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32e_esp32-wroom-32ue_datasheet_en.pdf) It has two I2C buses. That way ESP polls the sensors regularly and save the last values in a buffer available to Linux. Gps feed can be tapped from the connectorboard wires. Perhaps TX only? This way, we can connect your board directly to the IDC10 connector without major hardware modification. We move sensord to ESP32. Variod will still do it's job in the cubieboard but reading from I2C.

[DanD222]

Sorry, should have been 100mm x 30mm. This is the dimension of the current sensorboard. The maximum sensorboard width you could fit into the current OV case if the PCB sits flush with the rear panel is about 102mm.

The only way I can help is with the layout unfortunately (not in Altium though), and with some thoughts and observations, if that’s any help at all.

(I’d go for a class D audio amp to conserve battery power if we can do the filtering right)

[hpmax]

@iglesiasmarianod Sure! I'm not trying to be confrontational or asking for thanks, I just want to define a set of requirements and work toward the goal, so I'm not wasting my time jumping from one set of requirements to another and screwing around.

I was unaware of the two I2C busses. However, looking at the schematics, it does appear there is both SPI and I2C. In which case I think I'd prefer to use SPI to talk to it, but I don't feel strongly about it. I can't find ADS1110 sensor on the schematic but pictures show its on the back of the adapterboard, which may be an incentive to use I2C to talk to the sensorboard.

I can't find 12V on the UEXT, which means you couldn't mount the ADS1110 there even if you wanted to. There are a few thoughts here about 12V:

1) We are currently running the audio amp off 5V. You can get much more powerful 12V audio amps. I'm not sure this is actually a huge difference since you can get 3W out of a 5V amp @ 4 ohms, and that's probably enough. 2) Being able to sense the voltage may be useful to the sensorboard. I'm assuming that turning on the VHF transmitter will result in a drop in voltage. So if the sensorboard sees a sudden drop in voltage, the transmitter is on until it sees a sudden /increase. This probably can be calibrated to some degree. I'd further assume that the transmitter being on could affect the sensors, in particular the magnetometer. My understanding is that the "crude" way to determine your magnetic heading is to take the atan of y/x (or x/y?) Based on where you are on the planet relative to the magnetic poles, it seems like you should be able to apply some sort of transform on X, Y, Z to get better data. This is probably particularly useful if you are looking for pitch information and less so if you are just looking for X and Y. But... It is my understanding that magnetic fields add linearly, so correcting for deviation may be as simple as determining a magnetic field vector and subtracting it out prior to transforming or the trig. You could then have two magnetic field vectors, one with the TX off, and one with it on and it'd switch between them based on information from the voltage sensor.

I'm not clear if magnetometers have any error sources besides variation and deviation. I would think most of the other sources rely on inertia of the sensing element which isn't as much of an issue on a magnetometer.

Anyway, I've adjusted the board dimensions to 100x58mm. I'm going to try to fit in as much as I can so that the board can be used internally and externally.

[iglesiasmarianod]

Me neither guys! If my English seems rude I apologise beforehand. I've been thinking. We have 4 UARTs available. TTyS0, 1, 2 and 3. In Stefan's hardware TTyS0 and TTyS3 I believe are wired to DB15 connector pins. In OpenVario's hardware we have 4 RJ45 connectors. TTyS0 is connected between adapterboard and cubieboard with jumper wires. That UART I believe is used only for debbuging and you need to tamper the OS if you want to use it as a standard UART. I've never used it nor connected it. What do you think of using those wires for GPS input? We simply disconnect TTyS0 and use the already available 4 pin adapterboard header to tap GPS. If we have 4 ESP32 exposed pins (usb and serial) we can choose what GPS we connect to sensorboard. If you choose USB you connect the jumper wires to the USB header. If you use Serial you plug your wires to diferent pins. We would need a 6 pin header in sensorboard instead of a 4 pin. Outside connection is easy to solve with either option. We then feed GPS to sensorboard and sensorboard can feed all data to variod. We will need to change OpenVario protocol for Variod to feed GPS data to XCsoar.

[hpmax]

@iglesiasmarianod I think English is a second language for many of the people here, don't worry.

I didn't completely follow you though. I would like to use an external USB GPS. They are cheap and plentiful and the best way to get the latest technology. Finding a RS-422 or RS-485 or RS-232 based GPS is more challenging.

I don't have a huge problem with getting GPS data from OV/XCSoar, but that means:

1) We have to modify XCSoar to support that (it's possible it can already do that, I think there is a NMEA output). 2) We are reliant on XCSoar/OV for the GPS, this cripples the unit if used without XCSoar, if someone just wants to build a vario display around the sensorboard, which I thought was one of the goals.

[iglesiasmarianod]

Hi @hpmax. Please look at this two wires inside stefan's hardware. Those are TTyS0. It is not used to connect external devices. You'll find them wired to two DB15 connector pins 2 and 10. Those jumpers connect Cubieboard's serial pins to DB15 pins.

My idea is disconnecting those jumpers so we have an exposed interface outside the case. In your case two DB15 pins. If we connect those wires to sensorboard we are able to feed it with GPS signal and then sensorboard feeds Variod and XCSoar with GPS data. From DB15 to your external GPS device you can assemble a suitable wire.

Regarding sensorboard. You'll need to expose USB pins with a header. If we also expose one of the ESP32's UART you have the choice to use USB GPS or RS232 GPS to feed sensorboard. You simply change where you plug those jumper wires. Either USB input or Serial input. Youll need a level converter for Serial thou. Don't know if MAX3232 already converts levels for that pair of pins.

[hpmax]

So you are saying connect the GPS to the Sensorboard through RS-232, and if the OV is present we use XCSoar to feed the data, otherwise you find an external RS-232 GPS (which basically don't exist any more). I'm not sure what the benefit of that versus using the USB interface to the GPS and then RS-232 or SPI (I couldn't confirm this doesn't exist on the adapterboard) or I2C to talk to OV.

[iglesiasmarianod]

Today we have two paths for information. GPS is fed to XCSoar directly. Sensor data goes through Sensord and then Variod. Variod takes Sensord data through NMEA sentences, produces sound and exchanges polar, mc, ballast, bugs with XCSoar to produce correct Speed to Fly sound. Variod is always between sensors and XCSoar to produce this. Please remember we are not using XCSoar vario sound or STF sound so we need to comunicate XCSoar with whatever is making the calculations and producing sound. GPS is not in this path. My proposal is including GPS in this path. We send GPS to sensorboard instead of XCSoar directly. We then send this info to Variod throug I2C and Variod to XCSoar via NMEA toghether with MC, Polar, Bugs, Ballst and STF. We would need to expand Variod protocol to accept GPS and OpenVario's XCSoar driver to accept GPS too. This is the only way I see to use only one GPS to feed everything without too much modifications. If you still want to use old sensors, just plug an esp32 to buffer data an kill blips without changing anything else. XCSoar takes available data from the highest positioned driver first. So, if GPS is missing from device A It'll take it from B. Backwards compatibility is easier this way.

[hpmax]

Today we have two paths for information. GPS is fed to XCSoar directly. Sensor data goes through Sensord and then Variod. Variod takes Sensord data through NMEA sentences, produces sound and exchanges polar, mc, ballast, bugs with XCSoar to produce correct Speed to Fly sound. Variod is always between sensors and XCSoar to produce this. Please remember we are not using XCSoar vario sound or STF sound so we need to comunicate XCSoar with whatever is making the calculations and producing sound. GPS is not in this path.

I agree with all this.

My proposal is including GPS in this path. We send GPS to sensorboard instead of XCSoar directly. We then send this info to Variod throug I2C and Variod to XCSoar via NMEA toghether with MC, Polar, Bugs, Ballst and STF. We would need to expand Variod protocol to accept GPS and OpenVario's XCSoar driver to accept GPS too.

Yes, I agree, if a GPS were plugged into the sensorboard (via some not-yet-defined interface), the sensorboard could read the data and forward it to variod which in turn would forward it to XCSoar. I don't think would require rewriting XCSoar, as everything is NMEA, and we could just forward NMEA sentences and I think all would be good.

This is the only way I see to use only one GPS to feed everything without too much modifications. If you still want to use old sensors, just plug an esp32 to buffer data an kill blips without changing anything else. XCSoar takes available data from the highest positioned driver first. So, if GPS is missing from device A It'll take it from B. Backwards compatibility is easier this way.

I am advocating for plugging a USB GPS into the sensorboard, and then having the sensorboard forward the data through sensord (which would be massively re-written) to variod to xcsoar. This allows things to work internal or external. It does still leave open the question of how would the sensorboard communicate with Openvario if the sensorboard is external. And how would the sensorboard communicate with other external displays).

[iglesiasmarianod]

Yes, I agree, if a GPS were plugged into the sensorboard (via some not-yet-defined interface), the sensorboard could read the data and forward it to variod which in turn would forward it to XCSoar. I don't think would require rewriting XCSoar, as everything is NMEA, and we could just forward NMEA sentences and I think all would be good.

OpenVario's XCSoar driver only accepts Variod data today, we will need to include GPS in the communication word. Only $POV sentences are processed by this driver. Another option would be to make Variod to send vario data and GPS data to different TCP ports. Anyway, we can patch it for OpenVario while changes are accepted by XCSoar's community.

We can connect an external device via BT but we might need to write a dedicated XCSoar driver. If Variod resides in the external device all Vario calculations, polar, STF, MC, etc need to be stored there, set up and syncronized. If we move Sensord and Variod to the board we need to provide a simple way of updating software too. This way backwards compatibility is impossible and software diverges into two branches. This are the reasons why I proposed we focus on solving OV first and then moving on to the external unit. From my perspective Variod should stay inside Cubieboard. If we move that way, we can solve blip problems from a hardware point of view and update components that are too old. If we improve performance while doing this, so be it! After this is achieved we can move forward to a stand alone sensorboard.

[DanD222]

It does still leave open the question of how would the sensorboard communicate with Openvario if the sensorboard is external. And how would the sensorboard communicate with other external displays).

Just wondering, did you mean OpenVario, or XCSoar? I can’t imagine a use-case where the sensorboard would be external to OpenVario, which is why I ask.

@iglesiasmarianod Looking at Stefan’s Adapterboard schematic, pins 2 and 10 go to P6 through a MAX3232 converter, so P6 is UART and not RS-232.

@hpmax I think what iglesiasmarianod meant by RS-232 GPS is not a standalone RS-232 GPS module, rather, the output of his logger that he wants to use as the GPS source for sensorboard (which outputs NMEA sentences at RS-232 levels). He proposes to take this from the inside of the Openvario via the jumpers that he mentions - correct me if I'm wrong. Question for @iglesiasmarianod - if you connect your IGC logger to the sensorboard this way, how will you declare to it?

Regarding your other point - it seems that variod processes commands like MC, bugs, etc. If I’m building a standalone sensorboard I don’t need any of this - all I’m interested in is forwarding sensord sentences to a mobile phone over Bluetooth. That is, what’s in the “NMEA Sentence” box at the bottom: https://www.openvario.org/lib/exe/fetch.php?cache=&media=projects:series_00:software:sensordaemon_dataflow.png

This shouldn’t require any modification of variod the way I see it, and that was never my intention.

[iglesiasmarianod]

He proposes to take this from the inside of the Openvario via the jumpers that he mentions - correct me if I'm wrong. Question for @iglesiasmarianod - if you connect your IGC logger to the sensorboard this way, how will you declare to it?

You are right, if you want USB GPS you plug it to the USB input of ESP32, if you want logger input, to UART, only two additional pins are required in sensorboard. Don't know how to declare to logger yet. XCSoar fails with all LXNav loggers 99% of the time. Only FLARM declaration works OK 100% of the time.

Regarding your other point - it seems that variod processes commands like MC, bugs, etc. If I’m building a standalone sensorboard I don’t need any of this - all I’m interested in is forwarding sensord sentences to a mobile phone over Bluetooth. That is, what’s in the “NMEA Sentence” box at the bottom:

Please beware of this: Sound is produced by Variod, not Sensord. You'll send data to XCSoar, but STF and Vario sounds will not be produced. XCSoar's vario sound is not that good at all.

[DanD222]

It would seem to me that if you connect your logger to sensorboard, you won’t be able to declare to it, regardless of your success rates with particular devices - I don’t think sensord was designed with this in mind and it doesn’t really make sense to me to spend time and effort to adapt it for this purpose. So I don’t think connecting a logger to sensorboard is a great idea, unless you only want to use your logger as a cheap GPS source (in which case we might as well use a cheap USB GPS to begin with).

For what it’s worth, I have pretty good success rates with declaring to LXNav devices from XCSoar (Android, via a DIY Bluetooth adapter).

You're right about XCSoar’s vario sound, which is why I answered hpmax’s question

“Another question is... what about audio? Should the sensorboard produce its own audio?”

with

“Audio… good question. The big question for me is, how will you control the volume? If you can interface a dedicated rotary encoder to the board through a 4-pin RJ connector and have the board space for it and also the audio amp and connector then that’s awesome and would make the next-gen sensorboard a very useful stand-alone unit.”

My understanding is that hpmax is proposing to implement audio-generating code on the ESP32 (I am assuming without modifying existing variod code) - again, please correct me if I’m wrong.

[hpmax]

Use cases I can see are:

1) Inside OV driving OV 2) Inside OV driving OV and external dedicated vario display (or multiple displays -- for example, two different averaging time constants, netto vs compensated, or front and back seat) 3) Outside OV driving external dedicate vario display(s) or other non-OV flight computers 4) Outside OV driving OV driving OV and/or other displays. This one seems unlikely, since we are building it to fit the OV, why not put it in the OV if you have one.

Regarding some of the aforementioned stuff. In the case of being outside the OV, I can see why you may want audio-generating capability on the ESP32. If I am putting an audio amp on the board, I see no reason why it can't be connected (via jumpers) to the ESP32) so that software could be added to do that. I think it would be nice to offload the audio onto the ESP32, but since other audio is generated on OV, I don't really want to demand two speakers unless it can some how add in the audio to it. This seems like a slippery slope.

I see little benefit to using a logger for the GPS source. My assumption is that a $10 USB GPS will perform better than the logger, and did I mention, it's $10.

Also, regarding Bluetooth. The ESP has two models that are being considered here, the ESP32-WROOM-E, and the ESP32-S2. The S2 has Wifi + USB, the WROOM-E has WiFi + BT. You get BT or USB, not both. Sucks, but that's the way it is with the currently available models.

[iglesiasmarianod]

It would seem to me that if you connect your logger to sensorboard, you won’t be able to declare to it, regardless of your success rates with particular devices - I don’t think sensord was designed with this in mind and it doesn’t really make sense to me to spend time and effort to adapt it for this purpose. So I don’t think connecting a logger to sensorboard is a great idea, unless you only want to use your logger as a cheap GPS source (in which case we might as well use a cheap USB GPS to begin with).

We can resend data and make ESP32 declare to logger using it as a bridge, it's a matter or defining the communication protocols and architecture first.

Regarding loggers. 1) RS232 IGC communication is a FAI gliding standard. 2) Working on a gliding instrument ignoring gliding standards seems really odd to me. 3) OpenVario ports are all IGC compliant. I strongly believe we should keep it that way. 4) Loggers and FLARM are widespread. I don't know anyone flying a glider not having an IGC compliant GPS source. 5) OpenVario owners are using loggers and FLARM (wether they log your data or not) as GPS source right now. Will we force them to buy a USB GPS even when they already have a valid GPS surce?

I think we can add USB as an option to the serial communication. Not the other way around. As I said before, if you buy an arduino GPS board, plug in a level converter, an RJ45 connector and plug it to the existing ports you can replace an expensive logger with a cheap serial solution.

My understanding is that hpmax is proposing to implement audio-generating code on the ESP32 (I am assuming without modifying existing variod code) - again, please correct me if I’m wrong.

That means moving Variod to sensorboard with all it's implications. You can´t generate Speed to fly sound without knowing polar, ballst and MC setting.

[DanD222]

What you’re both proposing seems nice - I’d however be perfectly OK with keeping things as simple as possible in a benefit-cost kind of way. So I’d be OK with things like:

• Having two audio outputs and just connecting one speaker to either one of them
• I’m fine with either Bluetooth or Wifi, just as long as I can connect to the thing
• I’m also OK with Vario audio only without STF, if that means not messing with variod, or having no audio at all because you don’t want to break backwards compatibility

So that’s my point of view - if you feel the extra functionality is worth the effort then that’s great, but it would be a shame for some really complex use-case to block the fairly simple stuff.

[hpmax]

In case it wasn't clear, I don't have an IGC compliant logger and have no wish to spend hundreds of dollars for one and then figure out how to hook it up in order to relieve someone else of the need to buy a $10 GPS which is readily available on Amazon or AliExpress and which will have superior performance. For instance, modern GPS receivers can operate at 10 Hz, I bet most IGC compliant receivers only work at 1 Hz and the chipset is far older.

That said, if someone wants to reprogram XCSoar to move data from a GPS receiver to the sensorboard, that's fine.

@DanD222 I'm trying to make this as simple as possible. I have no need for an audio amplifier or making it work externally but those were things you asked for and I'm trying to provide while worried about board space.

At this point my big concern is what interface to allow external devices to talk to it. Preferably multiple external devices.

[DanD222]

@hpmax Yes - thanks. I’d very much appreciate that; I’m trying to not go overboard with demands if I think I can avoid it.

[iglesiasmarianod]

In case it wasn't clear, I don't have an IGC compliant logger and have no wish to spend hundreds of dollars for one and then figure out how to hook it up in order to relieve someone else of the need to buy a $10 GPS which is readily available on Amazon or AliExpress and which will have superior performance.

No need to. Leaving a pair of ESP32 RX TX pins exposed would be enough to connect a serial GPS for anyone wanting to. It does not consume much space on your board, only approx 1mmx3mm. I don't see too much trouble doing that.

I still don't understand the need to feed GPS to sensorboard. You can use Madgwick's sensor fusion algorithm and get a good stable AHRS without GPS if your sensor outputs quaternions. You get Pitch, Roll, Yaw and Heading. That would be more than enough for XCSoar to better calculate let's say wind direction. I don't know how will you use AHRS yet. Is it used to improve variometer readings? We are not thinking of an autopilot here. Aren't we overcomplicating the problem?

[hpmax]

@iglesiasmarianod can you provide a schematic and suggest a connector and I'll include it if there is space.

I have heard of Madgwick's algorithm but I'm not real familiar with it. There are two obvious things that need to be pointed out though, but I'll admit that I haven't thoroughly thought it out.

Magnetometers will have variance errors. GPS allows you to correct for the variance automatically aligning magnetic north with true north. I also suspect there may be some level of pitch error depending on your proximity to the pole. In otherwords we can assume that the Earth's magnetic field is in the same plane (no pun intended) as the surface of the planet, but the reality is... It's not... And the closer you are to the pole the more normal to the surface it becomes. If we know where we are and where the pole is (info that can be downloaded from the internet) the better understanding what the local magnetic field looks like. I'm not sure how Madgwick could get around that.

Accelerometers and gyros are also subject to drift. Both are measuring things that get integrated and hence any offset, even a small one would eventually get screwed up royally. The magnetometer can discipline it to some degree, but it can't discipline position, only orientation. Similarly the pressure sensors can discipline vertical position and airspeed... But GPS certainly could be helpful.

[iglesiasmarianod]

If you can please route a 3 pin 2,54 pinstrip (TX, RX, GND) to GPIO 9 and 10 or 17 and 16 in addition to your USB header will be enough.

Standard 2.54 pinstrip hole layout.

This is ESP32 pinout.