Hi There

I have a mamba mk3 20x20 stack and I want to wire a Matek M8Q-5883 which has a compass. But the stack looks like it doesn't have the scl and sda pads needed. I saw before (ifly, some other guy) that people were able to re-map a uart to allow for a compass. Would someone help me out on this?


Here is a little thing I came up with:

Uart 1 (rx/tx): Crossfire

Uart 2: NA

Uart 3: VTX

Uart 4 (rx/tx): GPS or Compass?

Uart 5 (rx/tx): GPS or Compass?

Uart 6 (rx only): not needed


Uart 3 has to be vtx (only has tx pad). 6 only has rx so that's basically useless (correct me if I'm wrong). Uart 2 isn't even on the diagram. That leaves uarts 1, 4, 5 (which all have both tx and rx) to use. One has to go to crossfire, one has to go to the gps rx and tx, and one I would like to go to the compass.

I guess the final question is whether I can remap 1, 4, or 5 to be the SDA/SCL pads.
Also, rx1/tx1 is weird because it is labelled as "RC" and "Inverter" could someone explain that to me? Thanks.

So you have three pairs of resource for SCL/SDA. The first is B08 and B09 respectively. They corresponds to the following. I see Camera control pad, but can't see the PPM.
resource PPM 1 B09
resource CAMERA_CONTROL 1 B08


The second pair is B10 and B11. Which corresponds to TX3 and RX3 respectively. Unfortunately I see TX3, but can't find RX3.
B10 is SCL
B11 is SDA

Lastly C09 and A08. These correspond to motor 3 and motor 2.

In theory, you can remap motors to something else and use them for SDA and SCL. Unless someone (Snow) can give a better suggestion.

So RC is inverted RX1 for SBUS. And inverted TX1 is for S. Port or F. Port. Because with Frsky signal protocol, the signal needs to be inverted. Where as Crossfire protocol just needs to be connected to a normal non-inverted UART. There are hardware inverter built into these UART. F4 MCU does not have native signal inversion that you can control through software.

I also want to add that RX1 and TX1 is capable of SDA/SCL. But RC is inverted.

So will crossfire work on tx1/rx1? That's is how they show it on their wiring diagram.

//edit: actually this whole inversion concept is frankly too confusing. Maybe you could compare how one would wire an rxsr vs crossfire and tell me what is inverted and what isn't? Or however else can explains inverted pads

It is actually best to wire Crossfire to UART 4 where they diagramed a DJI Air would be wired to. If you wired to RC, the Crossfire will likely not work, regardless of what the diagram says.

Here is a little explanation of UART and what an inverted signal is.

https://oscarliang.com/uninverted-sbus-s...receivers/
https://oscarliang.com/sbus-smartport-telemetry-naze32/



Imagine the signal stream of 0s and 1s. Let's say the a normal data stream is 0101010101. An inverted signal (like SBUS protocol) will generate it as 1010101010. For F4 FC, you need some kind of hardware circuit to invert the data stream coming from SBUS (natively inverted) to uninvert the signal. On your FC, the RC is the dedicated SBUS pad which has the built-in inverter. Or you have to hack your receiver for the non-inverted SBUS signal and wired it to a normal UART RX.

Thanks man. I understand better now. Respect to those who do the hack. That soldering job looks tight.

Anyway, so I'll move crossfire to 4 or 5.

As of now, there isn't a way to get SDA/SCL unless I use the motor pads right? At that point I'll just not use the compass which I'm totally fine with. But who knows maybe Snow will come along and show us something else.

You can connect the Crossfire Nano RX to UART1 on the Mamba F405 MK3 using the following connections:-

• Channel 1 (CRSF TX) -> RC
  
• Channel 2 (CRSF RX) -> TBS(TX1)
  

Once you've done that, run the following commands in the CLI to switch off inversion for UART1 and configure it for use with Crossfire...

If you want to use the compass on your Matek MQ8-5883 GPS with the Mamba F405 MK3 FC you only have one option which is to remap the UART1 pads to the I2C1 resource. That does mean you will need to wire and configure your Crossfire Nano RX to a different UART instead of UART1.

To reconfigure UART1 for I2C connectivity, run the following CLI commands:-


Once you've done that, UART1 will disappear from the Ports tab and the UART1 pads can instead be used for connecting the compass to from the Matek MQ8-5883:-

• SCL pad of the Matek MQ8 -> TBS(TX1) pad of the Matek F405 MK3
  
• SDA pad of the Matek MQ8 -> RC pad of the Matek F405 MK3
  

Snow you are at another level. Thanks for the help. I'll try using the compass on uart 1 and crossfire/gps on 4/5. Thanks again

No problem. Please let us know how you get on once it's all wired up.

I totally missed the inverter on uart 1 in the config file. Good catch Snow.

I found tx2 and rx2 but I don't know why they are so isolated or barely labelled. In the top left there are two pads underneath 5v and Curr. I see it much better on the actual FC. Guess I could also use that for crossfire or gps too...

Ok I have wired the gps up and everything seems to working so far in terms of locking, getting cords, etc. I do notice my tarsier is interfering with it as I turn it on/off but I'll trouble shoot that later. Also the compass seems to be working (thanks!).

I do have a question though: Is it normal for the compass to show North as the direction the quad is powered on in? When I power up the quad it marks that spawn direction as North.

I’ve got the same compass and it takes a while for it to show the right heading. There were instructions for my FC Mini lux7 that said sda and scl needed a “ pull up”. Since I have no idea what that is I couldn’t do it. So after flying around a bit it locks in the right direction. I have not enabled GPS rescue mode for this very reason. If anyone knows what a “pull up” is, I’d be all ears.

(13-Dec-2020, 08:23 AM)Kevin2112 Wrote: I’ve got the same compass and it takes a while for it to show the right heading. There were instructions for my FC Mini lux7 that said sda and scl needed a “ pull up”. Since I have no idea what that is I couldn’t do it. So after flying around a bit it locks in the right direction. I have not enabled GPS rescue mode for this very reason. If anyone knows what a “pull up” is, I’d be all ears.

The term "pull up" in the EE world means pull up resistor. With low and high logic level output voltages the level needs to be locked either low (0V) or high (3.3V). The design of an MCU means it only ever output one of the logic level states and the other state is assumed to be the default then the MCU isn't outputting its designated logic level state.

What this means if that if the external component doesn't have either a "pull up" or "pull down" resistor somewhere in its circuit design, then when the MCU isn't outputting its designated logic level state (i.e. the default sate is assumed) then the the logic level state voltage can end up "floating" somewhere between 0V and 3.3V which can cause unpredictable issues, especially if the floating voltage drifts around and end up fluctuating between a logic 0 and a logic 1. The way so solve this is with a pull up resistor that will force logic level to be fully at 3.3V (logic level 1) or with a pull down resistor that will force the default logic state to be fully at 0V (logic level 0). Then the component will always be at one logic state or the other when the MCU isn't outputting its designated logic level state.

With Betaflight you can do this one of two ways. You can either add an external resistor or you can enable the built-in pull up and pull down configuration. If you provide a dump of your Betaflight settings I can tell you what configuration to change to enable the pull up for the GPS module.