Sequencer functions oXs RP2040

[Satcomix]

Hello Mstrens, I have read the instructions several times now, but I have some questions about how the sequencer works. e.g. SEQ={3 0 100 15 -100 -100 +90} 1.Which PWM signal 1000us to 2000us triggers the sequence on GPio 15 to control a servo on channel 3.

2. 100ms clock for what? An analog servo is normally controlled at 50Hz 20ms, digital at 333Hz. 3.PWM = -100 (default), -100 (min) and 90(max) what are these values ​​for? Does the first -100(default) mean that the function is triggered at 1000us? I have already described in the RCG how I would like to trigger the sequences. With my FrSky X20S and the touch display which is controlled by a LUA script. This script creates 24 different PWM values on one RC channel, which are only generated once for 50ms to 150ms(normally, but i can set the time) when a button is pressed. best regards, Torsten

[Satcomix]

Good morning Mstrens, After I familiarized myself with the new commands, the first commands with buttons 1/6 to 3/8 work. SEQ= [6 0 20 3 -100 -100 100] (50 P) {0 -100 255} (100 R O) {0 100 255}

[7 0 20 3 -100 -100 100] (40 P) {0 -100 10} (90 R O) {0 50 3} {10 100 2}

[8 1 500 3 0 0 100 ] (30 P) {0 0 255} (80 R) {0 100 255} Buttons 1/6 and 2/7 each drive a servo, Button2/7 with Servo-sequence, and buttons 3/8 switch an LED on and off. I will now do further tests with version 2.8.29 and check the new button priority. Greeting, Torsten

[mstrens]

I hope that the options R U O P (on as well off ) work as expected but did not tested it myself.

[Satcomix]

Hello Mstrens, As far as I could test everything, the P R U O commands work. For U and P, U first runs the sequence to the end and then switches to sequence P. With O and P, O runs the sequence and immediately switches to P and runs it. Greetings, Torsten

[Satcomix]

Hello Mstrens, I think with the new commands things are going much better than before. Previously, you could simply switch to another step in the middle of a step while executing a sequence, which was a security risk for me. Of course it now also works with P and O. With the new commands P and U, when executing a sequence, the step is only changed when the previous one has been processed to the end and then the next step is only processed. For me, this function is the safest. Of course you can also link the commands P, U, O with each other during a sequence. Thank you for that work. Greetings, Torsten

[mstrens]

Please note that in a sequencer you can have e.g sequence 1 with U P sequence 2 with O sequence 3 with P sequence 4 with no option sequence 5 with no option. Then Sequence 1 will never be interrupted Sequence 2 may be interrupted but only by 1 or 3 Sequence 3, 4, 5 may be interrupted by 1,2,3, 4,5

So, when an sequence does not have U or O, it may be interrupted by any sequence (including it self). Note: A sequence with O+P may be also interrupted by itself

I also hope that the new way to enter the sequencer parameters is easier to understand (all in one command)

[Satcomix]

Hello Mstrens, I had to think about it this morning, but once you've tried it out, it's now easier than before with Sequence and Step. You just have to think carefully beforehand about which function is important and should be prioritized over others. For normal function I would always prefer U and P. For a kill switch, the setting is O and P

[Satcomix]

Hello Martens, I do some tests with the sequencer and my LUA app. I use button1 and 6 for the first servo function, button2 and 7 for the second servo function, button3 and 8 for the LED control. At button2 and 7 the servo is default in the middle position =0%. If I press button2 the servo moves to 100% and back to 0%. If I press button 7, the servo moves to -100% and back to center position = 0%. Why can't I press Button2 or Button7 twice? I can only press button2 and then button7 alternately. I change the settings but it was unsuccessful. Greetings, Torsten

SEQ= [6 0 20 3 -100 -100 100] (50 P) {0 -100 0} (100 O) {0 100 0} [7 0 20 3 0 -100 100] (40) {50 -100 0} {50 0 0} (90) {50 100 0} {50 0 0} [8 1 50 3 0 0 100] (30 P) {0 0 20}
(80 R O) {0 100 1} {0 0 1} {0 100 1} {0 0 1} {0 100 1} {0 0 1} {10 100 10} {10 0 10}

