Hi guys, I have an LED driver that takes a PWM input signal to control the current/brightness of the LED. My FC is GoKu-HD745-EVO-40A-AIO, and I have a spare UART port. How do I set it up in iNav?

AFAIK iNav does not support resource mapping. (Perhaps I am wrong).

If you have the skills then you may be able to build a custom iNav target and map one of the spare pins on the board but for PWM you will need a pin with a timer such as a motor pad or an LED pad.

In BetaFlight you can resource map a motor pad or an led pad for PWM output such as that used by the Servo Tilt function controlled by an Aux switch on your transmitter.

(25-Jul-2021, 07:29 AM)kafie1980 Wrote: AFAIK iNav does not support resource mapping. (Perhaps I am wrong).

If you have the skills then you may be able to build a custom iNav target and map one of the spare pins on the board but for PWM you will need a pin with a timer such as a motor pad or an LED pad.

In BetaFlight you can resource map a motor pad or an led pad for PWM output such as that used by the Servo Tilt function controlled by an Aux switch on your transmitter.

Thank you kafie1980. As you have said, I should be looking at motor pads that outputs to ESC instead of UART pads. Luckily my FC has 4 spare motor pads (M5-M8). Once I created a servo in the mixer, I was able to generated a PWM signal on one of the motor pads.

However, I noticed that the duty cycle and of the PWM output is bounded by the rate-limiter. iNav capped the MIN /MAX rate to 500/2500 (as shown in the screenshot, if I input a value beyond the limits, the iNav GUI automatically changes it back to the limit). I would like to change the values to 0/3000, is there any workaround or CLI command to do that?

   

Look here:





If you have unused motor signal pads it should work, I think…

JW

(26-Jul-2021, 03:22 PM)leestrong Wrote: Thank you kafie1980. As you have said, I should be looking at motor pads that outputs to ESC instead of UART pads. Luckily my FC has 4 spare motor pads (M5-M8). Once I created a servo in the mixer, I was able to generated a PWM signal on one of the motor pads.

However, I noticed that the duty cycle and of the PWM output is bounded by the rate-limiter. iNav capped the MIN /MAX rate to 500/2500 (as shown in the screenshot, if I input a value beyond the limits, the iNav GUI automatically changes it back to the limit). I would like to change the values to 0/3000, is there any workaround or CLI command to do that?

I am not an expert on iNav and just played very early on when I got into FPV with it. 

However I do not not think you can change those values because that setup is mainly for servos attached to control surfaces. 

In case someone needs more throw they can change the attachment position of the servo push-rod on the control surface. 

Another way is to increase or decrease the Rate % values in a positive or negative directions.

But I am unable to actual test this to give you a solid answer if anything has changed in newer versions of iNav.

(26-Jul-2021, 03:30 PM)lownslow Wrote: Look here:

If you have unused motor signal pads it should work, I think…

JW

Thanks JW, that was exactly the procedure I was looking for and used to generate a PWM signal.

(27-Jul-2021, 02:11 AM)kafie1980 Wrote: I am not an expert on iNav and just played very early on when I got into FPV with it. 

However I do not not think you can change those values because that setup is mainly for servos attached to control surfaces. 

In case someone needs more throw they can change the attachment position of the servo push-rod on the control surface. 

Another way is to increase or decrease the Rate % values in a positive or negative directions.

But I am unable to actual test this to give you a solid answer if anything has changed in newer versions of iNav.

Thanks again kafie1980. You are right that I cannot change the boundaries as an user. The rate % can increase the slope of input/output relationship, but it only meant that the boundaries will be hit at a lower stick position.

I dug through iNav's code and found that the servo's absolute output boundaries are defined in servo.h



Sending a cli command can change a servo's config (e.g. "servo <ID> <MIN> <MAX> <MIDDLE> <RATE>"), however command parser checks to ensure the parameters are within the SERVO_OUTPUT_MIN/SERVO_OUTPUT_MAX boundary, or the command will be dropped.



The only way to bypass this check is to 1) compile my own iNav, or 2) modify an existing firmware binary file. I went for option 2), decompiled the .hex file and modified the values, now I can successfully issue a command "servo 1 0 3000 1500 100" and generate a PWM signal with duty cycle 0-100%.

So thank you my friends, that is about it, all in all a fruitful journey.

Compiling a custom iNav target firmware is pretty straight forward and I did it a couple of days ago for an FC officially unsupported by iNav to test something Betaflight did not let me do (cutting the story short here).

