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

[SeanTheITGuy]

You can break a single UART into two RX pins, using softserial, if that's what you're asking. If you have two unidirectional devices (say a flysky receiver and a GPS) you can get them to talk on the TX/RX pins of a UART, keeping in mind that one of them will be using software serial which introduces more overhead to the MCU and is slower and less reliable, so don't put something like the receiver on the software serial pin.

If you have something bidirectional, like a CRSF receiver, then you need both pins of a UART to facilitate communication between the FC and the device.

This is true in BF as well as INAV, but in BF, resource allocation is considerably simpler.

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

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

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

[tonyyng]

Thanks Sean.

My original request on this thread was for SoftSerial support. If I need FPort (bidirectional), GPS (could be unidirectional), and IRC Tramp (bidirectional), I don't think that SoftSerial on TX2 will help me. It might be useful for the scenario you described, but making it available on another pad (LED, Buzzer, etc), would be useful in other configurations.

[SeanTheITGuy]

Is IRCTramp bidirectional? I'm pretty sure I've used it with a single wire before. I don't have any VTXs that support it at the moment, just SmartAudio.

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

Thanks Sean.

My original request on this thread was for SoftSerial support. If I need FPort (bidirectional), GPS (could be unidirectional), and IRC Tramp (bidirectional), I don't think that SoftSerial on TX2 will help me. It might be useful for the scenario you described, but making it available on another pad (LED, Buzzer, etc), would be useful in other configurations.

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

[tonyyng]

This page says it is: https://fpvsampa.com/smartaudio-tramp/ The current VTX channel/band/power/temp values are displayed in the OSD. I'm guessing that the settings are retrieved from the VTX for that purpose.

[SeanTheITGuy]

oh, correct.. they're both half-duplex bidirectional, so they work on a single wire. You can do that on a single softserial pin.

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

This page says it is: https://fpvsampa.com/smartaudio-tramp/ The current VTX channel/band/power/temp values are displayed in the OSD. I'm guessing that the settings are retrieved from the VTX for that purpose.

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

[tonyyng]

That's why I'm hoping for a softserial pin that doesn't interfere with either of the two uarts. They are spoken for by FPort and GPS. IRCTramp will work fine on a less reliable softserial connection.

[SeanTheITGuy]

Ah, I got you. Try this hex. PA15 (LED_STRIP) has been repurposed to SoftSerial1TX. You will have to enable Software serial and DISABLE ws2812 led support, otherwise there will be all kinds of shenanigans.

https://drive.google.com/file/d/1Ho-J6Z1b83N2Hd4pGzfrvKqsZRVb3A9e/view?usp=sharing

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

That's why I'm hoping for a softserial pin that doesn't interfere with either of the two uarts. They are spoken for by FPort and GPS. IRCTramp will work fine on a less reliable softserial connection.

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

[tonyyng]

Sorry. My FC board is still on its way. I'm just lobbying for the SoftSerial support I'll need. :-)

[SeanTheITGuy]

I gotcha. Well, it's pretty easy to add to a custom compile. I suspect it's not something that gets a lot of demand simply because how this one was by default, with the UART splitting, is exactly how the NOX target was set up, as well. However, I have no problem compiling you a one-off when the time comes. Feel free to msg me here and I'll drop you a link to a hex of whatever is the latest at the time.

[tonyyng]

I'm semi proficient at programming. Could you send me the changes that are needed from the stock version? I'll learn something from it and be able to help myself in the future.

[SeanTheITGuy]

In inav/src/main/target/FLYWOOF411/target.h, in the section:

define USE_SOFTSERIAL1

define SOFTSERIAL_1_TX_PIN PA15

define SOFTSERIAL_1_RX_PIN NONE

define your TX/RX pins to be whatever you want. recompile. flash.

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

I'm semi proficient at programming. Could you send me the changes that are needed from the stock version? I'll learn something from it and be able to help myself in the future.

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

[mooiweertje]

You don't need to hook up GPS RX to anything

At startup iNav configures the GPS to optimize performance to be used for airborne vehicles. For that initialization process both RX and TX are used. By default the GPS is optimized by itself for a pedestrian. For instance max speed is 109Km/h and 9600baud. What I used to do is connect FC with running GPS to PC by USB. Wait until the GPS is properly configured by iNav. Connect e-center through the same USB connection and serialpassthrough. Then save the config to PC with e-center and store the config to the non-volatile memory of the GPS to let it have the iNav config by default. After that only the GPS-TX and FC-RX need to be connected. But most small GPS modules do not have the non-volatile memory anymore. The Beitian BN-880 has non-volatile memory but the BN-220 does not. Having such a small FC with a huge GPS like the BN-880 doesn't make much sense to me. I use the BN-180 with volatile memory. The pedestrian config is fine for a slow copter with very precise RTH, but for a racequad or plane it sucks.

