Support new version of NOXE F4 FC

[FranzAr]

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

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label Feature request to this issue, with a confidence of 0.93. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[digitalentity]

Please have a look at https://github.com/iNavFlight/inav/blob/master/docs/policies/NEW_HARDWARE_POLICY.md#new-target-additions

[snaewe]

What, if someone would come up with a target config derived from betaflight for this FC? Any chance that would be merged ?

[digitalentity]

As a baseline - community created targets may be merged, but are unlikely to be included in the release.

A one off exceptions are possible if a board is well designed, would be a good fit for INAV and there is a significant demand for support of the board.

[moggiex]

Howdy @digitalentity ,

The board is a cheap 20x20mm board that even I picked because of the price, it has an OSD, 4 PWM channels and enough UARTs to be useful.

If I was to get one of these sent to you, would you be able to use it as a Dev board to make it compatible with iNav?

Matt

[moggiex]

Actually @digitalentity ,

Reading the policy, if I went through list of common cheap boards in BG and sent you say up to 5 of them, would that be better overall?

Have checked the minimum specs and it would take a short while to list and cross reference the boards, then get you to double check them.

The boards like this one will get bought by people like me and the user above because of their price, specs and specifically for their size for light builds.

Is that something you would find helpful?

Matt

[digitalentity]

Thanks for reaching out Matt, that would indeed be helpful. What boards do you have in mind?

[moggiex]

Howdy,

The one above for sure and basically anything is £25 or less per board that isn't supported.

The £25/$30 limit is a sensible one as the premium boards will be the likes of Matek and normally supported early. If you have any suggestions on specific ones let me know. I'll go do some searching now and see what I find.

Also are you able to send me an address and I'll get the NOXE board above sent to you asap too.

Matt

[digitalentity]

@moggiex Thanks for the offer, please give me a ping at ksharlaimov@inavflight.com to discuss further

[moggiex]

For anyone who is reading this and want at least 2.3.0 of iNav to run on this board, see here https://www.youtube.com/watch?v=lpzOU7lIsEg

@digitalentity , saw your reply earlier, have emailed you directly.

Matt

[tonyyng]

Can you also include SoftSerial support so we can use SmartAudio or Tramp components?

Thanks

[snaewe]

The HEX file linked above does not work! Based on the work by @SeanTheITGuy I did some changes and tests for the target. Look at my inav fork https://github.com/snaewe/inav/tree/add-FLYWOOF411 A small test is shown here: https://www.youtube.com/watch?v=pH0Ztvg2kkU

(@mooiweertje Are you Jannes Bosma who commented on the RagTheNutsOff video ?)

[snaewe]

@mooiweertje If you cloned my repo, you have to checkout the 'add-FLYWOOF411' branch first. Then 'make TARGET=FLYWOOF411'. HTH

[moggiex]

Thanks gents.

If you need an idiot to test with, just tag me a hex file :)

Matt

[snaewe]

@mooiweertje @SeanTheITGuy is also working on this (I based my changes on his). We need to synchronize that.

Re. 2 motors: Really? Why do we want two motors with this tiny board? Will that still allow 3 servos + 1 motor ? Re. testing: Yes, I only did a quick test of the motor/servo outputs. Testing more (OSD, GPS, I2C) would be next.

[moggiex]

It's just how INAV works with two motors on FixedWing. You can use only one of course but the mapping should have 2.

Wheres the head bang emjoi?

PS. Yes I know it's written into the base code and that its timer related. But really? How many people actually use two motors, let alone diff thrust and use it in the air anyway? Huge waste a PWM channel, especially on these smaller boards with limited outputs. Its been a feature waiting for a cause for years. Meh, rant over ;)

[snaewe]

I assume creating two target variants (1 motor vs. 2 motors) would be an option

[snaewe]

No just one with the standards is fine. You can setup what ever you want yourself in the configurator mixer tab.

Not if I want 3 servos and one motor and two of the four available outputs are "marked" as motor outputs, or am I missing something?

[snaewe]

No just one with the standards is fine. You can setup what ever you want yourself in the configurator mixer tab.

Not if I want 3 servos and one motor and two of the four available outputs are "marked" as motor outputs, or am I missing something?

