(28-May-2022, 06:43 PM)SnowLeopardFPV Wrote: I have no idea how the B10 and B11 pins are being assigned to an I2C resource on your FC. In the INAV target file for the BETAFPVF722 target configuration file (HERE) the only assignments for MCU pins B10 and B11 are for UART3. There are no other references to those pins.

Code:

#define USE_UART3
#define UART3_RX_PIN            PB11
#define UART3_TX_PIN            PB10

I've tried running resource remapping commands in INAV 4.1 and they just don't do anything. Anything after the "resource" command just gets ignored so all that gets output is a list of assigned resources.

Either way, INAV doesn't officially support use of an I2C device on the UART3 pads so you may somehow be trying to make use of an undocumented feature which might still be in development, thus the reason it is flaky. I don't honestly know.

If you want a official and stable compass support then you might have to switch to an FC that has official INAV support for an I2C resource via dedicated SDA and SCL breakout pads.

wow... thanks mate, and what flight controller would you recommend? I need it to have several uart and SDA/SCL, as well as it runs on inav.

I'm looking at the LUX-H7, with iFlight SucceX 50A 4in1 ESC, do you think is this set would function?

https://iha-race.com/producto/controlado...-ultimate/
https://iha-race.com/producto/esc-ifligh...32-4-in-1/

The webs are in spanish, but the manuals and pictures are universal.

Thanks in advance!

If I was building an INAV specific model I would use a Matek FC. Matek work quite closely with the INAV developers so Matek hardware always tends to work well with all the INAV features. Lumenier make use of the Matek hardware reference designs (under license I believe) so the FC you've listed will also be a good choice. Otherwise look for one of the Matek F7 or H7 FC's that are listed on the following page...

http://www.mateksys.com/?page_id=3834

As for the ESC, what current are your motors going to be pulling? I personally avoid FC's and ESC's manufactured by iFlight after having witnessed reports of their poor quality control, but that is just me.

I am not confident with H7 at this stage.

Try and look for an F7 based FC with an onboard barometer and SCL/SDA pads. Such FC’s are most likely supported by INAV because thats was most INAV pilots prefer.

I tend to stay away from iFlight stacks. Sorry if this upsets anyone.

I believe that H7 FC's are generally working fine with INAV. It just seems to be the Betaflight 4.3.0 release which has introduced a ton of issues specifically with H7 FC's. So for people who are only running INAV then I think an H7 FC will probably be fine.

There only appears to be 7 open issues in the INAV GitHub repo that are related to H7 FC's...

https://github.com/iNavFlight/inav/issue...%3Aopen+H7

And only one of those is specifically for the Lumenier H7 FC which is to do with blackbox logging on INAV 4.0, but there have been no updates on that issue since February so who knows if it's still an issue in the newest INAV 4.1 release (or the upcoming 5.0 release which had it's first RC1 published yesterday)...

https://github.com/iNavFlight/inav/issues/7863

Of course that doesn't mean there aren't other issues that haven't yet been reported. With the global chip shortage, F7 FC's seems to be getting more difficult to source. Holybro now only seem to manufacture H7 FC's, as do Matek. There are no F7 FC's at all in either of those manufacturer's current inventories. Maybe other manufacturers who do still sell F7 based FC's are just using up whatever stock of F7 MCU's they still have before then also making the switch to H7's. I guess we'll find out in due course.

(29-May-2022, 11:05 AM)SnowLeopardFPV Wrote: If I was building an INAV specific model I would use a Matek FC. Matek work quite closely with the INAV developers so Matek hardware always tends to work well with all the INAV features. Lumenier make use of the Matek hardware reference designs (under license I believe) so the FC you've listed will also be a good choice. Otherwise look for one of the Matek F7 or H7 FC's that are listed on the following page...

http://www.mateksys.com/?page_id=3834

As for the ESC, what current are your motors going to be pulling? I personally avoid FC's and ESC's manufactured by iFlight after having witnessed reports of their poor quality control, but that is just me.

I think I will go with this FC, I've it is based on Matek hardware too. 

For the ESC, the motors run max at 30A.

I have looked at different ESC, this one for example:

https://iha-race.com/producto/esc-hglrc-...i32-30x30/

It also comes as a stack with a FC:

https://iha-race.com/producto/stack-hglr...1-3030-mm/

But I think that I'd rather use the H7, for what u've said about the Matek Hardware.

There is an INAV target for the HGLRC F722 FC you have linked and it has a barometer and SCL/SDA pinouts.

The ESC is something I have not personally tested nor have I seen several reviews on. What kind of a quad are you building?

(29-May-2022, 12:02 PM)kafie1980 Wrote: There is an INAV target for the HGLRC F722 FC you have linked and it has a barometer and SCL/SDA pinouts.

The ESC is something I have not personally tested nor have I seen several reviews on. What kind of a quad are you building?

Yeah, it works on Inav, as the other one, there is also a target: MATEKH743.