[moggiex]

FYI. Both the standard and Deluxe boards are on their way to @digitalentity

[mooiweertje]

How is testing on this build going?

[snaewe]

Still only 1 motor + 3 servos. Oh, and the OSD is not working (confirmed by @moggiex, works with betaflight 4.2.x for me)

[mooiweertje]

settings are the same as BF. you could try playing around a bit with:

define MAX7456_SPI_CLK (SPI_CLOCK_STANDARD*2)

define MAX7456_RESTORE_CLK (SPI_CLOCK_FAST)

[snaewe]

I think I did that already. Will check again soon.

[mooiweertje]

Sorry I don't have analog FPV anymore so I can't help debugging. 1 motor and 3 servo's is probably good to go forward with.

[snaewe]

OSD is working now. Must have done something wrong. OLED works also.

[mooiweertje]

Super. If you give me push permission I can push my above suggested code cleanup branch and you can take along the things you like in your release.

[tonyyng]

Is this in the current code?:

#define USE_SOFTSERIAL1
#define SOFTSERIAL_1_TX_PIN      PA2 // Workaround for softserial not initializing with only RX
#define SOFTSERIAL_1_RX_PIN      PA2 // Backdoor timer on UART2_TX, used for ESC telemetry

Is Softserial still on TX2? Unless I've misunderstood the explanation for this, there aren't many situations where this is useful. Wouldn't it be better to define it on a pad that you don't lose one of the UARTs?

@SeanTheITGuy pointed out that this was how the older NOX target was setup as well, but it seems to me that including this "split UART" is just carrying forward a workaround from an older board.

[mooiweertje]

@SeanTheITGuy pointed out that this was how the older NOX target was setup as well, but it seems to me that including this "split UART" is just carrying forward a workaround from an older board.

Yes I copied those lines blindly from the Betaflight implementation to be compliant.

[tonyyng]

@SeanTheITGuy pointed out that this was how the older NOX target was setup as well, but it seems to me that including this "split UART" is just carrying forward a workaround from an older board.

Yes I copied those lines blindly from the Betaflight implementation to be compliant.

I don't understand what it needs to be compliant with.

Could you throw this approach into NOX_SS_TX2 and Sean's approach into NOX_SS_LED?

[mooiweertje]

Yes I copied those lines blindly from the Betaflight implementation to be compliant.

I don't understand what it needs to be compliant with.

The Betaflight implemtation of FLYWOOF411 does't have those lines either so I also don't understand why they are included here from the NOX implementation.

Could you throw this approach into NOX_SS_TX2 and Sean's approach into NOX_SS_LED?

Just adding #define SOFTSERIAL_1_TX_PIN = xx will do I think? This is FLYWOOF411 not a NOX anymore.

[tonyyng]

I'm confused. I thought you said you copied those lines.

[mooiweertje]

I'm confused. I thought you said you copied those lines.

Yes when I made the old NOX implementation. I agree they don't belong here, unless they actually solve something off course.

[snaewe]

I will try to get only the most basic things to be merged first (which won't happen if I understand the process correctly!). After that all "special wishes" might get added later as variants.

[mooiweertje]

Softserial on TX is pretty basic for receivers isn't it? I don't use telemetry but most pilots do.

[tonyyng]

I use an Frsky RXSR receiver with telemetry (FPORT) on a standard UART. With FPort and SPort receivers, they are connected with one signal wire to the TX pin. I was under the impression that you should avoid using SoftSerial for the receiver since performance might not be sufficient for this purpose.

[mooiweertje]

Why don't you test it? I think this F4 won't have any problem with performance.

[tonyyng]

My new nox board is on its way. I've used softserial with the old nox board, but connected to ppm with help from PachisPachis on this thread: https://github.com/iNavFlight/inav/issues/5334

I was hoping that the SoftSerial support for this board would work without needed to do a custom firmware build and would be implemented by folks who understand the code better than me. :-)

This page talks about SoftSerial on Betaflight and says: Duty cycle limitation – Softserial is not suitable for high duty cycle and “chatty” applications that occupy too much processor time like OSD and serial RX

I don't know if the same comment applies to iNav, but I would think a software emulated serial port wouldn't perform as well as a standard serial port.

[mooiweertje]

Letting the F4 do soft-serial leaves less time for other stuff, So if your setup is already running on 90% load, soft-serial may be the drop to overload it. In that case you could try lowering the pid loop frequency so the CPU has time for the soft-serial.. Etc. etc.. You can also try to make the F4 run windows in the background but that's just a matter of taste, but when it works, it works. P.S. Soft-serial isn't doing anything until it's turned on in configurator.