I did it on Windows 10 with Linux subsystem: Ubuntu LTS. Pretty straight forward and it is well documented here: https://github.com/iNavFlight/inav/blob/...bsystem.md

But if you are confident making edits to hex files then you should be golden

I must admit that editing Hex file is a temporary and dirty trick, and compiling a custom iNav target is the proper way.
My FC is not officially listed in the iNav repository yet, Flywoo is providing custom HEX files for iNav3.0.0 on their website.

From what I have gathered so far, in order to build my own iNav target, I must obtain the board specific target.h and target.c source files, are these 2 files all I need? Anything else I should pay attention to when building a custom target?

(27-Jul-2021, 03:52 PM)leestrong Wrote: From what I have gathered so far, in order to build my own iNav target, I must obtain the board specific target.h and target.c source files, are these 2 files all I need? Anything else I should pay attention to when building a custom target?

No. That is all you need.

I hope the info below is clearer than mud

Actually if the target for that FC exists in Betaflight then half your work is done: https://github.com/betaflight/unified-ta...gs/default

Based on the Betaflight target specific files in the above link, you can easily create your target.h configuration (the most important thing in this file is to have the pin assignments defined).

Please note that Betaflight will list the pins e.g. A01 while iNav will refer to it as PA1 (every pin has a P and take off the zeros).

You will need to create a new target folder in iNav (locally on your machine but I am giving an example of github path) in https://github.com/iNavFlight/inav/tree/...ain/target and create the following files there:
- CMakeLists.txt
- target.c
- target.h

If you are doing this for the first time then the best thing to do is to choose a board that both iNav and Betaflight support (e.g. Matek F722) and compare the definitions. Or choose an FC that is the most similar to yours with the same STM chip.

If you can decompile the hex and get the target.h and target.c then you have a shortcut there that makes all of this much much easier.

(27-Jul-2021, 04:10 PM)SnowLeopardFPV Wrote: No. That is all you need.

Thank you SnowLeopardFPV  you're my favorite FPV superhero.

(28-Jul-2021, 12:28 AM)kafie1980 Wrote: I hope the info below is clearer than mud

Actually if the target for that FC exists in Betaflight then half your work is done: https://github.com/betaflight/unified-ta...gs/default

Based on the Betaflight target specific files in the above link, you can easily create your target.h configuration (the most important thing in this file is to have the pin assignments defined).

Please note that Betaflight will list the pins e.g. A01 while iNav will refer to it as PA1 (every pin has a P and take off the zeros).

You will need to create a new target folder in iNav (locally on your machine but I am giving an example of github path) in https://github.com/iNavFlight/inav/tree/...ain/target and create the following files there:
- CMakeLists.txt
- target.c
- target.h

If you are doing this for the first time then the best thing to do is to choose a board that both iNav and Betaflight support (e.g. Matek F722) and compare the definitions. Or choose an FC that is the most similar to yours with the same STM chip.

If you can decompile the hex and get the target.h and target.c then you have a shortcut there that makes all of this much much easier.

This is clearer than crystal and is such a great idea, this way any Betaflight compatible FC can be ported to iNav. 

About working backwards from decompiled iNav codes, I imagine it would be harder than working forward with the Betaflight source.

I was using Ghidra for the disassembling and decompilation. The result is one giant C spaghetti mess that looked nothing like the original source code. A lot of useful information is impossible to restore (e.g. source file/directory structures, function names, variable names, structs, etc), all one can work with are pointer addresses, and arbitrarily assigned variable/function names. and due to compiler-optimization, even the control flow can be quite different from the original source.

Actually I got lucky when trying to modify the HEX. From iNav source code I noticed that the instruction I needed to modify is in close proximity to a call of the printServo() function, in which there defines a string constant - ""servo %u %d %d %d %d"" that can be easily searched for. Once I located the address of printServo() function, I worked backwards to find all calls to that address and eventually lead to the instruction that I was looking for.

-------------
I have a confession to make, it was a mistake saying that my FC is not officially listed in iNav repository. Actually it is (FLYWOOF745), and I was confusing it with another target - FLYWOOF745HD (Flywoo technical support said that it is only used for some special editions). Forgive me....

(28-Jul-2021, 10:51 PM)leestrong Wrote: I have a confession to make, it was a mistake saying that my FC is not officially listed in iNav repository. Actually it is (FLYWOOF745), and I was confusing it with another target - FLYWOOF745HD (Flywoo technical support said that it is only used for some special editions). Forgive me....

You do not need to be apologetic. We all overlook stuff every now and then. Everything we say or do is to the best of our knowledge which has its boundaries defined by what we know/understand or assume to know/understand.