As for the quad... well Im building something a bit weird. This is my final thesis for my university degree, Aerospace Engineering. Im building a rocket that lands by using a quadcopter configuration, instead of a parachute. In is a quadcopter in essence, that must be capable of performing a self-landing, right now Im using (if everything worked) the RTH Inav procedure. It will dropped, from a certain altitude, armed and ready, and then it will have to land.

Ok, makes sense now.

DaveC shared his attempt to make a somewhat 3d printed quadcopter rocket. Of course he did not have any jet propulsion engine incorporated in his design but its worth a quick glance: https://www.thingiverse.com/thing:4236457

Now for your your particular case where it will be dropped from a certain altitude and then armed followed by INAV RTH to bring it to a landing. This will become a bit challenging and you will need to modify some INAV code for this.

Why you may ask? Well INAV depends on the home location (takeoff/landing location) set when you arm the quad, which means if you arm mid flight it will not know where to land since it will not know the home position.

But you can work around this doing a few things:

- Simple way will be to enable motor stop function (prevent motors from spinning before applying throttle), arm the quad before launching the rocket (to set home position). Once you are at the desired altitude, simply move your throttle sticks to take control of the quad or if you have basic programing skills use the logical functions in INAV to start the motors (apply throttle inputs) at a certain altitude it reads from the barometer.

- Or check and see if you can setup a waypath Mission planning in INAV can do all of this automatically. I have never used Mission planning in INAV and have no idea if it will work without arming at home position but its worth a try.

One other thing to consider is for INAV you will also need to tweak the RTH settings for throttle percentage and PID etc based on altitude due to variations in air density at various altitudes during the landing procedure.

Another option would be to look at Ardupilot. That is much more comprehensive firmware than INAV with many more autonomous options which may offer you a better solution based on what you are trying to do. There aren't however many people on this forum who use Ardupilot so we would be of very limited help with that. Members on RC Groups would be better placed to help you with that if you decide to look into it. Only certain FC's support Ardupilot so keep that in mind. You can see a list of compatible Ardupilot flight controllers HERE.

Thanks to both of you! really! yopu have been of great help!

For now I will keep using INAV, since the project is due in 2 weeks, and I already have the report more or lesss written.

I won't attach any jet propulsion, nor rocket engine, my project is just a demonstrator, for what I have read, the procedure will be the following:

1. Arm the quad/rocket at the landing site, with the motor not spinning option enabled.

2. Drop it from a high enough place, and give a throttle imput, the motors start spinning and the rocket is free-falling.

3. Activate the RTH and hope it lands.

Do you think this procedure will work?

One other thing to mention here with GPS RTH is that there is a minimum distance away from the home position that can be set as low as 50m else RTH will not activate. This was the legacy code but I am unaware if they have reduced this limit further smaller in INAV. I will still recommend the GPS RTH distance to be set as low as possible but the actual distance between home position and launch site be twice that value to ensure RTH will kick in.

Also when you arm the quad to carry it from the home position to the launch side, ensure you hold the quad from the top or bottom of you lipo battery away from any props else you can get serious injuries. Once armed, the gyro will be active and although you have the motor stop setting you never know with opensource firmware.

And finally you may want to go to BLHeli and push the Beacon delay setting to maximum time setting (in minutes) to avoid the annoying idle beeps as you carry the quad from home position to launch site.

I should have asked this earlier: do you know how to fly a quad? If not the most important thing is to practice the disarm switch on your radio till it becomes second nature. Things can go wrong and first time pilots freeze in their tracks under panic conditions.

(31-May-2022, 11:15 AM)kafie1980 Wrote: One other thing to mention here with GPS RTH is that there is a minimum distance away from the home position that can be set as low as 50m else RTH will not activate. This was the legacy code but I am unaware if they have reduced this limit further smaller in INAV. I will still recommend the GPS RTH distance to be set as low as possible but the actual distance between home position and launch site be twice that value to ensure RTH will kick in.

Also when you arm the quad to carry it from the home position to the launch side, ensure you hold the quad from the top or bottom of you lipo battery away from any props else you can get serious injuries. Once armed, the gyro will be active and although you have the motor stop setting you never know with opensource firmware.

And finally you may want to go to BLHeli and push the Beacon delay setting to maximum time setting (in minutes) to avoid the annoying idle beeps as you carry the quad from home position to launch site.

I should have asked this earlier: do you know how to fly a quad? If not the most important thing is to practice the disarm switch on your radio till it becomes second nature. Things can go wrong and first time pilots freeze in their tracks under panic conditions.

Thank you for all the comments and tips, I will surely take them into account! I will take a deeper look into this settings that you mention, I intend to fly it this week, maybe the next if I can't.

And no... I dont rly know how to fly a quad, Im new to this and I picked this project beacuse it was challenging.

(23-May-2022, 10:31 AM)SnowLeopardFPV Wrote: The only option you have with that FC is to move your receiver to a different UART and remap the UART3 (R3 and T3) pads to I2C pads using the CLI commands below. The TX3 pad will then be an SCL pad, and the RX3 pad will be an SDA pad, so connect the SCL pad from the compass module to the TX3 pad on the FC, and connect the SDA pad from the compass module to the RX3 pad on the FC.

