Very happy to hear any updates on progress. IMO, this release is a really big deal and it needs to be right. Support for quality external FBL based governors is a paradigm shift in the industry. And places new demands on the ESCs.

Originally Posted by pitchfella

Hmmh, testing since october and still alpha

http://www.rcgroups.com/forums/showp...&postcount=136

The first versions must have been really bad news.

Either that or nearly everything there went on hold for the ICE HV recall, as they write. I tend to think this is the case.

Scott

Originally Posted by dunkonu23

Either that or nearly everything there went on hold for the ICE HV recall, as they write. I tend to think this is the case.

Scott

I sure hope that they don’t have the assembly line folks writing code in their spare time – LOL.

Well, they do have an opening for a programmer...

Scott

Hi guys. Any news on the new alpha release? Any chance we'll see a beta release this month?

CURRENT CASTLE LINK VERSION: 3.50.20
RELEASE DATE: 02-22-12


It's available now

http://www.castlecreations.com/downloads.html

YES!!!!!!!!!!!!!!!!!!!!!!!

Thanks Patrick!

Originally Posted by Patrick del Castillo

CURRENT CASTLE LINK VERSION: 3.50.20
RELEASE DATE: 02-22-12


It's available now

http://www.castlecreations.com/downloads.html

Patrick,
Looking at the release notes and the 3.50.20 Castle link, I don't see external governor mode mentioned? What am I missing?

I'm running demo mode. Maybe I need to be connected to a 4.0 ESC? Is there a way to force demo mode to run in 4.0 mode?

Can you point out some devices that will have Castle link live support?


All: Full 'CastleLink Live' support. This is a special mode that will allow the ESC to share telemetry data through the receiver wire in real-time to external devices that support 'Castle Link Live'.
All: Voltage cutoff option: RPM Reduction Cutoff: In governor mode this option will reduce your headspeed by 25%. In airplane mode, it will reduce your full throttle position by 25%.
All: Voltage cutoff option: Pulse Cutoff: In governor mode this option will slowly pulse the headspeed causing a slight tail twitch. In airplane mode, it will chop throttle momentarily making an audible change in prop RPM.
All: Increased power handling before loss of commutation on high inductance motors
All: Reduction of the power jump from 99% throttle to 100% throttle.
All: ESC now supports, and USES, high frequency receiver pulses (100+ hz). In previous versions of firmware, receiver input was processed at 50hz.
All: Firmware further optimized to spread the CPU load. This should result in better timing at high electrical RPM's.
All: Throttle is increased quicker when motor is not starting well. This reduces the time some motors take to start under load.
All: New motor running technique reduces controller heat and optimizes heatsink efficiency.
Phoenix HV/Phoenix ICE HV: Reduced maximum power level used when trying to start a stalled motor. This makes ESC damage less likely.
Phoenix 10/Thunderbird: Significant improvement of starting performance with outrunner type motors.
Heli: New governor mode with increased RPM holding precision. This should improve governing, especially on high electrical RPM setups.
Heli: New initial spool-up behavior. It should reduce the RPM overshoot during your initial (from a stop) spool-up.
Heli: When running governor mode and a fixed PWM rate (say 12 Khz), increase in output power during full throttle situations.
MultiRotor: New Multi-rotor vehicle type changes throttle response to allow for faster throttle response. Throttle processing has been completely rewritten to prevent aliasing of the throttle while limiting motor output throttle change rate.
Bug Fix: A bug was fixed that caused inappropriate power reduction on motors running right around 120,000 electrical RPM.

Looks like it's not included. If this is true that is sooo lame
Was waiting for this update but now it's clear I'm selling this thing and getting a ESC that works with my vbar. It's blue and made in china

I won't re-post what was said on the freak forum, but this is a big let-down. I can't blame you for making your esc's more reliable...lord knows we've seen enough posts...but after a year of anticipation, this was a massive disappointment for v-bar users.

I know myself, and many others, will be considering making the switch to other brands. I also know that, in the grand scheme of things, disappointing a select group of users was a necessary risk in order to hopefully satisfy the larger group of users.

However, I don't agree with making a promise to your clientele and NOT FOLLOWING THROUGH WITH IT!

Originally Posted by Rexaholic

I won't re-post what was said on the freak forum, but this is a big let-down. I can't blame you for making your esc's more reliable...lord knows we've seen enough posts...but after a year of anticipation, this was a massive disappointment for v-bar users.

I know myself, and many others, will be considering making the switch to other brands. I also know that, in the grand scheme of things, disappointing a select group of users was a necessary risk in order to hopefully satisfy the larger group of users.

However, I don't agree with making a promise to your clientele and NOT FOLLOWING THROUGH WITH IT!

Well -- this is the issue --

Most VBars use an external RPM sensor.

Most of the available RPM sensors on the market don't work with Castle ESCs.

It's not the VBar, or supporting the VBar -- it's the RPM sensor that doesn't work.

We are working with the VBar manufacturers for a work-around.


With an RPM sensor that works correctly with a Castle ESC -- this is the change that makes everything work:

ESC now supports, and USES, high frequency receiver pulses (100+ hz). In previous versions of firmware, receiver input was processed at 50hz.

Oops. I'm slightly embarrassed for starting the Helifreak thread which has now quickly turned into a bash thread.

Any chance you guys can produce your own rpm sensor to address the issue?

Originally Posted by OnTheSnap

Oops. I'm slightly embarrassed for starting the Helifreak thread which has now quickly turned into a bash thread.

Any chance you guys can produce your own rpm sensor to address the issue?

Yes -- and we are working with other manufacturers to change their RPM sensors so they work correctly.

Thanx!

Patrick

Originally Posted by Patrick del Castillo

Yes -- and we are working with other manufacturers to change their RPM sensors so they work correctly.

Thanx!

Patrick

Great! This is good news. Any chance the new feature - 'CastleLink Live' can send RPM data to a vBar and remove the need for an RPM sensor? Or is this not its intended purpose?

For us hackers, please post any home brew ways to make existing sensors work.