HW Platinum/Flyfun, innacurate voltage and current

[Klippeneck]

Next test: Voltage and current values can be trimmed to a usable accuracy by adjusting the divisor and ampGain in escHW4.h useful accuracy by adjusting the divisor or ampGain. Remaining measurement deviations probably come from the ESC. I can't measure RPM at the moment, but it could be correct. After further fine tuning of the coefficients I will test the combination in flight. Attached is a short LOG file.

jeti_log_1.txt

[dgatf]

• Which Flyfun model is?
• Which values for divisor and ampGain are you using?

[Klippeneck]

ESC is FlyFun 80A V5, Value for divisor is 15.4 und ampGain is 8.5. Fine tuning next days.

[dgatf]

Is the FlyFun 80A basic (LV, 3-6S), HV (5-10S) or OPTO?

[Klippeneck]

It is the new version of LV for 3-8 cells

[dgatf]

Maybe it has different sensors from previous ESC version. But neither I have confirmation if the values for ampGain and divisor are good for the old version FlyFun LH, as I've data for the Platinum versions but not for the FlyFun. For FlyFun, I've used the same values as for Platinum V4 LV/HV. I've only confirmed same divisor between FlyFun HV and Platinum HV.

It would be good to have more data feedback from FlyFun ESCs

[thnilsen]

I've got the Funfly 6S 80A LV version which I hope I'll get to test in the air this weekend weather permitting. I had to change the ampGain to 6 to get indoor tests closer what my watt meter was reading but still probably need some tuning. VoltageDivsor is left per default.

The CURRENT_TRESHOLD setting you added didn't help much as the throttle % needs to be quite highh. I added a CURRENT_MAX = 80 constant and added a check just after the CURRENT_TRESHOLD check, which seems to work a bit better.:

if (current > CURRENT_MAX) current = 0;

If I can't get flying this weekend I'll do a couple of ground runs outside to get some data and see if it works as expected.

• Thomas

[dgatf]

I've collected gain value from various models:

• FlyFun 60A LV gain = 6
• FlyFun 80A LV gain = 8.5
• Platinum V4 80A LV gain = 7.8
• Platinum V4 120A LV gain = 10
• Platinum V4 200A HV gain = 16.9

It seems that the gain is related to the ESC amperage. Maybe when Klippeneck fine tune the gain parameter, it gets closer to the Platinum 80A, with gain = 7.8

[dgatf]

For the missing models maybe it can be adjusted by least squares, until data is confirmed:

100A, gain = 9 130A, gain = 11.3 150A, gain = 12.9 160A, gain = 13.7

[dgatf]

For the voltage, the divisor is related to maximum battery voltage (S):

• 3-6S (LV): divisor = 11
• 3-8S (LV v2): divisor = 15.4
• 5-12s (HV): divisor = 21
• 6-14s (HV v2): divisor unknown

[dgatf]

There are many different sensors. I've condensed the protocol for Platinum V4 and FlyFun V5 to a single choice, PROTOCOL_HW_V4

Now the voltage divisor and diffamp gain values have to be set manually in escHW4.h based on the suggested values on the table. Some have been measured others are extrapolated. If someone find any discrepancy should post new values so the table can be updated.

Also the suggested filter for current max by thnilsen has been added

If using smartport and lua config, it is needed to update the script and reconfigure the ESC protocol

[Klippeneck]

Hello, while determining the exact coefficients for the current and voltage measurements, another problem I found. After a few seconds of operation in the model with a 14 pole motor, the sensor fails and brings at the current 819.1A, then shortly after no data at all. Only after disconnecting the drive battery everything works again for a few seconds. In addition, the speed of my motor seems much too high, the number of poles may have to be set somewhere?

[dgatf]

the speed of my motor seems much too high, the number of poles may have to be set somewhere?

Yes, you have to divide by pair of poles, 7 in your case. You can do this in the transmitter. I'll add a multiplier for RPMs so this can be done by code

[dgatf]

