Page 148 of 152

Re: ERSKYTX Coding

Posted: Sun May 19, 2019 10:47 pm
by MikeB
I've posted a .zip file (on the test versions thread) that is the intended r222 release.
I've also committed the sources, including the missing pxx2.cpp and pxx2.h, to Github.
The zip file includes the FrSky X9Lite and the Jumper T16.

Mike

Re: ERSKY9X Coding

Posted: Sun May 19, 2019 11:30 pm
by jhsa
Thanks Mike..

João

Re: ERSKY9X Coding

Posted: Sun May 19, 2019 11:33 pm
by jhsa
Mike, anything new apart from the support for the other radios?
Anything needing special attention?

Thanks

João

Re: ERSKY9X Coding

Posted: Sun May 19, 2019 11:43 pm
by antlerhanger
I've loaded it on my 3 pro's and Taranis ..All is perfect

Re: ERSKY9X Coding

Posted: Tue May 21, 2019 12:42 am
by Daedalus66
Hi Mike

Just received an FrSky X9 Lite. It looks and feels fine but does nothing when the button is pushed to turn it on (powered with six NiMH while I wait for 18650).

Presumably, it's necessary to load ERSkyTX before anything works. I put the xlite file into a FIRMWARE folder om the SD card and tried to invoke a bootloader (trims apart) or flash firmware (trims together) but absolutely no reaction. I've also tried eepskye but no sign of life. Is it necessary to go to Zadig?

Starting to wonder if the TX is dead. Can you offer any insight into how to get it running with ERSkyTX? Thanks.

Nigel

Re: ERSKY9X Coding

Posted: Tue May 21, 2019 8:01 am
by MikeB
I'm using 6 NiMh cells in my prototype at present. I understood they shipped with firmware on them.
I'm using a 6-cell battery from a X9D. The power connector on mine has the two, polarising slots towards the bottom of the case, the red wire to the right (positive) and the black wire to the left (negative) with no connection to the centre.

Possibly worth connecting the USB with the power off just to see if the DFU bootloader is found.

Mike

Re: ERSKY9X Coding

Posted: Tue May 21, 2019 1:52 pm
by Daedalus66
Thanks Mike.

Totally my fault. I misinterpreted the polarity (despite checking three times!) and applied reverse voltage. Now with correct polarity, I see the “OpenTX” screen but then it blanks out and shuts down. Slight noises while this is happening.

No obvious signs of burnt components.

I have another on the way. At $60 it’s probably cheaper than a new board (when parts become available). But if you have any suggestions for fixing the old one, I’ll give it a go.

Meanwhile, back to the QX7 with ERSkyTX latest r222 test version.

Re: ERSKY9X Coding

Posted: Tue May 21, 2019 4:12 pm
by MikeB
Does it start OK in bootloader mode?
What about if you hold the power button pressed while the splash screen is showing?
There is a MOSFET providing reverse polarity protection.

Mike

Re: ERSKY9X Coding

Posted: Tue May 21, 2019 4:53 pm
by jhsa
MikeB wrote: Tue May 21, 2019 4:12 pm
There is a MOSFET providing reverse polarity protection.
Then it shouldn't burn anything, providing that there aren't any design flaws of course ;) We have seen them before :P

João

ERSKY9X Coding

Posted: Wed May 22, 2019 1:08 am
by Daedalus66
Thank you Mike and Joao for getting me back on track. The X9-Lite appears to be unscathed by its encounter with reverse voltage. Here’s the story.

I’ve explained how I managed to misinterpret the polarity markings and connect a 6 cell NiMH battery (for the QX7) to the wrong battery springs. When turned on there was no smoke, but when I correctly connected the battery, I only got a very brief screen display (2-3 seconds), then it shut down. I concluded that the reverse voltage had blown something and turned my attention elsewhere.

This evening I followed your suggestion about testing in boot-loader mode. The screen lit up and showed boot-loader stuff. I pressed Exit and OpenTX appeared. All looked normal except that the Battery warning showed 6.2v. I assumed this was a calibration issue, but in about 30 seconds the voltage was at 5.7 and things were not working properly. I shut down and measured the battery voltage as 5.8.