[mstrens]

I suppose you are referring to this setting: [7 0 20 3 0 -100 100] (40) {50 -100 0} {50 0 0} (90) {50 100 0} {50 0 0} it is expected that pressing the same button twice should just work as if you would have press 2 different buttons (if the Rc channel values goes to another value in the meantime - this other value can e.g. be the 0% = 1500us). If it is not so, it means that there is still a bug.

[Satcomix]

I proofe it twice, no way to push a button for one way twice. [7 0 20 3 0 -100 100] (40) {50 -100 0} {50 0 0} (90) {50 100 0} {50 0 0} I want to move from 0% to 100% and back, and 0% to -100% and back. I can`t drive the servo, from 0% to 100% or -100% and back to 0% twice.

[mstrens]

I put version 2.8.33. I hope it allow you to restart the same sequence without activating another one.

[Satcomix]

Hello Mstrens, Ver.2.8.33 It works! Now i can push the button for function twice. Thank you. Greetings, Torsten

[mstrens]

Fine. I started to work to implement use of RTC (real time clock) in the logger. I think you challenger board has such a RTC. I put on github a version 0.0.6 of logger that is supposed to discover the type of RTC chip automatically and read twice the timestamp at startup. I do not yet has a command to set the timestamp in the RTC nor use it when a file is created.

When you have time can you just test if it discover the RTC and print 2X a time. Best would also be to open a new issue about RTC

[Satcomix]

Hello Mstrens, I really enjoy testing. :-)) For the RTC function on the Challenger RP2040 SD/RTC, I think I still have to connect a socket and the 3V battery. I have to look at the datasheet again. I wouldn't be able to carry out the first tests until Wednesday because I'll be busy until then. I will open an RTC function issue. greetings, Torsten

[mstrens]

For first test, I think it is not mandatory to add a backup battery. I presume that without battery, the date adn time will be lost at each power down but still, it should be possible to test:

• reading the RTC
• uploading a date and time into the RTC. I put a new version 0.0.7 that should allow you to
• fill in the SDA and GPI pin
• see if RTC is detected at power on and is running (with the ENTER command)
• update the date and time using a SD command. At this stage, I do not yet use the RTC to update the log file creation timestamp.

[Satcomix]

Hello Mstrens, I will begin the tests with 0.0.7 of RTC tomorow morning. For normal use or test you dont need the backup bat. I looked at the datasheet for the I2C1 Gpio of the RTC Chip. Greetings, Torsten

[Satcomix]

Hello Mstrens, I still have a questions about the sequencer. The sequencer is controlled from the SBUS, the RC channels must be 1 to 16/GPio 0 to 15, or I could also select 1-12 and 22-24 if I changed these in param.cpp and config.h. Background: The PimoroniServo2040 has a multiplexer 74LV4051BQ on board, which is connected via GPio22/Addr0 GPio24/Addr1 GPio25/Addr2 is controlled in order to measure, among other things, the voltage and current from the board itself, as well as has 6 additional measuring inputs that are led out via a SharedADC port (GPio29). Best regards, Torsten

[mstrens]

Sequencer can be controlled by Sbus or by any protocol. It only requires that oXs get the RC channels. A sequencer generates a PWM signal. RP2040 has 16 (8X2) hardware components to generate PWM signals. On the 16 components, there are 14 where it is possible to select one (and only one) alternative gpio.
E.g PWM generated on gpio0 can also be generated but only on gpio 16; gpio 1 on gpio 17, .. gpio 13 on gpio 29 Still PWM on gpio 14 and 15 have no alternative. So if you want 16 PWM you must at least use gpio 14 and 15. Using those 14 alternatives, would require a lot of additional parameters and in theory of usb commands. That is the reason why I did not offer this possibility.

[Satcomix]

I somewhat know the structure of the RP2040. I just wanted to know if I can move the GPio with a simple change in config.h and param.cpp. E.g. I need the GPio 22,24,25 to control the multiplexer, and I thought to myself that since the sequencer can switch H and L (Servo0/Analog1), I would simply use my LUA to switch the ports of the 74LV4051 via the sequencer.

3A = PWM 6 3A = PWM 22,

3B = PWM 7 3B = PWM 23,

4A = PWM 8 4A = PWM 24,

4B = PWM 9 4B = PWM 25,

[mstrens]

You can try the following (compiling your self). In param.cpp there is if (tempIntTable[0] < 0 || tempIntTable[0] > 15){ printf("Error : for sequencer number %i, gpio must be in range 0 / 15\n", seqIdx+1); return false; }

You can try changing "15" by "29" Just take care to avoid defining 2 different sequencers with 2 pins using the same PWM channel. Also do not the the alternative pin for a RC PWM channel output. E.g. if you use 21 for a sequencer, do not use 4 for a PWM rc channel

I expect it should work but as usual only a test will confirm it.

[Satcomix]

Hello Mstrens, Thank you for the feedback. I meant the lines in param.cpp. Replace everything that is 15(GPio0-15 not CH1-16) with 29, but be careful not to have double occupancy (3A/3A...). I have created an oXs build many times because I always had to change the I2C0 and I2C1 and, until yesterday, always the GPio for the RGB LED itself. :-)) Greetings, Torsten

[Satcomix]

Hello Mstrens, I suddenly have a problem creating a build. I did everything as usual. oXs-test copied to my folder. CMake opened, dependencies are checked, Existing configuration made again without changes in oXs.elf build. Copied new build to board, board logs off and on/reboots every 15 seconds. I have no idea what that means. Maybe you have an idea.

[mstrens]

Does the board restarts with the uf2 provided in github? I presume you already tried a clean upload (erase totally the flash memory)

In Vscode, did you tried to press CTRL+SHIFT+P and then Enter cmake : configure execute this command Then CTRL+SHIFT+P again Enter cmake : build execute the command.

[Satcomix]

Hello MStrens, I also have the same problem when I install Alain's new oXs_Gyro. It only works perfectly with the original oXs from here. Now i will try your suggestions with VSCode/CMake

[Satcomix]

Always the same error, reboot after 15sec.

[build] Error copying file "oXs.uf2" to "E:". [build] ninja: build stopped: subcommand failed. [driver] Build abgeschlossen: 00:00:01.593 [build] Der Build wurde mit dem Exitcode 1 abgeschlossen.

[mstrens]

The error copying file "oXs.uf2" to "E:" is not a real problem. When this occurs, the compilation is done and it it is only the copy to RP2040 that does not work. So the uf2 is already created and can be copied manually. Did you try to clear all flash memory before copying your uf2 (not sure it will make a difference as you can upload my uf2)

[Satcomix]

Normally I didn't have to NUKE when copying the oXs.uf2 from the build folder to the RP2040.

[Satcomix]

After a NUKE it works. Very strange, I play an unchanged .uf2 on the RP2040 and reboot every 15 seconds. There's still something hanging there somewhere. I will find it :-))

[Satcomix]

Hello Mstrens, For your information: After I reinstalled Pico SDK and VSCode, everything is working as it should, at least for now. I have created several builds with version 2.8.40 (pitch and roll enabled), all of which are running so far Last week there was a major Windows 10 update. I assume it was related and something was missing in VSCode since then. Greetings, Torsten

[Satcomix]

Hello Mstrens, I just tried to create my own build of version 2.9.2. In the Config.h I only integrated the camera stabilizer. After I created the build next to oXs.elf and copied it to the RP2040 board, I keep getting a REBOOT all the time. The board was nuked before. What I noticed after I enter cmake:configure is the PICO SDK version. After I reinstalled everything a few days ago, Pico SDK 1.5.1 was installed. After I integrated version 2.9.2 I only see Pico SDK 1.5.0. Maybe it has something to do with that. I've already done so many builds successfully, why is it suddenly not working with the newer oXs versions? Do you have another tip? greetings, Torsten

[mstrens]

The issue is perhaps indeed related to pico sdk version. When I compile 2.9.2 on my laptop I see that it uses SDK 1.5.0 At this stage, I do not know how the compiler makes the difference between 1.5.1 and 1.5.0

[mstrens]

On my pc, the sdk is here (at least it is the location used when I compile) "C:\Program Files\Raspberry Pi\Pico SDK v1.5.0

[Satcomix]

If I copy a new -test version into my environment and then run cmake : configure the .vscode and build folders are created. If I now create a build without making any changes and copy it to the board, I only get REBOOT. I'm starting to not know what to do anymore. I will completely delete/uninstall VSCode again and then reinstall it. Greetings, Torsten

[mstrens]

In the build folder I see a folder generated/pico_base/pico with a file config_autogen.h. It contains : // AUTOGENERATED FROM PICO_CONFIG_HEADERFILES and then PICO_CONFIG_HEADER_FILES // DO NOT EDIT!

// based on PICO_CONFIG_HEADER_FILES:

include "C:/Program Files/Raspberry Pi/Pico SDK v1.5.0/pico-sdk/src/boards/include/boards/pico.h"

// based on PICO_RP2040_CONFIG_HEADER_FILES:

include "C:/Program Files/Raspberry Pi/Pico SDK v1.5.0/pico-sdk/src/rp2_common/cmsis/include/cmsis/rename_exceptions.h"

Perhaps you can try to totally erase the content of build folder. I expect it should be regenerated automatically. Perhaps you have to press ctrl+shift+P in vscode and then run the command Cmake: Configure and then Cmake: build

[mstrens]

After having erase the build and run a cmake: configure, what is the sdk version that is used when you run the cmake build. Is it 1.5.1 or still 1.5.0?

In you PC do you have both sdk version installed?

[Satcomix]

On my PC where both versions SDK 1.5.0 and SDK 1.5.1 I have deinstalled evrything and cleanup the registry and make a new installation of the Pico SDK 1.5.1 from RPi

[proc] Fehler beim Befehl arm-none-eabi-gcc -v. Fehler: Error: spawn arm-none-eabi-gcc ENOENT [proc] Fehler beim Befehl arm-none-eabi-g++ -v. Fehler: Error: spawn arm-none-eabi-g++ ENOENT

[Satcomix]

[proc] Befehl wird ausgeführt: cmake --version [proc] Befehl wird ausgeführt: cmake -E capabilities [variant] Neue Varianten wurden geladen. [kit] Erfolgreich geladen: 1 Kits von C:\Users\Syracuse\AppData\Local\CMakeTools\cmake-tools-kits.json [proc] Befehl wird ausgeführt: "C:\Program Files\Raspberry Pi\Pico SDK v1.5.1\cmake\bin\cmake.EXE" --version [proc] Befehl wird ausgeführt: "C:\Program Files\Raspberry Pi\Pico SDK v1.5.1\cmake\bin\cmake.EXE" -E capabilities [proc] Befehl wird ausgeführt: "C:\Program Files\Raspberry Pi\Pico SDK v1.5.0\gcc-arm-none-eabi\bin\arm-none-eabi-gcc.exe" -v [proc] Fehler beim Befehl "C:\Program Files\Raspberry Pi\Pico SDK v1.5.0\gcc-arm-none-eabi\bin\arm-none-eabi-gcc.exe" -v. Fehler: Error: spawn C:\Program Files\Raspberry Pi\Pico SDK v1.5.0\gcc-arm-none-eabi\bin\arm-none-eabi-gcc.exe ENOENT

[Satcomix]

It`s a problem with the SDK version 1.5.1 I will clean up everything and make a new install of Pico SDK 1.5.0 You have the link on the readme.txt I think you should make a link to the older RPi Pico SDK 1.5.0 greetings, Torsten

