Support for BMP280

[Peuqui]

Hi there,
and thanks a lot for your effort!

As I flashed the newest firmware onto my TTGO with 1262 ( and Stratux setup V. 29), I noticed, that the BMP280 isn't working as with the SoftRF or OGN Tracker.

Will this being fixed in the future or shall I resolder the BMP280 from the TTGO to the Raspi?

Kind regards,
Peuqui

[rvt]

Pins of what OGN is using for the BMP280 is not the same as what GxAirCom is using.

OGN is using:

#define PIN_I2C_SCL GPIO_NUM_22   // SCL pin => this way the pin pattern fits the BMP280 module
#define PIN_I2C_SDA GPIO_NUM_21   // SDA pin

GxAirCom is using:

    PinBaroSDA = 13;
    PinBaroSCL = 14;

But not only that has to change, it would also require a software change on stratux to make this work properly.

A quick fix for you is to attach it you Raspi. This will give you the additional advantage of the calibration setting in Stratux. Using one of these https://dross.net/aviation/shop/stratux-ahrs-sensor-board-fits-us-cases-icm-20948-mpu9250-mpu9255-gy91-bmp280/ will make that even easer.

I do have a branch for STratux sitting on my computer that will also support getting baro from GxAirCom to Stratux but opted to not adding that in this version to keep the changes small. If there is traction I can send in a MR to Stratux to have that supported (GxAirCom would still need pin 13/14 though)

If you have soldered the BMP on your t-beam then just leave it and get a new BPM280 and add it to your Raspi. GxAirCom won't use/see it anyways. I found out the hard way this was easer :)

[Peuqui]

Thanks for reply!

If you have soldered the BMP on your t-beam then just leave it and get a new BPM280 and add it to your Raspi. GxAirCom won't use/see it anyways. I found out the hard way this was easer :)

I desoldered one from a broken T-Beam: wasn't funny, so I go your way.
But when I revert to OGN on the T-Beam, then the two BMPs may interfere with each other, isn't it?

[rvt]

Great question, I don't know well enough about OGN and understand what it does when two BMP's are connected.
Nowdays I always use a connector to connect the stuff so it's much easer to disassemble.

[Peuqui]

Yep, thought about that too. But when I use the Stratux in the Gyrocopter, I guess, that the vibrations let disconnect the connectors due to not soldered.

[b3nn0]

@rvt If you deliver the pressure altitude as $PGRMZ or $POGNB, it should be accepted by Stratux just fine, similar to SoftRF and OGN Tracker.
If there are two BMPs in the Stratux, one on the T-Beam and one on the PI, Stratux will only use the one on the PI and ignore $PGRMZ sentences.

[Peuqui]

I do have a branch for STratux sitting on my computer that will also support getting baro from GxAirCom to Stratux but opted to not adding that in this version to keep the changes small. If there is traction I can send in a MR to Stratux to have that supported (GxAirCom would still need pin 13/14 though)

It seems a better way to collect the baro data from the BaroSensor connected to the T-beam, rather than from baro Sensor connected on to the raspi. So the data comes from one single device and the T-Beam is able to transmit the baro data through the air, too. Which is not possible, when the baro Sensor sits on the Raspi, isn't it?

[b3nn0]

It seems a better way to collect the baro data from the BaroSensor connected to the T-beam, rather than from baro Sensor connected on to the raspi. So the data comes from one single device and the T-Beam is able to transmit the baro data too. Which is not possible, when the baro Sensor sits on the Raspi, isn't it?

In theory, yes. In practice, it doesn't matter. Neither Flarm, nor PAW or ADS-L work with pressure altitudes. Only OGNTP and I think FANET have it in an additional, optional field. If it's not there, GPS altitude is used for comparing. IIRC, Stratux even ignores that field when received, so do most others.

source: my bad memory.. might be wrong. But what's not wrong is, that it is, in my opinion, absolutely unimportant.

[Peuqui]

As I read correctly, it does have impact if altitude is from baropressure or GPS. The flight altitude depends on pressure altitude...
And stratux makes a lot of computation to achieve this

[b3nn0]

No. Stratux knows what it does. And if it receives an altitude, and knows its source (Baro or GPS), it will do the right thing. For traffic warnings, it will compare received GPS altitudes to its own GPS altitude, while for received Baro altitudes, it compares those. As long as Stratux knows both altitudes, or can at least get a good estimation, you will get proper traffic warnings.
The only advantage of "Mounting the BMP to the T-Beam" over "Mounting BMP to the PI" is, that the pressure altitude will also be transmitted via OGNTP or FANET, in addition to the GPS altitude. But that is entirely optional in those protocols. If the receiver makes use of this additonal information is up to him. Stratux doesn't do anything with it if it receives a target transmitting both altitudes. The reason is some buggy old firmware that did transmit wrong barometric altitudes. Therefore, Stratux just does the conversion itself:
https://github.com/b3nn0/stratux/blob/7903eb48781a53f5a70d9d90e4965386d3eeb002/main/ogn.go#L272

Conclusions:

• Baro altitude TX is pretty much irrelevant anyway
• It doesn't matter if Stratux uses either Baro. Internal i2c baro has the advantage of delivering a faster update rate and Stratux has better control over what happens, that's why we use that.
• If you still want to force it to use the T-Beam one, feel free to disable Baro i2c in the settings. T-Beam pressure altitude will still be used.

[Peuqui]

Thanks for that comprehensive explanation!