I hooked up a nearly full (8.1v) LiPo that was handy and all seems to be 100% normal!

So what apparently happened was that, contrary to my assumption, the transmitter was not harmed by the reverse voltage (protected by the MOSFT). Rather, the failure was simply due to a defective battery (which had shown 7.9v before I hooked it to the transmitter). I’m just checking the battery now, suspecting a bad cell (or two). It’s two years old and not normally in service.

The tx has now been running for nearly an hour since it’s “rebirth”. The LiPo still reads 8.1v. The menus all seem to work.

Thank you again.

Nigel

Re: ERSKY9X Coding

Posted: Wed May 22, 2019 8:26 am
by jhsa
Good that you solved the problem, and that there wasn't a problem at all, after all :) :mrgreen:

João

Sent from my BLN-L21 using Tapatalk


Re: ERSKY9X Coding

Posted: Wed May 22, 2019 9:41 am
by ozphoenix
@mikeb and @kilrah,
An old topic, I know, but I just wanted to confirm that, after similar testing, OpenTX has the same problem dealing with two MLVSS units on the same Rx SPort -- it does not work unless you connect a third (non-MLVSS) unit on the chain -- then it works the same as Ersk9x (oops, sorry - ErskyTx) - both MLVSS units report the total voltage correctly (I haven't figured out how to get individual cell voltages in OpenTX yet, nor how to do calculations on the total values, so that I can calculate and audio a percentage remaining, similar to what I do in Ersky).

So, as previously stated, the problem is in the MLVSS microcode, not in the radio OS chosen.

@mikeb - wondering if FrSky ever got back to you about a fix in the MLVSS? For now, I am running a third device (FCS40 or GPS or whatever, just not another MLVSS) when I need two LiPo sensors in the same plane.

Regards,
ozphoenix
MikeB wrote: Wed Jan 02, 2019 12:40 pm
Kilrah wrote: Wed Jan 02, 2019 7:00 am Just in case it might help, OpenTX supports that setup just fine.
Do you know if two MLVSS have been tested in openTx, rather than two FLVSS?
I'm suspecting there may be a problem with the MLVSS.

Mike

Re: ERSKY9X Coding

Posted: Fri Jun 07, 2019 10:44 pm
by MikeB
I'm considering the "instant trim" function. Currently it takes the stick, trim and sub-trim positions and places the result in the sub-trim, setting the trim values to 0.
This works OK, but this was implemented before "flight modes" were introduced, each of which may have their own trim settings. You may actually want a different trim setting on another flight mode.
I'm considering changing this to ignore the sub-trim value, and just combine the stick position with the trim, of the current flight mode, and put the result in the trim of the current flight mode.
Possibly I could add an option to allow a choice between these two functions.

Mike

Re: ERSKY9X Coding

Posted: Fri Jun 07, 2019 11:37 pm
by jhsa
Would this only affect thw flight modes? What about if the model do not use flight modes? Would it be saved to the sub trim as before? I think I am confused :)

João

Sent from my BLN-L21 using Tapatalk


Re: ERSKY9X Coding

Posted: Fri Jun 07, 2019 11:52 pm
by MikeB
All models use flight modes! If you don't configure anything, then you are using flight mode 0. With the new suggestion, then the stick + trim position of flight mode 0 will be combined to the trim of flight mode 0.
At the bottom of the LIMITS menu is an option to copy the trims (of the current flight mode) to the sub trim.

Mike

Re: ERSKY9X Coding

Posted: Sat Jun 08, 2019 1:13 am
by jhsa
Ahh, we can copy to the sub-trim, they are not applied automatically. And when we copy to the sub-trim, then trim is reset to zero, right?
What about if the instant trim does something extreme? can we reset it?

Thanks

João

Re: ERSKY9X Coding

