Hello!

I have a BETAFV F722 AIO FC, I need to add a GPS/Compass to it in orther to use the RTH in iNav, however, my FC doesnot have any SDA/SCL pads, is there a way to convert a UART to SDA/SCL?

I will attach the wiring diagram as well as my connections to the FC. (The current GPS has to be taken out, because it has no compass, the new one will be  a Beitan BN-880)

       

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.

(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

Thanks a lot! your help is so much valuable, can I put the receiver on the UART1? or where should it go?

(23-May-2022, 01:06 PM)alex.tersa Wrote: can I put the receiver on the UART1? or where should it go?

The receiver can be connected to any spare unused UART. so yes, using UART1 would seem to be the most logical UART to use for the receiver in my opinion.

(23-May-2022, 01:13 PM)SnowLeopardFPV Wrote: The receiver can be connected to any spare unused UART. so yes, using UART1 would seem to be the most logical UART to use for the receiver in my opinion.

Thanks a lot really! you just saved my project!

(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

Hi! I did all of this and it worked perfectly, for a day... Then it stopped working, the compass will stay in red in INAV, and the flight controller starts beeping, as if something is not correct. But then I change the I2C speed from 800kHz to 400kHz and everything works perfect. However, if I unplug it and plug it again i doesnt work, and changing the I2C speed back again to 800kHz seems to solve the problem, and back again... with this loop. 
I added an OpenLog data recorder to the build, but I dont see how this may affect the compass, the blackbox is connected to TX5, on the other side of the controller.

I wonder if there is some kind of interference on the I2C data lines or a bad intermittent connection (i.e. loose fitting connections in the plug to the GPS/Compass module). Make sure the wires to the GPS/Compass module are all twisted together.

Also, use a magnifying glass to thoroughly inspect the board on both sides to check that there are no splatters of solder, minuscule solder balls, or tiny whiskers of wire somewhere that might be causing an intermittent short. If you used flux when soldering to the FC pads then use some Isopropyl alcohol and a Q-tip / small brush to thoroughly clean the solder joints and pads.

(28-May-2022, 11:19 AM)SnowLeopardFPV Wrote: I wonder if there is some kind of interference on the I2C data lines or a bad intermittent connection (i.e. loose fitting connections in the plug to the GPS/Compass module). Make sure the wires to the GPS/Compass module are all twisted together.

Also, use a magnifying glass to thoroughly inspect the board on both sides to check that there are no splatters of solder, minuscule solder balls, or tiny whiskers of wire somewhere that might be causing an intermittent short. If you used flux when soldering to the FC pads then use some Isopropyl alcohol and a Q-tip / small brush to thoroughly clean the solder joints and pads.

I have inspected everything and all the pads seem clean and without soldering spills. But I have discovered something, If the battery is plugged first, and then the fc is plugged to the pc averything works fine, however, if the fc is plugged first, and then the battery, INAV says that the compass does not work.

Does that make any sense??

How about plugging the battery first and then connecting via usb to Betaflight?

Do you have the compass mounted or wires running close to the VTX?

Wait a minute: You can do resource remapping via CLI in INAV? Unless something has changed, until recently we had to compile a custom target to do this.

Are you on INAV or Betaflight?

(28-May-2022, 01:48 PM)kafie1980 Wrote: Wait a minute: You can do resource remapping via CLI in INAV? Unless something has changed, until recently we had to compile a custom target to do this.

Are you on INAV or Betaflight?

I did the remapping on INAV, Im not running betaflight, this is a university project and I need some autonomous flight modes. The remapping on INAV worked fine, the compass is acknowledged and as long as I plug the battery first it works perfectly.

(28-May-2022, 01:44 PM)kafie1980 Wrote: How about plugging the battery first and then connecting via usb to Betaflight?

Do you have the compass mounted or wires running close to the VTX?

If I do so, but on INAV, everything works, I dont have any VTX, the project will kind of fly by itself.

I missed the reference to INAV in your first post and assumed you were running Betaflight, so unfortunately I've led you up the garden path.

You can't remap resources in INAV so the commands I gave you did nothing. I just flashed the latest INAV version (4.1) to a spare FC that I have and resource remapping definitely still isn't implemented in INAV. I'm therefore not sure why your compass is even working at all on the UART3 pads. Maybe it's just a fluke that it's partly working for some unknown reason due to the MCU pads sharing those pads with both a UART and an I2C resource in conduction with something funky that the INAV firmware is doing.

Can you please run the "resource" command in the CLI and post the results back here because I will be interested to see what resources are currently assigned to the the B10 and B11 MCU pins.

(28-May-2022, 05:06 PM)SnowLeopardFPV Wrote: I missed the reference to INAV in your first post and assumed you were running Betaflight, so unfortunately I've led you up the garden path.

You can't remap resources in INAV so the commands I gave you did nothing. I just flashed the latest INAV version (4.1) to a spare FC that I have and resource remapping definitely still isn't implemented in INAV. I'm therefore not sure why your compass is even working at all on the UART3 pads. Maybe it's just a fluke that it's partly working for some unknown reason due to the MCU pads sharing those pads with both a UART and an I2C resource in conduction with something funky that the INAV firmware is doing.

Can you please run the "resource" command in the CLI and post the results back here because I will be interested to see what resources are currently assigned to the the B10 and B11 MCU pins.

# resource IO: ---------------------- A00: MOTOR4 OUT A01: MOTOR3 OUT A02: FREE A03: FREE A04: MPU CS A05: SPI1 SCK A06: SPI1 MISO A07: SPI1 MOSI A08: FREE A09: FREE A10: SERIAL1 UART RX A11: USB IN A12: USB OUT A13: FREE A14: FREE A15: OSD CS B00: MOTOR1 OUT B01: MOTOR2 OUT B02: FREE B03: SPI3 SCK B04: SPI3 MISO B05: SPI3 MOSI B06: FREE B07: FREE B08: I2C1 SCL B09: I2C1 SDA B10: I2C2 SCL B11: I2C2 SDA B12: SPI_PREINIT CS B13: FREE B14: FREE B15: FREE C00: ADC CH1 C01: ADC CH2 C02: FREE C03: FREE C04: MPU EXTI C05: FREE C06: SERIAL6 UART TX C07: SERIAL6 UART RX C08: FREE C09: FREE C10: FREE C11: FREE C12: FREE C13: FREE


I see here that they where corrctly remapped, I dont rly understand why, however the compass does connect, the issue is tha I cant connect the fc to Inav and then plug the battery, this gives me and error. If I plug the battery, and then the fc to inav everything is in blue, as it is working, however the runtime calibration is not correct, I dont think the quad will arm then.
C14: BEEPER OUT
C15: LED1 OUT
D02: FREE

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.


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.