I compiled a version with two outputs marked as motor, setup the mixer (1 motor + 3 servos) and got "PWM output init error: Not enough servo outputs/timers" in cli "status" -> No go.

[snaewe]

I'm missing the details too but this is the standard and it works the way you want it to work. Just do S1 and S2 TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR and S3 and S4 TIM_USE_MC_MOTOR | TIM_USE_FW_SERVO. You will see you can configure what you want in the configurator mixer tab.

Ehh...Nope. Doesn't work

[snaewe]

This is my version: DEF_TIM(TIM1, CH1, PA8, TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR, 0, 1), // S1_OUT 2,1 DEF_TIM(TIM1, CH2, PA9, TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR, 0, 1), // S2_OUT 2,2 DEF_TIM(TIM1, CH3, PA10, TIM_USE_MC_MOTOR | TIM_USE_FW_SERVO, 0, 0), // S3_OUT 2,6 DEF_TIM(TIM3, CH3, PB0, TIM_USE_MC_MOTOR | TIM_USE_FW_SERVO, 0, 0), // S4_OUT 1,7

and it doesn't work!

status

System Uptime: 239 seconds Current Time: 2041-06-28T01:04:00.000+00:00 Voltage: 0.00V (1S battery - NOT PRESENT) CPU Clock=96MHz, GYRO=MPU6000, ACC=MPU6000, BARO=BMP280 STM32 system clocks: SYSCLK = 96 MHz HCLK = 96 MHz PCLK1 = 48 MHz PCLK2 = 96 MHz Sensor status: GYRO=OK, ACC=OK, MAG=NONE, BARO=OK, RANGEFINDER=NONE, OPFLOW=NONE, GPS=NONE Stack size: 6144, Stack address: 0x20020000, Heap available: 1928 I2C Errors: 0, config size: 5839, max available config: 16384 ADC channel usage: BATTERY : configured = ADC 2, used = ADC 2 RSSI : configured = ADC 3, used = none CURRENT : configured = ADC 1, used = none AIRSPEED : configured = none, used = none System load: 2, cycle time: 1003, PID rate: 997, RX rate: 49, System rate: 9 Arming disabled flags: ACC RX CLI PWMOUT VTX: not detected PWM output init error: Not enough servo outputs/timers

[moggiex]

Note: I have a board here and servos connected, can easily test if needed gents.

[snaewe]

@moggiex https://bintray.com/snaewe/generic/download_file?file_path=inav_2.5.1_FLYWOOF411.hex

[snaewe]

Ah yes, I have the PWM output init error: Not enough servo outputs/timers message too. And the servo on your board doesn't respond?

I really didn't test...but what do you expect?

[snaewe]

Did you test it? @moggiex and I are currently testing and even though we don't get that "status" error, there's no signal at the output!

[SeanTheITGuy]

I don't think you can mix motors and servos on the same timer because they want totally different frequencies. Hence one motor and three servos in fw mode.

On Wed., Jul. 1, 2020, 7:25 a.m. Stefan Naewe, notifications@github.com wrote:

Did you test it? @moggiex https://github.com/moggiex and I are currently testing and even though we don't get that "status" error, there's no signal at the output!

— 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-652334688, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JCGZA2TAOFRMUOKNZOCTRZMFIVANCNFSM4ODYCGZA .

[SeanTheITGuy]

You can't look at what other targets do, because other targets use the timers differently. Look at what timer you are using per output, and group motors on timers separate from other items like PPM, UART and SERVO outputs. This is why some targets have motor outputs seemingly randomly allocated among the various S[X] outputs.

On Wed, Jul 1, 2020 at 7:57 AM Mooiweertje notifications@github.com wrote:

My finding is the same about mixing servo's and motor mappings in target.c. I thought there was some kind of algorithm to choose the right mapping based on the mixer tab settings. Nevertheless all the targets have S1 and S2 TIM_USE_FW_MOTOR...... I now think that the servo will turn on S2 since I have done that in the past with other boards, But not sure.

— 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-652349714, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JCG4ECCIQKVVNOQTIRDDRZMJBLANCNFSM4ODYCGZA .

[tonyyng]

Do you think it would be possible to add a SoftSerial port?

Thanks

[snaewe]

Do you think it would be possible to add a SoftSerial port?

SoftSerial is enabled on TX2 but I haven't tested it yet.