the sensor fails and brings at the current 819.1A, then shortly after no data at all

I believe the issue is the that you're using software serial to read the ESC. Software serial is a blocking routine, which means that while ESC packet is being received, it is not feasible to manage the hardware serial for the Jeti. ESC packet is 19 bytes, at 19200 bps, the duration of the packet is 10ms which is more that the allowed time to answer the Jeti protocol, which is 4ms

Conclusion: you are better with a board with 2 or more UARTs to be able to use Jeti with ESC serial. Though I'll make some tests with software serial and Jeti

[dgatf]

I've added a filter to avoid writing to Jeti Ex Bus too late, which was blocking the bus. This was most likely to happen when using sofware serial for ESC or GPS. I've also reduced the Jeti timeout from 2ms to 1ms

This may allow to use software serial with Jeti. Please try the updated code

[dgatf]

I'll add a multiplier for RPMs so this can be done by code

Done. In config.h set RPM_PAIR_OF_POLES and for helis also RPM_PINION_TEETH, RPM_MAIN_TEETH

[Klippeneck]

Test new SW: Error Message: Arduino: 1.8.13 (Windows 10), TD: 1.53, Board: "Arduino Pro or Pro Mini, ATmega328P (5V, 16 MHz)"

sketch\xbus.cpp: In member function 'void Xbus::update()': xbus.cpp:180:5: error: 'esc' was not declared in this scope esc.update(); ^~~ exit status 1 'esc' was not declared in this scope

[dgatf]

The error message is fixed now.

I've improved the serial drivers. Timeout is changed from milliseconds to microseconds for better handling fast protocols like Jeti Ex

[dgatf]

Using software serial for ESC with Jeti, hangs the arduino.

Download updated code and swap software serial for Jeti and hardware serial for ESC. Change lines 47 and 50 in constants.h:

#define SMARTPORT_FRSKY_SBUS_SERIAL softSerial
#define ESC_SERIAL hardSerial0

Also update connections: Jeti to pins 7 and 12 (with resistor) and ESC to Rx

Though I'd recommend to use a board with 2 or more UARTS

[Klippeneck]

Hello, with the recommended changes the sensor now runs on a 5V/16MHz Arduino Pro Mini. After adjusting the voltage divisor to 16.1 and the AmpGain to 11.3, now the displayed values are correct. If tomorrow the weather plays along, I can use the sensor in an electric glider. and if necessary make some last fine tuning. Should the coefficients change slightly, I will post them again. Thanks for the great sensor.

[dgatf]

Good. Code updated. Now software serial is only used for Rx protocols and not sensors.

If UART is available, hardware serial is used for Rx protocol. If no UART is available (because it is used by ESC and/or GPS), software serial is selected for the Rx protocol. This applicable for ATmegas with only one or two UARTS. This is done automatically, depending on the config variables.

[dgatf]

Klippeneck, you can reopen the issue any time you want.

Moved from the other issue:

Klippeneck Hello, today first test performed in flight, except for one problem everything fine. E- glider on the slope in good conditions, engine only for takeoff, then sailed about 52 minutes. Telemetry display Consumption until then 53mAh, seems plausible because of short motor use for takeoff. Then switched on the motor briefly, Consumption jumps to 297mAh at the motor start. This can also be seen in the log, but cannot be with max. 42.1 A motor current in the log. Subsequently, the motor was used several times, after 1 hour flight Consumption was at 475mAh. During the subsequent charging of the LiPo, the battery was full with 300mAh. How can the jump from 53 to 297 mAh be explained?

[dgatf]

This is due to the signal noise when throttle low (bad quality sensors HW). See previous comment from thomas

You need to increase CURRENT_THRESHOLD in config.h and set ESCHW4_CURRENT_MAX in escHW4.h to 100 (if using 80A model)

Please attach the log. This will help to adjust the parameters

[Klippeneck]

Hello, ESCHW4_CURRENT_MAX in escHW4.h is set to 100A. Here is the extract from the log:

jeti_log_2.txt

