tedsander

Well., I was slow on the uptake - but it seems like you did figure it out!

Ted

Jim.Thompson

Thanks again Ted.

Jim.Thompson

Double Post.

Jim.Thompson

I know this will come across a silly question but:

Why would a OTx / Taranis user do this?
I have read this page multiple times, but I cannot understand it.

https://rc-soar.com/opentx/setups/calib/calibration.htm

Is it explainable in simple conceptual terms?
If so, can someone please assist me with this and advise about doing it/ or not?

Jim.

scott page

I've never done the calibration setup - but I have a flying buddy that does. Frankly, I don't see a use or it. but he thinks it's the cat's meow. Basically -- it allows you to have both ailerons move the the same direction at the same time -- say both up so you can examine them and determine they are moving at the same speed and have same throw. Same if you have two elevator servos -- flaps etc. I guess I'm old fashion about this - but I just use a ruler. I have enough confusion setting up some of my planes -- running full span ailerons, crow (or butterfly), reversing throttle, and I usually have a fairly full telemetry package to set up. Not saying it's bad - just not my cup of tea.... however ... like I said... my buddy is all about it.

Jim.Thompson

Well, I'm with you here Scott, thanks for the reply.

Jim.

And hey, it is good of you to visit us over here on the beginners forum!..........I for one, am honoured.

tedsander

I tried this a while ago, and I see that he has really expanded the section on using it. All well and good to give one a defined standard to correct any mis-matches that may have been introduced into the model. Being a heavily involved sailplane pilot, he has a lot of pretty complex stuff going on. So for him it is an advantage to have a base on which to stand, to recheck things if needed.
I tried it for a while, but being as everything I have is pretty basic, even if there are a number of channels in use, I never found a need to have to "re-calibrate". It was just one more thing for me that, through dis-use, I had to go back and restudy why I had implemented it and how to use it. Perhaps if I had many layers of mixing and flight modes, it would be of more benefit.

- Ted

Jim.Thompson

Thanks for your feedback; I too figure it would be of absolutely no use at all to me!

Meanwhile, I am reading up on making an OpenXsensor/arduino based RPM sensor for my "D" series (hub protocol) receiver in my IC powered tug plane. I would like RPM telemetry and I could not get the Sbus sensor to work with a (now abandoned) "X" series receiver.
I have written elsewhere about my reasons for going back to "D" series receivers instead of the fabled "X" series. The reasoning is highly controversial, and for some (it appears) to be emotionally charged. Hence, I will only be commenting further on my empirical findings and conclusions regarding this choice on my blog.
This may be viewed as not a beginners subject, I don't know.
Apologies if it is not.

Jim.

siliconengineers

Thanks for this info

Jim.Thompson

Lua Scripts.

I have read some of the literature ostensibly explaining what these are and what they are used for etc.
However, the more I read, the more abstract and unclear the descriptions became.
Are these important to understand for the beginner? Or for the experienced OpenTx user?

I seem to have all the functions for the models I have set up so far with OpenTx while remaining in blissful ignorance of "LUA scripts"
Is there someone can set my mind to rest about these please?
Should I tackle them seriously and read more?

Jim.

tedsander

Have you been lurking on my posts over on the other forums??? (Just joking....)

Starting a couple of weeks ago, I decided to dip into lua. Initially just wanted to do something additional that the vast capabilities of the radio couldn't do. In this case: "If this is the first start up of the day, reset a global variable to "0", and reset one of the timers.". It was "first startup of the day" part the radio couldn't automatically do without lua. It was only every startup, or none.
While I have done a moderate bit of coding, I am in no way qualified to even be called a "lua newbie". There is a huge amount of writing lua in OpenTX I don't understand ...
To specifically answer:

You can rest assured that you can remain blissfully ignorant for all of your days.

