maybe thats why i thought the feeling was gentile. i know it moved a little bit but might have just
maybe thats why i thought the feeling was gentile. i know it moved a little bit but might have just been from gusts or soemthing
Nif the autopilot uses trim, and the trim was moving, that would move the stick regardless of the autopilot mode.. but AP following works a little differently than trim following. The trim following uses the physical/virtual offsets you describe above. AP following is a lot simpler. It just enables a static spring force and tells the joystick to "follow the axis". Also possible it worked at one point and an update from A2A did something with the autopilot thats now using an L:Var or something
Boh alright, that explains it.. relevant L:Var is ApMode if that helps
NIts great these guys are able to do all sorts of cool stuff internally with L:Vars and all.. but I wish they would copy values to standard simvars where applicable... I'll have to see if I can come up with a way to do dynamic simvar subscription based on aircraft. Not looking to start subscribing to every random L:var different planes use and putting a bunch of ifs in the code for specific aircraft...
BYeah its a real pain trying to set up LED profiles for my virpil stuff, got pretty good in searching and finding LVARs this way. The Comanches Autopilot has four states, which is why they use a custom LVAR i'm guessing.
MHey, A2A dev here. Unfortunately sometimes weird things happen when we drive those simvars, or sometimes we can't set them at all as there are limits in the sdk. But I'm open to suggestions for improvements.
MIn the case of autopilot, it's fully custom as the stock MSFS code is unsuitable for this model. One thing I'm aware that doesn't play well with FFB on our end, is the automatic disconnect when the joystick is deflected above the threshold (75% defletion)
N1.) Its awesome that your here and that you have a Rhino.. I wish more devs did, and had FFB in mind when working on their aircraft, even if the sim doesn't provide any framework for it.
2.) I meant no disrespect and I do understand how limiting the SDK is in a lot of cases. The FlyInside guys, for example, have to do some really awkward things to keep their flight model separate from the native helicopter flight model.
2.) I meant no disrespect and I do understand how limiting the SDK is in a lot of cases. The FlyInside guys, for example, have to do some really awkward things to keep their flight model separate from the native helicopter flight model.
N3.) It would be really cool to develop some custom secret sauce for FFB between the aircraft and TelemFFB so that it could not only understand the autopilot, but the aircraft could also understand when the axis movement is in response to the autopilot, vs the user actually deflecting the controls
MNo worries, I understand it can be frustrating when you try to write a software that works with every aircraft out there. On our end, we have to deal with at least three separate FFB implementations (Brunner, Xpforce, Vpforce) and each of them has different logic, simvars dependencies and own set of issues, lol.
MI haven't yet tested my VPforce in MSFS, as other developments had higher priorities, but I hope that at least I'll be able to improve our FFB compatibility when working on the next aircraft.
BI have been away for a while for various reasons. Today I'm back in the saddle (cockpit?) and am trying to get the HPG integration working. I have disabled the cyclic axes in MSFS and enabled axis control and the FTR and FT reset buttons on my stick. When I move the stick, the cyclic in the game does not move. I must be doing something dumb -- any ideas?
NMake sure you’ve got enough spring force enabled on the joystick that it can properly center. TelemFFB won’t start sending axis position until it initializes (centers) the joystick.
BNovember 4 8 1 you are Da Man. That was it! Thanks for the quick reply.
BWell shucky darn, I'm having what appears to be the same issue with the H160, Build 57. TelemFFB looks just like the screenshot above, spring is enabled in the Configurator... ?? (Same Rhino/stick config in MSFS that I used with the H145.)
NI haven’t tested the latest dev builds, but I assume they still work or else @exil35 would let me know.
Don’t forget to set up the trim release binding for the 160, too (msfs icon will be a red x while sim is unpaused if it’s not set).
There’s new in-sim settings for the newer versions related to setting up for FFB support https://davux.com/docs/h145/SETTINGS.html#setup-v2
Other than that, the 145/160 work the same way.
Don’t forget to set up the trim release binding for the 160, too (msfs icon will be a red x while sim is unpaused if it’s not set).
There’s new in-sim settings for the newer versions related to setting up for FFB support https://davux.com/docs/h145/SETTINGS.html#setup-v2
Other than that, the 145/160 work the same way.
BThank you. I'll check things tomorrow. I didn't realize the trim release stuff was specific to each aircraft.
NNo problem. I need to make it so the “red x” persists even after you pause. Otherwise you don’t know anything is wrong if you pause the sim before looking at the TelemFFB window 
EI haven't been able to try the latest 160 build but if it works for the 145 it should work for the 160 as well.
Are you sure you are on "none" and "hardware" on the 160 tablet as well?
Are you sure you are on "none" and "hardware" on the 160 tablet as well?
BI completely forgot to check that. Thank you!
CAt some point in the past I think I set up my rhino to have a forward offset center point. Today, I rotated my base 180deg to get better clearance with my SimFab chair (brilliant idea I stole from someone here). For the life of me though, I can't remember how to reset or flip the offset.
CI figured I had just done it with endstops and axis rescale, but resetting that does nothing.
CAww heck, disregard, I figured it out. It was because I was in a DCS aircraft and it was applying a new center point.
WThis may seem like an odd question, but I have a neurological condition that requires I ask this.
Can and how would the Rhino counteract an ~8hz oscillation of input with an amplitude of +/- 10 to 15% of the intended input force? Does it have the ability to smooth/dampen that level of variation of force input?
In a mechanical dampener system this would be smoothed out by the resistance induced by the flow of hydraulic fluid... how would/could the servo coding be adjusted to mimic that dampening effect?
Can and how would the Rhino counteract an ~8hz oscillation of input with an amplitude of +/- 10 to 15% of the intended input force? Does it have the ability to smooth/dampen that level of variation of force input?
In a mechanical dampener system this would be smoothed out by the resistance induced by the flow of hydraulic fluid... how would/could the servo coding be adjusted to mimic that dampening effect?
TThere are dampening and friction effects that can be tuned by the user. This is then all done via electronics rather than by hydraulic fluids like you mentioned. As far as your use case, it’s hard to say how well it could manage those oscillations but from my experience the dampening and friction can truly be felt and tuned so I think it is possible.
TWith no feedback from a game or in games that have no feedback implemented the Rhino behaves like a standard spring stick but has all the features of the other high end bases out there in terms of tuneability for friction, dampening, etc. So you could crank the dampening up to help with the oscillations. Maybe also crank the spring down so you have less force needed to push the stick to the required deflections.
TYou would ultimately end up tuning for your needs but hopefully that helps show how things could be adjusted.
WFor what it's worth I was thinking if it couldn't mimic it through code, it could be done with a 2 axis hydraulic dampening using something like 1/12 scale RC offroad truck dampeners mounted between a custom housing and the stick. Would be tricky to tune it, but might be fun to design regardless.
TThe dampening and friction effects built into the Rhino’s base software options would be equivalent to the 2 axis hydraulic dampening as you described. Much easier to tune though because it’s all done on a slider in the software rather than changing fluids/geometry of the physical dampeners
WI'm sure it would be easier to change via the software. But there are two questions my mind wants answered now.
1: Which would "feel" better.
2: Would a hydraulic dampener ease the momentary workload of the servo motor/controller and allow longer lifespan.
1: Which would "feel" better.
2: Would a hydraulic dampener ease the momentary workload of the servo motor/controller and allow longer lifespan.
WIf the software has to compensate 12 times a second for these input variances, there would be "some" delay in the compensation (probably not noticeable consciously), but it would also force the motor controllers to change their output 12 times a second putting possibly more wear on both controller and the motor.
A couple weeks of testing hydraulic flow dampening rates using various dampening disks might pay off in the long run when it comes to durability.
A couple weeks of testing hydraulic flow dampening rates using various dampening disks might pay off in the long run when it comes to durability.
WThe servo's lifespan isn't affected whether it has damping enabled or not. It's basically an axle with magnets riding on 2 bearings, no other surfaces make contact.
The software update loop runs at 1khz, so that's 1000 updates a second.
The software update loop runs at 1khz, so that's 1000 updates a second.
WAnd the controller sending power to the servo? Having to reverse current that often?
WIt's all solid state
MHi, is there any way to disable effect in vpforce telem app? I find annoying feature on high g turns, stick moves where g force vector goes. It's like inverted stick stiffness on high speed with warbirds. And I don't want to disable telem app, because it gives a lot good effects except this one
C@walmis I hooked up a 2kW 24V/80A power-supply to our rig as a main source. We have a DIY-FFB JS with two standard-motors 57BLF03, a DIY-FFB JS with 2x 86BLF04 and FFB-Rudder with 1x 86BLF04. Shure the JS will not be used together, but i stumbeled over the input-fields for the max-current. ive set them to 30A for all motors what is, mo my understanding, the limit of the driver. But the max-value for the PSU is limited to 25A. Does it make sense to allow a higher value like the 80A for our case as a fix for a next release?
BThat did it!! Thanks
EPerfect! 
NDid you try un-ticking the effect checkboxes in TelemFFB? I’d suggest starting with the one called “G Force”
OComments like this make me curious whether I’m running the right version of telemffb… mine has no checkboxes
SNewest WIP Version: https://vpforcecontrols.com/downloads/TelemFFB/?C=M;O=D
Stable Old Version: https://github.com/walmis/VPforce-TelemFFB/releases/tag/v1.0.0
Stable Old Version: https://github.com/walmis/VPforce-TelemFFB/releases/tag/v1.0.0
OAh that’d do it! I’m using stable
Mfound in config file, disabled deceleration force. That one was bugging me
NSorry, I have a tendency to assume everyone is running the wip version.. which greatly simplifies config management
Mi will try it thank you
thank you 
AFor the throw limiters available for purchase would a higher number mean more throw? I bought mine with the 11deg one but want to add more range. Should I order say a 14 or 15 degree one maybe both? Thanks
AIf I remember correctly the limiters are numbered by the degrees of travel
Aif you want to order a limiter but don't know exactly which one, maybe you can try to remove the one you have now, move the stick around (perhaps try the software limiters) to see where you'd like the limits to be, make note of the numbers and ask walmis what that means in degrees
OThere's a minor UI bug with the WIP version of TelemFFB - with windows desktop scaling set, some of the UI gets cut off
TI think I'm close with the HPG 145 setup, but it doesn't feel 100% yet. Could someone with a good config show me a screenshot of the configurator and TelemFFB? Been going through all the docs and searching in here...
SQuick question. I’m getting some noise in the pitch axis of my stick. Popping off the cover it seems to be a bit of a tolerance thing where the metal rod goes into the 3d print. I tried snugging up those 4 screws, but it still seems to be rubbing there or something. Any advice is appreciated!