[dgatf]

Did you still get ESC telemetry while the motor was stopped while flying?

If you didn't, it would use the last time when motor was on to calculate consumption and this could explain the issue

[dgatf]

I've added a filter to avoid calculating consumption when the interval is more than 1s

Commit c40bcd3e1b10ef242c13833083b135f6cff561dc

Flash updated code and test again

[Klippeneck]

Hello Daniel, on the Jeti EXBus signal the servos are also transmitted. Wouldn't that be a possibility to use the throttle channel as a condition for adding the Consumption? I could imagine as a non-programmer. Simply define in the config. a value from which the controller starts.

[dgatf]

That's what CURRENT_THRESHOLD does. It gets the throttle value from the ESC telemetry. It set current and consumption to 0 until throttle threshold is reached, by default is 25% You could increase slightly to 35% or so. Could you add the throttle to the log (or is there and I missed). I want to check if those current values under 10A are reached over 25% throttle

I discard the theory of no connection between arduino and ESC when motor is off because in the table there are current values when the jump occurs, that means arduino and ESC dind't lost connection (at least at the time of the jump)

From your last log:

Time (ms) | Curr (A) | Cons (mAh) -- | -- | -- 3084916 | 8.4 | 53 3085030 | 8.4 | 53 3085123 | 8.4 | 53 3085370 | 4.4 | 53 3085523 | 4.4 | 53 3085617 | 5.2 | 297 3085784 | 5.4 | 297 3085824 | 5.4 | 297 3085918 | 5.4 | 297 3086185 | 6.1 | 297 3086279 | 6.1 | 298 3086433 | 10.6 | 298 3086527 | 10.6 | 298 3086761 | 21.4 | 299 3086820 | 31.9 | 303

[dgatf]

I've added another filter in the consumption routine. Now it checks that calculated consumption for the interval is not higher that the consumption for the current max. Commit 9b26544febcbbc2ca173cba84adb5b1e616f96bc

Recap I've added two additional filters:

• Max interval is 1second, in case the ESC connection is lost for a while. Intervals over 1s are discarded for consumption calculation
• Check that calculated consumption is less than consumption for given interval at ESCHW4_CURRENT_MAX

[Klippeneck]

Hello, just came from testing the SW from yesterday. Unfortunately no good news, the sensor hangs again after a few seconds. For control I have switched the RC current sensor from Bodrico.com at the ESC input, also an EX bus sensor. The in the sail phases dropping capacity indication is due to the lack of adjustment, I forgot. Attached is a short excerpt of the log file.

jeti_log_3.txt

[dgatf]

I've reverted the consumption routine as it was before.

Please check that it works again.

[Klippeneck]

Next test with latest SW. Sensor does not run stable, after startup the sensor runs sometimes 10 seconds, sometimes 1 minute around then subsequently stop operation and no longer provide any values, regardless of whether the engine is on or not.

[dgatf]

There was an issue with the automatic baudrate selection for Jeti Ex Bus using sofware serial.

I've also added a simplified filter to avoid jumps in the consumption calculation. Hopefully all is solved now

Fixed with b1c07022d6ad7162d0dea1418976e3697095a2f1

[Klippeneck]

Hello, the sensor is running stable now, the small deviations in voltage and current I will solve by adjusting the coefficients. So far everything is ok, only the consumption is off by a factor of 30-40 and is also not stable in the course of time. plausible. and still needs correction. So that the ESC initializes correctly, I had to set in config.h define ESC_DELAY to 2000. In the telemetry overview in the transmitter is still missing the RPM value transmitted at Pos. 1.

[Klippeneck]

jeti_log_4.txt

[dgatf]

So far everything is ok, only the consumption is off by a factor of 30-40 and is also not stable in the course of time. plausible. and still needs correction.

You mean that calculated consumption needs to be multiplied by 30 to 40 to get real consumption?

You can remove the filter by commenting line 51 in escHW4.cpp:

//if (consumption < (ESCHW4_CURRENT_MAX * 100) / 3600)

