Inav: Problem with the implementation of the smartport telemetry improvements

[jaymal66]

In the new smartport telemetry documentation the following for the digit D of Tmp1 is stated
1 =angle mode ,2=horizon mode ,4 = auto tune mode ,4= passthru mode
Is that a tipo ?.... since otherwise the autotune and passthru mode would be undisdingshable even when applying the additive rule.
Indeed switching the the auto tune mode on top of the underlying 3 possible modes angle,horizon and rate/acro- the D digit would read respectively 5,6, but still 4 when on top of the rate/acro mode
Please clarify .

A further issue is that switching on and off the auto tune mode ( which otherwise is fully operationnal ) has no effect on the value of the D digit in Tmp1.
Everything else in the telemetry update however works as expected .

[teckel12]

The autotune and passthru modes were already in place before I made the changes to the SmartPort code (along with the flawed logic). I left it because I didn't want to mess up anyone who was using it. Basically, this is NOT part of my changes, but legacy stuff that is obviously incorrect.

I didn't change the legacy autotune/passthru mode stuff as I don't have any fixed wing models and I have no way of testing or even knowing what they're for.

If the autotune mode doesn't change the value, I would suggest removing it and leaving the 3rd bit (value of 4) for passthru mode. As I didn't change the logic of either autotune or passthru, my guess is that it never worked. And, it's obviously not right.

I don't even know what autotune and passthru mode are, maybe they can't happen at the same time?
Maybe they work with each other? I don't know as they're fixed wing stuff that others would need to investigate. But, it sounds like autotune doesn't report correctly anyway and maybe should be removed.

[teckel12]

@jaymal66 After looking at the code, I guess I did remove auto tune mode from Tmp1 field D. I really though I left it for legacy reasons, but maybe not. I'll change the documentation.

[jaymal66]

Thanks for the feedback .I do understand that dealing with legacy stuff is ungrateful.

No need to do anything beyond identifying the files which you touched to add or modify what ever you did as part of this telemetry update.

I’ll fork the stuff out , try sort things out myself and make a custom firmware for my flight controller .

If anything meaningful comes out I’ll notify

greetings

