BMP280 I2C address and values

[ghost]

I tested GPS, servo output and baro sensors here on my test board.

The servo values have been explained, but about the baro sensors, I have two questions.

I tested with MS5611, SPL06 and BMP280.

#1. The BMP280, you can get on shield normally has 0x76. The I2C address of BMP280 can be found in BMP280.h and in main.cpp. So on both files the I2C address has to be modified!? Please confirm.

#2. Values with MS5611 and SPL06 made sense here on the bench, but the BMP280 values looked a bit strange. High alt and vario values. Cross checked with different BMP280s, but still 'bad' values.

How can I help?

Besides, the new 'configuration' for basics in terminal is certainly helpful. but it should be pointed out, that platformio is necessary for modifications. Platformio IDE can be a bit daunting for 'normal' users like me, so maybe it should be said, that platformio CLI is sufficient to do the job.

br KH

[mstrens]

About #1, the value in BMP280.h is not used currently.cpp

About #2, I have no BMP280 to test but I will try to compare oXs code on AVR and on RP2040.
I hope I will find the bug.

I have no experience with platformio CLI. I can check this.
Otherwise, perhaps it is possible to make a version for Arduino IDE but the main idea was to avoid that the user has to compile it.
If I2C address has to be changed, I could e.g. add a parameter to the list of parameters that can be introduced via the terminal (so without compilation).
Still I ask myself it this is really required because I expected that most baro modules had a pin to be set to ground or VCC to select the I2C address. Don't you have such a pin/bridge to select the address on hardware level?

[mstrens]

About #2, I saw a bug in one line 103 of code in BMP280.cpp
There is
_calibrationData[i] = (readBuffer[0]<<8 ) | (readBuffer[1] );

It should be
_calibrationData[i] = (readBuffer[1]<<8 ) | (readBuffer[0] );

Can you try it?
If ok I will update code on github.

[ghost]

About platformio CLI. I am here with Debian and I like it simple. Don't have to install Visual Studio.

I make my modifications in the project, get the RP2040 in loader mode and then 2 commands

Looks like this

1.txt

For your changes in BMP280.cpp I'll try tomorrow. I'll put the sensor in my 'pressure camber' ;-) (Just a glass with lid and a syrinx for simulation of pressure changes) and report back.

I think oXs on RP2040 could be a small solution for ELRS in a plane with telemetry. ~5 PWMs, a vario, Lipo voltage and current (ACS712 mod. with 713, to measure unidirectional!) with the sensor for both values in between Lipo and ESC and maybe a GPS. No fancy PCB needed.

But this project needs people, who do some testing and report back to you. The thread on RCN seems to be dead.

br KH

[ghost]

Could not resist.

Made a short test, modified the line in BMP280.cpp as proposed and made a short video.

https://www.youtube.com/watch?v=rU570tZ50OQ

My test installation on a breadboard. RP2040, BMP280, ELRS RX and my PWM display instead of servos. The white cable is for a GPS Beitian BN 180 to be placed on the window sill. Not attached at the moment.

Demo of corrected PWM values and then the BMP280 values on the radio.

Then I changed to a SPL06 for comparison.

Please have a look ....

br KH

PS. At this stage, no sense putting the BMP280 in my 'baro chamber' .....

[mstrens]

I think I found a second bug for BMP280.
In file BMP280.CPP at line 199 there is currently
rawPressure = (uint32_t)((int32_t)p + ((var1 + var2 + _bmp280_coeffs.dig_P7) >> 4))* 10000 ; // in pascal

I expect it should be (removing the "*10000")
rawPressure = (uint32_t)((int32_t)p + ((var1 + var2 + _bmp280_coeffs.dig_P7) >> 4)) ; // in pascal

Thanks for testing this change too.

[ghost]

OK. You have seen the YT video, so I can delete it now.

I'll do the modifications in BMP280.cpp and report back.

At the moment, I am struggling a bit with GPS. Beitian BN 180.