Lua allows for more complicated logic and program flows than does the included world of logical switches. It is a full on programming language. It allows one to create custom screens, displaying bits of information that otherwise would not be available. And it can serve to pass information back and forth - to/from data files, talking to things like flight controllers (for initial configuration), etc.
While it can be used to change behaviors in flight, it is strongly, strongly advised to never do so. It is a secondary process, and if the radio needs the memory or processing to fly the plane, it will stop any running lua programs. Which would be bad if you had a lua program directing, say, your elevator.....
It is primarily used for:
1. Displaying custom screens that report telemetry information and "current state" values ("Throttle is at 30%", "Flight controller is in return to home mode", etc) or information derived from those values ("your average flight time today was XX:XX")..
2. Custom screens to read/write/pass some configuration parameter when not flying, either to the radio or connected device. ("Reset a timer", "Set a new value to be used for mixing", "Tell a flight controller to initialize GPS", etc.) (and most of those can be done without lua!)
- the "Create new model" wizard is an extreme example of this.

That said, there are a great number of scripts that you may find helpful. Think of them as add-on "apps" for your transmitter that you may find very useful for analyzing information, or in helping you set up things:
Installing and running lua scripts written by others is usually very easy. Drop the file onto the SD card, and follow the instructions from the author on how to get it running. Usually by configuring a custom screen on the Telemetry tab of the radio, which is just a couple of button pushes to set up (but there are a couple of other ways to run some types of scripts, so go by what the author says).
As always, save all of your current models to the computer, so you can easily restore if you don't like it. Don't forget to delete any files put on the SD card, if uninstalling.
Scripts written by Miami Mike, Mike Shellim, or I shems referenced over on RCGroups may be of interest to try.
https://rc-soar.com/opentx/
https://www.rcgroups.com/forums/member.php?u=15789
https://www.rcgroups.com/forums/member.php?u=577751
https://rcsettings.com/index.php/vie...13-lua-scripts

Actually writing scripts yourself? That takes you into a whole 'nother world of burning many hours of writing programming code. Which for some, can be fun in itself...and for others the worst possible way to spend their time.
See my first ever attempt just posted. https://www.rcgroups.com/forums/member.php?u=82725

Ted

Jim.Thompson

Thanks for the explanation Ted.
I am now a lot clearer on two points;
1. What Lua can be employed for &
2. Just how successfully I can totally ignore them!

Back to my main hobby now: designing and building model aircraft.
Whew!
I feel a great feeling of relief.

Jim

Jim.Thompson

I can understand why this statement is made repeatedly; there is no doubt that the fabled "X" series receiver have more features such as "S" bus etc.
However, I have just made a swap deal for my X8R receivers in return for some older "D" series (4, 6 and 8 channel).
I'm very relieved to have a D8R-11 Plus receiver in my tug plane after the X8R that was in it previously, locked out while I was doing an engine run test with the model tied down on the ground. (Please note: this is caused by two faults and not just one!). I have discussed this over on the other forum and found it was by no means and isolated experience.

Warning: Controversial suggestions following!

I have already received some acrimonious replies (and worse) over on the other forum for making the above conclusion. I have decided to limit comment over there about this experience. But, I'll give it a go here. Since I reported the problem (and before), others have described the same observed fault. I know that one isolated case is not statistically significant, but when more users start to report the same fault, it begins to become so.
Please, if you strongly don't agree with this, state your arguments about the faults of the reasoning, not about the writer!
Ad hominem attacks don't help anybody, least of all the debate.

1. There have been multiple Firmware updates put out by FrSky. Updates to fix previous updates etc. etc.
Have they solved all problems? It does not appear that is the case. I no longer have faith in the FrSky team. It appears the company is following a pattern that is becoming common in the modern world and is exemplified by the less then honest Toyota, Volkswagen, Boeing et. al.
(And I love my old Toyota Camry!)

2. My guess is that the problem with the reported X8R lockout(s) is primarily when it is D16 mode (but I am not sure; I never got around to testing one of them in D8 mode). Cramming 16 channels into a 9ms frame rate might have something to do with the unreliability. (compared to only 8 in a 18 ms frame rate leaving some space between). But I really don't know and I have yet to read a proper technical explanation. One of the reasons for this lack is that this discussion attracts a lot of responses that are more emotional and vituperative than well reasoned.