From: Tim Eckel [mailto:[email protected]]
Sent: Sunday, October 15, 2017 9:04 PM
To: iNavFlight/inav [e-mail]
Cc: jaymal66 [e-mail]; Author [e-mail]
Subject: Re: [iNavFlight/inav] Problem with the implementation of the smartport telemetry improvements (#2343)

The autotune and passthru modes were already in place before I made the changes to the SmartPort code. I left it because I didn't want to mess up anyone who was using it. Basically, this is NOT part of my changes, but legacy stuff that is incorrect.

I couldn't change the legacy autotune/passthru mode stuff as I don't have any fixed wing models.

If the autotune mode doesn't change the value, I would suggest removing that and leaving the 3rd bit (value of 4) for passthru mode. As I didn't change the logic of either autotune or passthru, my guess is that it never worked. And, it's obviously not right.

I don't even know what autotune and passthru mode are, maybe they can't happen at the same time, maybe they work with each other, I don't know as they're fixed wing stuff that others would need to investigate. But, it sounds like autotune doesn't report correctly anyway and maybe should be removed.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/2343#issuecomment-336733507 , or mute the thread https://github.com/notifications/unsubscribe-auth/AfTLW_9naXiRaWIUiC11hQOnvDYoDacuks5sslcWgaJpZM4P51RA . https://github.com/notifications/beacon/AfTLW9GJMerVTTHg5qKyaogAm5htwnxJks5sslcWgaJpZM4P51RA.gif

[teckel12]

@jaymal66 I've addressed the above changes (and a potential feature addition) in my local branch. I'll test this evening and submit the changes.

[jaymal66]

Quick inspection of smartport.c makes it plain.

The entry : FLIGHT_MODE(AUTO_TUNE) was removed Aug 28 by https://github.com/DzikuVx DzikuVx

So no wonder that tmp1 doesn’t change when the auto_tune mode is switch on and off.

Anyway the set of flight modes added with the present improvement is not helpful since relevant only to multi rotors users .

For fixed wings users and other flight modes are of interest among them autotune servo autotrim and home reset.

I will therefore adapt myself smartport.c to my own needs and implement them via a custom make.

From: Tim Eckel [mailto:[email protected]]
Sent: Monday, October 16, 2017 6:02 PM
To: iNavFlight/inav [e-mail]
Cc: jaymal66 [e-mail]; Mention [e-mail]
Subject: Re: [iNavFlight/inav] Problem with the implementation of the smartport telemetry improvements (#2343)

I've addressed the above changes (and a potential feature addition) in my local branch. I'll test this evening and submit the changes.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/2343#issuecomment-336934091 , or mute the thread https://github.com/notifications/unsubscribe-auth/AfTLW4dzbfKgh2dS1DPKtqmcXYBdLQyqks5ss338gaJpZM4P51RA .

[teckel12]

@jaymal66 Actually, home reset was one of the features I just added. autotune was removed as a flight mode, which is why it was removed in smartport.c.

There's really no reason to create your own build. If there's certain flight modes that are important to fixed wing pilots, I'm sure they can be worked into INAV without the need for a custom build. I didn't remove anything from smartport.c, I simply added additional features.

Let me know what flight modes are really needed with telemetry (some modes are not that useful for telemetry but are more suited to OSD). And I'll see what I can do!

[teckel12]

Resolved in #2356

[teckel12]

@jaymal66 I'm also the author of LuaTelemetry https://github.com/iNavFlight/LuaTelemetry and I'm interested in making the S.Port telemetry and Lua script flight screen useful to both fixed wing and multi-prop crafts. Not having fixed wing experience leaves me at a disadvantage. But, the goal is for both to be as supported as possible.

Feedback is appreciated.

[jaymal66]

What do you mean exactly by

“autotune was removed as a flight mode” ???

It’s still very much figures as a valid flight mode in the configurator and the doc and nothing to the contrary has been said elsewhere

From: Tim Eckel [mailto:[email protected]]
Sent: Tuesday, October 17, 2017 1:21 AM
To: iNavFlight/inav [e-mail]
Cc: jaymal66 [e-mail]; Mention [e-mail]
Subject: Re: [iNavFlight/inav] Problem with the implementation of the smartport telemetry improvements (#2343)

@jaymal66 https://github.com/jaymal66 Actually, home reset was one of the features I just added. autotune was removed as a flight mode, which is why it was removed in smartport.c.

There's really no reason to create your own build. If there's certain flight modes that are important to fixed wing pilots, I'm sure they can be worked into INAV without the need for a custom build. I didn't remove anything from smartport.c, I simply added additional features.

Let me know what flight modes are really needed with telemetry (some modes are not that useful for telemetry but are more suited to OSD). And I'll see what I can do!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/2343#issuecomment-337071841 , or mute the thread https://github.com/notifications/unsubscribe-auth/AfTLWwvig9bpR0_5WtpAD0QQmZUABLb0ks5ss-TqgaJpZM4P51RA .

[teckel12]

@jaymal66 When I look at flight modes for OSD and telemetry autotune isn't listed. I wasn't saying that autotune mode was totally removed, just removed from S,Port telemetry. But anyway... I'm just trying to help, and willing to enhance the code to accommodate FW needs.

Autotune was removed from S.Port telemetry because it conflicted with passthru mode. This conflict has existed since Mar 20, 2017. I left it (even though it was flawed logic) but DzikuVx removed it because it was wrong and could lead to rollover problems. It was only added to avoid a compile error, but added incorrectly.

In any case, if you'd like my assistance, what FW flight modes are important for telemetry? I added home lock last night, so that's one off your list.

[jaymal66]

Tim, you can reached me directly at [email protected] [e-mail] . This would avoid the dreary 1 day turnaround between question and response through github

From: Tim Eckel [mailto:[email protected]]
Sent: Tuesday, October 17, 2017 4:19 PM
To: iNavFlight/inav [e-mail]
Cc: jaymal66 [e-mail]; Mention [e-mail]
Subject: Re: [iNavFlight/inav] Problem with the implementation of the smartport telemetry improvements (#2343)

@jaymal66 https://github.com/jaymal66 When I look at flight modes for OSD and telemetry autotune isn't listed. I wasn't saying that autotune mode was totally removed, just removed from S,Port telemetry. But anyway... I'm just trying to help, and willing to enhance the code to accommodate FW needs.

Autotune was removed from S.Port telemetry because it conflicted with passthru mode. This conflict has existed since Mar 20, 2017. I left it (even though it was flawed logic) but DzikuVx removed it because it was wrong and could lead to rollover problems. It was only added to avoid a compile error, but added incorrectly.

In any case, if you'd like my assistance, what FW flight modes are important for telemetry? I added home lock last night, so that's one off your list.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/iNavFlight/inav/issues/2343#issuecomment-337246354 , or mute the thread https://github.com/notifications/unsubscribe-auth/AfTLW8FwrgJ9_iotJMfYIxm3h18-jJWdks5stLcogaJpZM4P51RA .

[fiam]

@jaymal66 The point of GitHub issues is that others can follow the conversation and add their opinions and feedback.

[teckel12]

@jaymal66 I show at least 3 back and forths in the last day. I check email about once a week, instead of several times a day here. Maybe the problem is that you're using email? Your replies via email add a lot of garbage and I'm sure slow things down.

I would suggest you visit https://github.com/iNavFlight/inav/issues/2343 directly instead so it's not email-based and there can be a back and forth communication between any number of people many times a day. It will also greatly clean up your replies making them easier to read.

[jaymal66]

Well then add one which relates to the subject matter

From: Alberto García Hierro [mailto:[email protected]]
Sent: Tuesday, October 17, 2017 11:14 PM
To: iNavFlight/inav [e-mail]
Cc: jaymal66 [e-mail]; Mention [e-mail]
Subject: Re: [iNavFlight/inav] Problem with the implementation of the smartport telemetry improvements (#2343)

https://github.com/jaymal66 @jaymal66 The point of GitHub issues is that others can follow the conversation and add their opinions and feedback.

—
You are receiving this because you were mentioned.
Reply to this email directly, https://github.com/iNavFlight/inav/issues/2343#issuecomment-337373632 view it on GitHub, or https://github.com/notifications/unsubscribe-auth/AfTLWwcl5wvdjlDCay8Jr8iuvpUibCLYks5stRiPgaJpZM4P51RA mute the thread. https://github.com/notifications/beacon/AfTLW6uYtkO-TTEUu7dycLXtZfb4VuH-ks5stRiPgaJpZM4P51RA.gif

[teckel12]

@jaymal66 Add one what? Your issue with the manual has been corrected. I've also added Home Reset to S.Port telemetry. Auto tune was removed, but that's because it was added incorrectly a few months ago and could cause problems. If you'd like something FW specific added or there's a bug, YOU should open an issue as I don't have a FW to know what a FW folk would need.

I would consider THIS issue closed, if you'd like to open another that relates to something else, feel free and I'd love to help address the issue.

[jaymal66]

teckel12 fact is that github is organized as a forum and that email is optmized for direct and the combination of two would the best of the 2 worlds.
The garbage you refer to this is a "feature* of github , indeed the way github handles the actual email thread is abysmal ( not to impute to email) the same holds for the propagation delays incured by github and so on ..
However, enough of that ... if you don't want to use email so be it .

Regarding the actual subject matter ;

Thanks for the clarifications however , the role and repeating reference you
make to OSD is still subject to some misunderstanding I guess.

I do appreciate your offering to help. To dispense you attempting the impossible I however, reciprocally offered you to handle things myself ,-)
Indeed pushing my motorless FW requirement through in the present in INAV deeply (very understandably so) enshrined “ multi rotor first” mindset is to say the least unrealistic.

A point in case for this matter is the OSD confusion.r ,For high performance motorless thermal glider especially in the 2M class OSD is an absolute no go (footprint,drag and weight of the OSD embarked infrastructure). So here we need realistically to handle Auto_Tune not with OSD but using simply main stream telemetry based on builtin in RX - like SmartPort - to do the job .

I’ve already stated what I need to have : first priority being AutoTune+Servo autotrim and as a nice to have Home Reset
What on the contrary is totally useless for motorless FW are the now included Position Hold ,Altitude Hold mode which are relevant only for multi rotors or motorized FW

So how do we proceed from here ?

[fiam]

@jaymal66 Please, behave yourself and stop asking other for features like they were your employees.

As @teckel12 has pointed out, this issue is now fixed so I’m closing it.

[jaymal66]

Well everything for me is very much still open ..since the real stuff the auto-tune and servo autotrim is still missing
On the other hand if you fell that everything has been said and done close it.
it is up to you

[jaymal66]

The behaviour of fiam is outrageous

[jaymal66]

@teckel12 I urge you to reopen the issue closed arbitrarily by fiam hurling out of the void preposterous ad hominem offenses !

[digitalentity]

@jaymal66 Please mind your attitude. You were answered in another issue that Smartport is favoring modes that require confirmation to make pilot aware if they are enabled.

Regarding your issue with flight mode reporting. This is open source software. You are free to fork it and change it in any way you like. Nobody here is in any way obliged to implement stuff that only you out of whole 30k users would need.

[jaymal66]

@digitalentity please don't rely on second hand fabrications (as abusively propagated by @fiam) and rather stick to the facts by checking yourself what actually has been said

Fact1 : I never asked that anyone in INAV to implement what I need but on the contrary stated repeatedly that i would make myself the modification in smartport.c my make my own custom firmware
here is one of the e verbatim:
_I will therefore adapt myself smartport.c to my own needs and implement them via a custom make._

Fact2 : It is @teckel12 who indeed - certainly to your surprise - suggested that it would make more sense to have him make the required changes. here is his verbatim:
_There's really no reason to create your own build. If there's certain flight modes that are important to fixed wing pilots, I'm sure they can be worked into INAV without the need for a custom build. I didn't remove anything from smartport.c, I simply added additional features._

So If anyone needs to mind his attitude and doings it's actually @fiam

Regarding what you stated elsewhere on the same topic
_Re LAUNCH mode - it's not pre-conditioned by anything. If you flip the switch when machine is disarmed and then arm - it will activate._

that is to activate the LAUNCH MODE as you state yourself requires to ARM the Target first which means simply and clearly that the Launch Mode is preconditioned by the ARM state ;-)

I'll concede on the other hand that indeed- I was wrong and you right regarding Turn Assist being a mode with no preconditions