[mstrens]

When I have time, I will try to install 1.5.1. Still for the logger I am using an arduino package and I do not know which version of sdk this package use. So, this will perhaps also be an issue.

In the meantime, what do you mean with "You have the link on the readme.txt"

Do you mean that I should add a comment in the README.md file of oXs? If so, do you know exactly what I should add?

[Satcomix]

When click on the "homepage" of oXs on the link to Raspberry Pico SDK, you get the SDK 1.5.1, and not the oder 1.5.0. Greetings, Torsten

[Satcomix]

Hello Mstrens, I have now tried several times to install Pico SDK 1.5.0 or 1.5.1. With version 1.5.0, error messages appear that certain information from the .path is missing. With version 1.5.1 I can no longer create a build either. I installed VSCode, CMake, Pico SDK and uninstalled them again and again after I had no success with the oXs_on_RP2040-test. Are there precise instructions for installing the older Pico SDK 1.5.0 and any extensions? It worked back then with WizIO and CMake and then with Raspberry Pico SDK 1.5.0 with the Win64 installer. Now you get the current Pico SDK1.5.1 with Win64 installer I'm stuck and can't create any more builds. Maybe you have a tip on how I can create my own builds in the future. Greetings, Torsten

[mstrens]

I have no tip on how to create your own builds in the future. I know there is a forum on the pico https://forums.raspberrypi.com/viewforum.php?f=143

