Erls 1000hz presets about firmware-presets HOT 6 CLOSED

For anyone curious: The change came with #362 and is not labelled with ExpressLRS

from firmware-presets.

For anyone curious: The change came with #362 and is not labelled with ExpressLRS

Yeah we made a basic 1000hz preset. It’s found in all my karate presets now

from firmware-presets.

so ive sill not managed to get it to upload even after changing the name so ive had to upload it to we transfer if you visit this link you will get the download hopefully this helps many thanks in advance for all your help and hard work
link https://we.tl/t-XDH1uE2S5X

from firmware-presets.

so ive sill not managed to get it to upload even after changing the name so ive had to upload it to we transfer if you visit this link you will get the download hopefully this helps many thanks in advance for all your help and hard work link https://we.tl/t-XDH1uE2S5X

@sugaarK

from firmware-presets.

To accurately analyse smoothing of something that steps at 1,000hz requires that we sample quite a lot faster. This log was at 2kHz, and that leads to aliasing artefacts. Could I suggest disabling as many logging items as possible, and logging at the full 8k? All we need is RC command, set point, and feedforward.

Also, this log looks like it was in level mode, which messes with setpoint. Do it on the bench in acro mode. Set the expo to 0. You don't need to spin the motors for the test, nor do you need a lipo or for the motors to spin - you can disable DShot Telemetry and enable the motors in the motors tab, arm and wiggle the sticks on the bench.

Also it's best to test on the bench top with zero expo so that the setpoint and RC command curves overlap in the log, with full stick travel inputs.

Using the log we have, it looks like the RC smoothing value is OK. It is set to 25, resulting in a PT3 cutoff at 430Hz.
This image shows the smoothing looks OK, but there is sampling aliasing, and the precision of the measurement of setpoint is a bit limiting. If the log has high-resolution setpoint it is better. We expect steps in RC command, but setpoint should be smooth. Overall, setpoint smoothing is sufficient. In part this is because at such a high link speed, the amount of change from one step to the next is always going to be small, so the smoothing requirement isn't massive since the size of any steps is small to start with.

Feedforward is an entirely different situation. There is quite a lot of variability in feedforward. This is because the resolution of the RC signal is not so great, especially when the sticks are not moving super fast. There is a limit to how accurately the change in position can be measured, from packet to packet, at such high rates.

This image shows feedforward, P and RC command all at the same scale factor.
Note that there is quite a lot more noise on feedforward than on P itself (and P carries gyro noise and setpoint noise).
The noise on FF is quite spiky; those spikes align with steps in the RC Command signal

Clearly this setup needs stronger feedforward smoothing than the 430hz given with auto smoothing of 25.

Could I suggest making another log at 4kHz, disabling as much other unnecessary stuff from the log, and trying a manual setpoint value of 400 and a manual feedforward value of 200, and then make a second log with the manual feedforward value of 100?

from firmware-presets.

Racing preset for 1000Hz was created and merged. Thanks to @ctzsnooze and @sugaarK

from firmware-presets.