[mooiweertje]

@snaewe If you need a good compare and merge tool, trail this: https://www.araxis.com/merge/

[snaewe]

• PPM in on TX2 works
• GPS on UART2 works
• SBus in on SBUS pin + S.Port telemetry on SoftSerial TX2 works

Latest code in https://github.com/snaewe/inav/tree/add-FLYWOOF411 (i.e. on branch 'add-FLYWOOF411'), based on branch 'release_2.5.1' to be able to use inav configurator 2.5

[snaewe]

One more small change (LED pin is PA15) and the LED-Strip is working now!

[snaewe]

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.

[schnupperm]

thank you for the test version. I found one problem: It is not possible to select any DSHOT esc protocol. After rebooting it reverts to STANDARD.

[SeanTheITGuy]

Correct. Just as the original NOX FC, it does not support DSHOT under INAV. It is a limitation of the platform under INAV.

On Thu, Jul 9, 2020 at 2:28 PM schnupperm notifications@github.com wrote:

thank you for the test version. I found one problem: It is not possible to select any DSHOT esc protocol. After rebooting it reverts to STANDARD.

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

[snaewe]

Well...if you don't #define USE_DSHOT, you don't get DSHOT....

Fixed, tested and pushed to branches add-FLYWOOF411 (based on current master 0bf0e4b4) and add-FLYWOOF411-2.5.1 (based on release_2.5.1)

I can do a test release if anyone wants it.

@schnupperm @SeanTheITGuy

[SeanTheITGuy]

Give it a try. The results are... Unpredictable.

On Fri., Jul. 10, 2020, 4:20 a.m. Stefan Naewe, notifications@github.com wrote:

Well...if you don't #define USE_DSHOT, you don't get DSHOT....

Fixed, tested and pushed to branches add-FLYWOOF411 (based on current master 0bf0e4b https://github.com/iNavFlight/inav/commit/0bf0e4b43a29ad277b988f5cf3e641ec3f187ed7) and add-FLYWOOF411-2.5.1 (based on release_2.5.1)

I can do a test release if anyone wants it.

@schnupperm https://github.com/schnupperm @SeanTheITGuy https://github.com/SeanTheITGuy

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

[snaewe]

Could you be a little bit more specific @SeanTheITGuy ?

The motor spins at least...

[SeanTheITGuy]

In my experience the board tends to lock up when you start fiddling the motor outputs with dshot enabled. I think something to do with how DMA streams work vs how beta flight does it means it won't work in this hardware in inav.

On Fri., Jul. 10, 2020, 6:31 a.m. Stefan Naewe, notifications@github.com wrote:

Could you be a little bit more specific @SeanTheITGuy https://github.com/SeanTheITGuy ?

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

[schnupperm]

@snaewe I have the quad with the NOXE v1 FC ready. If you like I can test the DSHOT version.

[schnupperm]

one other question: is the "Cam-C" pin inside of SBUS usable for soft serial 1 for vtx control?

[schnupperm]

something is not right, using:

git clone https://github.com/snaewe/inav.git git checkout add-FLYWOOF411-2.5.1 make TARGET=FLYWOOF411

• when I use DSHOT, motor 3 is constantly resetting (ESC arm beeps)
• when I use ONESHOT42 motor 2 does not spin up until it gets 30-40% throttle

config diff: noxeV2.5.1.txt

just checked: in BF-4.2.0 with DSHOT600 all motors are working ok

[SeanTheITGuy]

Yes. That is what happens. That's why the target doesn't support dshot. :)

On Tue., Jul. 14, 2020, 5:50 a.m. schnupperm, notifications@github.com wrote:

something is not right:

• when I use DSHOT, motor 3 is constantly resetting (ESC arm beeps)
• when I use ONESHOT42 motor 2 does not spin up until it gets 30-40% throttle

config diff: noxeV2.5.1.txt https://github.com/iNavFlight/inav/files/4917648/noxeV2.5.1.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-658057891, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4JCG4BGWCIMIQZXZGSNN3R3QL5NANCNFSM4ODYCGZA .

[schnupperm]

maybe, but the version without dshot has problems with motor 2.

[mooiweertje]

What about DSHOT150, DSHOT300, ONESHOT125, PWM, etc?

[schnupperm]

all DSHOTs behave in the same way. PWM and ONESHOT also. One interesting observation: With DSHOT and using the motor tab in the configurator, motor 3 works as log as I am using the master slider. It breaks down when using the single control for motor 3.

[mooiweertje]

So PWM doesn't work either?