Perhaps they could help.

In the coming days (probably friday) I can try to unisnstall 1.5.0 and install 1.5.1 on my pc. Then if my program always reboot, I can add some msg to tack where it crashes.

[Satcomix]

Hello Mstrens, Thank you very much for your help. I will wait Greetings, Torsten

[mstrens]

I uploaded version 2.9.3 that I compiled with sdk 1.5.0 (as usual up to now). Can you confirm that it runs on your side when you use the provided uf2 on github.

Then I installed sdk 1.5.1 without removing 1.5.0. I opened it and selected the kit for GCC 10.3.1 as previously. I opened the oXs_on_RP2040 folder, changed the version to 2.9.4 and I compiled it. Can you confirm also if you can use the uf2 provided in version 2.9.4.

[Satcomix]

Hello Mstrens, I can test the new versions tomorow morning, i am at work. greetings, Torsten

[Satcomix]

Good morning Mstrens, I was able to isolate the problem. Your version 2.9.4 with SDK1.5.1 runs on my boards. If I now change this version with CMake/VSCode and SDK1.5.1, e.g. Config.h version 2.9.5 and activate the Camera Stabilizer, I get a REBOOT loop on the board on which the original 2.9.4 was installed. If I take a board that only has PRI=5 and RGB=18 enabled, my own build works. So it has to do with the wiring of the GPio ports on the board. I will further narrow down the error. Greetings, Torsten

