Inav: 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 [email protected] 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 ?)

[mooiweertje]

I cloned the add-FLYWOOF411 repo but wasn't able to find the FLYWOOF411 target.
I've been working on a FLYWOOF411 target which builds and installs but doesn't run yet.

@snaewe yes

[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

[mooiweertje]

Looking good. I will walk through your changes and comment here.
I did notice at first glance you have only one TIM_USE_FW_MOTOR in target.c but there should be 2.
You can add your target to the target list in make/targets.mk.
Add a document docs/Board-FlyWooF411.md

@moggiex Probably snaewe tested a lot already but all IO needs testing. Flight functionality will work normal. Change is mainly about the CPU communicating through which pins to what peripherals. UART, ESC, servo, BARO etc etc. So all peripherals need testing, simply work or not work.

@digitalentity This change is looking good to my opinion and needs maybe minor ajustments and documentation. Is there a chance this change can go with 2.5.x in the near future?
@snaewe is there anything blocking your progress I could lend you a hand?

[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.

[mooiweertje]

It's just how INAV works with two motors on FixedWing. You can use only one of course but the mapping in target.c should have 2. The user can choose what he likes in the mixer tab in configurator.

It seems everything is working,
I2C is working since the BARO works.

Maybe you can send a list of things to test like OSD, etc to matt. Will save you some work.

[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 ;)

[mooiweertje]

P.S.
It's not the big thing you assume it to be now. I'm not a core iNav developer but just a developer that likes this board for it's obvious reasons, small, 2 UARTS, BARO, cheap, etc. I'm just trying to conform to standards to quickly release without fuss. I am using 4 of the old boards and have 2 of these new boards I want to use soon. I didn't realize either this new Noxe v1 is so different than the old Noxe v0.
I don't know why 2 motors is default for FixedWing in the confiigurator mixer tab. Maybe you can create a separate RFC for the two motor default for FW in the mixer tab in configurator but if you make it part of this change it may slow down release.

[mooiweertje]

This is the mapping of an AIRBOTF4. Mark the OR symbol '|' between the TIM_USE_** stuff.
S1 and S2 can do either MultiCopter motor or FixedWing motor. Quad or plane basicly. S3 and S4 Can be MultiCopter motor or FixedWing servo. This is the mapping that is the coding standard as it seems and complies with the defaults in the configurator mixer tab. When I configured S2 of an AIRBOTF4 to drive a servo in the mixertab in configurator it did so without any issues.
DEF_TIM(TIM3, CH3, PB0, TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR, 0, 0), // S1_OUT D1_ST7
DEF_TIM(TIM3, CH4, PB1, TIM_USE_MC_MOTOR | TIM_USE_FW_MOTOR, 0, 0), // S2_OUT D1_ST2
DEF_TIM(TIM2, CH4, PA3, TIM_USE_MC_MOTOR | TIM_USE_FW_SERVO, 0, 1), // S3_OUT D1_ST6
DEF_TIM(TIM2, CH3, PA2, TIM_USE_MC_MOTOR | TIM_USE_FW_SERVO, 0, 0), // S4_OUT D1_ST1
DEF_TIM(TIM5, CH2, PA1, TIM_USE_MC_MOTOR | TIM_USE_MC_SERVO | TIM_USE_FW_SERVO | TIM_USE_ANY, 0, 0), // S5_OUT / LED
DEF_TIM(TIM1, CH1, PA8, TIM_USE_MC_MOTOR | TIM_USE_MC_SERVO | TIM_USE_FW_SERVO, 0, 0), // S6_OUT

[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

[mooiweertje]

I've compiled and installed a version with this mapping. It seems to work fine. But I just have the board connected with USB without any servos or motors connected.
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

[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.

[mooiweertje]

inav_2.5.0_FLYWOOF411.hex.zip

[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, [e-mail]
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
.

[mooiweertje]

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. All my current FW's are with 2 servo's which I like best.

[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 [e-mail] 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 [e-mail]
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 [e-mail] 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 [e-mail] 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

[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 [e-mail] 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 [e-mail] 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 [e-mail] 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 [e-mail] 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 [e-mail] 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 [e-mail] 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, [e-mail]
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, [e-mail]
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, [e-mail]
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?

[schnupperm]

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

[schnupperm]

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

[mooiweertje]

And DSHOT150?

[schnupperm]

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

[snaewe]

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

[schnupperm]

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]

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 [e-mail]:

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]

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]

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]

@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]

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

[pauluzs]

Tnx @Fraggs150

[mooiweertje]

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 [e-mail]:

@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
.