[SeanTheITGuy]

I will often repurpose the PPM pin for Softserial TX, to use as a smartaudio port, leaving the UARTS intact for CRSF and GPS. All that needs to be done for that is to set define the SSTX pin in target.h as the PPM pin, and SSRX as "NONE".

On Wed, Jul 1, 2020 at 8:59 AM Stefan Naewe notifications@github.com wrote:

Do you think it would be possible to add a SoftSerial port?

SoftSerial is enabled on TX2 but I haven't tested it yet.

— 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-652376106, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JCG4FZ34LIM6AUYQCQJLRZMQJ3ANCNFSM4ODYCGZA .

[tonyyng]

Do you think it would be possible to add a SoftSerial port?

SoftSerial is enabled on TX2 but I haven't tested it yet.

Why would you put a Softserial port on a UART? The typical usage would be a receiver on TX1, GPS on TX2, and VTX control (Tramp, SA) on Softserial. Could Softserial be put on something like an LED pad?

[SeanTheITGuy]

This is typical with INAV. It's done so you can have two RX pins, or two TX pins instead of TX/RX. With IBUS/SBUS + GPS, for example, you can put both on one UART if you use softserial to repurpose both pins as an RX.

On Wed, Jul 1, 2020 at 9:02 AM tonyyng notifications@github.com wrote:

Do you think it would be possible to add a SoftSerial port?

SoftSerial is enabled on TX2 but I haven't tested it yet.

Why would you put a Softserial port on a UART? The typical usage would be a receiver on TX1, GPS on TX2, and VTX control (Tramp, SA) on Softserial. Could Softserial be put on something like an LED pad?

— 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-652377500, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JCGZR2VIQPGJZMS2P2F3RZMQWZANCNFSM4ODYCGZA .

[SeanTheITGuy]

DEF_TIM(TIM9, CH1, PA2,   TIM_USE_PPM,   0, 0), // PPM IN

PA2 is PPM.

[mooiweertje]

Just cosmetics but I think BUS_SPI3 should be renamed to BUS_SPI2 which sounds more logical to me and all seems to work fine when I tried.

[SeanTheITGuy]

Sounds good. I just used the bus numbering from the Betaflight wiki on that board. Since more work was done on the target that utilized mine as a base, that should probably be suggested for incorporation into the main project.

[mooiweertje]

Maybe talk to digital entity to check if it's ok to just have 1 FW motor and 3 servo. It makes sense to me. It's for the drift I presume?

@SeanTheITGuy I would like to use the RSSI pad for PPM. I don't use RSSI and I think all people nowadays use channel 16 or 8 for RSSI. I can do this on my local build so no pressure to get in a release. And so far I have everything I want so I try not to go into the whole timer and channel circus because that takes a lot of time.

[moggiex]

DEF_TIM(TIM9, CH1, PA2,   TIM_USE_PPM,   0, 0), // PPM IN

PA2 is PPM.

I thought this board was SBUS. Or can it accept PPM instead?

Excuse the daft question, you may just be able remap all the pins to whatever is desired. :)

[mooiweertje]

@moggiex Daft questions are the ones not being asked I hear a lot. And I agree with both.

PPM may work on the SBUS pad when you select PPM in configurator and nothing in ports. I would prefer SBUS in that case since you lose a free UART anyway.

I would like PPM mapped to PB1 which is the RSSI pad now and remove RSSI since RSSI commonly is fed by the receiver channel 8 or 16. That would keep both UARTS free for other stuff. But making a lot of changes would confuse people cause the FC manual and writing on the actual board itself would be wrong and misleading.

[mooiweertje]

The actual CPU is an STM32F411CEU6, to be read on the CPU with a magnifying glass, which datasheet can be found here: https://www.st.com/resource/en/datasheet/stm32f411ce.pdf which is a massive load of info for me. But it does contain some stuff I use sometimes. Our CPU is the 48 pin version shown here: Where you can find pin PA2 for instance on pin 12. If you are handy, which I am not with these super tiny CPU's, you can solder the PPM wire from your receiver straight to this pin and it should work. But some copper on the print from PA2 to a soldering pad or connector makes life truly worth living.

[mooiweertje]

What is the USE_IMU_ICM20689 in target.h for? Betaflight has it too but I don't see the chip on the board and there is no external SPI bus. I removed the ICM20689 support and all seems to work fine.