Posted: Sat Jun 08, 2019 8:31 pm
by MikeB
Yes, copying trims to subtrims then sets the trims back to zero.
I have this working, I have added an option to choose between the current operation and just having "instant trim" setting the trims.

Mike

Re: ERSKY9X Coding

Posted: Sat Jun 08, 2019 11:09 pm
by jhsa
Thanks Mike.. Need to test all that and decide which one to use :)

João

Re: ERSKY9X Coding

Posted: Wed Jun 12, 2019 9:56 am
by MikeB
The current implementation of "Instant Trim", when setting the subtrims, allows the subtrim values to be set to any value between -100.0% to +100.0%. I have received a suggestion that this is not such a good idea and the value should be limited to, perhaps, +/-25.0% (the same as if you use the new option of "Instant Trim" to set the trims instead of the subtrims.

Mike

Re: ERSKY9X Coding

Posted: Wed Jun 12, 2019 10:09 am
by jhsa
Mike, as you know, different servos of different brands have different center points. And many RTF models are impossible to adjust the linkage. I for example set one of those models for my son last night that needed easily over 25% if sub trim.. So, please do not change that, :o It has been working really well until now, and it us up to the people to know the limits of their hardware and stay below them. Changing that would.mean that many models could not be.fliwn with ErskyTX.. :(

Sent from my BLN-L21 using Tapatalk

Re: ERSKY9X Coding

Posted: Wed Jun 12, 2019 10:13 am
by budavaril
Same here... I agree with Joao...

Re: ERSKY9X Coding

Posted: Wed Jun 12, 2019 11:28 am
by Daedalus66
I had never thought of Instant Trim as being a way to give huge amounts of correction, just a quick way to apply relatively modest ones — certainly less than 25%. That’s the way I’ve always used it, and my concern was that having the ability to use up to 100% subtrim introduced the possibility of instantly rendering the model totally unflyable. I’d be interested to hear more about scenarios in which IT might be used to make very large in-flight corrections.

I’ve always been a bit leery of IT as a tool to use full-time and have advocated turning it on only for test flights, when it can be invaluable. It seems to me that having the ability to change flight trim drastically at the (accidental) flip of a switch is a bit of a hazard, to be used very sparingly (Boeing 737 Max comes to mind).

I think Mike’s new implementation of Instant Trim is a distinct improvement, in that it allows IT to work with Flight Mode. My only question was whether the existing use of subtrim up to 100% was too much of a good thing and might be an unnecessary risk.

Nigel

Re: ERSKY9X Coding

Posted: Wed Jun 12, 2019 11:36 am
by MikeB
Note the suggestion is to limit the amount of subtrim you may add when using instant trim, not to limit the overall amount of subtrim you may set in the menu. Also, the +/-25% is a suggestion, it could be +/-50% or more.

Mike

Re: ERSKY9X Coding

Posted: Wed Jun 12, 2019 12:16 pm
by jhsa
Mike, I thought you were talking about the subtrim in general.. Instant trim is a different story :)

Nigel, you can't compare our model flying with the.new Boeing planes :) Our model flying is way safer :mrgreen: ;)

We do not suffer from runaway trims :)
Please note that normally we use subtrim when setting up a new model. This is one of the first settings we need to take care of, together with the limits. This limits screen is where we take care of the different hardware systems in the market, example are the different servos with different mid point millisecond seconds. Also different servos have different end stop settings. This is where the limits menu is very useful, and untill today has been doing its job beautifully well.
You should not crash your model because of your "Limits" menu settings because they are done well before the model.leaves the ground.
For example, if the subtrim would be a problem, I could say that being able to set the limits to "0" (zero) would also be another problem. :) But I take this as being really flexible. Of course, a limit value of zero would prevent the control from moving at all.. But WE need to check everything before flying.
As I said above, there are some RTF models that need really loads of subtrim so the servo arm can be on a position that is acceptable. Some servos come pre glued in place, and there is nothing you can do about it. As I said, there was the case of my Son's plane yesterday..
Limits should normally not change at all during the entire life of the model unless you modify it in a way that changes its flying characteristics completely. Or a model that flies so badly that needs the help of lots of instatrim. But after that it shouldn't be necessary to change those values again.
You can perfectly use a servo that is very out of center because of a subtrim high value, as long as we don't try to drive it beyond its maximum throw. Servos are all different. And all this has to be done when setting up the model. First thing to do in my opinion, just after creating the basic mixes..


