Vector Feature Requests - Page 81 - RC Groups
Thread Tools
This thread is privately moderated by JohnET, who may elect to delete unwanted replies.
Mar 09, 2017, 09:40 AM
I'd be mad without a Taranis!
Originally Posted by HugoRogers
Yeah, this is a big deal for me.

I have submitted this as a feature request a while ago, and like all the feature requests it dissappeared into a hole, with a comment to the effect of we will add it to a list and then maybe consider whether will will add it.

After that nothing gets heard of feature requests, it would be nice to hear if a simple way of incorporating trims is on the cards. There is currently only one way of doing this from the air (menus), and this is not only impractical, it is not possible when you are bound by laws which require a spotter to remain LOS with the aircraft. It can fly hundreds of metres carrying out this function, and it is very hard to do for that reason.

It is true that given the ergonomic limits of a transmitter to deal with, it must be difficult to come up with a truly positive user experience. However there are much better ways of doing this. A single toggle on an Aux channel is one way, which can be done from a dedicated switch, or even, if you insist on forcing end users to use configuration menus for a main stream function, why oh why is it not at the top level menu rather than buried inside a submenu.

In (User) Interaction Design, one key measure of ease of use is the number of user inputs needed to achieve an objective.
Incorporate trims from the air goes like this :

4 to get the main menu up
about 7 to select the sub menu,
about another 2 to select the function
another 1 to invoke it and
another 2 two to accept with a toggle.

That is about 16 inputs. That is 15 too many!

Please let us know if you intend to address this.
As an opposing view, I have no problem with the way it's currently done.
Sign up now
to remove ads between posts
Mar 10, 2017, 12:27 PM
Registered User

Any info on how to get vector, x4rsb and trinity headtracker working through sbus

Hi people

I'm having problems getting all three of the above working together with the vector in sbus configuration, could anyone point me in the right direction, have tried to use x4r and 2 & 3 on x4r and 9 & 10 on Tara is x9d+ and can't get all three working independently, any one got this configuration working as should that can help me out?


Mar 13, 2017, 01:46 PM
Registered User
I would like to see a way to update the way points through Droid planner and Dragonlink v3 on the fly withought having to hook up a usb.
Mar 14, 2017, 05:28 PM
I'd be mad without a Taranis!
I would like the option to have waypoint navigation continue if a loss in RSSI occurs, rather than RTH engaging.
Mar 16, 2017, 10:52 AM
paulskyone's Avatar
Good Morning John<

This is Paul Kaup with STEM+C. Desperately trying to get the altitude readout fixed for our Spaceport Project. This is the last technical item that needs to be addressed. I would be willing to pay a software engineer to work on this for me. Please give me a call if you can...

I used the Vector OSD for a very high altitude project in the spring of 2016.
There were some minor issues with the Altitude readouts.

The above sea level altitude readout would reset every 21,500ft and then go back to "0" and reset the altitude information.

The ladder display would only read out through 9999ft and then would reset to "0".

Is there anyway that an Eagle Tree software engineer could address this issue?
We will be using the Vector system this spring 2017, April 29, 30, in a project at Spaceport New Mexico.
It would be really nice to get the software re-wriiten in order to display the altitude information.

I have everything video captured.

I have a full review on my web-page of the Vector.

Over all the Vector performed well.
The only issue was the altitude information.

Mar 19, 2017, 03:26 PM
Registered User
Allow an Aux channel to control the camera and vtx power on/off.
Mar 31, 2017, 10:43 PM
billpa's Avatar
All, there have been several requests here for fixed wing "closed loop" speed features, and we've just posted a beta version with support for this.

Details below - let us know your thoughts!
Mar 31, 2017, 11:44 PM
s'like freakin' NASA in there.
Jmel's Avatar
Looks good so far... will test Sunday. GE feature looks good, maybe I can use it as a sort of offline map for now.
Apr 01, 2017, 11:20 AM
s'like freakin' NASA in there.
Jmel's Avatar
Any chance we can get the option to reverse gain knob direction?
Apr 01, 2017, 09:38 PM
Registered User
I think it's called channel reverse in your transmitter
Apr 01, 2017, 10:22 PM
s'like freakin' NASA in there.
Jmel's Avatar
Originally Posted by garris2
I think it's called channel reverse in your transmitter
Snarky - but the situation I have doesn't allow for that.