[Satcomix]

Hello Mstrens, I found the error, it is the UART from the GPS. If I set GPS_RX=16 everything still seems to be OK, but it isn't! The I2C bus hangs and the servos are no longer responsive. If I then also enter GPS_TX=17, the board hangs and just reboots all the time. If I then set GPS_TX=255 the reboot stops. If I then deactivate the GPS_RX=255, all telemetry values ​​and functions work properly again. The strange thing is that when I install your version 2.9.4 the problem is not noticeable because I haven't made any changes to the version.

processing cmd

Version = 2.9.5 Function GPIO Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 255 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 255 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 2 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 4 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 14 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 15 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 255 255 255 255 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 255 255 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 12 13 Voltage 1, 2, 3, 4 = 26 27 28 29 (V1 / V4 = 26, 27, 28, 29) RGB led . . . . . . . . . = 18 (RGB = 0, 1, 2, ..., 29) Logger . . . . . . . . . = 0 (LOG = 0, 1, 2, ..., 29) ESC . . . . . . . . . . . = 255 (ESC_PIN= 0, 1, 2, ..., 29)

Esc type is not defined

Protocol is Fbus(Frsky) CRSF baudrate = 420000 Logger baudrate = 115200 PWM is generated at = 50 Hz

Voltage parameters: Scales : 1.000000 , 1.000000 , 0.100000 , 1.000000 Offsets: 0.000000 , 0.000000 , 2.000000 , 0.000000 One temperature sensor is connected on V3 RPM multiplier = 1.000000 Baro sensor is detected using MS5611 Sensitivity min = 100 (at 100) , max = 300 (at 1000) Hysteresis = 5 Acc/Gyro is detected using MP6050 Acceleration offsets X, Y, Z = 1270 , -1342 , -2864 Gyro offsets X, Y, Z = 21 , -163 , -189 Aispeed sensor is detected using MS4525 No Vspeed compensation channel defined; oXs uses default settings First analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Second analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Foreseen GPS type is Ublox (configured by oXs) :GPS is not (yet) detected Led color is normal (not inverted) Failsafe type is HOLD

No sequencers are defined

Config parameters are OK Press ? + Enter to get help about the commands processing cmd

Cmd to execute: FV

Volt 1 = 1778 mVolt Current (Volt 2) = 1658 mA Volt 4 = 329 mVolt Capacity (using current) = 230 mAh Temp 1 (Volt 3) = 21 degree Vspeed = 2 cm/s Baro Rel altitude = 250 cm Pitch = 0.490000 degree Roll = 1.560000 degree RPM = 999 Hertz Ads 1 1 = 119 mVolt Ads 1 2 = 119 mVolt Ads 1 3 = 119 mVolt Ads 1 4 = 119 mVolt Ads 2 1 = 119 mVolt Ads 2 2 = 119 mVolt Ads 2 3 = 119 mVolt Ads 2 4 = 119 mVolt Airspeed = 102 cm/s Compensated Vspeed = 15 cm/s Acc X = -0.008000g Acc Y = 0.027000g Acc Z = 1.000000g pwmTop= 20000

[Satcomix]

I can move the GY-86 and see the changes on the handset display or in FV. The servos on GPio12 (CH15) and GPio13 (CH16) do not move.

// -------------- Camera stabilizer ---------------------------------------- // uncomment PITCH_CONTROL_CHANNEL and/or ROLL_CONTROL_CHANNEL if you want to stabilize a camera on those axis)

define PITCH_CONTROL_CHANNEL 15 // Channel used to control the servo for the camera (pitch); uncomment to activate the pitch stabilization

define PITCH_RATIO_CHANNEL 5 // Channel used to set up the ratio between pitch and servo movement (optional)

define PITCH_RATIO 100 // Ratio to use when PITCH_RATIO_CHANNEL is undefined (or 255); increase/decrease the value in case of under/over stabilisation

define PITCH_MAX 100 // adapt upper limit of servo travel (should normally be the same value as on TX)

define PITCH_MIN -100 // adapt lower limit of servo travel (should normally be the same value as on TX)

define ROLL_CONTROL_CHANNEL 16// Channel used to control the servo for the camera (roll); uncomment to activate the roll stabilization

define ROLL_RATIO_CHANNEL 6 // Channel used to set up the ratio between roll and servo movement

define ROLL_RATIO 100 // Ratio to use when ROLL_RATIO_CHANNEL is undefined (or 255); increase/decrease the value in case of under/over stabilisation

define ROLL_MAX 100 // adapt upper limit of servo travel

define ROLL_MIN -100 // adapt lower limit of servo travel

[mstrens]

I perhaps introduced a bug when I changed the GPS in order to use the same PIO/SM for TX and RX and so get one PIO/SM for ESC Rx or for Logger TX (I do not remember). Perhaps can you test from which version the issue occurred. This would probably help to find the bug.

[Satcomix]

I'll start with 2.8.34.

[Satcomix]

Hello Mstrens, I've been looking for the error with SDK1.5.1 for a few days in vain. I can create my own builds of oXs version 2.8.0(SDK1.5.0) using SDK1.5.1. With 2.8.0 GPS and Camera Stabilizer works. The problems start with version 2.8.1.? I tested successfully up to version 2.6.8, after which I became ill for a long time. Version 2.8.0 still works fine. From version 2.8.8 I started testing again. I've just tested 2.8.0 again and then 2.8.8. Apparently there is a bug somewhere from version 2.8.0.up to 2.8.1?-2.8.8 ESC??? It doesn't benefit everyone if people want a new feature. This feature may also work for the person in question, but all other features have not been tested. I try to support as much as I can with the tests, but I would also like to see people who want new functions as active testers. Please don't misunderstand, this is not a criticism of you or your wonderful work, this criticism refers to the people who want to have everything but don't actively do anything for it. I'm having a lot of fun with all the testing, even though it also means a lot of work to make sure "everything" works properly. I also make mistakes in the tests again. Greetings, Torsten