[dgatf]

I've reintroduced the complete filter, as the issue of the sensor stopping was related to something else. Should work better now

Please try updated code

[dgatf]

Filter improved

[Klippeneck]

Hello Daniel, Thanks again for the sensor and your adjustments. Now the sensor runs as I want it, voltage and current are very good, as well as the consumption. Only the RPM do not come, but are not important to me. The flight today was about 40 minutes, everything is fine. Attached is an analysis of the data. Voltage divisor is 15.75 and current gain 12.4, so any values are very good even with a counter measurement. with a DMM.

[dgatf]

Only the RPM do not come, but are not important to me.

RPM was there before.

It could be that you've reached the maximum number of sensors. If you disconnect kapuki-CS, does RPM appear again?

[Klippeneck]

Hello, even without Kapuki with then only 9 values RPM also does not come. When reading the sensors several times, the voltage is also missing from time to time. For my application in the E-glider, the Consumption is the most important value. Voltage is not so important to me, because the current values from the ESC only come when the motor is running. What else comes to my mind, could this be related to the delay ESC_INIT_DELAY 2000 in config.h?

[dgatf]

could this be related to the delay ESC_INIT_DELAY 2000 in config.h?

Probably not, that only delays the start of MSRC

Another thing I noticed is that ESC temperature sensors are missing since the beginning

I've made some adjustments. Could you try the updated code

If RPM still doesn't appear, comment lines 402-409 in jetiex.cpp:

//sensorJetiExP = new SensorJetiEx(JETIEX_TYPE_INT14, 0, esc->tempFetP(), esc);
//sensorJetiExP->setSensorId(addSensor(sensorJetiExP));
//sensorJetiExP->setText("Temp FET");
//sensorJetiExP->setUnit("C");
//sensorJetiExP = new SensorJetiEx(JETIEX_TYPE_INT14, 0, esc->tempBecP(), esc);
//sensorJetiExP->setSensorId(addSensor(sensorJetiExP));
//sensorJetiExP->setText("Temp BEC");
//sensorJetiExP->setUnit("C");

[Klippeneck]

Hello Daniel, with today's SW the current comes only after I in the config.h also config Voltage 1 but now there are 2 temperatures BEC and FET and RPM is missing again. Without Voltage 1 comes RPM but no current, all a bit strange.

[dgatf]

I believe the issue of the temperatures was different. It may not be allowed special characters. I've removed ° from temperature unit, changing °C to C. You could check that by adding back ° to one of the temperatures unit.

[Klippeneck]

With line 492-409 commented the temperatures are missing, RPM does not come after all.

[dgatf]

With line 492-409 commented the temperatures are missing, RPM does not come after all.

Was voltage 1 enabled? Should be disabled. Only enable the ESC

[dgatf]

If still doesn't appear, change RPM type to INT14, line 399 in jetiex.cpp (and keep lines 402-409 commented):

sensorJetiExP = new SensorJetiEx(JETIEX_TYPE_INT14, 0, esc->rpmP(), esc);

[Klippeneck]

With Voltage 1 disabled, I get no power in the telemetry menu, but Voltage1 appears in it although not activated in config.h, also RPM is there. Only when I enable Voltage 1, I see the current, but no RPM anymore. I have commented out Cellvoltage in jetiex.cpp. I do not need it. The change in line 402 to 409 in jetiex.cpp omits the temperatures, but does not change the current. Attached are 2 screenshots of the telemetry selection display,

[dgatf]

Have you tried to change RPM type to INT14, line 399 in jetiex.cpp?

sensorJetiExP = new SensorJetiEx(JETIEX_TYPE_INT14, 0, esc->rpmP(), esc);

[Klippeneck]

Hello Daniel, yes I did, but in my sketch it is line 391.

[dgatf]

I believe the issue was related to sensors cycling and/or serial buffer. I've made some adjustments related to this. Hopefully is now solved. Disable Voltage 1, just in case.

Please try the updated code.