There is quite big gap between unpowered stick and zeros for all forces. I think that the minimum centering force is too much for the most helicopters.

32 minutes ago, Kassu62 said:

There is quite big gap between unpowered stick and zeros for all forces. I think that the minimum centering force is too much for the most helicopters.

Yeah I have never flown helos in the sim so have zero clue on what's right or wrong here, or even how to set it up for a helicopter! 

Happy to tweak stuff if you know how to do it.. if you can tune a profile that is mostly ok on a helicopter and send it to me, i can investigate 

Very close to launch! Just trying to track down an annoying crash that is affecting ~5% of users on windows. Once that's fixed, v1.0 should formally launch. But it's pretty much at a 1.0 state for the majority of people, so go ahead and try it out. Even if you don't have the stick, I would very much appreciate feedback on the total user experience, from the website to the email to the download to the actual app. 

And of course, it is, and will remain, totally free. My website is  built with a very strong emphasis on privacy. Basically, I built the app, website, and support experience that I would like. 

I'm glad I have been able to contribute in a positive way to the flight sim community. I've had a lot of fun with this project, and have many ideas for new products with the same level of polish, ease of use, great documentation... and generally, that feeling of quality. And first class Linux + Windows + MacOs support. That's the goal for any new app I create 🙂

I got a lot of feedback from many of you, and that was very very encouraging. Thank you all!

https://ffb-bridge.com

For those who had crashes - try a different USB port. Try plugging directly into your motherboard, try different ports. A user reported success with a simple replug into a new port - the crash went away and it all works great

Update : new beta build out that hopefully fixes that crash issue. Get it at https://ffb-bridge.com

New test build for the crashing issue. 
https://ffb-bridge.com/dl/diag/h-ZksejgFxSrxiwJeBUan5wlJw8SjC5XE0nAlX1f5io

Another build - http://ffb-bridge.com/dl/diag/854r5k4Sz_63L98vHq0eTc6EuWlskWY_ACcd894OiKE 

old one revoked. 

I’m still tackling that one last crash before launch .. plus one new feature. 

Crashing? Try this

I created a testing program that runs and generates a report that you can email to me. It’s a command line program that runs through a bunch of tests and creates a zip file with details about the stick. The same files are saved to the desktop as well, including a .html file you can open and read. same contents as the text file and the json file. feel free to read them all, no PII or anything in there.

Send me the full zip - [email protected]

https://ffb-bridge.com/dl/diag/HvvBHf774Zp98Z-kenMkf__KY_BnsepkCDvqZubGd1Y

 

BTW the new feature is Stick Trim alt mode.. tuning that up now, but will launch tomorrow 🙂

 FFB-Bridge 1.0.0-beta.8 is out.

Hey all,

This is a pretty big release, so fingers crossed it goes well!

Thank you for your patience with the crashes. I spent a long time trying to figure it out, and eventually I think it's been solved. This involved a major change to how the forces are modeled - more below.

In addition to that fix, this beta also brings in a much requested feature - Stick Trim Relief. Thank you to the user who suggested it. Your detailed email and superb feedback really made this possible.

TrimRelief — alternate trim mode. A new way to model how trim and stick force interact. With TrimRelief on, the airspeed-loaded force is computed against (elevator − trim) and the spring centre tracks trim with full authority. The felt result: at a trimmed steady state with neutral stick,zero force — and release the stick and it holds at the trimmed position the way a real cable-rigged stick does. Off by default; existing profiles and the legacy TrimFeel behaviour are untouched. Toggle on the Tuning page under Stick feel.

Software-blended periodics is the new default for fresh installs.

A small but real share of FFB2 stacks crash inside Microsoft's pid.dll when the bridge allocates its full seventeen-effect retained table — the firmware can't fit it. Software blending sidesteps the cap entirely: the bridge allocates only the four mandatory hardware effects and synthesises every periodic, one-shot, and buffet in C# at 200 Hz, folding the result into the constant-force outputs.

Every effect plays concurrently regardless of how few slots your firmware actually allows. Existing users keep their previous mode; if you'd like to try hardware periodics, the Doctor page now has a Test hardware effects button that runs a probe in a separate process — a probe crash leaves the bridge intact and tells you what happened on relaunch.

Other fixes.

Effects no longer play out their full 32-second firmware duration when you quit the bridge mid-flight. The shutdown path now sends a driver-level STOPALL before releasing the device.

Native crashes inside the driver no longer abandon live effects. The exception handler hits the device with STOPALL + RESET + Unacquire before the process dies, so the next launch starts from a clean state.

Stick stays firmly centred in every non-driving state — disarm, paused sim, sim main menu, FAULTED, quit. Limp stick was a beta.7 regression; back to firm now.

Crash-report dialog now offers a one-click Switch to software-blended periodics when the report mentions pid.dll or CreateEffect.

If you've been running with FFB_BRIDGE_MAX_EFFECTS=5 as a workaround from beta.7 — you can drop that variable now. Software blending dominates it (4 hardware effects vs 5, every effect playing vs only the loudest). Existing MaxEffectCount values in hardware.json auto-migrate on first launch.

 

https://ffb-bridge.com

Would love to know if the crashes are fixed @spilok and @DD_Arthur

New beta - https://ffb-bridge.com

Beta.9 is out. This is a focused stability release that (finally!) fixes the crash several of you reported on beta.8 and brings hardware-mode FFB back as the default.

What changed

• Hardware-mode FFB is the default again. Beta.8 forced everyone onto software-blended periodics defensively, because the crash above was harder to hit in blending mode. It was a race condition issue. With the COM race fixed, hardware mode is the better path — lower latency, firmware-generated waveforms, zero CPU-side synthesis. Existing users who were on blending only because beta.8 put them there are migrated to hardware mode once on first launch.

• If you genuinely prefer software blending, Doctor > Hardware compatibility still has the toggle and your choice will stick. The auto-migration only runs once per build.

As always

If anything misbehaves, hit Send feedback in the app — it bundles the session log + a crash dump (if any) and opens your mail client pre-filled. Replies come back from [email protected].

Thanks for sticking with the beta. If this crash is truly fixed, we are on a clear path to launch. I will then work on polish, adding profiles, things like that.

 

Dev update - the app is mostly working well now, with some rare random crashes that I’m tracing down as reports come in. You can help by submitting reports if it happens to you.

I am now turning my attention to production hardening on the code, interface cleanup, UI/UX improvements and so on. No more new features now.. freezing the feature set for 1.0 unless there’s a major reason to make a change.

The focus now is entirely on making sure the code is production ready and the experience is more polished. The app works, but is a bit “heavy” on the interface, some pages have too much text, some need cleanup…. etc.

Keep those feedback reports coming! help me trace down any final bugs.

I see there are a few people that put their email in but didn’t confirm the download, then tried another email and still didn’t download. I will not (cannot, by law) contact you via email until you confirm the link in your inbox - I have double opt-in as standard.

However, if you are a real person trying to download my software, and there’s some bug in my email send causing you not to get the email, I want to know about it. Contact me via PM here if you want me to investigate.

The person I’m referring to has an email that starts with

al<snip>@gmail

and the second email they tried was a.k<snip>@aero<snip>

If this is you.. contact me via PM on this forum and I’ll investigate 

Beta 10. just get it. 🙂

https://ffb-bridge.com