[mooiweertje]

I see some VTX switcher in Betaflight. Is this smartaudio/tramp? On PB5? To which pad/connector does it lead?

define USE_PINIO

define PINIO1_PIN PB5 // VTX switcher

//#define PINIO2_PIN PA15 // Camera switcher

define USE_PINIOBOX

[mooiweertje]

I've walked through all the target files for this board and I think all is well. Nothing critical to mention just the above suggestions. Thanks for sharing I will start using it in a few weeks or so. I am busy the next two days.

You can add your target to the target list in make/targets.mk to make it appear in the target message. Add a document docs/Board-FlyWooF411.md

[mooiweertje]

PA2 is the UART2_TX_PIN as well as PPM. So I guess what you configure in inav configurator is what the pin will do? Not so good for me caus I want 2 UARTS for DJI FPV and GPS which only leaves space for PPM. So I'd like PPM on the CAM-C or RSSI pad.

CAM-C pad seems to be pin PB10 but there is no continuity between pad and pin. Following the continuity of the CAM-C pad I end up at some two pin SMD components at the back. So that may be tricky. What is this CAM-C ment to do anyway?

PPM seems to be remap-able to the RSSI pad. I will try that sometime. There is continuity between PB1 and the RSSI pad.

[mooiweertje]

Playing with the mixer presets I noticed your pwm mapping is the same as the 'Skyhunter Nano (no rudder)' preset. That is nice.

[tonyyng]

This is typical with INAV. It's done so you can have two RX pins, or two TX pins instead of TX/RX. With IBUS/SBUS + GPS, for example, you can put both on one UART if you use softserial to repurpose both pins as an RX.

That would be great if I could make this work. If SoftSerial is on TX2, the Tramp signal wire to the VTX would be connected to TX2. If I was to connect the GPS to the same UART, what are the connections? I assume RX2 goes to TX on the GPS. What is the GPS RX pin connected to?

Thanks

[mooiweertje]

I'd expect a GPS would be connected to UART1. RX to TX and TX to RX.

[tonyyng]

I'd expect a GPS would be connected to UART1. RX to TX and TX to RX.

I need to keep UART1 for my FPort receiver. It is a single wire bi-directional connection on TX1.

I was trying to understand @SeanTheITGuy 's comment about putting IBUS/SBUS + GPS on one UART.

[mooiweertje]

Sounds impossible to me but let's wait for Sean his comment. I have used GPS on one wire many years ago. Normally INav configures the GPS module, but it's possible to configure the GPS yourself. So the GPS sends the data INav expects. That way connecting GPS TX to an RX on the FC did work. The GPS needs to be able to store the config you set. Most small GPS modules are unable to store config. It's complicated.

[SeanTheITGuy]

You don't need to hook up GPS RX to anything, unless you want to be able to configure the GPS through serialpassthrough to the e-center software. GPS communication to a FC is entirely one way, and so works with just the GPS TX pin to a RX pin on the FC. (Exactly like communication to something like a non-telemetry IBUS/SBUS receiver)

On Wed, Jul 1, 2020 at 6:02 PM tonyyng notifications@github.com wrote:

I'd expect a GPS would be connected to UART1. RX to TX and TX to RX.

I need to keep UART1 for my FPort receiver. I was trying to understand @SeanTheITGuy https://github.com/SeanTheITGuy 's comment about putting IBUS/SBUS + GPS on one UART. It is a single wire bi-directional connection on TX1.

— 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-652644941, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JCG7FGYQV2WTT5MQBDLTRZOP6FANCNFSM4ODYCGZA .

[tonyyng]

You don't need to hook up GPS RX to anything, unless you want to be able to configure the GPS through serialpassthrough to the e-center software. GPS communication to a FC is entirely one way, and so works with just the GPS TX pin to a RX pin on the FC. (Exactly like communication to something like a non-telemetry IBUS/SBUS receiver)

This wandered way off topic, but just so I understand when this is possible... Can you do this with any UART port or does it require that the firmware has configured the UART to work in this way? Based on your description ("non-telemetry receiver") does it mean it only works if the communication protocol is unidirectional? (as opposed to bidirectional protocols like SPort, FPort and IRC Tramp)

Thanks