iNavFlight / inav

INAV: Navigation-enabled flight control software
https://inavflight.github.io
GNU General Public License v3.0
3.08k stars 1.46k forks source link

Support new version of NOXE F4 FC #5867

Closed FranzAr closed 2 years ago

FranzAr commented 4 years ago

Current Behavior

The NOXE F4 FC from Banggood has been updated to a new version labeled "V1". The "old" target NOX does not work on that new hardware version.

Desired Behavior

Support new version "V1" as this FC is quite inexpensive and very small. Ideal for very limited space and light builds.

Suggested Solution

Betaflight seems to support this FC with the target Flywoo F411 and on the Flywoo website there is an iNav version 2.3.0 downloadable for this target. I flashed this to the new NOXE board and it seems to work fine. Maybe this could be a good starting point.

Who does this impact? Who is this for?

Everyone who needs a inexpensive and very small FC for iNav :-)

Additional context

iNav download from Flywoo: https://flywoo.net/products/flywoo-goku-f411-micaro-stack Noxe F4 at Banggood: https://www.banggood.com/de/20x20mm-Upgrade-Betaflight-F4-Noxe-V1-Flight-Controller-AIO-OSD-5V-8V-BEC-w-Barometer-and-Blackbox-for-RC-Drone-p-1310419.html

noxev1

schnupperm commented 4 years ago

motor 2 spins up at 30 to 40 % throttle using a pwm protocol like oneshot, mutltishot or standard

schnupperm commented 4 years ago

PWM works now. I've done a new esc throttle calibration and oneshot42 seems to work now!

mooiweertje commented 4 years ago

And DSHOT150?

schnupperm commented 4 years ago

no, dshot fails at motor 3, as soon as not all motors are at the same throttle value

snaewe commented 4 years ago

I've left the DSHOT support enabled for now and finally created a PR: #5958 .

schnupperm commented 4 years ago

Did anyone tested this on a multirotor? I've found an other problem: As soon as I start flying, the altitude in the osd drops fast to -70 to -90 meters. When I enable althold, the copter goes full throttle to the skies. Attached a blackbox log without props sitting on a table. (using betaflight 4.2 all is fine) blackbox_log_2020-07-18_220049.txt

mooiweertje commented 4 years ago

Did you put sponge/foam on the barometer unit to dampen the airflow from the props?

Op zo 19 jul. 2020 13:55 schreef schnupperm notifications@github.com:

Did anyone tested this on a multirotor? I've found an other problem: As soon as I start flying, the altitude in the osd drops fast to -70 to -90 meters. When I enable althold, the copter goes full throttle to the skies. Attached a blackbox log without props sitting on a table. (using betaflight 4.2 all is fine) blackbox_log_2020-07-18_220049.txt https://github.com/iNavFlight/inav/files/4943662/blackbox_log_2020-07-18_220049.txt

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/5867#issuecomment-660632512, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI6F3AZ5TOD675DUG6J7HLLR4LNKBANCNFSM4ODYCGZA .

schnupperm commented 4 years ago

yes, baro is covered. But the values from the baro sensor in the blackbox log also seem fine. Somehow the quad thinks it's falling down as soon as the motors are spinning even with out props. I also did the acc. calibration a second time. As I mentioned before, the altitude reading in Betaflight 4.2. is correct.

den-sinyo commented 4 years ago

I created two test releases based on 2.5.1 and master:

https://github.com/snaewe/inav/releases/tag/test-FLYWOOF411-2.5.1 https://github.com/snaewe/inav/releases/tag/test-FLYWOOF411-master

If anyone wants to test.

Greeting. I'm already testing this version as flying wing setup, and work well. But it's not quite working at the first time on flyingwing mixing standard option, missing the motor active pin on board. So i'm try a different way to solve, and i found with skyhunter mixing option working well, only with 1 motor and 3 servo configuration. For motor setup i'm using standard 400 mhz, and not test for other option. I hope this can help the other....and sorry for my bad English Thank's

pauluzs commented 4 years ago

@mooiweertje welke target and inav version are you using for the old nox V0 ?

The current naming is a bit confusing, as there is only one NOX target: https://github.com/iNavFlight/inav/blob/master/src/main/target/NOX/target.h

Which after reading seems to be for the V1 not the V0:

define TARGET_BOARD_IDENTIFIER "NOX1"

define USBD_PRODUCT_STRING "NoxF4V1"

Still got some of these V0's and want to use them in a flying wing with GPS and FPV

Thanks Paul

Fraggs150 commented 4 years ago

The Noxe v0 board target = nox (v2.5.1) The Noxe v1 board target = flywoo F4

