(27-Dec-2021, 05:47 AM)kafie1980 Wrote: I am not going to be able to get to my quads before mid Feb 2022 to test 4.3 RC1 but the DSP310 was added to 4.3 and I had confirmed this with a nightly build.

I got a couple of those dsp310’s a while back and found I couldn’t use them. So is there a way to use them now with also a gps unit that does altitude also?

Did you see this post I made a while ago:

(20-Aug-2021, 12:21 PM)kafie1980 Wrote: Update on the DPS310 Barometric pressure sensor.

I tested the Adafruit version of DPS310 with the latest build of Betaflight 4.3 that I compiled to find that Betaflight was not detecting the DPS310 sensor with the default setup.

On further investigation I found that in Betaflight the default I2C address for DPS310 is set to 0x76 : https://github.com/betaflight/betaflight...r_dps310.c



The official I2C address from the manufacturer specification sheet is 0x77 : https://www.infineon.com/dgdl/Infineon-D...0826c42242

So to get this to work you either have to:

Option 1: On the Adafruit DPS310 module: solder the "Addr" pads at the back of the board to change the default I2C address to 0x76 which is based on the SDO pin pulled-down to GND



Option 2: Manually set the I2C device address via the CLI to 0x77 (hex) or in decimals to 119:

set baro_i2c_address = 119


Option 2 is the easiest but usually most users leave the baro_i2c_address to the default of 0 in hopes it will be detected but this is not the case with the way it has been implemented Betalight currently. 

I have created a feature request at the Betaflight github with no hopes of them fixing it anytime soon but rather as information so other users can understand what the issue is and what the workaround is : https://github.com/betaflight/betaflight/issues/10911

NOTE: If you do get the Adafruit version of the DPS310 board, it does not come with any cables or connectors. If you want to avoid soldering and use the connector they recommend using a connector they call the "StemmaQT" connector which is so mis-leading as it is simply a 4-pin JST-SH connector similar to what we use on many of our quad components.

Manually setting the I2C address had worked for me on 4.3 nightly builds.

Yes I ordered a couple of their cables and the wire is terrible. It’s not silicone and pretty stiff. I currently do not have a gps on the marmotte so that will be a good candidate to try out and see. I think in previous conversations it was mentioned you just hook the wires up to the SCL, SDA pads. Now if there was a gps unit that was hooked up I understand these baro wires can be paralleled as the devices have their own address. Question is how do yo stop the gps altitude from getting read. Is that only an OSD adjustment so the altitude comes from the baro and not the gps?

Just set the following via CLI to use altitude data only from the barometer:

set position_alt_source BARO_ONLY

We discussed some of this in the following thread: https://intofpv.com/t-dps310-programming

Great thanks for the link back to our old discussion about this! I’m going to wait a little bit then will try out the  BF4.3 after we get some feedback. The quad I want to put it on is to expensive to loose to a bug. I like the idea of the JST-SH plug instead of their Q plug! If I don’t have a 4 pin I think I can get a kit and make one. My crimpers only make the larger balance port side

Betaflight 4.3.0 RC2 and Betaflight Configurator 10.8.0 RC2 have now been released. Relevant links have been updated in the first post of this thread.

Changes to Betaflight 4.3.0-RC2 since 4.3.0-RC1

• various fixes (see here for a complete list).
  

Changes to Betaflight Configurator 10.8.0-RC2 since 10.8.0-RC1

• various fixes (see here for a complete list).
  

When will betaflight 4.3 be completely done ?
This is my first time seeing betaflight updated and it gets kind of confusing seeing all the pre release updates and what is the final update called?
There’s a RC1 and now a RC2.
Will there be a RC3,RC4,etc….

(17-Jan-2022, 07:40 PM)Rob3ddd Wrote: When will betaflight 4.3 be completely done ?
This is my first time seeing betaflight updated and it gets kind of confusing seeing all the pre release updates and what is the final update called?
There’s a RC1 and now a RC2.
Will there be a RC3,RC4,etc….

Something to keep in mind is that we had 6 release candidates of Betaflight 4.0, 6 release candidates of Betaflight 4.1, and 4 release candidates of Betaflight 4.2.

Betaflight 4.3 is a much bigger release than any of those 3 previous releases and there are still quite a lot of Betaflight 4.3 related bugs being reported on GitHub, so I would expect to see at least a few more release candidates before we see a final release of Betaflight 4.3.

Anyone know when RC3 will be out? Feels like it should come any day now as it has been a couple of weeks.

(26-Jan-2022, 10:57 AM)Myman Wrote: Anyone know when RC3 will be out? Feels like it should come any day now as it has been a couple of weeks.

There is no defined schedule for publishing release candidate builds. It happens when the Betaflight devs think it is a good time to compile and publish another RC. Looking at last releases, each incremental release candidate has been published with a 2 to 4 week period between each one. Betaflight 4.3.0 RC2 was published 17 days ago, so it could be another 2 weeks before we see another RC build, or it could be tomorrow. All you can really do is sit back and wait.

Out of interest, are you experiencing a bug that you are waiting to be fixed in RC3? If you are desperate you can potentially just install one of the latest nightly builds while you're waiting.