I had it working, but at the moment it refuses to show up. ;-(

I have a 120R in between RP2040 TX <> GPS RX, that should be ok

That is the 'old' screenshot. The SAT number is a bit strange '105'!

br KH

[mstrens]

The number of sat is OK.
Someone asked to add 100 to the number of sat when there is a3D fix. It is done here:
if ( _buffer.solution.fix_type == FIX_3D ) fields[NUMSAT].value += 100; // we add 100 when we have a 3d fix (for Ublox)
There are other sensors (or fligth controllers) that works so.

The resistance between RP2040 TX and GPS RX should not be an issue.
Still this is not required with the RP2040 because the 2 devices (RP2040 and GPS) are both working on 3.3V.
When you use an arduino pro mini 5V 16MHz then it is safe to have a resistor to protect the GPS input from the 5V on arduino TX pin. I think I recommended even a higher value (e.g. 10k) for arduino 5V.

[mstrens]

I just merged the branch "test for 16 PWM" into the Main branch.
I corrected the 2 bug fix already explained.
I plan to delete the test branch in the future and only to keep Main branch.

[ghost]

Next YT video. Sorry for the bad quality ...

https://www.youtube.com/watch?v=Wq1DZv8qevI

First part with the SPL06, trying to fly a bit and then the BMP280.

If I do the same soft slow movements with the syringe, NO reaction, I have to make heavy strong movement to see a then heavy reaction on the telemetry screen.

I checked the BMP280 in the camber connected to an arduino uno with a standard BMP280 sketch.

The sensor is ok!

Your modifications in BMP280.cpp I have applied, but still no good.

I'll postpone my GPS test for the moment (some problems also) and concentrate on BMP280.

One remark: Paket rate on ELRS is 100Hz Full and Telem ratio was 1:32, but that seems to slow for the vario values, I'll change that for further test to 1:8.

br KH

[mstrens]

thank for testing.
Could you try the following:
I put on github (in Main) a new version that should normally provide more infos for the BMP280 to debug the issue.
Can you upload it on your RP2040.
There is already a compiled version in folder uf2 (so no need to compile; I also changed BMP280 I2C address to 0X76).
To test it, you do not have to connect the RP2040 to the ELRS receiver.
You can just connect the BMP280 to the RP2040 (as usual) and connect the RP2040 to the PC via USB (just like when you want to configure oXs).
If you open a serial terminal it should display the debug messages.
I expect that there should be 12 lines at the beginning (after a reset) with the 12 calibration parameters from the BMP280.
Afterward there should be one line each time the RP2040 get data from the BMP280. Those lines should contain

• the temperature in 1/100 of degree (e.g. 2152 for 21°52)
• the pressure in Pa (so e.g. 101325 for the standard pressure)
• the altitude in 1/100 of cm (so e.g. 1m2345 should be displayed 12345). It is not the "relative altitude" but just the result of the conversion of the pressure.
  No need for a video (a screenshot with the values is OK and easier to read).
  No need to change the pressure with the camber (measuring the atmo pressure is better to know about the expected value)

If you have time and if your arduino sketch for testing allows it, you could also provide a screen shot of the BMP280 calibration paramaters as they are read by this sketch (to check if the calibration values are the same or not)

[ghost]

No problem!

I expect that there should be 12 lines at the beginning (after a reset) with the 12 calibration parameters from the BMP280.

I am missing those lines.

I use the terminal in Arduino IDE for visualization and when opened, those lines rush ....

If I blow lightly at the sensor, pressure and temp change a little, alt is stuck!

If you have time and if your arduino sketch for testing allows it, you could also provide a screen shot of the BMP280 calibration paramaters as they are read by this sketch (to check if the calibration values are the same or not)

I'll have a look into some ino sketches, how to get the calib. values. I have 2 BMP280 sensors here on the table.

PS. I'll remove the YT video, but I think, a short video tells (sometimes) more then 1000 words.

br KH

[mstrens]

OK.
Temp and pressure are OK.
So no need to check for calibration. I expect they are OK.
I see why the Alt is = 0.
In line 203 there is currently
altitude = 443300000.0 * (1.0 - pow(rawPressure / 101325, 0.1903)); // 101325 is pressure at see level in Pa; altitude is in cm *100

Could you change it to (so just adding a ".0"
altitude = 443300000.0 * (1.0 - pow(rawPressure / 101325.0, 0.1903)); // 101325 is pressure at see level in Pa; altitude is in cm *100

[mstrens]

You can delete the videos. The problem with the video is that the contrast was quite low and so it was difficult to read the lowest lines on the display.

[ghost]

Had the output of the 2 BMP280 sensors in a Terminal and pushing 'reset' several times, if lucky
I get these outputs

SENSOR 1

temp=2095   Press=99067   Alt=0
temp=2095   Press=99067   Alt=0
temp=2094   Press=99069   Alt=0
temp=2095   Press=99067   Alt=0
temp=2094   Press=99069   Alt=0

Version = 0.2.9 
    Function              Code      Pin (255=disabled)
Primary channels input    PRI          9
Secondary channels input  SEC        255
Telemetry                 TLM         10
GPS Rx                    GPS_RX      11
GPS Tx                    GPS_TX      12
Sbus OUT                  SBUS_OUT   255
RPM                       RPM        255
SDA (baro sensor)         SDA         14
SCL (baro sensor)         SCL         15
PWM Channels 1, 2, 3 ,4   C1 / C4      0    1    2    3
PWM Channels 5, 6, 7 ,8   C5 / C8      4    5  255  255
PWM Channels 9,10,11,12   C9 / C12   255  255  255  255
PWM Channels 13,14,15,16  C13/ C16   255  255  255  255
Voltage 1, 2, 3, 4        V1 / V4    255  255  255  255

Protocol is CRSF (=ELRS)
CRSF baudrate = 420000
Voltage/RPM parameters:
    Scales : 1.000000 , 1.000000 , 1.000000 , 1.000000 
    Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000 
Baro sensor is detected using BMP280
    Sensitivity min = 100 (at 100)   , max = 300 (at 1000)
    Hysteresis = 5 
Foreseen GPS type is Ublox  :GPS is not (yet) detected
Failsafe type is HOLD

Config parameters are OK
temp=2092   Press=99065   Alt=0
temp=2093   Press=99067   Alt=0
temp=2094   Press=99067   Alt=0
temp=2092   Press=99064   Alt=0
temp=2092   Press=99066   Alt=0
temp=2091   Press=99061   Alt=0
temp=2091   Press=99064   Alt=0
temp=2091   Press=99063   Alt=0

SENSOR 2

temp=2165   Press=98591   Alt=0
temp=2165   Press=98591   Alt=0
temp=2165   Press=98590   Alt=0
temp=2165   Press=98593   Alt=0
temp=2164   Press=98591   Alt=0

Version = 0.2.9 
    Function              Code      Pin (255=disabled)
Primary channels input    PRI          9
Secondary channels input  SEC        255
Telemetry                 TLM         10
GPS Rx                    GPS_RX      11
GPS Tx                    GPS_TX      12
Sbus OUT                  SBUS_OUT   255
RPM                       RPM        255
SDA (baro sensor)         SDA         14
SCL (baro sensor)         SCL         15
PWM Channels 1, 2, 3 ,4   C1 / C4      0    1    2    3
PWM Channels 5, 6, 7 ,8   C5 / C8      4    5  255  255
PWM Channels 9,10,11,12   C9 / C12   255  255  255  255
PWM Channels 13,14,15,16  C13/ C16   255  255  255  255
Voltage 1, 2, 3, 4        V1 / V4    255  255  255  255

Protocol is CRSF (=ELRS)
CRSF baudrate = 420000
Voltage/RPM parameters:
    Scales : 1.000000 , 1.000000 , 1.000000 , 1.000000 
    Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000 
Baro sensor is detected using BMP280
    Sensitivity min = 100 (at 100)   , max = 300 (at 1000)
    Hysteresis = 5 
Foreseen GPS type is Ublox  :GPS is not (yet) detected
Failsafe type is HOLD

Config parameters are OK
temp=2148   Press=98595   Alt=0
temp=2147   Press=98594   Alt=0
temp=2147   Press=98596   Alt=0
temp=2147   Press=98594   Alt=0
temp=2147   Press=98597   Alt=0
temp=2147   Press=98596   Alt=0
temp=2147   Press=98597   Alt=0
temp=2147   Press=98595   Alt=0
temp=2148   Press=98596   Alt=0
temp=2147   Press=98596   Alt=0

In line 203 there is currently
altitude = 443300000.0 * (1.0 - pow(rawPressure / 101325, 0.1903)); // 101325 is pressure at see level in Pa; altitude is in cm *100

Could you change it to (so just adding a ".0"
altitude = 443300000.0 * (1.0 - pow(rawPressure / 101325.0, 0.1903)); // 101325 is pressure at see level in Pa; altitude is in cm *100

In 'oXs_on_RP2040-Test-for-16-PWM' I guess?

No problem ;-)

br KH

[mstrens]

Always in Main branch ( I do no update to the other branch for now).
Sorry, it seems it was not enough adding ".0".
Can you change the line 203 with this one
altitude = 443300000.0 * (1.0 - pow( ( (double) rawPressure) / 101325.0, 0.1903)); // 101325 is pressure at see level in Pa; altitude is in cm *100

[ghost]

About the GPS. The problem was, I have to say, me!

But could you please give me an answer on some questions, I have concerning the data shown

I think, this is BEFORE FIX

It shows the coordinates, so the are saved somewhere I guess. What is the meaning of SAT 3, a sign for 'no fix'?

And here a fix, I think.

How many SATs are that now? 10 SAT and 7 is a status number?
And what is HEADING now?

PS. Just see your reply, I'll change over to MAIN and report ....

br KH

[mstrens]

Sorry perhaps a misunderstanding;
I just updated Main with all fixes we tested but (as I expected it should now work) I already remove a #define for debugging the bmp280..
For debugging BMP280 when using version in main, you should now un-comment the line 17 in bmp280.cpp
//#define DEBUG_BMP280
should become
#define DEBUG_BMP280
for debugging.
Afterwards, it can be commented again.

About the number of sat the meaning is the following:

• 3 means that GPS can see 3 sat and has no 3D fix
• 105 means that GPS can see 5 sat and it can calculate an altitude. (3D).
  The Ublox GPS has several levels of fix. E.g. there can be 2D fix and 3D fix (when there are enough sat).
  When the GPS has a 3D fix level, than the number is increased by 100. So 5 becomes 105 but it still means that there are only 5 sat.
  The GPS tries to calculate the direction it moves. Heading gives this direction (0° = North, 180 = South).
  When the GPS does not really move (speed is low), the information is not meaningful (not accurate)

[mstrens]

Note : your display shows a "" before each telemetry value when it get an update.
If you do not see the "", it means that the Tx does receive anymore an update of this telemetry field.
Note: GPS data like long/lat,... are sent by oXs only when the GPS has a 2D fix or a 3D fix.
As said there are several levels of fix. It could even be that there is a level below 2D fix and that the GPS led starts blinking from this first level (I am not sure- it should be checked in GPS datasheet).

[ghost]

Looks much better now ;-)

Roller blinds are down, so no GPS.

Next thing, I'll look into will be the voltage inputs.

Keep on the excellent work.

Good evening from Germany to Belgie - KH

[mstrens]

Thanks for having tested.
Good evening too.

Perhaps we can close this issue (and open a new one if you find something else).

Note: about "voltages": please note that ELRS is not as flexible as SPORT FRSKY. There is one type of ELRS packet sent by the Rx to the TX about "battery". It has 4 fields named Voltage, Current, Capacity and Remain (only one byte max value is 128 I think).
I think that oXs can fill all 4 fields (when it is configured to measure the 4 voltages) but for the last one, the value that is sent is divided by 10 (to fit in one byte).