pauluzs commented 4 years ago

Tnx @Fraggs150

mooiweertje commented 4 years ago

NOX is the old board and FLYWOOF411 is the new NOX board. With special thanks to Banggood for naming chaos.

Op ma 17 aug. 2020 21:16 schreef Pauluzs notifications@github.com:

@mooiweertje https://github.com/mooiweertje welke target and inav version are you using for the old nox V0 ?

The current naming is a bit confusing, as there is only one NOX target: https://github.com/iNavFlight/inav/blob/master/src/main/target/NOX/target.h

Which after reading seems to be for the V1 not the V0:

define TARGET_BOARD_IDENTIFIER "NOX1"

define USBD_PRODUCT_STRING "NoxF4V1"

Still got some of these V0's and want to use them in a flying wing with GPS and FPV

Thanks Paul

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/5867#issuecomment-675063212, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI6F3A33UEZ6TIFMIHB4XJDSBF6YNANCNFSM4ODYCGZA .

mirov commented 3 years ago

I just came across this thread. Have things settled down for this FC ? I now have several and will use them for an INAV series of builds. I like that it has dual BECs, one of them is 8V@3A. That's more than my VTX wants to see, but by changing two resistors (0402) I can drop it down to 5.0V@3A which is perfect for servos. Speaking of which, I use flaperons, so I need four servos and something to drive the motor ESC. Is that easily handled in the firmware now ? And let me second the desire for soft serial for the VTX control. BTW, with two multi-amp BECs, is anyone else concerned about supplying all that current through the single VBAT pin ?

-Russ

tonyyng commented 3 years ago

@mirov I don't know the answer to your questions, but I'm interested in your comment about changing the voltage on the BEC by changing resistors. Can you elaborate or point me at more information if the explanation would take this thread too far astray?

Fraggs150 commented 3 years ago

Hi Russ, I have 3 servos and an esc setup and all working fine on my testbed Noxe F4 on the bench also have a gps unit connected and have yet to have any issues with it/ the firmware, ect. Stu (fraggs)

On Tue, 24 Nov 2020, 22:35 Russ Mirov, notifications@github.com wrote:

I just came across this thread. Have things settled down for this FC ? I now have several and will use them for an INAV series of builds. I like that it has dual BECs, one of them is 8V@3A. That's more than my VTX wants to see, but by changing two resistors (0402) I can drop it down to 5.0V@3A which is perfect for servos. Speaking of which, I use flaperons, so I need four servos and something to drive the motor ESC. Is that easily handled in the firmware now ? And let me second the desire for soft serial for the VTX control. BTW, with two multi-amp BECs, is anyone else concerned about supplying all that current through the single VBAT pin ?

-Russ

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/5867#issuecomment-733272673, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQKN7BWPVUQWWCNVCUY325DSRQYKLANCNFSM4ODYCGZA .

mirov commented 3 years ago

(updated 12/2/2020 to adjust one resistor value)

Sorry if this is off-topic, but there are so many folks interested in this FC that I thought I'd share this info.

For those wanting to mod their 8V BEC and make it a 5V BEC, buy two resistors: https://www.digikey.com/en/products/detail/bourns-inc/CR0402-FX-1052GLF/4697969 https://www.digikey.com/en/products/detail/bourns-inc/CR0402-FX-3302GLF/3783317

and swap them for the ones already installed in the attached picture. NOXE_F4_V1_BEC_MOD

The particular DC/DC converter chip that this design uses has an unusual feature that increases the voltage output as the load current increases (apparently to compensate for wire IR drop). With the values shown it is at 5.01V on my unit with no load.

-Russ

satsepp commented 3 years ago

Hi, i try to get this board running. i used FLYWOOF411 Inav 2.6RC3, and for Test altough older verision. I always get error: PWM output init error: Not enough motor outputs/timers

If i delete Motor Mixers, and Add 3. Servo Mixer with "stable throttle" the motor likes to work. And i can use 3 Servos and one Motor.

But my Video Input don´t work. I get OSD but no Video. maybe i damaged because i connectet ground instead of Video input. But i think this schould not destroy anything?

can someone please check this. I altoug tryed Target lined some postes above, same effekt.

best reguards

Josef

mirov commented 3 years ago

Hi Tony, if you end up trying this note that I changed one of the resistor values to 10.5K from 12.7K, sorry for the trouble.

-Russ

On Tue, Nov 24, 2020 at 6:20 PM tonyyng notifications@github.com wrote:

@mirov https://github.com/mirov I don't know the answer to your questions, but I'm interested in your comment about changing the voltage on the BEC by changing resistors. Can you elaborate or point me at more information if the explanation would take this thread too far astray?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/5867#issuecomment-733419513, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJFJKXHGKEUSHAWUXL7PADSRRSU7ANCNFSM4ODYCGZA .

mirov commented 3 years ago

I've been struggling to get my Noxe V1 to do what I want. I've got the four primary PWM outputs configured for my fixed wing servos (Rudder, Elevator, two Alierons), but haven't been able to get a Motor channel working yet. The ESC and motor are fine, and if I hook the ESC input wire to one of the servo channels (or a servo simulator) it spins up just fine.

I'd like to use the LED_STRIP pad (PA15) for the motor output. This is what I have at the moment:

DEF_TIM(TIM2, CH1, PA15,   TIM_USE_FW_MOTOR,  0, 0), // MOTOR 1

DEF_TIM(TIM1, CH1, PA8,   TIM_USE_FW_SERVO,  0, 0), // S1_OUT 2,1
DEF_TIM(TIM1, CH2, PA9,   TIM_USE_FW_SERVO,  0, 0), // S2_OUT 2,2
DEF_TIM(TIM1, CH3, PA10,  TIM_USE_FW_SERVO,  0, 0), // S3_OUT 2,6
DEF_TIM(TIM3, CH3, PB0,   TIM_USE_FW_SERVO,  0, 0), // S4_OUT 1,7

I learned about the serious constraints on timers and timer channels for each GPIO port (thanks Pawel for the video), but I haven't been able to understand why for INAV it is common to have defines that include things like: TIM_USE_MC_MOTOR | TIM_USE_FW_SERVO Clearly the intent is to allow the GPIO pin to be used as either a multicopter motor or a fixed wing servo, but without the resource remapping of Betaflight how is this useful for INAV ? And what are the differences between MC_MOTOR and FW_MOTOR?

I saw that in target.h the LED_STRIP pin was defined to use the A15 pad. commenting out the USE_LED_STRIP line and the WS2811_PIN lines kept the board from booting after a flash, but then I found that I could move the LED_STRIP function to PB6 and then temporarily turn off UART1 while I debug this stuff. So there should be no conflict over the A15 pad use. I do however get "PWM output init error: Not enough motor outputs/timers" in the CLI status output.

I've been testing things exclusively with the "Outputs" screen of INAV after selecting "Airplane" as the choice for default values, "Airplane" as the choice for mixer preset, enabling motor and servo outputs on the configuration screen, and then enabling motors and enabling motor control and live modes on the Outputs screen. I've not been able to get the ESC control signal to show up on A15 (checked with a scope) and the motor doesn't spin up...

Any idea of what I'm doing wrong ?

-Russ

mirov commented 3 years ago

Well there's part of Murphy's law that says after you post a long plea for help you'll figure it out yourself... Anyway, I got it working by realizing that the MATEKF411_WING config I'm using on another FC shared the same STM device and I should be able to leverage the motor config. Here's what I ended up with:

DEF_TIM(TIM2, CH1, PA15, TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR,  0, 0), // S1  D(1,4,5)
DEF_TIM(TIM3, CH2, PB5,  TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR,  0, 0), // S2  D(1,5,5)

DEF_TIM(TIM1, CH1, PA8,   TIM_USE_FW_SERVO,  0, 0), // S3_OUT 2,1
DEF_TIM(TIM1, CH2, PA9,   TIM_USE_FW_SERVO,  0, 0), // S4_OUT 2,2
DEF_TIM(TIM1, CH3, PA10,  TIM_USE_FW_SERVO,  0, 0), // S5_OUT 2,6
DEF_TIM(TIM3, CH3, PB0,   TIM_USE_FW_SERVO,  0, 0), // S6_OUT 1,7

I really have no idea why this works and the earlier one does not. I've also been unsure about what those last two arguments to the DEF_TIM macro do (they are all set to 0, 0) sometimes I see a "1" in a few spots. I'm also unable to decode the comments that everyone is using - what does OUT 2,6 mean for example? Or D(1,4,5) ? Note that the second motor (that is of course unused) points towards a pin that is actually not connected to anything. Seemed safe.

-Russ

mirov commented 3 years ago

Well this was quite a learning experience (the '411 SOC has quite a few constraints on timers and pins). Anyway I've attached the target.c/target.h and a .hex file for a fixed wing config that supports four servos, one motor/esc, GPS, LED_STRIP, BEEPER, and a CURRENT monitoring input. To do this I had to change the functions of a few pads. The RSSI pad is now the CURRENT input pin. The CURT pin is now the LED_STRIP pin. The LED pin is now the MOTOR1 pin. RSSI is provided over a receiver channel so no analog input is needed anymore. GPS is connected to UART1 as is recommended. I'm running the GPS and receiver off the 4.5V supply output, and the servos off the modified "8V" output (now 5.0V). Pretty good for a 20x20mm FC that is $18USD on Banggood right now.

inav_2.6.0_FLYWOOF411_FIXED_WING_4SERVOS_FULL_HOUSE.zip

Smart Audio on the "TX2" pin (PA2) also is confirmed to be working (select the the TBS/SmartAudio peripheral on the ports screen for SOFTSERIAL1).

wvarty commented 3 years ago

@mirov the binary linked in your last comment saved me. Wasted a full evening trying to get iNav working on this FC, and your binary is the only one that has everything I needed. Just wanted to say thanks.

SkyChief101 commented 3 years ago

Well this was quite a learning experience (the '411 SOC has quite a few constraints on timers and pins). Anyway I've attached the target.c/target.h and a .hex file for a fixed wing config that supports four servos, one motor/esc, GPS, LED_STRIP, BEEPER, and a CURRENT monitoring input. To do this I had to change the functions of a few pads. The RSSI pad is now the CURRENT input pin. The CURT pin is now the LED_STRIP pin. The LED pin is now the MOTOR1 pin. RSSI is provided over a receiver channel so no analog input is needed anymore. GPS is connected to UART1 as is recommended. I'm running the GPS and receiver off the 4.5V supply output, and the servos off the modified "8V" output (now 5.0V). Pretty good for a 20x20mm FC that is $18USD on Banggood right now.

inav_2.6.0_FLYWOOF411_FIXED_WING_4SERVOS_FULL_HOUSE.zip

I haven't been able to test VTX control over SmartAudio yet, but expect that it should work.

SkyChief101 commented 3 years ago

I would love to learn how to do this. I have the banggood controller but no ideal how to put the files on it to use for a fixed wing airplane

Fraggs150 commented 3 years ago

Skychief101 plenty of guides on how to flash firmware on flight controllers on YouTube and even on Github too, if you look at how to flash/install Inav onto your flight controller it should give you some idea

mirov commented 3 years ago

First thing to do is to back up your current flight controller config if you want the option someday of putting it back. The firmware flashing steps outlined below will erase all that and you'll be starting INAV from scratch.

It is pretty straight forward, but the one trick that I had to learn (though it is spelled out, it seems too simple to really be required) is this: exit the INAV configurator app. Power off the flight controller (ie: no battery power, no USB cable plugged in). Hold down the BOOT button on the flight controller, and while it is down plug in the USB cable. The red light should stay on, that means it is in boot mode. Start up the INAV configurator, go into "firmware flasher", and "Load Firmware [local]" selecting the appropriate .hex file that you've downloaded to your PC. Once that is done press "flash firmware" and after a minute you'll be ready to reboot and use the configurator to make things the way you like them.

On Tue, Dec 22, 2020 at 3:18 PM Fraggs150 notifications@github.com wrote:

Skychief101 plenty of guides on how to flash firmware on flight controllers on YouTube and even on Github too, if you look at how to flash/install Inav onto your flight controller it should give you some idea

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/5867#issuecomment-749831055, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJFJKVIIV65XOIWWRYFSHTSWESNDANCNFSM4ODYCGZA .

Fraggs150 commented 3 years ago

Nice guide Mirov , should make it a bit easier for Skychief to get things working. I have not had to press the boot to flash the firmware hex files on my flight controller, just go to the firmware flashing screen in Inav and update as normal ( using windows )

mooiweertje commented 3 years ago

Thanks Mirov, I'd like to use the RSSI or current pin for PPM. Can I just Change PA2 to the desired pin in target.h or should I take more things into consideration? I want to use UART 1 and 2 for GPS and telemetry (DJI OSD) and PPM for the RC receiver, like I did with the previous Nox board.

mirov commented 3 years ago

Hi Mooiweertje. There are at least several changes I think. I haven't tested any of these, my one working FC of this type is wired into a cramped model with a different config (several more are on order but haven't arrived yet).

However, in target.c, change the PPM_IN line to DEF_TIME(TIM5, CH2, PA1, TIM_USE_PPM, 0, 0), // PPM IN on the pad marked CURT Delete these lines: DEF_TIM(TIM5, CH4, PA3, TIM_USE_ANY, 0, 1), // RX2 1,0 DEF_TIM(TIM5, CH2, PA1, TIM_USE_LED, 0, 0), // LED 1,5

In target.h change the UART2_RX line to this:

define UART2_TX_PIN PA2

And probably it is best to comment out the SOFTSERIAL lines and change the serial port count: //#define USE_SOFTSERIAL1 //#define SOFTSERIAL_1_TX_PIN PA2 // Clash with TX2, possible to use as S.Port or VTX control //#define SOFTSERIAL_1_RX_PIN PA2

define SERIAL_PORT_COUNT 3 // VCP, USART1, USART2

And we have to remove PA1 from being used as the LED strip output, so comment out these lines: //#define USE_LED_STRIP //#define WS2811_PIN PA1 // CURT Pin now used as LED_STRIP

And that might either work for you or get you pretty close. Note that in the inav_configurator you'll have to make sure that you aren't asking for soft_serial ports, or LED_Strips now.

The STM32F411 datasheet here: https://www.st.com/en/microcontrollers-microprocessors/stm32f411ce.html has all the important info on what each pin can be used for and what timers are associated with each one. For example, PA1 shows up on page 40, and you can see that it has a bunch of "alternate functions" and one "additional function". In that first change of target.c I selected Timer5, Channel 2 because it OK to use for this pin, and the other choice Timer 2 is already being used for Motor_1's output on PA15. I'm still learning the rules, I'm not sure if PPM_IN pins can share timers with other functions like servos or ESCs. But it is clear that servos and ESCs can't share timers.

Good luck, I hope it still compiles!

Finnigan1971 commented 3 years ago

Hi there, sorry for my bad english, as always: i'm following this thread with interest, i'm asking if the .hex files attached in the previous posts are good for my quad. Remember that (as all the people here, i guess) I have the motor#3 freezed with Dshot protocol. The other make the motors spin weird. These .hex fix my problem or are only for FW models?

mirov commented 3 years ago

These .hex fix my problem or are only for FW models?

Hi Finnigan1971. The .hex file I posted was made specifically for FW models. It was difficult to have four servos, an ESC, GPS, RSSI, LED Strip, Beeper, and Current monitor all working at the same time. I'm not familiar with the motor3 issue with quads, sorry.

schnupperm commented 3 years ago

Hi Finnigan I tried repo build 2.6.0 motor 3 Oneshot125 and it worked. Maybe the problem is in your hardware?

I think he means d-shot. My board only works in pwm, oneshot123, oneshot42 and multishot. Using any d-shot mode motor 3 does not work

Finnigan1971 commented 3 years ago

Hi Finnigan I tried repo build 2.6.0 motor 3 Oneshot125 and it worked. Maybe the problem is in your hardware?

My Noxe V1 is brand new and works pefectly in Betaflight (even compass and GPS are detected and working). No issues concerning motors protocols: i can use Dshot and oneshot without issues.

I'll try to re-flash with the version mentioned by mooiweertje. If i'll find it: where is it???

Finnigan1971 commented 3 years ago

I already tried the version you mentioned:

Concerning DSHOT: With the motor tab i can't spin the motor 3. Arming, all four motors spin, the third stops once the throttle is raised.

Concerning ONESHOT: With the motor tab i can spin all four motors. Arming, the motors start to run, in sequence.

Concerning MULTISHOT: With the motor tab, i can spin all four motors. Arming, first start the Front Right motor, then the others.

mirov commented 3 years ago

Hi Mooiweertje, are your problems that SBUS doesn't seem to work or something else? Last week I switched to a R9 mini receiver that uses SBUS and could not get it working. It turned out that the SBUS inverter transistor location on the NOXE PCB had the wrong type of transistor installed (PNP vs the desired NPN). It is quite possible someone at the factory put in the wrong reel of parts and many other NOXE V1 controllers have the same issue.

NOXE_V1_Transistors

The transistors for the inverter and the BEEP circuitry should be the same, as in the picture above. In my case the one on the left was incorrect and the inverter that I needed was never inverting.

mooiweertje commented 3 years ago

No I just want 2 UARTS for GPS and DJI OSD and sbus for RC receiver. If I use the SBUS pin for the RC receiver I lose UART 2. I solved this now by using PPM over the LED pin.

Maybe another option is to use UART2 for the RC and softserial on some other pin for the DJI OSD?

elielmarcos commented 3 years ago

I already tried the version you mentioned:

Concerning DSHOT: With the motor tab i can't spin the motor 3. Arming, all four motors spin, the third stops once the throttle is raised.

Concerning ONESHOT: With the motor tab i can spin all four motors. Arming, the motors start to run, in sequence.

Concerning MULTISHOT: With the motor tab, i can spin all four motors. Arming, first start the Front Right motor, then the others.

the same thing happens to me, DSHOT doesn't work engine 3, MULTISHOT everything ok

elielmarcos commented 3 years ago

I need to use 2 UARTs for receiver and GPS, and a softserial for VTX/SmartAudio.

The FC has these outputs:

UART1 for GPS - ok UART2 for receiver - ok

In iNAV (firmware FLYWOO-f411) the configurator shows the option to use softserial, if I enable it, what are the outputs (tx / rx) in FC? I need to use them for VTX on a Quad.

According to target.h, SoftSerial Tx pin PB6 and Rx pin PB7, but no controller output is connected to these pins. Should I redirect to the RSSI or LED?

information taken from iNAV target firmware FlywooF411: Screenshot_2021-01-27-18-18-36-737_com miui notes

mirov commented 3 years ago

my target.h file serial section looks like this:

// * UART ***

define USE_VCP

define USE_UART1

define UART1_TX_PIN PB6

define UART1_RX_PIN PB7

define USE_UART2

define UART2_TX_PIN NONE //PA2

define UART2_RX_PIN PA3

define USE_SOFTSERIAL1

define SOFTSERIAL_1_TX_PIN PA2 // Clash with TX2, possible to use as S.Port or VTX control

define SOFTSERIAL_1_RX_PIN PA2

define SERIAL_PORT_COUNT 4 // VCP, USART1, USART2, SS1

define DEFAULT_RX_TYPE RX_TYPE_SERIAL

define SERIALRX_PROVIDER SERIALRX_SBUS

//#define SERIALRX_PROVIDER SERIALRX_IBUS

define SERIALRX_UART SERIAL_PORT_USART2

And I've used both SBUS/IBUS and Smart Audio. The SA wire from the VTX solders to the TX2 pad.

-Russ

elielmarcos commented 3 years ago

my target.h file serial section looks like this:

// * UART ***

define USE_VCP

define USE_UART1

define UART1_TX_PIN PB6

define UART1_RX_PIN PB7

define USE_UART2

define UART2_TX_PIN NONE //PA2

define UART2_RX_PIN PA3

define USE_SOFTSERIAL1

define SOFTSERIAL_1_TX_PIN PA2 // Clash with TX2, possible to use as S.Port or VTX control

define SOFTSERIAL_1_RX_PIN PA2

define SERIAL_PORT_COUNT 4 // VCP, USART1, USART2, SS1

define DEFAULT_RX_TYPE RX_TYPE_SERIAL

define SERIALRX_PROVIDER SERIALRX_SBUS

//#define SERIALRX_PROVIDER SERIALRX_IBUS

define SERIALRX_UART SERIAL_PORT_USART2

And I've used both SBUS/IBUS and Smart Audio. The SA wire from the VTX solders to the TX2 pad.

-Russ

Thank you, I'll try it.

I was comparing the target of iNAV and BetaFlight, the UART2 pins in both are the same (TX-PA2 and RX-PA3), but UART1 are different: UART1 TX - PA9 (iNAV), PB6 (BF) UART1 RX - PA10 (iNAV), PB7 (BF)

That is, the pins of BF UART1 are the pins of iNAV SoftSerial, so who are the pins of UART1 of iNAV ??? What a mess...

Sorry if I didn't express myself well

elielmarcos commented 3 years ago

my target.h file serial section looks like this:

// * UART ***

define USE_VCP

define USE_UART1

define UART1_TX_PIN PB6

define UART1_RX_PIN PB7

define USE_UART2

define UART2_TX_PIN NONE //PA2

define UART2_RX_PIN PA3

define USE_SOFTSERIAL1

define SOFTSERIAL_1_TX_PIN PA2 // Clash with TX2, possible to use as S.Port or VTX control

define SOFTSERIAL_1_RX_PIN PA2

define SERIAL_PORT_COUNT 4 // VCP, USART1, USART2, SS1

define DEFAULT_RX_TYPE RX_TYPE_SERIAL

define SERIALRX_PROVIDER SERIALRX_SBUS

//#define SERIALRX_PROVIDER SERIALRX_IBUS

define SERIALRX_UART SERIAL_PORT_USART2

And I've used both SBUS/IBUS and Smart Audio. The SA wire from the VTX solders to the TX2 pad.

-Russ

Sorry for my inability, but according to the BetaFlight target, the PB10 pin is used for CAM_C (where there is an output on the board for this pin), which I will not use.

So I ask, could you use PB10 instead of PA2 for SoftSerial1 and leave PA2 for UART2?

Would that work?:

define SOFTSERIAL_1_TX_PIN PB10 //Card output marked by CAM-C

define SOFTSERIAL_1_RX_PIN PB10 //Card output marked by CAM-C

define UART2_TX_PIN PA2 //Card output marked by TX2

mirov commented 3 years ago

I actually am not sure what the CAM-C pin is connected to on the NOXE V1 board, but I also assumed that's what I'd be using for the VTX control only to find out that it wasn't working for me. The TX2 pin however seems to work just fine. Does anyone know what the CAM-C pin is connected to or the circuitry behind it ?

-Russ

On Wed, Jan 27, 2021 at 2:21 PM Mooiweertje notifications@github.com wrote:

TX2 doesn't work?

Op wo 27 jan. 2021 23:16 schreef Eliel Romancini <notifications@github.com

:

my target.h file serial section looks like this:

// * UART ***

define USE_VCP

define USE_UART1

define UART1_TX_PIN PB6

define UART1_RX_PIN PB7

define USE_UART2

define UART2_TX_PIN NONE //PA2

define UART2_RX_PIN PA3

define USE_SOFTSERIAL1

define SOFTSERIAL_1_TX_PIN PA2 // Clash with TX2, possible to use as

S.Port or VTX control

define SOFTSERIAL_1_RX_PIN PA2

define SERIAL_PORT_COUNT 4 // VCP, USART1, USART2, SS1

define DEFAULT_RX_TYPE RX_TYPE_SERIAL

define SERIALRX_PROVIDER SERIALRX_SBUS

//#define SERIALRX_PROVIDER SERIALRX_IBUS

define SERIALRX_UART SERIAL_PORT_USART2

And I've used both SBUS/IBUS and Smart Audio. The SA wire from the VTX solders to the TX2 pad.

-Russ

Sorry for my inability, but according to the BetaFlight target, the PB10 pin is used for CAM_CC (where there is an output on the board for this pin), which I will not use.

So I ask, could you use PB10 instead of PA2 for SoftSerial1 and leave PA2 for UART2?

Would that work?:

define SOFTSERIAL_1_TX_PIN PB10

define SOFTSERIAL_1_RX_PIN PB10

define UART2_TX_PIN PA2

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/5867#issuecomment-768614741, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AI6F3A443KY554K45P632K3S4CGDZANCNFSM4ODYCGZA

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/5867#issuecomment-768617469, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJFJKUHJJO4GYRWXQWVS53S4CGYHANCNFSM4ODYCGZA .

elielmarcos commented 3 years ago

TX2 doesn't work? Op wo 27 jan. 2021 23:16 schreef Eliel Romancini notifications@github.com: my target.h file serial section looks like this: // * UART *** #define USE_VCP #define USE_UART1 #define UART1_TX_PIN PB6 #define UART1_RX_PIN PB7 #define USE_UART2 #define UART2_TX_PIN NONE //PA2 #define UART2_RX_PIN PA3 #define USE_SOFTSERIAL1 #define SOFTSERIAL_1_TX_PIN PA2 // Clash with TX2, possible to use as S.Port or VTX control #define SOFTSERIAL_1_RX_PIN PA2 #define SERIAL_PORT_COUNT 4 // VCP, USART1, USART2, SS1 #define DEFAULT_RX_TYPE RX_TYPE_SERIAL #define SERIALRX_PROVIDER SERIALRX_SBUS //#define SERIALRX_PROVIDER SERIALRX_IBUS #define SERIALRX_UART SERIAL_PORT_USART2 And I've used both SBUS/IBUS and Smart Audio. The SA wire from the VTX solders to the TX2 pad. -Russ Sorry for my inability, but according to the BetaFlight target, the PB10 pin is used for CAM_CC (where there is an output on the board for this pin), which I will not use. So I ask, could you use PB10 instead of PA2 for SoftSerial1 and leave PA2 for UART2? Would that work?: #define SOFTSERIAL_1_TX_PIN PB10 #define SOFTSERIAL_1_RX_PIN PB10 #define UART2_TX_PIN PA2 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5867 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI6F3A443KY554K45P632K3S4CGDZANCNFSM4ODYCGZA .

Sorry i haven't tested it yet.

I need the following configuration:

UART1 for GPS UART2 for Receiver (F.port or TBS or SBUS ...) SOFTSERIAL1 for VTX (SmartAudio).

So, I would like to understand if I compile the firmware this way will suit me or I will have bugs:

define UART1_TX_PIN PB6 //Card output marked by TX1

define UART1_RX_PIN PB7 //Card output marked by RX1

define UART2_TX_PIN PA2 //Card output marked by TX2

define UART2_RX_PIN PA3 //Card output marked by RX2

define SOFTSERIAL_1_TX_PIN PB10 //Card output marked by CAM-C

define SOFTSERIAL_1_RX_PIN PB10 //Card output marked by CAM-C

mirov commented 3 years ago

It might work, though as I said I'm not sure how PB10 is connected to the CAM-C pad (it didn't seem to be a direct connection, but perhaps I made an error with the continuity meter).

I do know that the target.h lines I supplied along with the TX2 pin does work across multiple planes.

-Russ

On Wed, Jan 27, 2021 at 2:33 PM Eliel Romancini notifications@github.com wrote:

TX2 doesn't work? Op wo 27 jan. 2021 23:16 schreef Eliel Romancini notifications@github.com: … <#m-2808383528899962194> my target.h file serial section looks like this: // * UART *** #define USE_VCP #define USE_UART1 #define UART1_TX_PIN PB6 #define UART1_RX_PIN PB7 #define USE_UART2 #define UART2_TX_PIN NONE //PA2 #define UART2_RX_PIN PA3 #define USE_SOFTSERIAL1

define SOFTSERIAL_1_TX_PIN PA2 // Clash with TX2, possible to use as

S.Port or VTX control #define SOFTSERIAL_1_RX_PIN PA2 #define SERIAL_PORT_COUNT 4 // VCP, USART1, USART2, SS1 #define DEFAULT_RX_TYPE RX_TYPE_SERIAL #define SERIALRX_PROVIDER SERIALRX_SBUS //#define SERIALRX_PROVIDER SERIALRX_IBUS #define SERIALRX_UART SERIAL_PORT_USART2 And I've used both SBUS/IBUS and Smart Audio. The SA wire from the VTX solders to the TX2 pad. -Russ Sorry for my inability, but according to the BetaFlight target, the PB10 pin is used for CAM_CC (where there is an output on the board for this pin), which I will not use. So I ask, could you use PB10 instead of PA2 for SoftSerial1 and leave PA2 for UART2? Would that work?: #define SOFTSERIAL_1_TX_PIN PB10 #define SOFTSERIAL_1_RX_PIN PB10 #define UART2_TX_PIN PA2 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5867 (comment) https://github.com/iNavFlight/inav/issues/5867#issuecomment-768614741>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AI6F3A443KY554K45P632K3S4CGDZANCNFSM4ODYCGZA .

Sorry i haven't tested it yet.

I need the following configuration:

UART1 for GPS UART2 for Receiver (F.port or TBS or SBUS ...) SOFTSERIAL1 for VTX (SmartAudio).

So, I would like to understand if I compile the firmware this way will suit me or I will have bugs:

define UART1_TX_PIN PB6 //Card output marked by TX1

define UART1_RX_PIN PB7 //Card output marked by RX1

define UART2_TX_PIN PA2 //Card output marked by TX2

define UART2_RX_PIN PA3 //Card output marked by RX2

define SOFTSERIAL_1_TX_PIN PB10 //Card output marked by CAM-C

define SOFTSERIAL_1_RX_PIN PB10 //Card output marked by CAM-C

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/5867#issuecomment-768622861, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJFJKRA6GHZYVHNUZEIX73S4CIDVANCNFSM4ODYCGZA .

mooiweertje commented 3 years ago

In iNAV (firmware FLYWOO-f411) the configurator shows the option to use softserial, if I enable it, what are the outputs (tx / rx) in FC?

RX2 for receiver TX2 for sa

elielmarcos commented 3 years ago

I understand, it should probably contain some circuit that is not compatible with SmartAudio.

In this case, instead of using PA2 (TX2) or PB10 (CAM-C), could the RSSI or LED_STRIP pin be used for SoftSerial?

elielmarcos commented 3 years ago

In iNAV (firmware FLYWOO-f411) the configurator shows the option to use softserial, if I enable it, what are the outputs (tx / rx) in FC?

TX2 RX2.

Perfect

elielmarcos commented 3 years ago

In iNAV (firmware FLYWOO-f411) the configurator shows the option to use softserial, if I enable it, what are the outputs (tx / rx) in FC?

RX2 for receiver TX2 for sa

Thank you very much, I think my problem is now solved.

Receiver in RX2 SmartAudio in TX2 GPS in TX1 / RX1

elielmarcos commented 3 years ago

I actually am not sure what the CAM-C pin is connected to on the NOXE V1 board, but I also assumed that's what I'd be using for the VTX control only to find out that it wasn't working for me. The TX2 pin however seems to work just fine. Does anyone know what the CAM-C pin is connected to or the circuitry behind it ?

Simple RC filter, i just checked the sign on the plate, If you remove the capacitor and put a wire in place of the resistor, we will have a direct output

IMG_20210127_202847 IMG_20210127_203730