(26-Jan-2022, 11:50 AM)SnowLeopardFPV Wrote: There is no defined schedule for publishing release candidate builds. It happens when the Betaflight devs think it is a good time to compile and publish another RC. Looking at last releases, each incremental release candidate has been published with a 2 to 4 week period between each one. Betaflight 4.3.0 RC2 was published 17 days ago, so it could be another 2 weeks before we see another RC build, or it could be tomorrow. All you can really do is sit back and wait.

Out of interest, are you experiencing a bug that you are waiting to be fixed in RC3? If you are desperate you can potentially just install one of the latest nightly builds while you're waiting.

Nah no bugs that i have noticed. I put togheter a quad and thought i would want the latest. And if RC3 was only a few days away i could wait for that before seting up the  quad and tuning it.

(26-Jan-2022, 03:01 PM)Myman Wrote: Nah no bugs that i have noticed. I put togheter a quad and thought i would want the latest. And if RC3 was only a few days away i could wait for that before seting up the  quad and tuning it.

I am still seeing quite a few Betaflight 4.3.0 bugs being raised on GitHub which is why I'm still staying away from it for the time being. I did put the RC2 build on one of my 5" quads, but I haven't flown yet with the RC2 build on it and I'm even considering reverting it back to Betaflight 4.2.11 until we get a proper final release with all of the serious bugs fixed.

A recent worrying bug reported within the last few days by more than one person is the inability to disarm a quad in some scenarios which is quite dangerous and can result in a potential flyaway or injury if you end up having to try and disconnect the LiPo from your quad with spinning motors because it won't disarm. One of the people who reported that bug already said he injured himself because of the issue. So if you decide to use any RC builds, just understand the risks and do so with caution.

(26-Jan-2022, 03:15 PM)SnowLeopardFPV Wrote: I am still seeing quite a few Betaflight 4.3.0 bugs being raised on GitHub which is why I'm still staying away from it for the time being. I did put the RC2 build on one of my 5" quads, but I haven't flown yet with the RC2 build on it and I'm even considering reverting it back to Betaflight 4.2.11 until we get a proper final release with all of the serious bugs fixed.

A recent worrying bug reported within the last few days by more than one person is the inability to disarm a quad in some scenarios which is quite dangerous and can result in a potential flyaway or injury if you end up having to try and disconnect the LiPo from your quad with spinning motors because it won't disarm. One of the people who reported that bug already said he injured himself because of the issue. So if you decide to use any RC builds, just understand the risks and do so with caution.

Ouch, thats a scary bug for sure. Especially since mine is a 7" so would hurt quite a bit being hit. Yeah might be wise to wait for the final.

(26-Jan-2022, 03:45 PM)Myman Wrote: Ouch, thats a scary bug for sure. Especially since mine is a 7" so would hurt quite a bit being hit. Yeah might be wise to wait for the final.

Even Dominic Clifton [hydra] (founder of Cleanflight and the designer of SPRacing FC's) has weighed in stating how serious the issue is and that it needs to be fixed as a matter of urgency.

On first glance it appeared that this disarm issue might just be related to specific FC's, but looking at the code snippet which Dominic posted it seems to be a common issue that is not just isolated to the FC's it has been reported for, but which could potentially happen on any FC. The reported issues in question are at the links below...

• Failsafe / loss-of-control / disarm not honored on SPRacing H7RF -> https://github.com/betaflight/betaflight/issues/11338
  
• Disarm failure on HGLRCF722 -> https://github.com/betaflight/betaflight/issues/11344
  

Another slightly worrying comment made HERE by Bruce Luckcuck [etracer65] who is one of the main Betaflight devs has also expressed concern that code changes to the task scheduler in the Betaflight 4.3 release are now causing some critical tasks (which includes disarming and failsafes) to abort processing before their execution is complete.

(26-Jan-2022, 05:25 PM)SnowLeopardFPV Wrote: Even Dominic Clifton [hydra] (founder of Cleanflight and the designer of SPRacing FC's) has weighed in stating how serious the issue is and that it needs to be fixed as a matter of urgency.

On first glance it appeared that this disarm issue might just be related to specific FC's, but looking at the code snippet which Dominic posted it seems to be a common issue that is not just isolated to the FC's it has been reported for, but which could potentially happen on any FC. The reported issues in question are at the links below...

• Failsafe / loss-of-control / disarm not honored on SPRacing H7RF -> https://github.com/betaflight/betaflight/issues/11338
  
• Disarm failure on HGLRCF722 -> https://github.com/betaflight/betaflight/issues/11344
  

Another slightly worrying comment made HERE by Bruce Luckcuck [etracer65] who is one of the main Betaflight devs has also expressed concern that code changes to the task scheduler in the Betaflight 4.3 release are now causing some critical tasks (which includes disarming and failsafes) to abort processing before their execution is complete.

Thats not good at all for sure. I am flashing 4.2 no doubt. I sometimes fly over a lake where live and if the disarm gets messed up it could bounce righ into the water.
Thanks for sharing all the info!