Code:

serial 2 0 115200 57600 0 115200
resource SERIAL_TX 3 NONE
resource SERIAL_RX 3 NONE
resource I2C_SCL 2 B10
resource I2C_SDA 2 B11
set mag_bustype = I2C
set mag_i2c_device = 2
set mag_i2c_address = 0
set mag_spi_device = 0
set mag_hardware = AUTO
save

@SnowLeopardFPV

Hi , i am soon looking for a similar solution (betaflight user) for a GEPRC F722 A35 AIO  and a Matek M8Q-5883 GPS/Compas module.
There are still on the way, but already looking for solutions for connecting the SDA/SCL and stumbled on this post.
Trying to understand , but not yet familiar with resource remapping so please some advice.
The devices i will need uarts for are a vista, a crossfire nano, the gps and then (which i only no realise) some remapped SDA/SCL solution similar to above for the magnetometer.
I see SBUS on UART2 in the manual (there its indicated use is for DJI remote signal , which i dont need) and i guess that is what you are remapping ? 
I need some guidance (or can we only get the correct info when the i have the actual aio to figure out the resource mapping ? Or is it standard / known.
Anyway some help please on the required cli kung fu . 
(note to self : Really need to get into this resource mapping thing as second time i come short and need this and the only thing left sofar in betaflight that i dont get yet.... Time to study)

Ok, just watched JB's video on resource remapping (and i learned something today) and now looking at your commands i thing i may get it (maybe) . Please confirm or correct my steps below.

1. Run the resource command and check what ports are connected to UART2 (which has SBUS, which i dont need) .
So i should check for the lines and find X/Y
resource SERIAL_TX 2 <target port X>
resource SERIAL_RX 2 <target port Y>

2. Also check the resource command for available I2C_SCL and I2C_SDA lines and find the device nr (can i pick any that shows up in case more than 1 ?). p.s. The assigned current ports behind it i can ignore correct ?)

3. Set the serial port speeds etc for the target uart2 (port counts from 0 so 1 lower then resource id correct ?)
serial 1 0 115200 57600 0 115200

4. Un-assign the UART2 SERIAL_RX/TX
resource SERIAL_TX 2 NONE
resource SERIAL_RX 2 NONE

5. Assign ports I2C_SCL/SDA to now free ports X and Y
resource I2C_SCL <dev id > <port X>
resource I2C_SDA <dev id > <port Y>

6. set the other mag parameters and save
set mag_bustype = I2C
set mag_i2c_device = <dev id >
set mag_i2c_address = 0
set mag_spi_device = 0
set mag_hardware = AUTO
save


Let me know if that makes sense or i totally misunderstood.

(08-Oct-2022, 11:08 PM)fpvapnea Wrote: Ok, just watched JB's video on resource remapping (and i learned something today) and now looking at your commands i thing i may get it (maybe) . Please confirm or correct my steps below.

1. Run the resource command and check what ports are connected to UART2 (which has SBUS, which i dont need) .
So  i should check for the lines and find X/Y
resource SERIAL_TX 2 <target port X>
resource SERIAL_RX 2  <target port Y>

2. Also check the resource command for available  I2C_SCL and I2C_SDA lines and find the device nr (can i pick any that shows up in case more than 1 ?).  p.s. The assigned current ports behind it i can ignore correct ?)

3. Set the serial port speeds etc for the target uart2 (port counts from 0 so 1 lower then resource id correct ?)
serial 1 0 115200 57600 0 115200

4. Un-assign the UART2 SERIAL_RX/TX
resource SERIAL_TX 2 NONE
resource SERIAL_RX 2 NONE

5. Assign ports I2C_SCL/SDA to now free ports X and Y
resource I2C_SCL <dev id > <port X>
resource I2C_SDA <dev id > <port Y>

6. set the other mag parameters and save
set mag_bustype = I2C
set mag_i2c_device = <dev id >
set mag_i2c_address = 0
set mag_spi_device = 0
set mag_hardware = AUTO
save


Let me know if that makes sense or i totally misunderstood.

1. I would strongly advise you to not use a magnetometer with Betaflight. At best it will give you an approximate compass heading in the OSD, at worst it will cause RTH to fail and the quad to flyaway or disarm. It is extremely difficult to get a magnetometer mounted properly on a small (<7") quad where it will not be prone to erroneous readings due to electrical interference. A compass is not needed for RTH or the home direction arrow. 

2. If you still want to add a compass, check the target first: https://github.com/betaflight/unified-ta...AIO.config
It already has I2C pads mapped, and they are shared with the TX3/RX3 pads. Also, the mag I2C device and bustype are already set to have a compass connected to those pads. So in order to get it to work, all you have to do is not enable UART3 on the ports tab and connect SDA/SCL to the RX3/TX3 pads, respectively, on the FC. 

Relevant snippet from the config: