search

dgatf / msrc

Multi Sensor for RC with RP2040 - FrSky D, SmartPort, XBUS, SRXL, IBUS, SBUS, Multiplex Sensor Bus, Jeti Ex Bus, Hitec, CRSF, Sanwa
GNU General Public License v3.0
174 stars 43 forks source link

Castle Link: erratic readings #12

Closed twistedwings closed 3 years ago

twistedwings commented 3 years ago

I have made a telemetry log with my heli on the bench. RPM=0, lipo voltage 23.0V all the time. The telemetry values look strange.

image

Here is the log: https://drive.google.com/file/d/1Tes9JJHe6Kpq8qTiYFw9zbXp99co7ER8/view?usp=sharing

Talon 90 Radiomaster TX16S OpenTX 2.3.10

dgatf commented 3 years ago

Are you using an Arduino 8mhz (3.3v) or 16mhz (5v)?

twistedwings commented 3 years ago

16mhz (5v)

dgatf commented 3 years ago

Ok. Better with 16mhz

In escCastle.h I've added in line 21 #define FIXED_CALIB and #define DEBUG_CALIB

Please make the following tests:

Test 1: Uncomment #define FIXED_CALIB and check the telemetry log again. This fixes the telemetry calibration. Values should be more stable

Test 2: Uncomment #define DEBUG_CALIB and connect TX to TTL RX and open a serial monitor at 115200 baud. Connect Arduino and heli GNDs (do not connect ttl vcc to the arduino) and post the output

twistedwings commented 3 years ago

I will give it a try. Should #define FIXED_CALIB be uncommented for Test 2 too ?

dgatf commented 3 years ago

It doesn't matter for Test 2

twistedwings commented 3 years ago

Test 1: I don't see an improvement image https://drive.google.com/file/d/1QFCHxxZyTn3DXSFlbpYtlt01Juk3M-wP/view?usp=sharing

Test 2: https://drive.google.com/file/d/1YpEXI038_ywlZ04W7kG70JUPnYJa2uek/view?usp=sharing

dgatf commented 3 years ago

I addition to the esc, do you have enabled other sensors in the Arduino config?

twistedwings commented 3 years ago

no, castle esc is the only sensor.

dgatf commented 3 years ago

Castle telemetry involves measuring time very precisely. Atmega328 has only one 16-bit timer with one timer interrupt (already used to measure the pwm signal from the receiver) which forced me to measure the telemetry with a pin interrupt (less precise as to when it happened as it maybe delayed by other interrupts) rather than the precise timer interrupt and Test 1 confirms that telemetry readings are sometimes delayed by other interrupts (software serial for smartport makes an intensive use of them). The deviations in Test 1 are only to one side (increasing the values, not also decreasing as before the test). The difference is that the calibration scaler (based on telemetry) is fixed rather than adjusted every 10 frames, and a bigger (delayed) scaler means lower telemetry values. Unfortunately until next month or so I won't be able to test with my castle esc to compare the deviations, but I doubt if something can be improved in this regard. So all in all castle telemetry is on the limit (or a bit beyond) of what atmega328 can do

I suggest the following:

Possible solutions:

twistedwings commented 3 years ago

I had a quick look at the code and have the following suggestion: Why not simply "pass thru" the RC input and use the 16-bit timer for castle telemetry ?

dgatf commented 3 years ago

Pass thru is not possible, because castle esc requires an inverted pwm signal when activating the telemetry

To invert the pwm signal from the RX it is needed:

I don't think there is another way without using the 16-bit time, but suggestions are very welcome

twistedwings commented 3 years ago

IMHO there is no need to measure the pulse length or to generate a pwm signal. The rc output (to esc) should be the same as the rc input (from receiver) but inverted. If the rc input goes high you'll get an interrupt and can switch the rc output to low. If the rc input goes low you'll get an interrupt and can switch the rc output to high. So for this "rc pass thru" no timer is needed at all and latency would be almost zero.

dgatf commented 3 years ago

That has the same issue as the telemetry (I tried that time ago), it relies on a pin interrupt, that fires and interrupt routine which can be delayed in the same way by other interrupts, resulting in a unstable signal increasing for small periods the motor throttle. Timer interrupt is needed as it saves the time when it was fired despite when the routine will be processed. Pwm is needed as is the only way that guarantees the length of the pulse, otherwise same delay may occur. It's not latency the issue (indeed current latency is up to 20ms, but not an issue), is the accuracy of the signal. The delays producing this issue are around 0.1ms (100μs)

twistedwings commented 3 years ago

OK, I see. Then I hope to see a STM32F103 port someday. An alternative solution might be a hardware inverter for the rc input.

twistedwings commented 3 years ago

Maybe the SBUS solution is worth thinking about since many FrSky receivers have an inverted SBUS signal.

dgatf commented 3 years ago

Support for ATMega328PB and ATMega2560 has been added. Those boards solves the issue of the erratic reading for Castle ESC. Pololu ATMega328PB recommended