I use a 6 channel tx, and a dragonlink attached that gives me another 3 channels. I can't reverse the channel in the dragonlink. I've asked them too.

This is a very simple request, and I think it's not that far fetched to enable this in the software.
Apr 02, 2017, 05:33 AM
Registered User
wazoo22's Avatar
Originally Posted by billpa
All, there have been several requests here for fixed wing "closed loop" speed features, and we've just posted a beta version with support for this.

Details below - let us know your thoughts!
Just downloaded the Beta and read the manual.
I'm one of those who have been asking for more robust use of the pitot data, and am very glad for this feature to finally arrive.
Reading the manual, however, illustrates, once again, how things that seem to be fairly simple turn out to be a lot more complex than first thought would suggest. I am chastened.
Thanks for this option, finally.
Apr 02, 2017, 12:36 PM
because rust never sleeps....
HugoRogers's Avatar
Originally Posted by billpa
All, there have been several requests here for fixed wing "closed loop" speed features, and we've just posted a beta version with support for this.

Details below - let us know your thoughts!
Thank you for this update.

I am a pitot user and would use airspeed over GPS. I understand the difficulties in deducing failure modes in the airspeed transducer *during* flight. However the fact that there is no fall back, should I hit a cloud of insects which blocks my pitot probe means that I would just rather not take the risk. I would possibly use GPS, or in fact just leave it to Cruise/Climb settings to sort out a general, progressive speed which does not stall the wing.

Not meaning to sound negative about this feature, just replying to your request for feedback.
Apr 03, 2017, 08:07 AM
because rust never sleeps....
HugoRogers's Avatar
Would it be possible to invoke Google Maps in a web browser from the application, with the downloaded flight data, so that the flight path view shown on the Google Flight Map tab can instead be shown with :

a) a squarer aspect ratio, and
b) full screen.

The current offering is really nice, but is a bit too "letter box".

Apr 04, 2017, 10:46 AM
FPV guru
evensis's Avatar
Stall sensing feature. Now full scales have this as we all well know, but my thoughts around this would require the pitot tube sensor (then we know absolute airspeed) and using the sensors in the vector to know when a stall event is happening. I.e, no input, speed is slow and all of sudden a wing drops. G sensor would pick this up. Or progressively losing altitude from a neutral held altitude as a result of reduced lift from being underspeed. I can appreciate this would need to be an in air calibration so would need to be tied to the toggle on the mode switch. Could also tie into the Vectors voice system, shouting out "stall"! Would be pretty cool!

My main reason behind this, was I had a fly away last year, I had tested RTH from a small distance away everything seemed fine. However, on the particular day there was not a lot of wind, and had a complete loss of video signal ~9km out. First port of call was the RTH switch, waited for 15 minutes or so, and she never turned up again. Long story short, a farmer found it in one piece (!!!) in one of his fields a month later, a bit water damaged from being out in the elements for so long and one very dead cell in the LIPO but will fly again thankfully. Unfortunately, I could never get the logging data out of the Vector to find out what exactly happened, which was particularly irritating so can only theorise as to what went wrong. Lots of thought experiments later, i've more or less come to the conclusion that the model was in a progressive stall where it gradually fell out of the sky under 'cruise' conditions,or the minimum ground speed setting was too low. Nether the less, it was a gradual fall out of the sky, as the model was relatively unscathed (literally only damage was a control horn had snapped which held on the camera). Had plenty of GPS at the time as well so can count out failure of GPS too.

Now i'm wondering, since you've implemented the close loop system for air speed control you're more or less halfway there already, and would be a bolt on. If the Vector knows the stall speed of the airframe, then the closed loop system can auto increase motor speed to compensate for the condition. A dumbed down version of this feature, would be the models operator doing the tests themselves, and manually inputting the stall speed of the airframe via the GUI or the OSD GUI, and the Vector prohibiting air speed from dropping down this low. Again, pitot tube only feature as GPS ground speed would not give the necessary data for this.

First one obviously being the most difficult to implement, with the secondary being substantially easier.

Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Idea Vector Feature Request Rick01 Eagle Tree Systems 2 Oct 13, 2014 06:16 AM
Discussion Vector Feature Request Rick01 Eagle Tree Systems 0 Dec 06, 2013 01:04 PM