iNAV 1.2.0 RC3 has removed the barometer and sonar from my NAZE32

[jstremmler]

Barometer and sonar al no loger shown on my NAZE32 with the RC3 on version 1.2.0.

[martinbudden]

Support for SONAR and BMP280 barometer have been removed from NAZE target due to lack of ROM space.

[stronnag]

As the naze r6 is BMP280, perhaps you could rethink this one.

[martinbudden]

Things that could be removed instead:

define USE_GYRO_MPU3050

define USE_BARO_BMP085

define TELEMETRY_LTM

I'm not actually sure what uses the MPU3050 gyro.

Any preferences?

[xdigyx]

I agree with sonar, but can not understand removing BMP280 which are used for latet Naze rev (6). Would it not be better to remove earlier revs hardware BMP085, MPU3050, ADXL345? Or some GPS protocols: as probably most users are using ublox (rahter than NMEA, NAZA or I2C), or even beeper, or blheli interface (it's something that can be done using external tools) would make more sense. Another idea could be to split copter FW from FWings (as it's done for ardupilot).

[stronnag]

I would agree with BLHELI flashing going, and NMEA (as it was broken until very recently anyway). IIRC ADXL345 is used by some of the older NAZE / FLIP32, last time we removed it there were protests. I doubt we have many NRF24 users

[martinbudden]

GPS_PROTO_NMEA, GPS_PROTO_I2C_NAV and GPS_PROTO_NAZA have already gone.

So has ADXL345 - perhaps I should put that back in.

We are really squeezing the pips here.

[xdigyx]

What about splitting copter from FWings for future releases. is it something that could be considered? would that release significant amt of memory?

[martinbudden]

OK I've got a PR to put back BMP280 and ADXL345 and take out TELEMETRY_LTM

[martinbudden]

@xdigyx , that's a good idea. Two NAZE variants, copter and airplane.

It will have to wait for v1.3 though.

[xdigyx]

glad to hear it! as I have Naze F1, I would like to have full functionality that profits flight performance and features.

[stronnag]

Just upgrade to a modern compiler. GCC 6.1 has no problem including BMP280.

[martinbudden]

I'm very keen on supporting both the NAZE and CC3D targets. Both because I think it is important to support people who have build aircraft using those FCs and also to enable the cheaper FCs for those on a budget.

I also think that the effort of supporting those targets improves the quality of the codebase.

[martinbudden]

@digitalentity , what about upgrading to GCC v6.1?

[jstremmler]

My old NAZE32 Rev5 works with the RC3. In the sensors menue the barometer first did not show any reaction. Switching in the CLI command set baro_hardware=0 made it work also in the sensors menu, which is suspicious.... Unfortunately I had removed this FC 2 days ago when crashing with RC2...... Think it's time for my Sparky2, with OPlink and TauLabs software... But Taulabs latest GCS release unfortunately has an issue with storing waypoints in the F4 FC.

[stronnag]

@martinbudden, I think arm gcc 6.1 is not available on legacy OS.

[martinbudden]

@stronnag , what do you mean by legacy OS?

[stronnag]

Windows, MacOS :-)

Seriously, though unless you use a progressive Linux distro, you're likely to be on 5.4 at best unless you build from source, which is a pity as arm-gcc 6.1 has some really nice size optimisations, as well as the linker diagnostics that catch (admittedly trivial) things like #524.

[martinbudden]

Well, much as I'd like to use Linux, it's just way too much yak shaving. I've only just updated my OSX - and that has caused me a lot of pain and wasted time.

As far as iNav is concerned it doesn't matter - all that matters is what the travis build uses, and presumably that can use gcc 6.1. (I'm presuming travis is used to produce the release - but actually I don't know that.)

[stronnag]

regardless, removing the USE_SERIAL_4WAY_BLHELI_INTERFACE saves a large amount of space (3650b in the hex) , allowing for common sensors, LTM and SONAR. Given that one only flashes ESCs occasionally and there are other solutions, this would seem like a good candidate to go on F1.

[skaman82]

If USE_SERIAL_4WAY_BLHELI_INTERFACE will be removed, can LED STRIP be readied again?

[stronnag]

Only if you remove SONAR and FRSKY. Removing SONAR and LTM does not do it. Even without SONAR and FRSKY, you need gcc 6.1, anything earlier would overflow. We really have no good options on F1 any more.

[martinbudden]

OK, USE_SERIAL_4WAY_BLHELI_INTERFACE removed. SONAR and LTM back in.

Sadly no room for LED STRIP.

[stronnag]

It doesn't really matter what we do, we're on a hiding to nothing here. I guess you don't read the RCG thread (don't) ....

[xdigyx]

I believe there is plenty ways to keep F1. ie splitting Fwings and copter code. maybe even it could be done that a user could select his hardware via web and then code would be generated...?

EDIT: just one more thought: there could be even separate Naze targets for different Revs...

[oleost]

Please remember to get these changes to the release notes and updating wiki when RC is going out.

[martinbudden]

No, I hardly ever read RC groups. Just don't have the time.

@oleost - yes, good point.

[digitalentity]

@martinbudden thanks! @oleost noted, will try not to forget update the wiki.

[digitalentity]

This is fixed in latest master and will be in RC4 soon.