If this applies only to the instatrim, cool, but it should still.be tested with a really bad model and see how it goes.
I personally never read that a servo was damaged because of it.

We have to make sure the control rods are not bending and the servos are not being stalled. After such a drastic instatrim setting, we should actually check out all our setup again..

Just my 2c of course. :)

João

Sent from my BLN-L21 using Tapatalk


ERSKY9X Coding

Posted: Thu Jun 13, 2019 11:47 pm
by Daedalus66
Not sure how this got off track. I thought it was clear that what we talking about was how Instant Trim should be implemented. I don’t think either Mike or I could be seen as suggesting any change to Subtrim itself.

Just to reiterate, I think the change to IT made by Mike in the latest version (applying IT to either trim or subtrim) is very useful, in that it adds to flexibility in general and specifically allows IT to be used in a Flight Mode setup.

My only question concerned the advisability of limiting IT to 25% when applied to subtrim (as is the case when applied to trim). It seemed to me that being able, in one fell swoop, to apply full offset to one or more of the flight controls was a bit risky.

This was a theoretical question, as I’ve never encountered problems using IT, but I thought somebody, somewhere might run into trouble, and I couldn’t see any good reason to allow 100% IT application.

Mind you, it’s a bit of a stretch to envisage a scenario in which the present 100% arrangement would get one into trouble. Here’s one attempt: Instant Trim is set up to be activated by the momentary switch. You do a snap roll involving lots of aileron, rudder and elevator and manage to hit the switch (don’t ask how, I know it’s a bit implausible). The result would be an unflyable model.

Maybe I’m being paranoid. Please tell me what you think!

Nigel

Re: ERSKY9X Coding

Posted: Fri Jun 14, 2019 2:28 am
by jhsa
It's my fault. I thought you guys were talking about Subtrim, not only about the Instant trim. I misunderstood it.
But in a way, I'm glad I did.. It made me realize how really important it is when setting up a new model..

Actually, I have a model that needs 2 different Aileron Subtrim settings. One for Summer when it is warm, and another one for winter when it is cold :) Don't ask me why, the fact is When the temperature is very different from last time I flew, and I turn the model on again, the ailerons are not exactly where they should with the stick at centre. After I adjust the subtrim, it stays good until the temperature changes again by much :)

João

ERSKY9X Coding

Posted: Fri Jun 14, 2019 2:54 am
by Daedalus66
So what do you think about the 100% subtrim capability of Instant trim? Is it OK? Should it be restricted to 25% like trim?

I’m starting to think don’t fix if it ain’t broke.

Re: ERSKY9X Coding

Posted: Fri Jun 14, 2019 9:04 am
by jhsa
Without testing we won't know. ;)
First we need to try to make it fail at 100% :)
Oh, just had an idea, Mike, what about an undo feature?
I don't know, but perhaps a longer press of the instatrim switch?

Note, instatrim SHOULD NOT be active all the time. Normally only during model's first flights..

João

Sent from my BLN-L21 using Tapatalk


Re: ERSKY9X Coding

Posted: Fri Jun 14, 2019 2:58 pm
by mentero
Hi,

Just for me to understand, if you make a big mistake pushing the switch at the wrong moment, will it revert to "normal" if you push again (hands off the sticks) ?

If this is the case, my vote goes for 100% correction, and my recommendation will be to follow jhsa's in getting rid of this feature after the first flight.

Miguel

Re: ERSKY9X Coding

Posted: Fri Jun 14, 2019 4:38 pm
by jhsa
This feature is not meant to be always ON.. :) That would mean trouble.. actually, I think ErskyTX should have a warning at power ON, if the instatrim was left ON. Mike?

João