3. I have a stock of "D" series receivers and have been using them since they came out. I don't recall reading about any number of similar failures in operation about them in the years since, and I have never had a lockout while using them. I have reason to conclude they are rock solid reliable. No Firmware update to fix a reported fault required.

4. In conclusion, I figure why should I risk the safety of a 1/4 scale tug plane, along with people and property, for the sake of a few Wiz Bang fancy features? Hence the swap over to the tried and trusted D8R-11 Plus.

5. For the sake of the vast numbers of FrSky users (and myself), I would like to be able to form another conclusion, believe me. However, at this stage, I remain skeptical. The adoption of FrSky years ago was, and continues to be, a revolutionary move for me.

Thanks for reading.

Jim.

scott page

If telemetry is not your thing then the D8 receivers are a very good choice. I doubt of much of the D8 telemetry gear is even available anymore but it was delicate and difficult to deal with IMO. The D16 receivers, which includes X, S, and R, have a much better telemetry setup and more physically robust - which is why I dumped my D8 in favor of the D16 gear. Additionally they D16 provide model match, which D8 do not do. I have complete confidence in the D8 protocol and have taken gliders to over 2000 feet with it.
I think much of this ACCST D16 "uncommanded servo movement" has been WAY over hyped for FCC systems - however I'll admit that it does make me unsettled. As I was one of the original FrSky evangelists I'm fairly embarrassed by the path FrSky has chosen. I had an EU system I'd be more concerned and might ground my fleet until this is more satisfactorily resolved; at least the expensive planes.
Keep in mind that other brands have firmware iterative updates and bug fixes. ie. My father's Furaba 14SG is about 8 years old and they just issued the 9th firmware update fixing a problem with range check which they broke in a previous firmware update. Point being -- this is not unique to FrSky - just much more public given the crowd sourced testing and development community that's attracted to FrSky.

Jim.Thompson

Thanks for your reply Scott.
I did not know anything about the "delicacy" of the D8 system. Perhaps I have just not come across it.
As for telemetry, I have working variometer, RSSI, battery voltage on my D8 receivers and don't particularly need more. Although, I am working on a openXsensor arduino based tacho, but that is a bit frivolous and not really important.
The "uncommanded servo movement" is a worry, but I had not experienced it. It was the total link lockout that pushed me into sacking the X8R receivers.

I am aware the problems FrSky are creating (or not fixing..........whichever way you want to describe it), are not unique. Futaba too? I read a problem about Hitec too some time ago...............where do we turn to?

But I am not jumping ship now; OpenTx is generally fantastic, beyond all previous experience of mine anyway.

Thanks again for helping us over here on the Taranis beginners thread!
Jim.

The world is getting better and better and worse and worse faster and faster.

scott page

Just looked at the D8 telemetry still available (not much). The hub that was used in the past had really small wires and easily broken or pulled out plugs. They had a ton of sensors back in 2011 -- but most were discontinues due to lack of interest. It seems the hub is gone too. As I fly only electric anymore -- what I really need is cell voltage, amp meter / mAh consumption, and vario. The rest is interesting, but I've gotten over being enamored by every shiny new telemetry gadget. I really like where FrSky has gone with their telemetry ESC's. Wish they had vario built in s well. Other than knowing when it's time to land or how high I am -- telemetry is mostly for figuring out what went wrong.

Jim.Thompson

Taranis X9D Plus running OpenTx 2.2.3 and Companion 2.2.4

My tug plane set up shows two lines (double entry) in the mixer page on the flap channel, while it only shows one in the transmitter (I have only entered one). I have read the file from the radio to Companion several times.
It is the same for the second (left) aileron. (The second or left aileron uses the first right aileron as the source.)
Can someone tell me why this is?
(I was not game to ask over on the other thread!).
I was unable to upload the .otx file here --unacceptable file type!

tedsander

The name right next to the Channel (CH6:flap) comes from whatever you put in on the Output page for that channel.
The name on the right side is whatever you named that specific line in the mixer.
So for flaps, you do have two mixer lines, both the same except that they have different names. In that instance, it looks like you are taking the input from LS twice, producing double the output to CH6.
For CH7, it sure looks like you have two feeds going to it - CH1 which is what is the final result that goes to the RX (ie - the final output of Ch1 is being looped back to feed Ch7), and I1, which is what is coming from the source modified on line 1 of the Inputs tab (probably the ail stick).
The second line for Ch7 is the usual way to control a second aileron servo. Using CH1 instead can get strange if you have additional mixing happening to it, or the outputs tab entry is different from CH7, or if you have special functions doing something to it.
Try renaming the otx file to "txt" and attaching. We can then rename it back and open it to get a better idea of the whole picture.
If the file contains several models, let us know which one to look at.

Are you saying you don't see the same entries on the radio? If so, which ones are showing (or which are not)?

Jim.Thompson

That is what I was trying to express Ted; that is the whole point of the post.
The display in my transmitter is different from that in Companion.
In my transmitter (Radio) only the first line in each channel is displayed.
I have since changed the source for the Ch7;ail2 to the aileron stick (after reading your answer above).

Both second lines in Ch6 & Ch7 are not present in the radio display. I have no idea where these (+=) prefixed second lines came from!

Edit: I am now trying to take a picture of the transmitter display of the mystery lines @ CH6 & CH7 in the mixer page. No success yet.
Edit #2:
I now have a picture of the single line entries displayed in the mixer lines for CH6 and CH7.
See second attachment.

tedsander

I downloaded the file, and yes the entries were there. Then put it on my radio - and they are gone, just like your picture!
This is very, very odd! Will spend a few looking at things a bit more....

What radio are you using? A regular Taranis, or a Plus?

[later edit: Oops, Look at the picture Ted...he's got a Plus!]

Ted

Jim.Thompson

The Mystery deepens!

This is the post I made on Jan5 over on the other thread. The set up file is shown there with the correct (single) line entries for CH6 and CH7.

https://www.rcgroups.com/forums/show...ostcount=34162

I have worked on the set up since then, but I've not touched the entries or mixes for CH6 or for CH7.
What could be going on?
Very strange indeed.

Jim.Thompson

Ted,
Should I move this discussion over onto the other forum?
Or do you want to work on it for some time? I don't mind either way, I am not in a hurry for it as I will not be flying the plane anyday soon.
I am just thinking now that it was poor judgement on my part to avoid posting it over there in the first place, and perhaps not fair to you.

Many thanks,

Jim.

tedsander

If you use the simulator in Companion, it does not show the additional mixer lines, either!


I tried copying the model from both the file it was in to a second spot, and also to a completely new file. In both cases the doubling showed when editing the model, but not on screen (neither on the radio nor in the simulator).

On the radio, I tried making small changes to the mixer lines, hoping a change there would correct the problem. Then uploaded to Companion. The bad lines still showed up.

On the radio, I did not try totally deleting the afflicted mixer lines, exiting out, going back in and then adding the correct entries. Maybe that would also work to clean things up.

But: Editing the model in Companion to remove/correct the bad lines resolved it. Everything looked correct both after downloading the fixed model to the radio and then uploading again to Companion.

All I can assume is that a particular part of the file on the radio had a some corruption, that pointed to incorrect entries or partial old edits, that Companion displayed, but the simulator and radio did not.


Several years ago, I was working with a very noted expert in data storage for many, many hours, trying to resolve a very serious corruption problem in a big system. In our darkest moment, he let out a big sigh, saying "We're essentially dealing with static electricity on plastic. How stable do you really think it can be?" We did eventually resolve the issue...but the "why" was never fully answered. It never happened again, though.

tedsander

Feel free to post over there - it is definitely strange behavior! I'd call it fixed by making edits in companion, and resaving it to the radio....but it would be interesting to see if any of the experts or even developers that participate can shed some light on the "why".

Jim.Thompson

Resaving to the radio is a function I am still a bit shy of!
Of course, I will do again one day if I absolutely have to.